Laguna S 2.1 for Claude Code Pipelines: Cost vs Quality

By Lazar Milicevic · Published October 28, 2026 · 10 min read

Your coding-agent bill keeps climbing, and every task you hand to a frontier model costs the same whether it's a one-line config fix or a gnarly refactor. Poolside's Laguna S 2.1, an open-weight 118B coding model, is the first Western-lab release in its size class in nearly a year that's cheap enough to change that math. Here's what it can and can't do, with the caveats Poolside itself disclosed.

What Poolside actually shipped

Laguna S 2.1 is a 118-billion-parameter Mixture-of-Experts model that activates 8B parameters per token, announced by Poolside on July 21, 2026. It supports a context window of up to 1M tokens in both thinking and no-thinking modes (Poolside announcement).

A few details matter more than the headline:

• It scales up an earlier family. Laguna S 2.1 is a scale-up of Laguna XS, which Poolside announced earlier, on July 2, 2026 (Poolside blog). It was trained on the same pre-training data as XS 2.1 and is Poolside's first model where reinforcement learning was done in FP8 precision (announcement).
• Training was fast. Pre-training began on 4,096 NVIDIA H200 GPUs on May 22, 2026, and the model went from the start of training to launch in under nine weeks (announcement).
• Weights are public from day one. They're on Hugging Face under the OpenMDW-1.1 license, in BF16, FP8, INT4 and NVFP4, plus official GGUF and MLX conversions and DFlash draft models. vLLM, SGLang and Ollama support it from day one (announcement).
• Thinking has two settings. Off and max. There's no low/medium/high effort dial (announcement).

That last point shapes how you'd route work to it, and I'll come back to it.

Poolside's framing is that no Western lab had released open weights in this size class in 11 months, since OpenAI's gpt-oss-120b the previous August (VentureBeat). Whether that gap matters to you depends on your procurement rules and your appetite for running your own inference. For many small teams it matters less than the price.

The benchmark numbers, read carefully

Poolside reports these pass@1 scores: 78.5% on SWE-Bench Multilingual, 59.4% on SWE-Bench Pro (public), 40.4% on DeepSWE v1.1, 46.2% on SWE Atlas Codebase QnA, and 49.7% on Toolathlon Verified (Center Consulting summary). On Terminal-Bench 2.1 it scores 70.2% in Poolside's own agent harness with thinking enabled (announcement).

The "beats rivals 10x its size" headline holds in specific places. In Poolside's comparison table, Laguna S 2.1 scores 40.4% on DeepSWE v1.1 against DeepSeek-V4-Pro-Max's 9.0%, with roughly one-sixth the active parameters. On SWE-Bench Pro it scores 59.4 against 55.4 for DeepSeek-V4-Pro-Max, a 1.6T-total, 49B-active model (MarkTechPost).

Now the other side of the same table. Closed or larger models still lead on several benchmarks. Claude Fable 5 scores 88.0 on Terminal-Bench 2.1 and 80.3 on SWE-Bench Pro (public), and Kimi K3 scores 88.3 on Terminal-Bench 2.1. Laguna S 2.1 scores 70.2 and 59.4 on those two (MarkTechPost). That's a gap of roughly 18 points on Terminal-Bench and 21 points on SWE-Bench Pro, not a rounding error.

Three caveats on how to read all of this:

1. The scores are vendor-compiled. Poolside's launch scores take the highest of up to three sources (vendor, author leaderboard, third-party leaderboard), and are pass@1 averaged over three or four attempts (AIToolsReview). That's a defensible method, but it's optimistic by construction.
2. The leaderboard rank is contested. Sources disagree on whether Laguna S 2.1 ranks 11th on Poolside's compiled Terminal-Bench leaderboard or first among open disclosed-size models, and it's a Poolside-compiled list, not an independent one. Don't build a decision on a rank.
3. Benchmarks aren't your codebase. Your repo has its own conventions, test setup and weird legacy corners that no public benchmark covers.

One thing Poolside did that's genuinely useful: it released full trajectories for every trial in the final evaluation set at trajectories.poolside.ai (announcement). You can read what the agent actually did on failed runs instead of trusting a single number. If you're deciding whether to pilot the model, spend an hour there first.

The thinking toggle also matters for cost planning. Max thinking lifts Terminal-Bench 2.1 from 60.4% to 70.2%, and DeepSWE from 16.5% to 40.4% (announcement). On hard multi-step tasks, running with thinking off leaves most of the performance on the table. On simple tasks, it's wasted tokens. That argues for routing by task difficulty rather than picking one setting for everything.

What it costs to run

Hosted access is the cheap path to try. OpenRouter listed paid access at $0.09 per million input tokens and $0.18 per million output tokens, with cache reads at $0.009 per million tokens, a 1.0M context, and a Jul 21, 2026 release date (OpenRouter listing). Other sources quote slightly different rates, so check the current pricing page before you budget. Poolside publishes no rate card of its own; per-token rates come from gateways such as OpenRouter and Vercel AI Gateway (Layer3 Labs guide).

OpenRouter also lists a free endpoint with a 262,144-token context window and 32,768 max output. The catch: free-tier inputs and outputs may be used by Poolside to train its models (free listing). Fine for open-source experiments. Don't send client code or anything under NDA through it.

Here's illustrative math, using round numbers I'm choosing, not measured figures. Say a pipeline job consumes 2M input tokens and 200K output tokens a day:

# Illustrative example only - round numbers, not benchmarks.
# Rates from the OpenRouter listing (check current page before relying on them).
in_tokens_m = 2.0     # millions of input tokens per day
out_tokens_m = 0.2    # millions of output tokens per day

laguna_in, laguna_out = 0.09, 0.18   # $ per 1M tokens

