Poolside brings open-weight models into agentic coding workflows

Poolside develops foundation models for software engineering and the agent tools used to work with them. Its current offer includes the Laguna model family, a terminal agent called pool, editor integrations, a desktop client and self-managed inference documentation. That combination makes it relevant to teams that want to evaluate both the coding model and the environment around it, including a route to running model weights on infrastructure they control.

01 / ProductModels and the agent are related but separate

Poolside’s model page presents Laguna S 2.1 and Laguna XS 2.1 as models trained for agentic coding. It describes reinforcement learning inside its own harness, but claims about superior performance remain vendor claims. The practical offer is inspectable model weights and several ways to connect those models to development work.

The supported-model documentation distinguishes the larger S 2.1 from the smaller XS 2.1, and also lists M.1. S 2.1 has 118 billion total parameters with eight billion active per token; XS 2.1 has 33 billion total with three billion active. Active parameters describe computation, not the memory needed to store the entire model.

The getting-started page offers the pool terminal agent, a macOS desktop client and editor routes including VS Code, Visual Studio and ACP-compatible editors. The terminal client is a way to operate an agent; it is not itself proof that inference stays on the laptop. Where model requests go depends on the configured backend.

02 / AudienceFor teams that care about where coding inference runs

A software team may want assistance with a private codebase while retaining control of its model-serving environment. Poolside deserves consideration because its documentation covers hosted access, local model execution and self-managed inference. The useful question is whether the relevant model and runtime meet the team’s actual constraints, rather than whether open weights are desirable in the abstract.

It can also fit an individual developer experimenting with a terminal-first agent across several editors. ACP provides a connection between an editor and agent, which reduces the need to choose the whole coding workflow around one interface. That still leaves differences in how each editor exposes permissions, context and conversation state.

The Zed blueprint is a useful comparison for the editor layer, while the Tabnine blueprint helps frame enterprise coding assistance and deployment requirements. Poolside’s distinctive purchasing boundary includes its own foundation models. A team already satisfied with another model may value a different harness or administrative package more.

03 / WorkflowA proposed evaluation on a private repository

Use a repository that the team can evaluate without exposing production secrets. This proposed workflow asks an agent to explain a legacy data parser, add coverage for an ambiguous input and then make one behavior-preserving refactor. These stages separate code understanding, test design and implementation, making it easier to see where assistance succeeds or needs intervention.

Begin with hosted preview access if the data policy permits it. Ask the agent to identify the parser’s callers and current edge cases before editing. Give it a precise acceptance rule, such as preserving the existing handling of missing fields while removing duplicated conversion code. A bounded change is more informative than asking it to improve an entire repository.

Configure permissions for the project. Poolside separates tool rules and path rules, combines allow and deny rules across configuration scopes, and gives a matching deny priority. Its documentation explicitly says approvals are a convenience rather than a security boundary. Use an isolated environment when the evaluation requires stronger containment.

Review the added test before the refactor. The agent might encode its own mistaken interpretation as the expected result, so a passing test is only useful when a maintainer agrees with the behavior it specifies. Keep the original implementation available and compare its outputs on the same fixtures. Review the final patch independently of the agent’s explanation.

If local inference is the goal, repeat the task with a specific model artifact and runtime. The local Ollama guide connects a locally served model to pool and explains the relationship between weights, memory and context. Record the exact checkpoint and quantization; otherwise a local-versus-hosted comparison can quietly compare different model variants.

Measure the time to an accepted patch, peak memory, command failures and reviewer corrections. A model that fits in memory can still be too slow for interactive use, and a long theoretical context window can consume more memory than the available machine supports. Evaluate the working context required by this repository rather than maximizing the context setting.

If both routes produce usable results, decide which work belongs where. Local inference might suit repository explanation or small changes while a supported hosted route handles larger tasks. That is a proposed operating choice, not a guarantee that every Poolside model or client supports identical behavior across backends.

04 / PricingPreview access, model rights and service contracts

Free preview is useful for learning the workflow, but it is not a lifetime tariff or a production service-level commitment. The current public getting-started page establishes an entry route without proving that a particular organization receives unlimited usage. Before incorporating the service into a team-wide process, confirm limits and the terms that apply to the account.

The official XS 2.1 model card identifies OpenMDW-1.1 and points organizations to Poolside for production support, optimization or output indemnification. Downloading weights does not include those services. A self-managed budget should include memory-capable hardware, deployment maintenance, monitoring and the people who respond when the model server fails.

05 / DistinctionsThe model-to-harness connection is the interesting choice

Poolside gives a team the ability to investigate both the model and the surrounding software agent. That matters because coding performance is affected by file search, tool feedback, context management and the execution environment. A model score alone does not predict how well a particular repository task will finish in a particular harness.

The current supported-model page also distinguishes general model characteristics from access-method details. Identifiers and available variants can differ across providers. Treat the model name as the beginning of a configuration record, not the entire record: include endpoint, runtime, reasoning settings and tool policy.

Open weights can make evaluation and deployment more portable. They do not eliminate integration work. A team still needs a reproducible serving configuration and a method for checking that an upgrade preserves the behavior it relies on. That is particularly important when the application expects structured tool calls rather than ordinary prose.

06 / QuestionsVersion mismatches can change the deployment decision

The local Ollama guide still contains Laguna XS.2 examples and an Apache 2.0 license entry, while the current XS 2.1 model card specifies OpenMDW-1.1. Those are different releases. Do not copy the older model’s license or memory examples into an XS 2.1 procurement decision. Match the downloaded artifact to its own card and instructions.

Poolside’s permissions documentation explains that Auto mode may send approval-classification context to the configured model provider. An organization planning a local workflow should inspect that path as well as its primary model traffic. A local model server alone does not prove that every optional tool or approval feature is operating offline.

What level of support applies to the chosen self-managed environment? A model that can be launched experimentally is different from a configuration the vendor supports and patches. Keep the proof of concept honest about that boundary, and request a deployment-specific support scope before depending on it for a large engineering team.

07 / DecisionChoose the complete coding setup, not only the weights

Poolside is a useful candidate when coding-model choice and deployment control are connected requirements. Start with an observable repository task, compare the complete hosted or local setup, and make the commercial decision only after understanding the supported artifact and operating cost.