🧩 Poolside Laguna XS 2.1: A 33B Coding Model for One GPU

3 billion active parameters out of 33 billion total is the number that makes Laguna XS 2.1 worth a paragraph on a site about local hardware. Mixture-of-experts models keep promising "big model quality, small model cost" — this is one of the few recent releases where the small-model cost is small enough to actually mean a single GPU on a desk, not a rack in someone else's data center.

By the numbers

Spec	Value
Total / active parameters	33B / 3B (MoE)
SWE-bench Multilingual	63.1% (+5.4 pts over XS.2)
Context window	256K tokens
Minimum VRAM	6GB (8GB recommended)
License	OpenMDW-1.1 — permissive
Quant formats	BF16, FP8, INT4, NVFP4 (GGUF pending)
API pricing	$0.10 / $0.20 / $0.05 per 1M input / output / cache-read tokens
Release date	July 2, 2026

Poolside also reports 33.4% on Terminal-Bench 2.1 — worth noting since terminal-style, multi-step agent tasks are where a lot of "great on benchmarks, useless in a real shell session" coding models fall apart.

Why 3B active is the number that matters, not 33B total

A 33B dense model doesn't run on 8GB of VRAM. A 33B MoE model with a 3B expert path activated per token does, because you're only ever paying the compute and memory-bandwidth cost of the active slice, not the whole parameter count sitting in memory doing nothing on a given forward pass. That's the entire pitch of mixture-of-experts architectures, and Laguna XS 2.1 is one of the tighter recent demonstrations of it working at a size that fits our own rig's numbers rather than a vendor's benchmark server.

Run the math against what we've published before: our quantization guide puts a dense 30B-class model comfortably in 24GB territory at Q4. Laguna XS 2.1 gets into single-digit VRAM instead — the MoE routing is doing the work a quant alone can't.

Getting it running

Poolside shipped broad framework support on day one — vLLM, SGLang, TensorRT-LLM, Transformers, and Ollama all list Laguna XS 2.1 in their model catalogs. The one gap: GGUF export for llama.cpp was marked "coming soon" at launch, which matters if your whole local setup is built around llama-server the way ours is for smaller models. Check the model card before you commit an afternoon to it — a "coming soon" that's still pending three weeks later is a different situation than one that shipped the next day.

For the fastest on-ramp right now, Ollama is the path of least resistance:

ollama run laguna-xs-2.1

If that pull doesn't resolve yet on your version, the Hugging Face collection (poolside/Laguna-XS-2.1 and the -GGUF variant once it lands) is the fallback, alongside vLLM if you're comfortable standing up an OpenAI-compatible server yourself. Our run-llama-locally guide covers the same three on-ramps in more depth if Ollama, LM Studio and raw llama.cpp are new territory.

DFlash speculators: the part that's easy to miss in the headline specs

Poolside open-weighted speculator models alongside every XS 2.1 checkpoint — small models that predict likely next tokens ahead of the main model, verified in a batch rather than generated one at a time. Used correctly, speculative decoding roughly doubles achieved tokens/second on the same hardware, at no quality cost when the speculation is right (and no correctness cost when it's wrong — the main model still verifies). If your inference stack supports speculative decoding and you skip pairing XS 2.1 with its DFlash speculator, you're leaving real throughput on the table for free.

The honest limitation

A 3B active-parameter model is not going to out-argue a frontier coding agent on genuinely hard, multi-file refactors — 63.1% on SWE-bench Multilingual is a real result, not a frontier one. Where it earns its place is the volume tier: fast, cheap-to-run, good-enough completions and agentic terminal tasks where you'd otherwise be burning API credits on a much larger hosted model for work that doesn't need that model's ceiling. We treat it the same way we treat any efficient local model — the tool for the 80% of coding tasks that don't need the expensive one, freeing the expensive one for the 20% that do.

Where it sits in Poolside's own lineup

Laguna XS 2.1 isn't Poolside's only release this cycle — there's also a larger Laguna S 2.1 in a different weight class, pitched harder at matching bigger rivals rather than fitting on one desktop GPU. If you've got 24GB+ to spare and want the strongest coding result Poolside ships rather than the smallest footprint, that's the model to check instead. XS 2.1 is specifically the "runs on what you already own" option, and that's the axis we're evaluating it on here — not a claim that it's Poolside's best model outright.

A quick sanity check before you commit an afternoon

Before pulling the weights, confirm three things: your inference stack actually supports GGUF yet if that's your plan (check the model card, not just this guide, since that status was still moving as of publication); your card clears the 6-8GB floor, which almost any GPU bought in the last four years does; and you're evaluating it against other 3B-active MoE models rather than dense 30B+ models, since the comparison that actually matters is compute-for-compute, not parameter-count-for-parameter-count. Skipping that last check is the single most common reason people come away disappointed by efficient MoE releases — they benchmarked it against the wrong weight class in their head before the first token even generated.

How we tested this

Specs and benchmark figures in this piece are pulled directly from Poolside's own release documentation and model card, cross-checked against the Hugging Face collection metadata. VRAM figures are Poolside's stated minimums; we have not yet run Laguna XS 2.1 on our own RTX 4080 rig to independently confirm real-world throughput, and we'll update this guide with our own numbers once we have — treat the numbers here as vendor-reported until then, same caveat we apply to any model we haven't personally benchmarked yet.