daily = in_tokens_m * laguna_in + out_tokens_m * laguna_out
print(f"Laguna S 2.1 hosted: ${daily:.3f}/day, ${daily*30:.2f}/month")
# -> $0.216/day, $6.48/month

At that volume the model cost is close to noise. Compare it against whatever you pay your current provider (check Anthropic's pricing page for current Claude rates) and the gap is large. But the real cost of a worse model is rarely the token bill. It's the failed run you rerun, the PR you review by hand, the subtle bug that ships. A model that's cheap per token and needs three attempts is not cheap.

Self-hosting is a different calculation. The BF16 checkpoint is roughly 236GB and needs multiple GPUs to serve, so open weights are not the same as cheap self-hosting for a small team. The 4-bit/NVFP4 build fits a single 128GB DGX Spark (AI Weekly). Sources put the quantized footprint at roughly 70GB, with small disagreements between them, so check the Hugging Face model card for the exact figure for the build you pick. Reported local speeds vary widely across secondary sources and I haven't seen them confirmed in official docs; benchmark on your own hardware.

My rule of thumb for solopreneurs and small teams: use hosted endpoints until you have a concrete reason not to. Self-hosting makes sense when data can't leave your network, when you have steady high volume, or when you need to pin a version. A low-volume team buying a multi-thousand-dollar GPU box to save a few dollars a month is optimizing the wrong thing.

Where it will probably fall down

Poolside was candid about limitations, which is to its credit. The model can overfit to its native harness and stumble on different tool schemas in third-party agents. It mangles JSON in nested tool arguments. It's prone to overthinking on competition math (VentureBeat).

The first two are the ones that bite pipeline builders. Most real automation isn't a model in its native harness; it's a model plugged into your tool definitions, your function schemas, your retry logic. If your agent passes deeply nested JSON arguments to tools, expect failures that a benchmark run in Poolside's own harness would never show.

I also haven't found a source confirming that Laguna S 2.1 works with Claude Code or an Anthropic-compatible API. Treat that as unconfirmed. If you want to point Claude Code at a different backend, you'd go through a gateway or proxy that translates the API, and you'd need to test whether tool calls survive the translation. Don't assume.

A defensive pattern for any non-native model is to validate and repair tool arguments before executing them:

import json
from jsonschema import validate, ValidationError

def safe_tool_call(raw_args: str, schema: dict, repair_fn=None):
    """Parse and validate model-produced tool arguments.
    Fail loudly instead of executing malformed calls."""
    try:
        args = json.loads(raw_args)
        validate(instance=args, schema=schema)
        return args
    except (json.JSONDecodeError, ValidationError) as e:
        if repair_fn:
            # e.g. re-prompt the model once with the validation error
            return repair_fn(raw_args, str(e))
        raise

Log every validation failure per model. That error rate is your real compatibility metric, and it's something no leaderboard will give you.

A routing approach that makes sense

Given the numbers above, the sensible position isn't "replace your frontier model." It's "stop paying frontier prices for work that doesn't need a frontier model." A tiered setup looks like this:

The key enabler is a verification step that doesn't depend on the model's confidence: run the test suite, lint, type-check. A cheap model with a strict gate often beats a pricier model with no gate.

A minimal routing config might look like this (the tier names and thresholds are my own illustration, not a product feature):

routes:
  - match: { files_changed_max: 3, has_tests: true }
    model: laguna-s-2.1
    thinking: off
  - match: { files_changed_max: 15, has_tests: true }
    model: laguna-s-2.1
    thinking: max
    on_failure: escalate
  - match: { default: true }
    model: frontier   # your current provider's top model
gates:
  - run: "pytest -q"
  - run: "ruff check ."
max_retries: 1

The on_failure: escalate line is the part that saves money without costing quality: let the cheap model try, let tests judge, and only pay frontier rates when the cheap attempt fails. Measure your escalation rate for a couple of weeks. If it's 60%, the savings are thin. If it's 15%, you've found real money.

Read the license before you build on it

The weights ship under OpenMDW-1.1. Secondary sources describe it as permissive and allowing commercial use, but I haven't read the license text. Read it yourself, along with the terms of use of whichever hosting provider you choose and Poolside's own usage terms, especially if you plan to fine-tune, redistribute, or embed the model in a product you sell to clients. "Open-weight" is not a synonym for "do whatever you want."

Also keep the data-handling distinction clear. Hosted endpoints send your prompts to a third party, and the free tier may train on them. Self-hosted weights keep data local but put the operational burden on you. Pick deliberately per project.

Where this fits in my own work

I build AI automations for solopreneurs and small teams, and cost-sensitive workloads are where smaller open-weight models earn a look. The pattern I use is the one above: route by task difficulty, gate every output with tests and schema validation, and escalate to a stronger model only on failure. Whether a model like Laguna S 2.1 earns a slot depends on how it performs on your own code and tool definitions, not on public benchmarks. The honest outcome is sometimes "keep Claude for everything" and sometimes "move a chunk of the volume to a cheaper tier." Measured results should decide which one it is.

What to do this week

1. Skim the trajectories. Read a handful of failed runs at trajectories.poolside.ai to see how the model fails before you commit.
2. Pick 20 real tasks from your recent history with known-good outcomes (merged PRs with passing tests).
3. Run them through a hosted endpoint with thinking off and max, and through your current model. Record pass rate, retries, tool-call JSON errors and token spend.
4. Compute cost per accepted result, not cost per token.
5. Decide the routing split from your own data, and re-run the test when the next model drops. Rankings shift fast, and any leaderboard position cited today may be stale next month.

Laguna S 2.1 is a credible, transparent, cheap option for the easier slice of coding-agent work, and a poor bet to treat as a drop-in frontier replacement. The only way to know which slice yours is, is to measure it.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.