Laguna S 2.1 is poolside’s open-weight coding model, released on 21 July 2026 with weights on Hugging Face under the OpenMDW-1.1 license. It is a mixture-of-experts model at 118 billion total parameters with 8 billion active per token, and a context window of just over a million tokens.
The number that earns it attention is 70.2 percent on Terminal-Bench 2.1, which poolside reports beats open models roughly ten times its size. The claim that will get argued about is the marketing line: poolside describes it as the West’s most capable open-weight model. Both are worth testing rather than repeating, and both come with conditions the announcement does not lead with.
What Laguna S 2.1 actually is
The architecture is aggressively sparse. At 118 billion total parameters with only 8 billion active, roughly 7 percent of the model participates in any given token. That ratio is what makes the efficiency story work, and it is worth understanding correctly: sparsity reduces the arithmetic per token, not the memory needed to hold the model. Every expert still has to be resident, a point we worked through in detail in what self-hosting Kimi K3 actually costs.
The context window needs reading carefully. The model config sets a ceiling of 1,048,576 tokens, but it gets there by YaRN-scaling the full-attention layers 128 times from an 8,192-token base rather than by pretraining at that length. In practice you rarely get the full million: Ollama serves 256K on every tag, OpenRouter’s free endpoint serves 262,144 with a 32,768-token output cap, and only the paid OpenRouter endpoint exposes the whole window.
Two other details stand out. Pretraining began 22 May 2026 on 4,096 NVIDIA H200s and the model shipped under nine weeks later, with poolside’s press release putting the end-to-end training itself at under four weeks. Both figures are poolside’s own and neither has been independently audited. And the NVFP4 quantised weights, at roughly 71GB, fit on a single NVIDIA DGX Spark, the 128GB desktop-class machine.
That last detail is the practically interesting one, with a caveat the announcement skips. Most open-weight models making frontier-adjacent claims need a datacenter node. Laguna S 2.1 fits on a box you can put under a desk. But fitting is not the same as being pleasant to use: poolside’s own figures for that hardware are 600 to 800 tokens per second on prefill and around 15 per second on decode for prose, 22 to 24 for code, dropping to 13 or 14 without speculative decoding. That is workable for a background agent chewing through a queue and slow for anything interactive. Note too that only the quantised builds tell this story. The full BF16 checkpoint is roughly 236GB and still needs multiple GPUs.
What that 70.2 percent actually is
The headline benchmark needs the same treatment as the context window, because it is not a leaderboard result.
Poolside ran it themselves, on an internal fork of the Laude Institute’s Harbor framework using poolside’s own agent harness, capped at 500 steps with a five-hour timeout, reporting mean pass@1 averaged over four attempts per task. Laguna S 2.1 does not appear on the official Terminal-Bench 2.1 leaderboard, where the top entry is Claude Code paired with Fable 5 at 83.8 percent.
That is not an accusation. Vendors self-report constantly and poolside published its method, which is more than most do. But harness choice moves this benchmark by several points on its own, so a number produced on a custom fork is not comparable to a leaderboard entry, and it should not be read as one.
The "ten times its size" framing needs a similar qualifier. It holds against some of poolside’s comparison set and not others. Laguna outscores DeepSeek-V4-Pro Max, roughly 13 times its size, on most of the suite. But Kimi K3, around 24 times larger, scores 88.3 percent on Terminal-Bench 2.1 against Laguna’s 70.2, and Tencent Hy3 at only 2.5 times the size scores 71.7. Poolside’s own technical blog puts it more modestly than the press release does: the model "holds its own against models many times its size."
Availability
Weights are on Hugging Face under OpenMDW-1.1. The model is reachable through OpenRouter at $0.10 per million input tokens and $0.20 per million output, runs locally under Ollama and vLLM, and poolside ships its own agent CLI called pool.
That combination matters more than any benchmark. Weights plus a permissive license plus day-one support in the tools people already run is what makes an open release actually usable rather than notionally available.
The "most capable in the West" claim
This is vendor framing, and it should be read as vendor framing. It is also worth knowing where it appears: the phrase is the headline of poolside’s press release, and it turns up in neither the technical blog post nor the model card, both of which claim only best-in-weight-class. But there is a real observation underneath it.
The open-weight frontier has been overwhelmingly Chinese for over a year. Kimi K3 from Moonshot, GLM-5.2 from Zhipu, DeepSeek’s V4 line, Alibaba’s Qwen, and MiniMax all sit in that category. Western labs have largely kept their strongest models closed, with Meta’s flagship going proprietary and the most capable American models available only through APIs.
So Laguna S 2.1 is a genuine counterweight, and that is the honest version of the claim. Whether it is the most capable Western open-weight model depends on which capability and whose benchmark, and poolside has not published the kind of independent comparison that would settle it. Terminal-Bench 2.1 measures agentic terminal coding specifically, which is poolside’s home turf. A model can lead that benchmark and trail badly elsewhere.
Parameter count has never been a clean proxy for capability either, and beating a larger model on one benchmark is a normal outcome rather than a surprising one when the smaller model is trained for that task.
Who this is actually for
Three situations make Laguna S 2.1 worth evaluating.
You need a coding model that runs on hardware you own. If data governance rules out sending source code to a third-party API, an open-weight model that fits on one machine is a materially different proposition from one requiring a GPU cluster. This is the strongest case, provided you can live with the throughput.
You want to fine-tune on your own codebase. Open weights permit adaptation that an API forbids, and at 118 billion parameters with a permissive license this is tractable.
You are testing whether a smaller specialised model can replace a frontier API for routine work. Not every coding task needs the most capable model available, and the economics of a local model change sharply if it handles the bulk of your volume. Our comparison of Claude Code and OpenAI Codex covers what the hosted alternatives do well.
If none of those apply, a hosted frontier model will likely still produce better results on hard problems, and the operational overhead of running your own inference is real.
Frequently Asked Questions
What is Laguna S 2.1?
Laguna S 2.1 is an open-weight coding model released by poolside on 21 July 2026. It is a mixture-of-experts model with 118 billion total parameters and 8 billion active per token, with a context ceiling of 1,048,576 tokens reached by YaRN-scaling from an 8,192-token base. Weights are published on Hugging Face under the OpenMDW-1.1 license.
Can Laguna S 2.1 really run on one machine?
Yes, in its NVFP4 quantised form the weights are roughly 71GB and fit on a single NVIDIA DGX Spark, which carries 128GB of unified memory. The full BF16 checkpoint is around 236GB and does not. Expect poolside’s own reported throughput on that hardware: 600 to 800 tokens per second prefill, and 15 per second decode on prose or 22 to 24 on code with speculative decoding enabled, 13 to 14 without. Remember too that mixture-of-experts sparsity reduces compute per token, not the memory required, so all 118 billion parameters must stay resident.
Is it really the most capable Western open-weight model?
That is poolside’s own framing, it has not been independently verified, and it appears only in the headline of the press release rather than in the technical blog post or model card. The defensible version is narrower: the open-weight frontier has been dominated by Chinese labs, and Laguna S 2.1 is a genuine Western counterweight. Its headline benchmark, Terminal-Bench 2.1 at 70.2 percent, is self-reported on poolside’s own harness, is absent from the official leaderboard, and measures agentic terminal coding specifically, which is the company’s specialism rather than a general capability measure.
What license is it under?
OpenMDW-1.1, with weights hosted on Hugging Face. As with any open-weight release, read the actual license text before building commercially on it rather than relying on the announcement’s characterisation.
How do I run it?
It is available through OpenRouter for hosted access at $0.10 per million input tokens and $0.20 per million output, and runs locally under Ollama and vLLM. Poolside also ships its own agent CLI, `pool`. Day-one support in tools people already use is a meaningful part of what makes this release practical. Note that served context varies by path: 256K on Ollama, 262,144 on OpenRouter’s free endpoint, and the full window only on the paid one.
How does it compare to Kimi K3?
They are aimed at different situations. Kimi K3 is a 2.8-trillion-parameter model requiring Blackwell-class server hardware to self-host, competing at the general frontier. Laguna S 2.1 is a 118-billion-parameter coding specialist that fits on a single desktop-class machine. If you need broad frontier capability, K3 is the larger model; if you need a coding model on hardware you control, Laguna is far more practical.
What does 118B total and 8B active mean?
It is a mixture-of-experts design. The model holds 118 billion parameters, but a router activates only about 8 billion of them for any given token, so the arithmetic cost per token resembles a much smaller model. The memory cost does not shrink: any expert may be needed next, so all of them stay loaded.
Should we switch our coding workflow to it?
Only if you have a specific reason: data governance that rules out sending code to an external API, a need to fine-tune on your own codebase, or high enough routine volume that local inference changes the economics. For hard problems a hosted frontier model will likely still perform better, and running your own inference carries real operational overhead.
