Poolside releases Laguna S 2.1 as 118B open-weight coding model

• Laguna S 2.1 shipped as a 118B-total, 8B-active MoE with 1M context, and SGLang's day-zero note says it supports thinking and no-thinking modes.
• Poolside is pitching the model around local agentic coding runs, with Pi's benchmark chart putting SWE-bench Multilingual at 78.5% and Poolside's DGX Spark demo showing the model loading on a desk-side box.
• The benchmark story has caveats: a LocalLLaMA overview says Kimi K3 and Claude Fable 5 still lead key top-end scores, while one private local eval found hard fabrications under pressure.
• Day-one access is unusually broad for a fresh open-weight coding model: SGLang shipped serving support, Kilo made it free in Kilo Code, and Pi exposed it through OpenRouter.

The Hugging Face model card lists top-10 routing over 256 experts, a 512-token sliding window, and DFlash drafts. Poolside's launch post says max thinking lifted DeepSWE from 16.5% to 40.4%, then discloses harness overfitting and nested-tool-call failures. OpenRouter's model page already has a paid endpoint at $0.10 per 1M input tokens and $0.20 per 1M output tokens, while Kilo's launch note says its IDE extension, CLI, and Cloud Agents had free access on day one.

Laguna S 2.1 is Poolside's mid-size coding specialist, positioned between Laguna XS 2.1 and Laguna M.1. The useful bit for engineers is the self-hostable coding-agent shape.

• Model: 118B total parameters, roughly 8B active per token, according to Poolside's launch post.
• Context: 1,048,576 tokens, listed on the Hugging Face model card.
• Modes: thinking and no-thinking, with thinking enabled by default in Poolside's examples.
• License: OpenMDW-1.1, which the OpenMDW license text describes as a permission grant for model materials under copyright, patent, database, and trade-secret rights.
• Training-to-launch: under nine weeks, a turnaround Omar Sar's launch reaction called out as pressure on closed frontier coding models.

Poolside compared Laguna S 2.1 against much larger disclosed models and closed systems. AymericRoucher's benchmark reaction got the vibe right: the chart is a parameter-efficiency flex.

Key reported scores from the Hugging Face model card:

• Terminal-Bench 2.1: 70.2%, ahead of DeepSeek-V4-Pro Max at 64.0% and Nemotron 3 Ultra at 56.4%.
• SWE-bench Multilingual: 78.5%, ahead of DeepSeek-V4-Pro Max at 76.2% and roughly tied with Qwen 3.7 Max at 78.3%.
• SWE-Bench Pro: 59.4%, ahead of DeepSeek-V4-Pro Max at 55.4% and Inkling at 54.3%.
• DeepSWE: 40.4%, ahead of DeepSeek-V4-Pro Max at 9.0%, behind Kimi K3 at 69.0% and Claude Fable 5 at 70.0%.
• Toolathlon Verified: 49.7%, behind Muse Spark 1.1 at 75.6% and DeepSeek-V4-Pro Max at 55.9%.

The caveat is in Poolside's own methodology: Poolside's launch post says it takes the maximum of vendor self-reported scores, benchmark leaderboards, or third-party leaderboard results for most comparisons, and DeepSWE harnesses vary.

The Hugging Face model card gives the implementation inventory:

• Layers: 48 total.
• Attention layout: 12 global-attention layers and 36 sliding-window layers.
• Sliding window: 512 tokens.
• Experts: 256 routed experts, top-10 routing, plus one shared expert.
• Attention heads: grouped-query attention with 8 KV heads and 128 head dimension.
• Tokenizer: Laguna-family tokenizer with 100,352 vocabulary entries.
• Quantizations: FP8, NVFP4, INT4, and GGUF, plus BF16 base weights.

BF16 needs roughly 236GB of weights, according to the model card. The local-access headline comes from quantization: SGLang's launch note says official NVFP4 fits on a single NVIDIA DGX Spark.

Thinking is a first-class serving knob. The model card says enable_thinking can be controlled per request, and that agentic use preserves reasoning_content from previous assistant messages.

Poolside reported a large test-time-compute jump in its own harness: Poolside's launch post says max thinking moved Terminal-Bench 2.1 from 60.4% to 70.2% and DeepSWE from 16.5% to 40.4%.

