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.
", "aboutText": "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.\n\nIts 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.\n\nFor 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.\n\nFor 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.\n\nLaguna 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.\n\nThinking 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.\n\nFor 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.\n\nPoolside 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.\n\nThe 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.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "fdb9089ff0fe6c3a49505d2a9e423d5de26faac7dcfa6bd5b82722ab00fc2faa", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "poolside/laguna-xs-2.1:freePoolside Laguna XS 2.1 is a 33B-total, 3B-active text model for agentic coding and long-horizon work. It has a 262,144-token context and native reasoning between tool calls. Its smaller MoE design and separate quantized releases support local deployment with configuration-dependent resource needs.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
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.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits poolside/laguna-xs-2.1:free | Default— |
Fieldmessages | Typearray | RequirementRequired | Values & limits | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits false | Defaultfalse |
Fieldmax_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Maximum: 32,768 | Default— |
Fieldmax_completion_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Maximum: 32,768 | Default— |
Fieldn | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Maximum: 128 | Default— |
Fieldtemperature | Typenumber | RequirementOptional | Values & limits | Default— |
Fieldtop_p | Typenumber | RequirementOptional | Values & limits | Default— |
Fieldseed | Typeinteger | RequirementOptional | Values & limits | Default— |
Fieldstop | Type | RequirementOptional | Values & limits | Default— |
Fieldfrequency_penalty | Typenumber | RequirementOptional | Values & limits | Default— |
Fieldpresence_penalty | Typenumber | RequirementOptional | Values & limits | Default— |
Fielduser | Typestring | RequirementOptional | Values & limits | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages |
Parameteroptional | Contractstream, max_tokens, max_completion_tokens, n, temperature, top_p, seed, stop, frequency_penalty, presence_penalty, user |
Parametermaterial_types | Contracttext |
Parameterconditions | ContractUse literal text messages only. Cache controls, tools, image/audio/video content and streamed responses are unavailable for this method., The complete encoded JSON request must not exceed 262144 bytes. |
Lifecycle: synchronous_json
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nexport AILOOT_API_KEY\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "poolside/laguna-xs-2.1:free", "messages": [{"role": "user", "content": "Summarize the supplied text in three concise points."}], "stream": false}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\n# Submit once. Retain the complete result, original identifiers and every response header.\nJSON
Keep every complete returned response, file and content part.
Retain the complete response, all actual results, original identifiers, usage and response headers.
Preserve the original response, headers and X-Client-Request-ID. An uncertain outcome does not authorize another creation.
Ailoot Ultra poolside/laguna-xs-2.1:free
Use the method paths shown above.
poolside/laguna-xs-2.1:freePoolside Laguna XS 2.1 is a 33B-total, 3B-active text model for agentic coding and long-horizon work. It has a 262,144-token context and native reasoning between tool calls. Its smaller MoE design and separate quantized releases support local deployment with configuration-dependent resource needs.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
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.
POST /v1/messagestexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits poolside/laguna-xs-2.1:free | Default— |
Fieldmessages | Typearray | RequirementRequired | Values & limits | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits false | Defaultfalse |
Fieldsystem | Typestring | RequirementOptional | Values & limits | Default— |
Fieldmax_tokens | Typeinteger | RequirementRequired | Values & limits Minimum: 1 Maximum: 32,768 | Default— |
Fieldtemperature | Typenumber | RequirementOptional | Values & limits | Default— |
Fieldtop_p | Typenumber | RequirementOptional | Values & limits | Default— |
Fieldtop_k | Typeinteger | RequirementOptional | Values & limits | Default— |
Fieldstop_sequences | Typearray | RequirementOptional | Values & limits | Default— |
Fieldmetadata | Typeobject | RequirementOptional | Values & limits | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages, max_tokens |
Parameteroptional | Contractstream, system, temperature, top_p, top_k, stop_sequences, metadata |
Parametermaterial_types | Contracttext |
Parameterconditions | ContractUse literal text messages only. Cache controls, tools, image/audio/video content and streamed responses are unavailable for this method., The complete encoded JSON request must not exceed 262144 bytes. |
Lifecycle: synchronous_json
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nexport AILOOT_API_KEY\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "poolside/laguna-xs-2.1:free", "messages": [{"role": "user", "content": "Summarize the supplied text in three concise points."}], "stream": false, "max_tokens": 256}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\n# Submit once. Retain the complete result, original identifiers and every response header.\nJSON
Keep every complete returned response, file and content part.
Retain the complete response, all actual results, original identifiers, usage and response headers.
Preserve the original response, headers and X-Client-Request-ID. An uncertain outcome does not authorize another creation.
Ailoot Ultra poolside/laguna-xs-2.1:free
Use the method paths shown above.