Poolside Laguna S 2.1 Guide: Serving, API and Benchmarks

Poolside released Laguna S 2.1 on July 21, 2026. This guide reconciles Poolside's launch claims with the official Hugging Face files, runtime recipes, trajectory archive, hosted-provider listings, and legal pages as they stood on July 22. The result is a deployment guide for engineers choosing a checkpoint, inference engine, API, or coding-agent scaffold—not a claim that launch benchmarks transfer unchanged to production.

What Poolside released

Laguna S 2.1 is a text-to-text Mixture-of-Experts model trained for agentic coding and long-horizon work. Poolside uses 118B-A8B as the rounded product label; the precision-specific model cards report 117.6B total parameters and 8.5B active parameters. It is larger than Laguna XS 2.1 and smaller than Laguna M.1 by total and active parameter counts. Do not transfer XS 2.1's 33B-A3B size, 256K context, or runtime behavior to this model merely because both use the laguna architecture.

The release has four distinct availability layers:

Poolside also created a public Laguna-S-2.1-base repository, but it contains metadata and license files rather than base weights. Its README directs researchers to email Poolside. Treat that as an access path, not a downloadable base checkpoint.

The 118B-A8B architecture and its real context boundary

The official model card and raw configuration describe the following architecture:

Sparse activation mainly reduces compute per generated token. All expert weights still have to live somewhere, so capacity planning follows the full checkpoint size, not the active-parameter headline. The 1M setting also does not make a million-token request cheap: global-attention KV state, runtime buffers, batching, and generated tokens consume memory beyond the model file.

There is a second context caveat. The BF16 configuration declares 1,048,576 tokens, while the official FP8, NVFP4, INT4, and GGUF guidance commonly ships at 262,144 and recommends 256K for output quality. Poolside documents manual RoPE changes for longer runs, but configuration acceptance is not the same as validated accuracy across the full window. Start at the checkpoint's documented default and increase context only after retrieval, tool-use, latency, and memory tests pass.

The shipped implementation uses sigmoid for MoE expert-routing scores and a separate softplus per-head attention-output gate. The model card's “softplus routing” wording appears to conflate those two mechanisms.

Thinking modes, preserved reasoning, and DFlash

Laguna S 2.1 launches with thinking on or off. It does not expose a documented low/medium/high effort scale. For self-hosted chat-template calls, the per-request control is:

extra_body={
    "chat_template_kwargs": {
        "enable_thinking": False
    }
}

When thinking is enabled, preserve reasoning_content from earlier assistant messages in conversation history. Poolside warns that dropping those blocks can cause the model to stop reasoning on later tool steps. This is an integration requirement: a gateway or agent that retains only visible answer text can silently change multi-turn behavior.

Poolside reports a large thinking-mode spread in its own harness: 70.2 versus 60.4 on Terminal-Bench 2.1, and 40.4 versus 16.5 on DeepSWE. Those are vendor-run results, not a reason to leave thinking enabled for every request. The same launch post says reasoning can continue longer than expected, so measure cost, wall time, useful tool progress, and abort behavior.

DFlash is a six-layer draft model for speculative decoding. It proposes token blocks that the target model verifies, aiming to reduce latency without replacing the target model's distribution. The BF16 DFlash artifact is about 2.08 GiB, which must be added to target-model and cache memory.

The current checkpoint default is 15 proposed tokens. The vLLM recipe also validates 15 and reports about 3.1 accepted tokens per step on its natural-text test, while the Poolside llama.cpp example caps the draft at 15. An older main-card example uses seven. Treat 15 as the current starting configuration, not a universal optimum. Benchmark acceptance rate, latency, throughput, and memory on your prompt distribution.

Checkpoints, downloads, and realistic hardware

The following sizes come from Poolside's official Hugging Face repository blobs, not parameter-count multiplication. They are download/storage sizes; loaded memory varies by engine and kernel.