Serving support already includes the agent plumbing:

• vLLM: --tool-call-parser poolside_v1, --reasoning-parser poolside_v1, and optional DFlash speculative decoding.
• SGLang: --reasoning-parser poolside_v1, --tool-call-parser poolside_v1, and --trust-remote-code.
• TRT-LLM: --tool_parser poolside_v1 and --reasoning_parser laguna.
• llama.cpp: Poolside's Laguna branch supports GGUF and DFlash, while base Laguna support is in upstream review, according to the model card.

Laguna S 2.1 landed across hosted, local, and agent surfaces on day one.

• SGLang: SGLang's announcement shipped a cookbook and day-zero serving support.
• OpenRouter: OpenRouter's Poolside page lists Laguna S 2.1 and Laguna S 2.1 free variants.
• Pi: Pi's follow-up said the model was available to try in Pi.
• Kilo Code: Kilo's post said Laguna S 2.1 was free in Kilo Code, and Kilo's blog says it works across the IDE extension, CLI, and Cloud Agents.
• Nous Portal: Teknium's launch note said Poolside's latest model would be free for two weeks on Nous Portal.
• Poolside API: Poolside's models page lists API-key access and an OpenAI-compatible Chat API.

Atomic Chat's side-by-side Doodle Jump demo.

Early hands-on reports were narrower than the benchmark chart, and more useful.

• Local game coding: Rohan Paul's Atomic Chat test said Laguna S 2.1 matched GLM-5.2 on three self-playing arcade-game tasks while using 10.3K total tokens versus GLM-5.2's 26.4K.
• Tool calling: one LocalLLaMA eval measured 0.89 tool-call argument pass rate versus Qwen3.5-122B at 0.86, six-level tool chains versus Qwen's four, and zero JSON, streaming, or envelope errors.
• Single-card speed: the same eval reported 109 tok/s on an RTX Pro 6000 Blackwell at 256K context with official NVFP4, versus 103 tok/s for Qwen3.5-122B.
• Cheap multi-GPU serving: one LocalLLaMA hardware post said Q4_K_M fit at 256K context on 3x V620 cards totaling 96GB VRAM, with 400 to 600 tok/s prefill and 16 to 20 tok/s generation before DFlash.
• Access independence: andrew_n_carr's access post framed the DGX Spark path as a way to keep coding-model access under local control, even at 50 to 70 tok/s decode speeds.

Poolside shipped Laguna S 2.1 with named limitations. Poolside's launch post lists three that matter for agent harnesses:

• Harness overfitting: the model can use a memorized tool interface on first use when a third-party harness looks similar to Poolside's native harness.
• Nested tool calls: XML-like tool-call tags can produce invalid or incorrectly escaped JSON when an argument expects a JSON array, with Pi's edit tool named as an example.
• Overthinking: the model can spend long sequences thinking before progress, especially on competition math, and Poolside has not shipped low, medium, and high effort controls yet.

The private LocalLLaMA eval found a separate grounding failure. The evaluator reported sports knowledge and odds math at 0.80 versus Qwen3.5-122B at 1.00, grounding under pressure at 0.80 versus 0.97, and three hand-confirmed hard fabrications when tools returned no data.

The same evaluator also ruled it out as a daily driver for one simple reason: no vision.

Poolside's release notes are unusually specific about what changed. Poolside's launch post says S 2.1 reused the same pretraining data as XS 2.1, with the move to S driven by scale, training-code fixes, small recipe changes, and post-training.

The post-training setup:

• Pretraining: Laguna S 2.1 was trained in-house on 30T tokens, according to Poolside's models page.
• Base change: same pretraining data as XS 2.1.
• Post-training: SFT first, partly with synthetic data, then RL for tasks the model could not solve at high pass rate.
• RL precision: S 2.1 was Poolside's first model with RL done in FP8 precision.
• Task pool: 409K agentic and non-agentic environments.
• Terminal setups: 83K.
• Standard software-engineering workflows: 168K.
• Real-code-history tasks: roughly 38K tasks across about 17K repositories.

The XS lineage had already been moving in code-specific ways before S arrived. eliebakouch's J-lens analysis found XS.2 and XS.2.1 looked very different on code prompts, while wikitext representations stayed more similar except near the late-layer "motor" section.