Executive summary
Laguna S 2.1 is a 118B-parameter Mixture‑of‑Experts model. Poolside reports it activates roughly 8B parameters per token (~6.8% active), supports up to a 1, 000, 000‑token context, and offers a runtime “max thinking” mode that boosts long‑horizon coding performance at the cost of much higher completion‑token use. Poolside published weights (Hugging Face) and three unedited long trajectories. The numbers below are Poolside‑reported and tied to their harness and traces.
A compact explanation: MoE, sparse activation, and what “max thinking” means (and doesn’t)
Mixture‑of‑Experts (MoE) models keep many parameters in memory but route only a subset of experts to compute on each token. Poolside reports Laguna S 2.1 has 118B resident parameters and routes about 8B active parameters per token (~6.8% activation). That lets the model act like a much larger system while lowering per‑token compute.
Poolside calls “max thinking” a test‑time, higher‑compute reasoning mode. The reported effects are concrete: max thinking increases completion tokens per trajectory (for example, DeepSWE from ~99k to ~249k) and raises pass@1 on long‑horizon coding benchmarks. Poolside does not publish a low‑level recipe that proves whether max thinking mainly (a) activates more experts per token, (b) runs additional iterative self‑loops or agentic reasoning, (c) increases rollout or completion length, or (d) changes precision. Treat “max thinking” as a runtime compute budget increase that Poolside says trades cost and latency for stronger long‑horizon behavior.
Quick specs (Poolside‑reported)
- Model: Laguna S 2.1-118B total parameters (Mixture‑of‑Experts).
- Active per token: ~8B parameters (~6.8% active).
- Context window: up to 1, 000, 000 tokens (both thinking and no‑thinking modes).
- Weights & license: published on Hugging Face (poolside/Laguna‑S‑2.1) under OpenMDW‑1.1 (Linux Foundation Open Model, Data & Weights), Poolside‑reported.
- Quantizations/formats Poolside provides: BF16, FP8, INT4, NVFP4. Official GGUF and MLX conversions and DFlash draft models are available, Poolside‑reported.
- Deploy targets (Poolside‑reported): 4‑bit ~59 GB (NVFP4/INT4) fits on a single NVIDIA DGX Spark (128 GB). FP8 ~118 GB. BF16 ~236 GB.
- Training: pre‑training began 22 May 2026 on 4, 096 NVIDIA H200 GPUs. Poolside reports a training‑to‑launch interval under nine weeks.
- Reinforcement learning: Poolside reports this is the first Poolside model where RL ran in FP8 precision.
- Day‑one integrations / hosted options (Poolside‑reported): vLLM, SGLang, Ollama. Available via Baseten, Kilo, Prime Intellect (Prime Lab), ZML. Hosted via OpenRouter and other managed providers.
Benchmarks: headline gains and the price to pay
Poolside published pass@1 results across several coding benchmarks using their harness. Pass@1 measures the fraction of problems for which the model’s first generated solution is correct under the benchmark’s evaluation criteria. These are Poolside‑reported numbers and should be validated independently before using them to make procurement decisions.
- SWE‑Bench Multilingual: 78.5% (Poolside‑reported; shown as top of Poolside’s table).
- Terminal‑Bench 2.1: 70.2% with max thinking (60.4% with thinking off), Poolside‑reported.
- DeepSWE v1.1: 40.4% with max thinking (16.5% off). Poolside reports completion tokens per trajectory rising from ~99k to ~249k in thinking mode.
- SWE‑Bench Pro: 59.4% (Poolside‑reported).
- SWE Atlas (QnA): 46.2% (Poolside‑reported).
- Toolathlon Verified (tool use): 49.7% (Poolside‑reported; behind Muse Spark 1.1 at 75.6% in Poolside’s table).
Poolside’s EFFORT interactive data shows how much extra token work max thinking can demand. For example, Terminal‑Bench completion tokens rose from 80 to 129 in their interactive numbers, and DeepSWE trajectories jumped from about 99k to 249k completion tokens. The trade‑off is higher pass@1 on long problems at much greater runtime and token cost.
Context and caveats
- These results come from Poolside’s harness and evaluation pipeline. Independent replication under different prompt engineering, time budgets, or harnesses may yield different numbers.
- Benchmarks like pass@1 are useful comparators but sensitive to sampling, prompt tuning, and harnessed verification such as test suites, unit tests, or execution environments.
- Metrics that report completion‑token totals mix per‑example rollout length with cumulative trajectory work. When planning pilots, measure both per‑call latency and cumulative work per task.
Trajectories: three published long runs (Poolside‑reported)
Poolside published three unedited trajectories to show agentic, multi‑step behavior. They are demonstration traces and single runs. Reproduce them in your environment before treating them as robust evidence.
- Empty folder → HTML/CSS rendering engine: 181 steps over ~50 minutes, validated against headless Chromium with no human help (Poolside trace at trajectories.poolside.ai).
- Self‑optimization: a run that Poolside reports sped up their harness by +5.2% and reduced memory allocation by ~71% by replacing an O(n²) string concatenation with buffered operations, Poolside‑reported profiling details are in their trace.
- Offline math: a ~68‑minute trajectory that Poolside presents as an independent re‑derivation of Erdős Problem #397 in Perl. Poolside’s trace shows the steps, but independent mathematical verification is advisable.
Deployment economics and integration notes
Poolside positions Laguna S 2.1 for teams that want high agentic capability without the fixed cost of monolithic dense models. The raw numbers Poolside provides are useful planning inputs, but you should validate them in your infrastructure.
- 4‑bit deployment (Poolside‑reported): ~59 GB using INT4/NVFP4. Poolside reports this fits on a single NVIDIA DGX Spark (128 GB). Confirm the exact machine name and memory configuration with your vendor.
- FP8 and BF16 footprints (Poolside‑reported): FP8 ~118 GB (fits a Spark or single H200). BF16 ~236 GB (multi‑GPU).
- Hosted endpoints & pricing (Poolside‑cited): OpenRouter offers free access at 256K context and a dedicated 1M‑context endpoint with pricing Poolside cited. Verify current pricing on the provider’s pricing page before planning scale.
- Day‑one runtime support (Poolside‑reported): vLLM, SGLang, Ollama integrations and managed availability through Baseten, Kilo, Prime Intellect (Prime Lab), ZML.
Practical risks and what to validate before production
- Independent replication: re‑run Terminal‑Bench 2.1 or another representative workload with and without max thinking in your harness. Track pass@1, per‑call latency, and completion tokens. Poolside’s numbers are a baseline but not a guarantee.
- Cost modeling: measure end‑to‑end cost, including compute, storage, and API overhead, per workflow. Max thinking is a high‑cost mode. Treat it as an occasional escalation, not a default.
- Safety & sandboxing: agentic runs with tool access require strict controls: sandboxed file systems, network egress blocking, per‑agent RBAC, destructive‑action whitelists, and immutable audit logs.
- Drift and hallucination with long rollouts: very long contexts and iterative planning can compound hallucination or drift. Add validators, unit tests, and automated checks inside trajectories to limit silent failures.
- RL and training opacity: Poolside reports RL ran in FP8 but does not publish reward design, algorithms, or ablation studies. Expect unknowns in learned decision thresholds and risk behaviors.
Getting started: a pragmatic pilot plan
- Spin up the 4‑bit weights on your test node or use a managed 1M‑context endpoint and run a small suite: one short problem, one medium multi‑file synthesis, one long DeepSWE‑style trajectory. Measure pass@1, latency, and completion‑tokens per trajectory.
- Reproduce one of Poolside’s published trajectories, for example the empty‑folder HTML engine, in your harness to validate expected tool integrations and sandbox behavior.
- Implement minimal guardrails before agentic runs: read‑only production access, strict egress rules, and retained logs of decisions and tool calls for post‑mortems.
- Reserve max thinking for escalation paths. Add a cost‑aware policy that only enables max thinking after X failed attempts or for Y‑tier tasks.
“Pre-training began 22 May 2026 on 4, 096 NVIDIA H200 GPUs.”, Poolside (reported)
“It is the first Poolside model where reinforcement learning ran in FP8 precision.”, Poolside (reported)
Key takeaways, short questions and honest answers
- Can Laguna S 2.1 run on a single machine for production use?
Poolside reports a 4‑bit quantized deployment (~59 GB) that fits on a single NVIDIA DGX Spark (128 GB). Verify the exact machine name, memory configuration, and vendor compatibility in your environment before planning production rollout.
- Does “max thinking” actually improve performance?
Poolside‑reported results show notable lifts on long‑horizon coding benchmarks (for example, Terminal‑Bench 2.1 from 60.4% → 70.2%; DeepSWE from 16.5% → 40.4%), but those gains come with substantially higher completion‑token use and latency. Treat max thinking as a high‑cost, high‑value runtime option to be measured against your SLAs and budgets.
- Are the benchmark numbers independent?
No, the pass@1 figures and trajectories are Poolside‑reported and tied to their harness. Independent reproduction is required to confirm how Laguna S 2.1 performs in your tooling and test suites.
- Is this model suitable for building autonomous coding agents?
Yes, Poolside designed Laguna S 2.1 for agentic coding and published multi‑step trajectories showing autonomous planning, testing, and refactoring. That said, safe deployment requires sandboxing, strict controls on tool access, and observability of intermediate steps.
- How should businesses think about the cost vs. capability tradeoff?
Use the off/default mode for routine, latency‑sensitive tasks and reserve max thinking for complex, high‑value problems where the marginal benefit justifies the extra compute and token cost. Run dedicated pilots to quantify that tradeoff in your workloads.
Sparse MoE routing plus a programmable test‑time compute budget is a practical design choice. It can deliver much of the long‑horizon behavior teams want without forcing everyone to run massive dense models. Poolside’s Laguna S 2.1 is an explicit bet on that approach. It looks promising, the traces are demonstrable, and it is worth piloting for teams building autonomous developer assistants or long‑context automation. Validate the claims in your harness, plan for cost and safety, and treat “max thinking” as a tool in the toolbox rather than the default posture.