Poolside's S 2.1 artifacts support a roughly 75 GB Q4_K_M download, a 256K quantized checkpoint configuration, and increasing context as memory allows. They do not publish a 32K–64K recommendation for S 2.1. On a 128 GB unified-memory system, 32K is AgentPedia's conservative test starting point, leaving room for KV cache and runtime overhead; raise it only after measuring your batch size, prompt mix, latency, and memory headroom.

For teams comparing owned hardware with rented GPUs, AgentPedia's GPU cloud guide explains the surrounding capacity and procurement tradeoffs. Before renting a large node, load the exact checkpoint, parser, context, batch size, and speculative decoder you plan to serve.

Serve Laguna S 2.1 locally

These commands are adapted from Poolside's model card and engine-specific pages. At the July 22 cutoff, vLLM base serving requires 0.25.0 or later and the documented DFlash path is validated on 0.25.1. SGLang's Laguna S 2.1 cookbook requires current main, then at 9456cef279ea42f032431600e88e5c2d2752bb86, and does not identify a tagged minimum release. TensorRT-LLM's --tool_parser poolside_v1 --reasoning_parser laguna interface appears in the 1.3 release-candidate documentation; the reviewed main snapshot was 9095cc11d10971ec9954310f706f0e09d257eb18. Treat those hashes as dated review points, pin exact builds, and validate Laguna and DFlash separately.

vLLM

The official vLLM recipe requires vLLM 0.25.0 or later at the research cutoff. Poolside's basic multi-GPU command is:

vllm serve poolside/Laguna-S-2.1 \
  --trust-remote-code \
  --revision 179ee67cf0fff5391c67fe1a392ea849fa6d643f \
  --code-revision 179ee67cf0fff5391c67fe1a392ea849fa6d643f \
  --tokenizer-revision 179ee67cf0fff5391c67fe1a392ea849fa6d643f \
  --host 127.0.0.1 \
  --api-key "$LAGUNA_API_KEY" \
  --tensor-parallel-size 4 \
  --tool-call-parser poolside_v1 \
  --reasoning-parser poolside_v1 \
  --enable-auto-tool-choice \
  --served-model-name laguna \
  --default-chat-template-kwargs '{"enable_thinking": true}'

Add DFlash only after the target works by itself. For production, use vLLM 0.25.1 or later, stage both target and draft at reviewed immutable revisions, and point serving at those local snapshots. The current recipe requires the Triton MoE backend:

--speculative-config '{"model":"/srv/models/Laguna-S-2.1-DFlash","num_speculative_tokens":15,"method":"dflash"}' \
--moe-backend triton

The recipe separately recommends explicit production context and parallelism settings, including 262,144 tokens and larger TP on suitable hardware. Copying TP4 into a node that cannot hold the weights and KV cache will not make it fit.

SGLang

The SGLang Laguna cookbook documents precision-specific hardware constraints. Poolside's model-card command is:

python -m sglang.launch_server \
  --model-path poolside/Laguna-S-2.1 \
  --revision 179ee67cf0fff5391c67fe1a392ea849fa6d643f \
  --host 127.0.0.1 \
  --api-key "$LAGUNA_API_KEY" \
  --tp-size 4 \
  --reasoning-parser poolside_v1 \
  --tool-call-parser poolside_v1 \
  --trust-remote-code

That immutable repository revision pins the target, tokenizer, and executable remote code together. Review the code before enabling it. If you add DFlash, also set --speculative-draft-model-revision to a reviewed commit or serve a staged local snapshot.

NVIDIA TensorRT-LLM

Poolside documents a different reasoning-parser name for TensorRT-LLM:

trtllm-serve /srv/models/Laguna-S-2.1 --trust-remote-code \
  --host 127.0.0.1 \
  --tool_parser poolside_v1 \
  --reasoning_parser laguna

The path above must be a verified local snapshot containing the pinned target, tokenizer, and reviewed executable code. Laguna and DFlash support landed through separate merged TensorRT-LLM changes. Validate the exact release and checkpoint precision; do not translate vLLM's underscore/hyphen flags or poolside_v1 reasoning parser mechanically. The reviewed trtllm-serve CLI does not establish server-side API-key enforcement, so keep it on loopback or behind an authenticated TLS proxy.

