Introducing Laguna S 2.1
Table of contents
Punching above its weight class
Punching above its weight class
A closer look at DeepSWE
Evaluation methodology
Seeing the model work
Thinking effort
Limitations
What actually changed in this model
What actually changed in this model
A strong base, then new post-training
A strong base, then new post-training
Distribution of post-training tasks
Distribution of post-training tasks
What changed in the training loop
What changed in the training loop
The bets we're making
Three models in three months
Get started
Today we’re releasing Laguna S 2.1, a significant step forward in our development of models that pursue longer horizon work and make effective use of reasoning.
Laguna S 2.1 is a 118B total parameter Mixture-of-Experts (MoE) model with 8B activated parameters per token and supports a context window of up to 1M tokens in thinking and no-thinking modes. It went from the start of training to launch in under nine weeks, and on long-horizon coding benchmarks it holds its own against models many times its size. For every benchmark score we publish today, we are releasing full trajectories for every trial in the final evaluation set at trajectories.poolside.ai.
Laguna S 2.1 118B-A8B
Tencent Hy3 295B-A21B
Inkling 975B-A41B
Nemotron 3 Ultra 550B-A55B
DeepSeek-V4-Pro-Max 1.6T-A49B
Kimi K3 2.8T-A50B
Qwen 3.7 Max —
Muse Spark 1.1 —
Claude Fable 5 —
Terminal-Bench 2.1
SWE-Bench Multilingual
SWE-Bench Pro (Public Dataset)
DeepSWE
SWE Atlas (Codebase QnA)
Toolathlon Verified
Punching above its weight class
Laguna S 2.1 is, as far as we can measure, the most capable agentic coding model in its weight class by a wide margin.
S 2.1 scores 70.2% on Terminal-Bench 2.1 in our agent harness with thinking enabled. Its compact size makes it uniquely suitable for complex work on local machines.
Terminal-Bench 2.1 leaderboard
A ranked comparison of reported Terminal-Bench 2.1 scores.
Open weights
Closed / size undisclosed
1 GPT-5.6 Sol 88.8
2 Kimi K3 2.8T-A50B 88.3
3 Claude Fable 5 88.0
4 GPT-5.6 Terra 87.4
5 GPT-5.6 Luna 84.7
6 Claude Opus 4.8 84.6
7 Claude Sonnet 5 80.4
8 Muse Spark 1.1 80.0
9 Qwen-3.7 Max 74.5
10 Hy3 295B-A21B 71.7
11 Laguna S 2.1 118B-A8B 70.2
12 MiniMax M3 428B-A23B 66.0
13 DeepSeek-V4-Pro-Max 1600B-A49B 64.0
14 Inkling 975B-A41B 63.8
15 DeepSeek-V4-Flash-Max 284B-A13B 61.8
16 Nemotron 3 Ultra 550B-A55B 56.4
17 Inkling-Small 276B-A12B 52.7
18 Qwen3.6-27B 27B 51.3
19 Qwen3.6-35B-A3B 35B-A3B 44.9
20 Nemotron 3 Super 120B-A12B 38.6
21 Laguna XS 2.1 33B-A3B 33.4
22 Mistral Small 4 119B 21.4
Terminal-Bench 2.1 evaluates a wide, high-quality set of long-horizon tasks where an agent model is connected to its environment through a terminal. Laguna S 2.1 is a standout model in its size category on this benchmark.
Model size versus benchmark score
Scatter plot of disclosed total parameter count on a logarithmic axis against Terminal-Bench 2.1 score. Laguna S 2.1 is highlighted as a triangle.
Laguna S 2.1
Other Laguna
Other disclosed models
A closer look at DeepSWE
The benchmarks above are all meaningful, and we're glad to be close to the frontier on them. But part of that closeness is a property of maturing benchmarks: as the frontier advances, top scores cluster in the 70-90% range and models that behave very differently end up no more than a few points apart. Datacurve’s DeepSWE still has significant headroom. Its tasks are longer-horizon and hard to partially solve, and the scores actually spread: frontier models range from 54% to 73% on the v1.1 variant, with some 1T+ parameter open models scoring below 10%.
On DeepSWE v1.1, Laguna S 2.1 scores 40.4 in thinking mode in pool harness.
DeepSWE v1.1 leaderboard
A ranked comparison of reported DeepSWE scores.
Open weights
Closed / size undisclosed
1 GPT-5.6 Sol 73.0
2 Claude Fable 5 70.0
3 GPT-5.6 Terra 70.0
4 Kimi K3 2.8T-A50B 69.0
5 GPT-5.6 Luna 67.2
6 GPT-5.5 67.0
7 Claude Opus 4.8 59.0
8 Claude Sonnet 5 54.0
9 Grok 4.5 54.0
10 Muse Spark 1.1 53.3
11 GPT-5.4 52.0
12 GLM 5.2 753B-A40B 44.0
13 Laguna S 2.1 118B-A8B 40.4
14 Gemini 3.5 Flash 37.0
15 Kimi K2.7 Code 31.0
16 Claude Sonnet 4.6 30.0
17 Gemini 3.1 Pro 12.0
18 DeepSeek-V4-Pro-Max 1600B-A49B 9.0
19 Laguna XS 2.1 33B-A3B 0.3
It is worth noting that Laguna S 2.1 scored 40.4% in our agent harness, pool, not mini-swe-agent which DeepSWE’s leaderboard uses. For other models we report maximal over reported scores which for most models are the official leaderboard results reported by Datacurve. While this makes scores less comparable, we don’t believe it puts us in a particularly advantageous position as it’s been reported that many of the models score the same or better in mini-swe-agent compared to their native harnesses. Every trajectory in the final evaluation run is available here.
Evaluation methodology
Evaluation of agent models is notoriously difficult due to prevalence of reward hacking. We have previously written about reward hacking in leading benchmarks and our evaluations system and rigor as part of the technical report on our Laguna M.1 and XS.2 models. Recent work has focused on adversarial judging to increase reward hacking detection.
With this release, we are making all trajectories from our final evaluations of the published Laguna S 2.1 checkpoint available to view and download at trajectories.poolside.ai.
Seeing the model work
Benchmark scores give a quantitative view into the model behavior, but to get a better intuitive understanding of how the model works it’s useful to look into runs on real world tasks. We share three such tasks with unedited trajectories and commentary.
Case study 1
A browser engine from a blank folder
One of our favorite things about Laguna S 2.1 is its resourcefulness: It will find clever
ways to get to the goal even if the direct path is not available. We saw a great demonstration of
this when we asked it to build a browser engine from scratch; knowing it would be a challenge for
Laguna to verify its work given its lack of vision capabilities. In one 50-minute session of 181
steps, with no human intervention, Laguna S 2.1 built a working HTML/CSS rendering engine from an
empty folder, then proved it renders like a real browser by measuring itself against one.
Throughout its work, the model found increasingly complex ways to validate its work despite its
limitations, leading to running headless Chromium to read canvases back and comparing screenshots
numerically. See the full trajectory here.
Over the session the model built the full pipeline, parser → cascade → layout → renderer, in
vanilla JavaScript: an HTML tokenizer and DOM tree, a CSS parser with selector specificity, a
cascade engine with inheritance, box-model layout, and a canvas-2D renderer, wrapped in an app
that shows nine snippets on its own canvas beside the same markup in an iframe, so the hosting
browser sits right there as the reference.
Case study 2
Optimizing our own harness
Laguna S 2.1 is capable of pursuing meaningful engineering and research work. In one example, one
of our researchers pointed it at our agent harness, used for training/evaluation and user
interaction with our models. In an automated loop, Laguna S 2.1 made our harness 5.2% faster with
~70% lower memory allocation. See the full trajectory here.
For this task, we instrumented the harness with benchmarks so the model could see exactly where
the time and memory went. We set strict rules: one approach at a time, benchmark after every
change, keep only what measurably wins. We then ran Laguna S 2.1 in an automated research loop
that fed each result back to it and pushed it to keep improving.
Results. Over multiple hours of work, Laguna S 2.1 found and implemented
multiple different optimizations in our agent harness, resulting in an overall speedup of 5.2%,
and reducing memory allocation by ~70%. The plot below shows the progression of the
optimization, with the insights and discoveries the model made along its way.
Laguna S 2.1 found that streaming-token accumulation used O(n^2) string concatenation and
replaced it with buffers. It also found several instances of redundant copying and
over-allocation during trajectory materialization, which it resolved by memoizing
materializations and pre-allocating slices to their exact sizes.
Notably, after speedup improvements became marginal and hard to measure in our setup, Laguna S
2.1 kept driving forward, continuing to optimize. It found that memory allocation was more
accurately measured and focused its effort there. This reinforces the notion that Laguna S 2.1
truly is a model that doesn't give up and understands limitations of its environment and it is
able to progress despite that.
Harness optimization attempts
Twenty harness optimization attempts showing wall-clock and allocation improvements against baseline. Attempt 9 produced the best ranked solution at 5.19 percent faster with 71.1 percent fewer allocations.
Wall-clock best-so-far (ranked objective)
Allocations best-so-far (proxy)
Attempt (did not improve best)
While the benchmarks used here are not a full production test, we validated the final run with
Go's race detector and go vet gating enabled, and we tested the final artifact to confirm
it works. This gives us confidence that the model's intermediate solutions were valid, stable software
rather than gains bought with hidden race conditions.
Case study 3
Re-deriving Erdős problem #397, offline, in Perl
We found Laguna S 2.1 more capable in mathematics than any model we have developed to date. It
independently discovered a proof to Erdős problem #397 (Erdős, Graham, Ruzsa, Straus, 1975),
finding a construction that yields an infinite family of solutions. This is an independent
re-discovery, as a proof to the conjecture was found earlier in January 2026 by GPT-5.2 Pro. We are confident that this result was not influenced by the previous result given that the
model has a knowledge cutoff date in November 2025. Before GPT 5.2 Pro’s solution, this problem
remained open for over 50 years. See the full trajectory here.
found earlier in January 2026 by GPT-5.2 Pro
S 2.1 worked over 68 minutes to discover a conclusive solution. The sandbox had no Python; the
model found Perl and did its number theory there: brute-force exact prime factorizations,
pattern analysis, a conjectured family, then the proof: a closed-form infinite family of
eight-index solutions.
While the result is a rediscovery, not a first solution, the family Laguna S
2.1 derived is structurally different from the earlier published construction (eight indices
growing linearly vs the known six-index family), showing a fresh derivation rather than reciting
from memory.
We found Laguna S 2.1 to be an exceptionally persistent problem solver across domains, finding
ways to utilize all tools its environment has to offer, and pushing until it gets the job done.
It is this characteristic that makes it so competitive even when compared to models multiple
times its size.
Thinking effort
Laguna S 2.1 has two thinking modes: off and max (enabled by default) where it determines the right thinking/test-time compute budget for a given problem. We have observed coherent, productive thinking over several hours and hundreds of thousands of tokens in length.
Max thinking lifts S 2.1’s score on Terminal-Bench 2.1 from 60.4% to 70.2% and on DeepSWE from 16.5% to 40.4%. We are releasing this model without user-configurable effort (low-medium-high) control today to get Laguna S 2.1 into the hands of users immediately.
The two modes still give you a real choice, and it's worth seeing what each point costs:
Score versus mean completion tokens
Each line connects a cheaper no-thinking run to a higher-scoring thinking run for the same benchmark.
SWE Multilingual
TB 2.1
SWE Pro
DeepSWE
hollow = no-thinking
Limitations
We are excited about the capabilities of Laguna S 2.1, in general as well as in the context of its size. In order to learn quickly we are making the model available with some known limitations that we are working on for the next iteration:
Harness overfitting: in some cases, we observe that Laguna S 2.1 struggles with adhering to tool schema definitions in third-party agent harnesses (e.g., the terminal tool in Hermes Agent) which are very similar to those in our native harness but with slight differences. In this case, the model may rely on its memory of the tool interface on the first use of the tool instead of following the definition. This is typically resolved through in-context learning should the harness reject the invalid tool call and ask the model to retry.
Nested tool calls: Laguna S 2.1 is guided to use a tool call format where tool calls are marked by XML-like tags:
In cases where a tool argument expects a JSON array (e.g., Pi’s edit tool) the model may generate incorrectly escaped or invalid JSON.
Longer than expected thinking duration/overthinking: Laguna S 2.1 may think for long sequences before making progress, especially when working through competition mathematics problems. In future models we will introduce effort control for thinking as well as seeking to improve thinking efficiency.
What actually changed in this model
If the bet is long-horizon work, what did we improve that helps a model keep going? For S 2.1, it isn't just increasing the model size.
What we've done in this model is not necessarily add more intelligence, but improve the behaviors that lead to a more capable model: more verification, less taking things for granted, not declaring victory early, and being more persistent.”
The easiest way to see this is to watch the model work. Earlier Laguna series models would declare victory on a partially-passing test suite or abandon an approach two steps before it worked, S 2.1 keeps going.
We believe in scaling laws and will keep training larger models. What Laguna S 2.1 suggests is that raw intelligence is one axis, and the model's way of working (persistence, verification, willingness to backtrack) is a second axis that matters immensely. We're investing in both: our next, larger, Laguna series model began pre-training last week.
A strong base, then new post-training
Laguna S 2.1 is a scale-up of the Laguna XS family, trained on exactly the same pre-training data as XS 2.1: the step from XS 2.1 to S 2.1 was scale, training-code fixes, and small recipe changes, not new data. S 2.1 is also our first model where RL was done in FP8 precision, accelerating that part of the training.
The long agentic sessions in this post routinely accumulate hundreds of thousands of tokens of working context. Extending to a 1M-token context window enables the strongest performance on hard tasks.
The majority of what separates S 2.1 from the XS models comes from post-training, in two stages: an SFT stage that bootstraps capabilities partly with synthetic data, then RL, reserved for tasks the model can't yet solve at a high pass rate.
Distribution of post-training tasks
Our training corpus spans 409k agentic and non-agentic environments; within this, 83k setups are dedicated to terminal use cases, while 168k target standard software engineering workflows. These task sets were curated from open-source repositories, synthesized by our internal teams, including a specialized system for automatic dependency installation, or secured via strategic acquisitions from external data vendors.
Software-engineering tasks are mostly grounded in real code history: the largest source reproduces real commits (~38,000 tasks across ~17,000 repositories). The next reproduces merged pull requests and the remaining tasks are to fix injected bugs or reconstruct deleted files against a test suite. New for S 2.1 is agentic repository installation: given a repository, install every dependency and get the test suite running.
Terminal tasks come from datasets where agents build unseen environments and tasks from a seed.
What changed in the training loop
More generous rollout budgets: substantially longer timeouts, more tokens per turn, and more turns per task than any model before it (likely one reason for its persistence).
Better sandbox infrastructure: RL moved to a new sandboxing service, enabling background processes, selective network blocking to shrink reward-hacking surface and artifact caching to avoid overloading external services.
Multi-harness rollouts: the same prompts are rolled out in several agent harnesses, so the model learns behaviors that carry across scaffolds instead of overfitting to one.
The bets we're making
Laguna S 2.1 began pre-training on 4,096 NVIDIA H200 GPUs on May 22, 2026, 60 days ago. The Model Factory supports a high cadence of releases because building on foundations of work done, whether in pre-training data, architecture ablations or our evaluations stack, is automatic. In particular, advancements in post-training have enabled us to unlock more from test-time compute. Of all models we have trained to date, Laguna S 2.1 has the greatest delta in evaluations and perceived quality between its non-thinking mode and thinking mode: its internal monologue is very effective, especially for harder, complex problems.
A small team can only move this fast by focusing. We focus on two bets.
The first bet: we continue to focus on agentic coding capabilities. The path to intelligence runs through coding capability and the flexible interface that is software. This is increasingly evident as model intelligence advances: we now see hours- and days-long coherent work from models acting as agents, using software to interact with their environment. Laguna S 2.1 shows capabilities in this domain that were reserved for frontier models just 6 months ago at a small enough size to run on a single NVIDIA DGX Spark.
The second bet is that the web can be decompressed: almost everything humanity has written records the answer, not the thinking that got there, and we believe reinforcement learning can recover that thinking. This release is evidence for the first bet. The second we're still actively developing and excited to share more about in the future.
Three models in three months
Our internal platform for research and engineering, which we refer to as the Model Factory, allows us to industrialize the model development process. We invest heavily into continuously improving the process of how we conduct research and model building; to maximize research iteration and integration speed, and to minimize the amount of attention researchers need to pay to bookkeeping and infrastructure.
In less than 3 months from our Laguna M.1 release, we have pushed our techniques to deliver a substantially stronger model at half the running size. We are taking this forward to larger and larger models over the coming year.
Three models in three months
A three-point timeline from the dual Laguna M.1 and XS.2 release through XS 2.1 to Laguna S 2.1.
28 April 2026 Laguna M.1 and Laguna XS.2 / 225B-A23B and 33B-A3B, a dual release Our first serious agentic coding model alongside the first of the XS line. Together they taught us where the harness, the data, and the training loop were weakest.
Laguna M.1 and Laguna XS.2 / 225B-A23B and 33B-A3B, a dual release
Our first serious agentic coding model alongside the first of the XS line. Together they taught us where the harness, the data, and the training loop were weakest.
2 July 2026 Laguna XS 2.1 / 33B / 3B active A new iteration of the XS size to check the improved recipe. Matched M.1 on SWE-Bench Multilingual at a seventh of the size.
Laguna XS 2.1 / 33B / 3B active
A new iteration of the XS size to check the improved recipe. Matched M.1 on SWE-Bench Multilingual at a seventh of the size.
21 July 2026 Laguna S 2.1 / 118B / 8B active Everything we learned from the previous ones, applied. Under nine weeks from the start of training to this post.
Laguna S 2.1 / 118B / 8B active
Everything we learned from the previous ones, applied. Under nine weeks from the start of training to this post.
Get started
Laguna S 2.1 is available on Hugging Face from day one under OpenMDW-1.1, with BF16, FP8, INT4 and NVFP4 weights, official GGUF and MLX conversions, and official DFlash draft models.
We worked across the ecosystem so developers can run Laguna S 2.1 where they already build. NVIDIA helped optimize inference across its hardware, from TRT-LLM serving and NVFP4 on Blackwell systems down to a single NVIDIA DGX Spark. vLLM, SGLang and Ollama support open serving and local inference from day one.
For hosted access, Laguna S 2.1 is available through Baseten’s Model Library and Frontier Gateway, OpenRouter, including a free endpoint and a dedicated 1M-context deployment, and Vercel AI Gateway.
You can also use Laguna S 2.1 through Kilo, Hermes Agent, pi, OpenCode, OpenClaw and Cline, as well as pool, our terminal-based coding agent. In pool, toggle thinking per session with /thought-level.
On OpenRouter, the free endpoint offers 256K context. A dedicated paid endpoint provides the full 1M context window at $0.10 input, $0.20 output and $0.01 cache-read per 1M tokens.
For developers who want to go further, Laguna S 2.1 can be post-trained with NVIDIA NeMo AutoModel and Prime Intellect’s Prime Lab. ZML’s LLMD framework runs it across a wide range of hardware.
If you’re not a developer, chat.poolside.ai is a simple web chat with web search and basic code execution. No login required.
If you want the base model, meaning the pre-post-training weights for research or your own post-training, email models@poolside.ai.
Footnotes
All Laguna S 2.1 agentic benchmarking was completed using our internal fork of the Laude
Institute's Harbor Framework with our
agent harness, a maximum of 500 steps and
sandboxed execution via our internal sandbox service. We report mean pass@1 averaged over
multiple attempts per task (avg@k), with k per benchmark listed below.
SWE-bench Multilingual and SWE-Bench Pro were run through their Harbor adapters, with every task
executing in our internal sandbox service. Storage and memory ceiling limit multipliers were set
per benchmark (SWE-bench Multilingual: 2.0/2.0, Terminal-Bench 2.1: 3.0/3.0, SWE-Bench Pro:
1.0/1.0, with a guaranteed minimum of 2 CPU cores, 8 GB memory and 25 GB of storage). These are
set to prevent sandbox preemptions.
DeepSWE v1.1 was run on an internal fork of Harbor configured to closely match the official
DeepSWE Pier harness (Pier is itself a fork of Harbor). Internet access was disabled and
sandboxes used the task-prescribed CPU count with guaranteed RAM and storage, with ceilings
tripled to prevent pod preemption.
SWE Atlas (Codebase QnA) followed Scale AI's methodology from their public repository, run
through Harbor with no changes to individual tasks or graders, judged by Opus 4.5.
Toolathlon Verified was run as a clone of the sandboxed benchmark harness on an EC2 instance in
our infrastructure, with no changes to correct flaky tasks or offset rate limits, using a custom
Toolathlon agent. Unlike the official version, we performed a full environment reset and repair
after every evaluation run (default is every 4 hours).
SWE-bench Multilingual: mean pass@1 averaged over 4 attempts per task
SWE-Bench Pro: mean pass@1 averaged over 4 attempts per task
Terminal-Bench 2.1: mean pass@1 averaged over 4 attempts per task
DeepSWE v1.1: mean pass@1 averaged over 3 attempts per task
SWE Atlas (Codebase QnA): mean pass@1 averaged over 3 attempts per task
Toolathlon Verified: averaged over 3 runs
Our
technical report
contains a section on individual task modifications that have been made but not adopted
upstream. All final run trajectories are available to view and download at
trajectories.poolside.ai.
Unless stated otherwise, all of our evaluations are run with access to the internet. This can be
a major source of misaligned trajectories where the model finds solutions to tasks online
without solving it itself (a.k.a., “reward hacking”).
Using an LLM as a Judge (LLMaaJ) calibrated with human labeled trajectories, we tag solutions
that potentially reward hack after every eval. During early post-training we observed low rates
of reward hacking (<2%). As training progressed, reward hacking rates spiked on the SWE-bench
family of tasks with over 50% of trajectories being flagged. Manual inspection revealed the
model was simply doing research to solve the problem, found the PR or repository the task was
based on and applied the fix. In practice this is good behavior as any coding agent should be
able to use solutions found online. However, this muddies the signal of the benchmark.
To address this we added a small prompt addendum to the user prompt instructing the model to not
use direct solutions found online. Though not a guaranteed fix (ProgramBench, MirrorCode were
exceptions), in general we did see the model respond and a drop in reward hacking rates to below
2%.
In addition, to confirm acceptable levels of reward hacking, we used:
Manual inspection of positive cases flagged by our production LLMaaJ service
Ad-hoc open-ended agent-supported analysis of all trajectories
Expert annotator review of all trajectories for one of the high-scoring Terminal-Bench 2.1 runs