Liquid AI LFM2.5-2.6B is the post-trained text model in Liquid’s compact LFM2.5 family, designed for on-device agents and practical workflows. Its exact model card lists 2.69B parameters and 30 layers: 22 double-gated short-convolution blocks and eight grouped-query attention blocks. The hybrid design targets efficient text processing. The model accepts text and returns text, including a reasoned answer or a request to use a defined function.
The manufacturer recommends it for agentic workloads, tool use, data extraction, retrieval-augmented generation and long-context workflows. The release’s training pipeline combines supervised fine-tuning, specialized teachers, multi-domain on-policy distillation and reinforcement learning inside agent environments. This helps explain its focus on following task instructions, using tool observations and progressing through several steps. Give it the actual materials and a precise objective, rather than relying on broad learned knowledge to fill gaps.
For extraction, define the fields and source rules before supplying the material. A practical request is: “Read these service updates, extract each record’s identifier, stated status and next required action, and retain the sentence supporting every field. Return null when a field is missing.” Specify whether to copy a value exactly, normalize it or infer it. This makes the output inspectable and prevents a plausible interpretation from silently replacing information actually present in the source.
For RAG, provide relevant passages with stable labels and ask for an answer grounded in those passages. An example is: “Using only these installation instructions, explain which steps apply to the stated environment and list the prerequisites that remain unknown.” Keep document versions and conditions with the text. Ask the model to identify a missing or conflicting fact rather than invent a complete procedure. This fits the maker’s recommendation for source-grounded tasks better than asking the compact model to act as an exhaustive store of specialist knowledge.
LFM2.5-2.6B is a pure reasoning model: its chat template begins the assistant answer with a thinking marker, and it reasons before the final answer. The manufacturer’s model card recommends temperature 0.1, top-k 50 and repetition penalty 1.1 for generation. Those are settings for the named model’s recipe. Keep the final deliverable distinct from the reasoning text, and leave space for both in a working request. Controls or direct-answer modes belonging to other LFM instruction editions should not be assumed for this model.
The model uses a ChatML-like conversation format with system, user, assistant and tool roles. Its documented function workflow has four stages: define the tools, let the model request a function, execute that function in the surrounding application, and return the actual result so the model can answer. Native calls are Pythonic lists enclosed by tool-call markers; the maker also describes requesting JSON call format through the system instruction. Use the appropriate parser, check the function name and arguments against the supplied definitions, and retain the result with the call that produced it.
For a compact agent workflow, expose only the functions relevant to the current task, with concise descriptions and explicit argument types. Tool definitions themselves occupy context. A useful sequence might look up the status of a supplied record, compare the returned status with a rule and explain whether follow-up is needed. Supply the record identifier as evidence and ask for a final answer tied to the returned observation. The model proposes and interprets the operation; the application supplies its actual execution and result.
The current manufacturer model card specifies a 131,072-token model context, and the release describes a dedicated context-extension stage. Work within the window of the configuration in use, retaining source boundaries, relevant history and room for the continuation. For several documents, ask for a particular comparison or dependency to trace. The native checkpoint, GGUF, ONNX and MLX artifacts serve different deployment needs, and a speculative-decoding draft is a separate companion artifact. Resource or speed figures from one configuration do not automatically describe every model format and working window.
Liquid explicitly does not recommend LFM2.5-2.6B for agentic coding or knowledge-heavy tasks. Keep it focused on concrete workflows with supplied evidence, extraction rules and tool observations. The pre-trained Base checkpoint is also a separate artifact intended for customization, while this post-trained edition is the agent model. For the final result, inspect extracted values against their source, check that a cited passage supports the answer, and distinguish a requested tool call from an operation with a recorded outcome. Preserve unresolved information where it affects the conclusion instead of letting fluent text obscure it.
", "aboutText": "Liquid AI LFM2.5-2.6B is the post-trained text model in Liquid’s compact LFM2.5 family, designed for on-device agents and practical workflows. Its exact model card lists 2.69B parameters and 30 layers: 22 double-gated short-convolution blocks and eight grouped-query attention blocks. The hybrid design targets efficient text processing. The model accepts text and returns text, including a reasoned answer or a request to use a defined function.\n\nThe manufacturer recommends it for agentic workloads, tool use, data extraction, retrieval-augmented generation and long-context workflows. The release’s training pipeline combines supervised fine-tuning, specialized teachers, multi-domain on-policy distillation and reinforcement learning inside agent environments. This helps explain its focus on following task instructions, using tool observations and progressing through several steps. Give it the actual materials and a precise objective, rather than relying on broad learned knowledge to fill gaps.\n\nFor extraction, define the fields and source rules before supplying the material. A practical request is: “Read these service updates, extract each record’s identifier, stated status and next required action, and retain the sentence supporting every field. Return null when a field is missing.” Specify whether to copy a value exactly, normalize it or infer it. This makes the output inspectable and prevents a plausible interpretation from silently replacing information actually present in the source.\n\nFor RAG, provide relevant passages with stable labels and ask for an answer grounded in those passages. An example is: “Using only these installation instructions, explain which steps apply to the stated environment and list the prerequisites that remain unknown.” Keep document versions and conditions with the text. Ask the model to identify a missing or conflicting fact rather than invent a complete procedure. This fits the maker’s recommendation for source-grounded tasks better than asking the compact model to act as an exhaustive store of specialist knowledge.\n\nLFM2.5-2.6B is a pure reasoning model: its chat template begins the assistant answer with a thinking marker, and it reasons before the final answer. The manufacturer’s model card recommends temperature 0.1, top-k 50 and repetition penalty 1.1 for generation. Those are settings for the named model’s recipe. Keep the final deliverable distinct from the reasoning text, and leave space for both in a working request. Controls or direct-answer modes belonging to other LFM instruction editions should not be assumed for this model.\n\nThe model uses a ChatML-like conversation format with system, user, assistant and tool roles. Its documented function workflow has four stages: define the tools, let the model request a function, execute that function in the surrounding application, and return the actual result so the model can answer. Native calls are Pythonic lists enclosed by tool-call markers; the maker also describes requesting JSON call format through the system instruction. Use the appropriate parser, check the function name and arguments against the supplied definitions, and retain the result with the call that produced it.\n\nFor a compact agent workflow, expose only the functions relevant to the current task, with concise descriptions and explicit argument types. Tool definitions themselves occupy context. A useful sequence might look up the status of a supplied record, compare the returned status with a rule and explain whether follow-up is needed. Supply the record identifier as evidence and ask for a final answer tied to the returned observation. The model proposes and interprets the operation; the application supplies its actual execution and result.\n\nThe current manufacturer model card specifies a 131,072-token model context, and the release describes a dedicated context-extension stage. Work within the window of the configuration in use, retaining source boundaries, relevant history and room for the continuation. For several documents, ask for a particular comparison or dependency to trace. The native checkpoint, GGUF, ONNX and MLX artifacts serve different deployment needs, and a speculative-decoding draft is a separate companion artifact. Resource or speed figures from one configuration do not automatically describe every model format and working window.\n\nLiquid explicitly does not recommend LFM2.5-2.6B for agentic coding or knowledge-heavy tasks. Keep it focused on concrete workflows with supplied evidence, extraction rules and tool observations. The pre-trained Base checkpoint is also a separate artifact intended for customization, while this post-trained edition is the agent model. For the final result, inspect extracted values against their source, check that a cited passage supports the answer, and distinguish a requested tool call from an operation with a recorded outcome. Preserve unresolved information where it affects the conclusion instead of letting fluent text obscure it.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "cc78c451edffe92bef70469acb366527dae5e017225e241c0bfa848a23707d68", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "liquid/lfm-2.5-2.6b:freeLiquid AI LFM2.5-2.6B is a compact text reasoning model for agents, tool use, data extraction and RAG. Its hybrid design has 2.69B parameters. It reasons before answering and works best with concrete source material and clearly defined tools; the maker cautions against agentic coding and knowledge-heavy tasks.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Liquid AI LFM2.5-2.6B is the post-trained text model in Liquid’s compact LFM2.5 family, designed for on-device agents and practical workflows. Its exact model card lists 2.69B parameters and 30 layers: 22 double-gated short-convolution blocks and eight grouped-query attention blocks. The hybrid design targets efficient text processing. The model accepts text and returns text, including a reasoned answer or a request to use a defined function.
The manufacturer recommends it for agentic workloads, tool use, data extraction, retrieval-augmented generation and long-context workflows. The release’s training pipeline combines supervised fine-tuning, specialized teachers, multi-domain on-policy distillation and reinforcement learning inside agent environments. This helps explain its focus on following task instructions, using tool observations and progressing through several steps. Give it the actual materials and a precise objective, rather than relying on broad learned knowledge to fill gaps.
For extraction, define the fields and source rules before supplying the material. A practical request is: “Read these service updates, extract each record’s identifier, stated status and next required action, and retain the sentence supporting every field. Return null when a field is missing.” Specify whether to copy a value exactly, normalize it or infer it. This makes the output inspectable and prevents a plausible interpretation from silently replacing information actually present in the source.
For RAG, provide relevant passages with stable labels and ask for an answer grounded in those passages. An example is: “Using only these installation instructions, explain which steps apply to the stated environment and list the prerequisites that remain unknown.” Keep document versions and conditions with the text. Ask the model to identify a missing or conflicting fact rather than invent a complete procedure. This fits the maker’s recommendation for source-grounded tasks better than asking the compact model to act as an exhaustive store of specialist knowledge.
LFM2.5-2.6B is a pure reasoning model: its chat template begins the assistant answer with a thinking marker, and it reasons before the final answer. The manufacturer’s model card recommends temperature 0.1, top-k 50 and repetition penalty 1.1 for generation. Those are settings for the named model’s recipe. Keep the final deliverable distinct from the reasoning text, and leave space for both in a working request. Controls or direct-answer modes belonging to other LFM instruction editions should not be assumed for this model.
The model uses a ChatML-like conversation format with system, user, assistant and tool roles. Its documented function workflow has four stages: define the tools, let the model request a function, execute that function in the surrounding application, and return the actual result so the model can answer. Native calls are Pythonic lists enclosed by tool-call markers; the maker also describes requesting JSON call format through the system instruction. Use the appropriate parser, check the function name and arguments against the supplied definitions, and retain the result with the call that produced it.
For a compact agent workflow, expose only the functions relevant to the current task, with concise descriptions and explicit argument types. Tool definitions themselves occupy context. A useful sequence might look up the status of a supplied record, compare the returned status with a rule and explain whether follow-up is needed. Supply the record identifier as evidence and ask for a final answer tied to the returned observation. The model proposes and interprets the operation; the application supplies its actual execution and result.
The current manufacturer model card specifies a 131,072-token model context, and the release describes a dedicated context-extension stage. Work within the window of the configuration in use, retaining source boundaries, relevant history and room for the continuation. For several documents, ask for a particular comparison or dependency to trace. The native checkpoint, GGUF, ONNX and MLX artifacts serve different deployment needs, and a speculative-decoding draft is a separate companion artifact. Resource or speed figures from one configuration do not automatically describe every model format and working window.
Liquid explicitly does not recommend LFM2.5-2.6B for agentic coding or knowledge-heavy tasks. Keep it focused on concrete workflows with supplied evidence, extraction rules and tool observations. The pre-trained Base checkpoint is also a separate artifact intended for customization, while this post-trained edition is the agent model. For the final result, inspect extracted values against their source, check that a cited passage supports the answer, and distinguish a requested tool call from an operation with a recorded outcome. Preserve unresolved information where it affects the conclusion instead of letting fluent text obscure it.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits liquid/lfm-2.5-2.6b:free | Default— |
Fieldmessages | Typearray | RequirementRequired | Values & limits | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits false | Defaultfalse |
Fieldmax_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Maximum: 8,192 | Default— |
Fieldmax_completion_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Maximum: 8,192 | 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 65536 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": "liquid/lfm-2.5-2.6b: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 liquid/lfm-2.5-2.6b:free
Use the method paths shown above.
liquid/lfm-2.5-2.6b:freeLiquid AI LFM2.5-2.6B is a compact text reasoning model for agents, tool use, data extraction and RAG. Its hybrid design has 2.69B parameters. It reasons before answering and works best with concrete source material and clearly defined tools; the maker cautions against agentic coding and knowledge-heavy tasks.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Liquid AI LFM2.5-2.6B is the post-trained text model in Liquid’s compact LFM2.5 family, designed for on-device agents and practical workflows. Its exact model card lists 2.69B parameters and 30 layers: 22 double-gated short-convolution blocks and eight grouped-query attention blocks. The hybrid design targets efficient text processing. The model accepts text and returns text, including a reasoned answer or a request to use a defined function.
The manufacturer recommends it for agentic workloads, tool use, data extraction, retrieval-augmented generation and long-context workflows. The release’s training pipeline combines supervised fine-tuning, specialized teachers, multi-domain on-policy distillation and reinforcement learning inside agent environments. This helps explain its focus on following task instructions, using tool observations and progressing through several steps. Give it the actual materials and a precise objective, rather than relying on broad learned knowledge to fill gaps.
For extraction, define the fields and source rules before supplying the material. A practical request is: “Read these service updates, extract each record’s identifier, stated status and next required action, and retain the sentence supporting every field. Return null when a field is missing.” Specify whether to copy a value exactly, normalize it or infer it. This makes the output inspectable and prevents a plausible interpretation from silently replacing information actually present in the source.
For RAG, provide relevant passages with stable labels and ask for an answer grounded in those passages. An example is: “Using only these installation instructions, explain which steps apply to the stated environment and list the prerequisites that remain unknown.” Keep document versions and conditions with the text. Ask the model to identify a missing or conflicting fact rather than invent a complete procedure. This fits the maker’s recommendation for source-grounded tasks better than asking the compact model to act as an exhaustive store of specialist knowledge.
LFM2.5-2.6B is a pure reasoning model: its chat template begins the assistant answer with a thinking marker, and it reasons before the final answer. The manufacturer’s model card recommends temperature 0.1, top-k 50 and repetition penalty 1.1 for generation. Those are settings for the named model’s recipe. Keep the final deliverable distinct from the reasoning text, and leave space for both in a working request. Controls or direct-answer modes belonging to other LFM instruction editions should not be assumed for this model.
The model uses a ChatML-like conversation format with system, user, assistant and tool roles. Its documented function workflow has four stages: define the tools, let the model request a function, execute that function in the surrounding application, and return the actual result so the model can answer. Native calls are Pythonic lists enclosed by tool-call markers; the maker also describes requesting JSON call format through the system instruction. Use the appropriate parser, check the function name and arguments against the supplied definitions, and retain the result with the call that produced it.
For a compact agent workflow, expose only the functions relevant to the current task, with concise descriptions and explicit argument types. Tool definitions themselves occupy context. A useful sequence might look up the status of a supplied record, compare the returned status with a rule and explain whether follow-up is needed. Supply the record identifier as evidence and ask for a final answer tied to the returned observation. The model proposes and interprets the operation; the application supplies its actual execution and result.
The current manufacturer model card specifies a 131,072-token model context, and the release describes a dedicated context-extension stage. Work within the window of the configuration in use, retaining source boundaries, relevant history and room for the continuation. For several documents, ask for a particular comparison or dependency to trace. The native checkpoint, GGUF, ONNX and MLX artifacts serve different deployment needs, and a speculative-decoding draft is a separate companion artifact. Resource or speed figures from one configuration do not automatically describe every model format and working window.
Liquid explicitly does not recommend LFM2.5-2.6B for agentic coding or knowledge-heavy tasks. Keep it focused on concrete workflows with supplied evidence, extraction rules and tool observations. The pre-trained Base checkpoint is also a separate artifact intended for customization, while this post-trained edition is the agent model. For the final result, inspect extracted values against their source, check that a cited passage supports the answer, and distinguish a requested tool call from an operation with a recorded outcome. Preserve unresolved information where it affects the conclusion instead of letting fluent text obscure it.
POST /v1/messagestexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits liquid/lfm-2.5-2.6b: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: 8,192 | 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 65536 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": "liquid/lfm-2.5-2.6b: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 liquid/lfm-2.5-2.6b:free
Use the method paths shown above.