llama.cpp

Upstream base Laguna support merged on July 22, but Poolside's model card still directs full S 2.1 and DFlash use to its laguna fork:

git clone https://github.com/poolsideai/llama.cpp
cd llama.cpp
git checkout 04b2b72cb54048ead292884adbe11f284e3ec950
cmake -B build
cmake --build build -j

./build/bin/llama-server \
  -m laguna-s-2.1-Q4_K_M.gguf \
  --jinja \
  --host 127.0.0.1 \
  --api-key "$LAGUNA_API_KEY" \
  --port 8000

With the official GGUF draft model:

./build/bin/llama-server \
  -m laguna-s-2.1-Q4_K_M.gguf \
  -md laguna-s-2.1-DFlash-BF16.gguf \
  --spec-type draft-dflash \
  --spec-draft-n-max 15 \
  -fa on \
  --jinja \
  --host 127.0.0.1 \
  --api-key "$LAGUNA_API_KEY" \
  --port 8000

The commit above is the reviewed July 22 snapshot, not a timeless latest recommendation. Pin a reviewed commit because Poolside's branch has no release. For every engine, terminate TLS and enforce authorization at a reviewed reverse proxy before binding beyond loopback. vLLM otherwise defaults to all interfaces without a key; SGLang and llama.cpp default to loopback without a key; TensorRT-LLM defaults to localhost and its sample client key is not evidence of server-side authentication.

Hosted IDs, context, output, and price

Provider facts below are volatile and dated July 22, 2026. Prices are per million tokens.

Poolside's API overview documents an OpenAI-compatible Platform base URL of https://inference.poolside.ai/v1; a Poolside deployment uses its own API domain, such as https://poolside.example/openai/v1. List models first:

curl --request GET \
  --url https://inference.poolside.ai/v1/models \
  --header 'Accept: application/json, application/problem+json' \
  --header "Authorization: Bearer $POOLSIDE_API_KEY"

This avoids treating a gateway slug as proof of the model ID enabled for a Poolside account. Hosted-price comparisons also need the cost of long reasoning, retries, cache misses, tool execution, and agent time; AgentPedia's coding-model cost guide provides a broader comparison framework.

Pool and coding-agent integrations

Poolside's launch page names pool, Kilo, Hermes Agent, Pi, OpenCode, OpenClaw, and Cline as launch integrations. The strongest first-party path is Poolside's own pool agent, which can use Poolside, OpenRouter, Ollama, or another OpenAI-compatible endpoint and can act as an ACP client or server. In pool, the launch page says /thought-level toggles thinking for the session.

Poolside also publishes setup pages for Hermes, OpenCode, Kilo Code, Pi, Cline, and other clients. Integration claims need one qualifier: Poolside explicitly names Hermes Agent's terminal schema as an example of launch-day harness overfitting. The model can initially emit the remembered Poolside terminal shape instead of Hermes's slightly different definition; a rejected call and retry often corrects it, but that behavior belongs in a compatibility test.

If Hermes is your scaffold, use AgentPedia's Hermes Agent guide for the surrounding agent setup, then run Laguna-specific schema and reasoning-preservation tests. Do not assume “available in Hermes” means every nested tool argument is valid.

What the benchmark table actually proves

All Laguna S 2.1 values below are Poolside-run, vendor-reported results. Harnesses differ by benchmark, so they are not independent reproductions or a single controlled harness comparison.

Poolside's comparison chart selects the maximum available comparator score from a vendor report, benchmark-author leaderboard, or Artificial Analysis, except that it excludes third-party figures for SWE Atlas. That makes the chart useful for orientation but not a controlled model-only experiment. Poolside also does not publish every sampling parameter, timeout, token budget, or resource allocation for all six S 2.1 runs.

