Laguna XS 2.1 Guide: A 3B-Active Coding Agent for Your Desk

Laguna XS 2.1 is a model built for one specific constraint: an agentic coding loop that runs on hardware you already own. Poolside describes it as designed for agentic coding and long-horizon work on a local machine, and the model card says it is compact enough for a Mac with 36GB of memory.

It shipped on 2 July 2026 as a refresh of Laguna XS.2. Same architecture, same parameter counts, better scores. This guide covers what improved, where it still trails the obvious alternative, and the setup details that decide whether a local run works at all.

What 33B-A3B buys you

XS 2.1 is a mixture-of-experts model with 33B total parameters and about 3B active per token. The model card lists 40 layers, ten with global attention and thirty with a 512-token sliding window, and 256 experts plus one shared expert. The KV cache is quantised to FP8. Context is 262,144 tokens.

The 3B active figure is the point. Decode speed on a laptop is governed largely by how many parameters each token touches, and 3B is small. The 33B total still has to fit in memory, which is why a 36GB machine is the stated floor rather than a 16GB one. Quantised FP8, NVFP4 and INT4 checkpoints are published for tighter budgets.

Poolside also released DFlash speculator models alongside each checkpoint and reports that they roughly double achieved tokens per second in its tests. Speculative decoding is worth enabling locally, where every token per second is felt directly.

What changed from XS.2

The model card puts the two side by side, pass@1 with thinking enabled on Poolside's own agent harness:

• SWE-bench Verified — 69.9% to 70.9%
• SWE-bench Multilingual — 57.7% to 63.1%
• SWE-Bench Pro — 46.3% to 47.6%
• Terminal-Bench 2.0 — 35.7% to 37.5%

The multilingual jump is the real change; the rest are small. If your repositories are not Python, that 5.4-point gain is the reason to upgrade. If they are, the difference from XS.2 is close to noise, though XS.2 is being retired from Poolside's own API a week after launch, so the choice is partly made for you on that platform. It stays available through Baseten for dedicated deployments.

The honest comparison: Qwen3.6 35B-A3B

Poolside's own table includes a competitor in exactly the same weight class, and it scores higher on every column shown: Qwen3.6 35B-A3B at 73.4% Verified, 67.2% Multilingual, 49.5% Pro and 51.5% on Terminal-Bench 2.0. The terminal gap in particular is wide, at fourteen points.

That does not make XS 2.1 the wrong choice, but it does mean you need a reason. Plausible ones:

• Licence. XS 2.1 is under OpenMDW-1.1, which Poolside calls fully permissive. Check whether that suits your legal team better than the alternative.
• Harness fit. Poolside tunes against its own pool agent. If you use it, you are running the model in the conditions it was evaluated under.
• Your own results. Vendor tables are run on vendor harnesses. A few points either way often reverses on a real codebase.

The Qwen3.6 35B-A3B guide covers the other side of this comparison.

Getting a local run right

Most failed local trials of a new model are configuration problems, not model problems. The model card is specific about several:

• Thinking must be on for agent work. Serve with enable_thinking set to true by default and pass previous reasoning_content back in the message history. The card warns that dropping prior reasoning can stop the model reasoning in later steps.
• Use the right parsers. vLLM needs version 0.21.0 or later and the poolside_v1 tool-call and reasoning parsers; the card notes a specific upstream fix is needed for correct tool-call parsing.
• Sampling. The benchmark settings were temperature 1.0, top_k 20, top_p 1.
• Ollama on Apple Silicon. ollama run laguna-xs-2.1 pulls a Q4_K_M build by default, but the card warns of empty output on Apple Silicon due to a Metal bug. If you see blank responses, that is the likely cause.
• llama.cpp support required building from a specific pull request at the time of the card; official GGUF files exist in BF16 and Q4_K_M.

vllm serve   --model poolside/Laguna-XS-2.1   --tool-call-parser poolside_v1   --reasoning-parser poolside_v1   --enable-auto-tool-choice   --default-chat-template-kwargs '{"enable_thinking": true}'

Hosted, if you do not want to run it

The model is also on OpenRouter and Poolside's API, each with a free and a paid endpoint. Poolside's launch post priced the paid tier at $0.10 per million input tokens, $0.20 per million output and $0.05 per million cached input, unchanged from XS.2. At the time of writing the OpenRouter listing was lower, at $0.06 in, $0.12 out and $0.03 cached; aggregator listings move, so check the current figure. The free endpoint is rate-limited and suits evaluation, not a production loop.

At those prices the hosted model is cheap enough that self-hosting rarely wins on cost alone. Run it locally for privacy, offline work or latency, not to save money. Local models vs API runs those numbers in more detail.

XS 2.1 or S 2.1

Poolside's larger Laguna S 2.1 shares the same pre-training data at 118B-A8B with a 1M window. Poolside reports S 2.1 at 70.2 on Terminal-Bench 2.1 against 33.4 for XS 2.1. Choose XS 2.1 when the model must live on one machine or the task is a short, bounded edit. Choose S 2.1 when the session is long and unattended or the context runs past 256K. If you are not sure, start on XS 2.1 and escalate the tasks it fails, which is the pattern model routing and fallbacks describes.