Laguna S 2.1 Local Setup (July 2026): 118B Coding Model on 64GB and 128GB
Poolside shipped Laguna S 2.1 on July 21, 2026. It is 118B total parameters with only 8B active per token, a 1,048,576-token context, and 70.2 on Terminal-Bench 2.1 — beating models roughly ten times its size. Every other July 2026 frontier open-weight release went the other way. Kimi K3 is 2.8T parameters. GLM-5.2 needs ~256GB just to load. Laguna S 2.1 fits a 128GB Mac at Q4 and generates at small-model speed. This page covers the quant sizes, what actually fits 48/64/128GB, and the OpenClaw config.
Setting up Laguna S 2.1 as your coding agent?
See our AI training options. We'll wire Laguna S 2.1 into OpenClaw on your machine, free.
UD-Q4_K_M is 73.1 GB. A 128 GB unified-memory Mac runs it with room left for a 1M-token context and OpenClaw itself. On NVIDIA you need 96 GB of VRAM to match. A 32 GB 5090 runs Laguna XS 2.1 instead.
Amazon affiliate links — we earn a small commission at no cost to you.
Bottom Line (July 2026)
- What it is: Laguna S 2.1, Poolside, released July 21, 2026. 118B total params, 8B active, Mixture-of-Experts.
- Context: 1,048,576 tokens native. No other local coding model in this size class matches it.
- Score: 70.2 on Terminal-Bench 2.1 — it beats models roughly 10x its size.
- License: OpenMDW-1.1. Permissive, but it is not Apache 2.0 — read the terms before you ship a product on it.
- 128GB: run UD-Q4_K_M (73.1GB) with lots of context headroom. This is the tier the model was built for.
- 64GB: run UD-IQ4_XS (57.6GB) with modest context, or UD-Q2_K_XL (39.7GB) comfortably.
- 48GB: UD-Q2_K_XL (39.7GB) only.
- 32GB and below: no. Run Laguna XS 2.1 instead — 20.27GB at Q4_K_M.
Note what did not happen this month. Kimi K3 shipped at 2.8T parameters and roughly 1.4TB of weights. GLM-5.2 needs about 256GB minimum. Kimi K2.7-Code is 1T. All three left consumer hardware behind. Laguna S 2.1 went the other direction and stayed.
What Laguna S 2.1 Actually Is
118B total parameters. 8B active per token. Those two numbers do different jobs, and mixing them up is the most common mistake on this page.
Total parameters set your memory bill. Every one of the 118B weights must sit in RAM or VRAM, because the router can call any expert on any token. That is why the Q4 file is 73.1GB.
Active parameters set your speed. For each token the model routes through roughly 8B of those weights. Generation speed on a memory-bandwidth-bound machine tracks how many bytes you read per token, so you get roughly 8B-class throughput out of a 118B-class model.
That trade is the whole story. You buy the memory once. You get the speed on every token. A dense 118B model would cost the same RAM and run ten times slower.
The 1M-token context matters for the same reason coding agents matter: you can feed a whole repository, a long test log, and a design doc into one session without a retrieval layer. Poolside targeted long-horizon agent work, and the Terminal-Bench 2.1 score of 70.2 reflects that — it is a multi-step terminal task benchmark, not a single-shot completion test.
Poolside has not published a SWE-bench Verified score for S 2.1. Do not trust any number you see floating around for it.
Quant Sizes and What Fits
Sizes below are Unsloth’s dynamic GGUF builds. Add KV cache on top of every row.
| Quant | File Size | Min RAM/VRAM | Context Headroom | Verdict |
|---|---|---|---|---|
| UD-Q4_K_M | 73.1 GB | 128 GB | Large — 256K+ practical | Best quality. The pick. |
| UD-IQ4_XS | 57.6 GB | 64 GB | Tight — cap 16K–32K | The 64 GB answer. |
| UD-Q2_K_XL | 39.7 GB | 48 GB | Comfortable on 64 GB | Only option at 48 GB. Quality drops. |
Ollama q4_K_M tag | 75 GB | 128 GB | Large | Easiest path if you already run Ollama. |
Ollama q8_0 tag | 128 GB | 192 GB+ | None on 128 GB | Skip unless you have a 192 GB Ultra. |
| Laguna XS 2.1 Q4_K_M | 20.27 GB | 24 GB | Good — 256K native | Use this at 24–32 GB. |
The 128GB row is the one that matters. At 73.1GB of weights you keep roughly 50GB free for KV cache, OpenClaw, your editor, and the OS. That is what turns the 1M context from a spec-sheet number into something you can actually use.
Setup
Two paths. Ollama is easier. llama.cpp with Unsloth’s GGUFs gives you exact quant control and the smaller IQ4_XS build that 64GB machines need.
Path 1 — Ollama (128GB)
ollama pull laguna-s-2.1 # default tag is q4_K_M, 75GB ollama run laguna-s-2.1
Path 2 — llama.cpp + Unsloth GGUF (64GB, or exact quant control)
pip install -U "huggingface_hub[cli]" # 64GB machines: IQ4_XS, 57.6GB hf download unsloth/Laguna-S-2.1-GGUF \ --include "*UD-IQ4_XS*" \ --local-dir models/laguna-s-2.1 # 128GB machines: Q4_K_M, 73.1GB hf download unsloth/Laguna-S-2.1-GGUF \ --include "*UD-Q4_K_M*" \ --local-dir models/laguna-s-2.1
Serve it on an OpenAI-compatible port:
llama-server \ -m models/laguna-s-2.1/Laguna-S-2.1-UD-IQ4_XS-00001-of-00002.gguf \ --host 127.0.0.1 --port 8080 \ --ctx-size 32768 \ --n-gpu-layers 999
Raise --ctx-size only if you have the free memory. On 64GB at IQ4_XS, 32K is the honest ceiling.
OpenClaw config
# Ollama path openclaw config set agents.defaults.models.code ollama/laguna-s-2.1 openclaw config set agents.defaults.context_limit 262144 # llama.cpp path openclaw config set agents.defaults.models.code openai/laguna-s-2.1 openclaw config set agents.defaults.models.code_base_url http://127.0.0.1:8080/v1 openclaw config set agents.defaults.context_limit 32768 openclaw config set agents.defaults.keep_alive 4h
Keep-alive matters more here than on small models. Reloading 73GB of weights from disk costs a minute or more, and an agent loop that idles between steps will pay it repeatedly.
Laguna S 2.1 vs Laguna XS 2.1 — Which One
Both come from Poolside, both are MoE, both ship under OpenMDW-1.1. They target different machines.
Take XS 2.1 if you have 24GB or 32GB. 33B total, 3B active, 256K context. Q4_K_M is 20.27GB, so it fits a single 24GB GPU with context to spare, and fits a 32GB RTX 5090 with roughly 64K context. Its SWE-bench Verified score sits around 70.9% (chart-sourced, treat as approximate); the XS.2 predecessor is firmly verified at 68.2%. There is an official Ollama tag and an official Poolside GGUF repo.
Take S 2.1 if you have 64GB or more. You get 118B total against 33B, the 1,048,576-token context against 256K, and better long-horizon agent behavior — which is what the 70.2 Terminal-Bench 2.1 score measures. The cost is 3x the memory and slower prompt processing on long inputs.
The honest split: XS handles a file or a module. S handles a repository. If your agent runs are short and scoped, XS is the better use of your hardware. If you run multi-hour autonomous loops over a large codebase, S earns the RAM.
Common Mistakes
- Reading “118B” and assuming it is slow. Only 8B parameters activate per token. Generation speed tracks active params, not total. This model runs at small-model speed on a 128GB Mac.
- Pulling
q8_0because you have 128GB. That tag is 128GB by itself. It leaves nothing for KV cache or the OS. Stay on q4_K_M at this tier. - Setting context to the full 1M on a 64GB machine. At IQ4_XS the weights already take 57.6GB. A 1M-token KV cache would need many times your remaining RAM. Cap at 16K–32K on 64GB.
- Assuming the license is Apache 2.0. It is OpenMDW-1.1. The license is permissive, but the terms differ. Read them before you build a commercial product on the weights.
- Quoting a SWE-bench Verified number for S 2.1. Poolside has not published one. Terminal-Bench 2.1 = 70.2 is the verified figure. The ~70.9% SWE-bench number belongs to XS 2.1, not S.
- Running Q2 on a 128GB machine to save disk. UD-Q2_K_XL is 39.7GB and noticeably degraded on multi-step coding. If you have 128GB, use the 73.1GB Q4 build.
See Also
- Best Local LLMs for 128GB RAM — the full 128GB tier, where Laguna S 2.1 at Q4 now sits
- Best Local LLMs for 64GB RAM — the IQ4_XS tier and what else fits alongside
- Best Local LLM by RAM (hub) — pick your tier first, then your model
- Best Local Models for OpenClaw — model-first guide for agent loops
- Best Local LLM for M4 Max — Apple Silicon bandwidth and what it means for MoE speed
Need OpenClaw fixed live?
Remote rescue sessions for gateway, auth, tunnel, VPS, and model access problems.
See Rescue Session