Poolside: Laguna XS 2.1 (free)

Poolside Laguna XS 2.1 is a mixture-of-experts language model for agentic coding and long-horizon work, positioned as the smaller local-deployment model in the Laguna series. It has 33B total parameters and 3B active per token. It is an updated model relative to Laguna XS.2, retaining that model’s architecture while improving the maker’s reported software-engineering and terminal-task results. The model accepts text and generates text, code, reasoning and tool-call requests.

Its 40-layer design combines 10 global-attention layers and 30 sliding-window layers, with sigmoid gating and a 512-token sliding window. That local-attention window is separate from the model’s 262,144-token context. Poolside also describes an FP8 KV-cache design to reduce memory per token. These features help explain the model’s local-deployment focus, but the precise memory requirement still depends on the checkpoint, quantization, working context and serving configuration.

For a coding task, give the relevant source files as text, the expected behavior and the actual error or failing output. A useful request is: “Fix this parser’s treatment of escaped delimiters while preserving the published input format. Show the proposed change, explain which cases are affected, and identify examples that would reveal a regression.” Keep a concrete deliverable and a completion condition so the model can work toward a result rather than merely discuss the problem.

For terminal-style tasks, provide the current environment, relevant command output and constraints on the work. In a tool-connected application, the model proposes a function call, the application executes it, and the result is returned for the next decision. Ask it to explain what a failure reveals before proposing another command. For example, supply the dependency manifest and the failed installation output, then request the smallest source-grounded correction and the expected result of the next check. Preserve earlier successful steps and the unresolved issue in the history.

Laguna XS 2.1 is designed for interleaved thinking before and between tool calls. The manufacturer recommends retaining reasoning content from earlier assistant messages when reconstructing the next request. Dropping that content can prevent further reasoning in follow-up steps. Keep the assistant response, its tool-call information and the matching tool result together, with the ongoing objective visible. This is particularly useful when several observations contribute to a fix and a later step depends on a decision made earlier.

Thinking can be enabled or disabled through the chat template. Poolside recommends enabling it for agentic coding and preserving it across turns. A direct-answer request may suit a small transformation or explanation, while a repair with several dependent conditions benefits from a continuing reasoning-and-observation loop. State the final output format and leave room for the final answer. The manufacturer’s evaluation settings are recipe choices, not a universal guarantee about the amount of reasoning or the maximum answer length.

For long source input, organize files and documentation with clear boundaries and stable names. Ask for a specific relationship to trace, such as which callers depend on a changed interface, which conditions distinguish two implementations, or why a test result contradicts the proposed diagnosis. Keep the important decisions and actual checks in a compact task record, and remove irrelevant history. The context limit covers the working material and generated continuation; an entire context-sized final response is not a separate promised capacity.

Poolside publishes BF16 and separate FP8, NVFP4, INT4 and GGUF variants, as well as DFlash draft-model artifacts. These are different deployment choices. A small active parameter count does not mean the complete model weights occupy only that amount of memory, and a draft model is an acceleration companion rather than the coding model itself. Retain the exact checkpoint when comparing local results, and prepare code or document contents as text for this text-to-text model.

The maker documents a tool-parser issue in older serving builds that can drop certain calls and expose their raw markup as ordinary response text. This illustrates why a tool-connected workflow needs to distinguish the model’s intended request from a correctly parsed function call. Inspect the parsed name and arguments, validate them against the actual schema, and preserve the execution result. A final report should identify the revised artifact, the observed checks and the remaining assumptions. A proposed patch or command becomes a completed result only when its behavior is established by those records.