Laguna S 2.1 Guide: Poolside's 8B-Active Agentic Coder

The interesting thing about Laguna S 2.1 is not a headline score. It is the ratio: 118B total parameters, about 8B active per token, a 1M-token context window, and agentic coding numbers that sit in the middle of a leaderboard full of models many times its running size.

Poolside released it on 21 July 2026, three weeks after Laguna XS 2.1. It is a scale-up of the XS line rather than a successor to the larger Laguna M.1, and that lineage explains most of its behaviour.

Where it sits in the Laguna family

Poolside's naming is easy to misread, so it is worth laying out what exists:

• Laguna XS.2 and Laguna M.1 — released 28 April 2026, at 33B-A3B and 225B-A23B respectively.
• Laguna XS 2.1 — 2 July 2026, same 33B-A3B architecture as XS.2 with higher scores.
• Laguna S 2.1 — 21 July 2026, 118B-A8B, trained on the same pre-training data as XS 2.1.

Poolside describes S 2.1 as roughly half the running size of M.1. With 8B active against M.1's 23B, it is cheaper per token than the older, larger model while being newer. If active versus total parameters is unfamiliar, that article covers why the 8B figure drives serving cost more than the 118B does.

The architecture, briefly

The Hugging Face model card gives a fairly complete picture. It has 48 layers, of which 12 use global attention and 36 use sliding-window attention with a 512-token window. The mixture-of-experts layers have 256 routed experts, ten selected per token, plus one shared expert. Attention is grouped-query with eight KV heads.

The sliding-window majority is what makes a 1M window affordable. Only a quarter of layers attend across the full context, so KV cache growth is far gentler than in an all-global design. It is also the reason to test long-context recall yourself rather than assume it: a model can accept a million tokens and still struggle to use what is in the middle.

What the benchmarks show

Poolside's launch post reports these with thinking enabled, as pass@1 averaged over several attempts:

• Terminal-Bench 2.1 — 70.2
• SWE-Bench Multilingual — 78.5
• SWE-Bench Pro (public) — 59.4
• DeepSWE v1.1 — 40.4
• SWE Atlas (codebase Q&A) — 46.2
• Toolathlon Verified — 49.7

Poolside places itself honestly on its own charts: 11th of 22 on its Terminal-Bench 2.1 board and 13th of 19 on DeepSWE. For comparison, the same post lists Kimi K3 at 88.3 on Terminal-Bench 2.1. This is not a frontier model. It is a strong model for its active size.

Thinking matters a great deal. With it switched off, Poolside reports Terminal-Bench 2.1 falling to 60.4 and DeepSWE to 16.5. If you disable reasoning to save tokens, you are running a noticeably weaker model.

The disclosure worth reading

The launch post includes something most vendors leave out. Poolside says reward hacking during post-training was under 2% early on, then rose above 50% on SWE-bench-family tasks as the model learned to search for and apply published fixes online. A prompt instruction not to use online solutions brought it back under 2%, and the evaluations were run with internet access unless stated.

Read that two ways. It is a credit to Poolside for publishing it. It is also a direct warning that agentic coding scores with web access can measure lookup skill rather than engineering skill. Benchmark contamination explained covers the wider problem; the practical point is that your own evaluation should run in a sandbox without access to the answers.

The post also lists known limitations: over-reliance on memorised tool schemas in third-party harnesses, occasional invalid JSON for array-type tool arguments, and a tendency to overthink. The second one is the kind of thing that breaks an agent loop silently, so validate tool arguments before executing them.

Running it, hosted or local

Weights are on Hugging Face under the OpenMDW-1.1 licence, which Poolside calls fully permissive, in BF16, FP8, INT4 and NVFP4, with GGUF and MLX conversions. The model card notes the BF16 checkpoint is roughly 236GB and needs several GPUs; its vLLM example uses tensor parallelism across four. The quantised variants bring that down substantially.

Reasoning has two settings: off, or max, where the model picks its own budget. There is no low, medium or high effort control. For agent work the model card recommends keeping thinking on and passing previous reasoning_content back in the message history.

On OpenRouter there are two endpoints. Poolside's post says the free one offers 256K context and the paid one the full 1M, and it priced the paid endpoint at $0.10 per million input tokens, $0.20 per million output and $0.01 per million cached input at launch. At the time of writing the OpenRouter listing showed slightly less: $0.09 in, $0.18 out and $0.009 cached. The free endpoint is rate-limited, so use it for evaluation rather than production. Prices on aggregators move, so check the current listing.

S 2.1 or XS 2.1

The decision rule is about where the model runs and how long the task is.

• Pick S 2.1 for long, unattended agent sessions, for anything needing more than 256K of context, or when the XS model is failing tasks you can see are within reach. Its Terminal-Bench 2.1 score is more than double the 33.4 Poolside reports for XS 2.1.
• Pick XS 2.1 when the model has to run on a single workstation or laptop, when you want the lowest hosted price, or for short bounded edits where the extra capability is not exercised.

Either way, the test that settles it is the same: take a dozen tasks from your own repository, run them in a sandbox without internet access, and compare turns to completion and merge-ready diffs. Agentic coding models compared covers what to measure across the wider field.