The SWE-Bench Pro result deserves an additional warning. OpenAI's contemporaneous benchmark audit argues that broken tasks now materially distort the benchmark. A 59.4 launch score is still a reportable vendor result; it should not be treated as a precise estimate of production issue-resolution probability.

What the published trajectories add

Poolside's trajectory archive is more useful than a static score because it exposes tool steps and results from the evaluation runs. Its Terminal-Bench page states pass@1 over four attempts and notes that a timed-out attempt may have no trajectory. That qualification matters: Poolside's launch says it publishes every final-evaluation trial, while the archive explains why a global timeout can leave no trajectory artifact.

Use trajectories to inspect behavior, not just success:

• Did the model follow the current tool schema on its first call?
• How much work happened in reasoning versus terminal steps?
• Did it verify tests or declare success early?
• How often did recovery come from the model versus harness feedback?
• Did thinking mode improve task completion enough to justify its token and time cost?

Poolside also publishes several demonstrations. They remain vendor-run case studies:

These examples show persistence and inspectable work. They are not substitutes for blinded tasks from your repositories.

Known limitations, safety, and data handling

Poolside discloses three model-specific failure modes:

1. Harness overfitting. The first tool call can follow a remembered Poolside schema instead of a similar third-party definition, including Hermes Agent's terminal tool.
2. Nested tool-call serialization. Arguments containing JSON arrays, such as some Pi edit operations, can be incorrectly escaped or invalid.
3. Overthinking. Reasoning can run for long stretches without useful progress, especially on competition mathematics, and there is no effort control between off and maximum at launch.

Add the ordinary system risks: the model is text-only, tool output can contain prompt injection, generated patches can be insecure, and a 1M window increases the amount of potentially sensitive code retained by a hosted request. Use least-privilege credentials, sandbox shell access, require approval for destructive or external actions, and log reasoning/tool boundaries in a form your team can audit.

For self-hosting, review trust_remote_code, model and runtime revisions, exposed ports, and downloaded artifacts. For hosted access, review provider routing, retention, training, region, subcontractors, and opt-out behavior before sending proprietary code. An OpenAI-compatible wire format does not make those policies equivalent.

OpenMDW-1.1 is permissive, but the legal stack has layers

The main checkpoints include the OpenMDW-1.1 license. In practical terms, it:

• grants broad, royalty-free rights to deal in the supplied Model Materials;
• requires redistributions to keep the license and applicable copyright/origin notices;
• terminates grants for certain non-defensive patent or copyright litigation over the Model Materials;
• imposes no model-license obligations on generated outputs;
• provides the materials as-is and leaves third-party rights clearance and due diligence to the user.

OpenMDW applies to materials actually supplied under it. It does not require Poolside to release training data or every model component, which is why the inaccessible base weights matter. “Open weight” is more precise here than “fully reproducible.”

The model license itself does not incorporate an acceptable-use policy. Separately, the model card says use should be consistent with Poolside's AUP and advises against removing guardrails without equivalent mitigations. At the research cutoff, the linked AUP URL unexpectedly served Poolside's Terms of Use and defined an AUP by reference to that same URL. This circular/mislabeled document is an unresolved legal-documentation issue; ask Poolside which AUP text applies before deployment.

Poolside's hosted-service Terms distinguish models from hosted “Products.” For those Products, the reviewed terms prohibit highly sensitive data without written permission, put responsibility for agent actions and output verification on the customer, and allow Poolside to use content for service improvement and model training unless the user opts out, with exceptions for feedback and safety review. Third-party gateways can impose different controls. Self-hosted model rights, Poolside-hosted service terms, and gateway terms should therefore be reviewed as separate layers.

A practical evaluation and migration plan

Before deployment

• Record immutable target, tokenizer, executable-code, and DFlash revisions; pin the runtime/container digest and Poolside llama.cpp commit; download into a controlled artifact store; verify expected files and SHA-256 digests; then serve local snapshots with outbound network access disabled where practical.
• Explicitly set bind address and authentication for every engine. Keep unauthenticated engines behind a loopback or Unix-socket boundary, or an authenticated TLS proxy.
• Confirm weight files plus KV cache, runtime, batch, and DFlash fit under sustained load—not only at startup.
• On a 128 GB local system, use AgentPedia's conservative 32K test starting point; expand only with measured quality and memory headroom.
• Verify cache-read/write price and observed cache-token accounting separately from retention policy. Confirm gateway retention, provider retention/training, ZDR eligibility, region, and cache behavior independently; OpenRouter treats provider in-memory prompt caching as compatible with its ZDR policy.
• Review OpenMDW redistribution notices and obtain a clear AUP answer; resolve the DFlash and GGUF licensing ambiguity before redistribution.

Build an evaluation set

• Use blinded tasks from at least three real repositories: a bounded bug, a cross-file feature, and a long-running test/debug task.
• Run thinking on and off with identical tools and budgets.
• Test first-call tool-schema adherence in every intended scaffold, especially Hermes and tools with nested arrays.
• Inject hostile instructions into repository text, issue bodies, test output, and documentation.
• Measure accepted patches, test pass rate, regressions, wall time, input/output/cache tokens, tool errors, retries, and reviewer time.

Migrate safely

1. Shadow existing agent runs without write or network authority.
2. Compare complete tool traces and accepted outcomes, not prose preference.
3. Add retry handling for invalid tool calls, but cap loops and surface repeated failures.
4. Preserve reasoning_content only through systems approved to store it; otherwise evaluate no-thinking behavior explicitly.
5. Canary one low-risk repository with human approval for every write and command.
6. Define rollback by model ID, endpoint, parser, and checkpoint revision before widening access.

Use Laguna S 2.1 or skip it?

Evaluate it now if you want an open-weight coding model with inspectable trajectories, credible four-bit local paths, long context, and both thinking and no-thinking behavior. It is especially interesting when a 128–256 GB workstation or a small high-memory GPU node is already available.

Use a hosted pilot first if buying hardware depends on proving sustained utilization, long-context quality, or latency. Keep the free 256K and paid 1M endpoints distinct in your results.

Wait if you need independent benchmark reproduction, a stable upstream-only DFlash path, fine-grained reasoning effort, a downloadable base checkpoint, or unambiguous AUP and DFlash license documentation.

Skip it for the current workflow if the agent must natively inspect images, if 67–75 GiB of quantized weights is already beyond the hardware budget, or if your security model cannot tolerate remote model code, agent tool execution, or provider-side code processing.

Sources and methodology

This article prioritizes first-party model, runtime, provider, and benchmark sources. It labels Poolside benchmark and case-study results as vendor-run and uses independent material only for benchmark methodology or a direct methodological challenge.

Poolside and model artifacts

• Poolside launch article, official launch post on X, and Laguna S 2.1 trajectory archive
• Laguna S 2.1 BF16, FP8, NVFP4, INT4, MLX NVFP4, GGUF, DFlash, and the official collection
• Shipped model implementation, raw configuration, and DFlash generation defaults
• OpenMDW-1.1 text, Poolside legal index, linked AUP URL, and Poolside API documentation

Runtime and hosted-provider sources

• vLLM Laguna S 2.1 recipe, SGLang cookbook, TensorRT-LLM Laguna change, and TensorRT-LLM DFlash change
• Pinned Poolside llama.cpp snapshot, upstream Laguna change, and Poolside local-running guide
• OpenRouter model page, data-collection policy, provider-logging controls, and prompt-caching guide
• Vercel AI Gateway listing, Vercel launch changelog, and Baseten model library entry
• Pool coding agent and Poolside's Hermes setup

Benchmark definitions and caveats

• Terminal-Bench 2.1, SWE-bench Multilingual, SWE-Bench Pro Public, DeepSWE paper, SWE Atlas Codebase QnA, and Toolathlon
• OpenAI's July 2026 SWE-Bench Pro audit