Mistral Small 4 combines general instruction following, reasoning and coding in a single multimodal model. The maker describes it as unifying the Instruct, Magistral reasoning and Devstral coding families. It accepts text and images and returns text, with function calls and JSON output available for tool-assisted applications.
Architecture and key features
The release has 119 billion total parameters and activates 6.5 billion per token. Its mixture-of-experts architecture contains 128 experts, with 4 active, and the maker documents a 256k context window. The active parameter count and number of experts describe how the model is organized; they are distinct from the amount of text or image content included in one task.
The model provides instruction and reasoning functionality in the same checkpoint. The maker also identifies vision, system-prompt adherence and multilingual support across dozens of languages, including English, French, Spanish, German, Italian, Portuguese, Dutch, Chinese, Japanese, Korean and Arabic. A text instruction can therefore ask about an image or combine a written requirement with visible evidence, with the answer returned as text.
A visual task can provide a document page and ask for the values relevant to a named condition. Keep the labels and units readable and state whether the result should preserve the original wording, summarize it or compare it with another source. An interface task can pair a screenshot with the user's goal and request the relevant visible control and the evidence supporting a proposed next step.
Choosing instruction or reasoning mode
The released card documents reasoning effort none for an immediate instruction-style answer and high for reasoning, with high recommended for complex prompts. The choice is made per request within the same Small 4 model. An ordinary classification or short rewrite can have a different answer contract from a mathematical, visual or coding problem that needs a developed explanation.
The maker recommends temperature 0.7 for high reasoning effort. For none, it specifies temperatures between 0.0 and 0.7 according to the task. These settings describe the documented modes and do not turn reasoning effort into a guarantee of a correct result. Define the assumptions, output form and relevant source material before choosing how much reasoning the task requires.
For a worked problem, provide the full condition and ask for the important justified steps followed by the final expression. For a code task, provide the requirement, the affected function and a concrete input; request the proposed implementation separately from the explanation and examples. The maker's usage demonstrations include instruction following, a calculation tool applied to an image and visual reasoning, illustrating how text and visual evidence can enter these different tasks.
Coding, documents and tools
The model is positioned for codebase exploration and software-engineering agents, general assistants, document understanding and research. A coding-agent request can name the module to change, the interface to preserve and the behavior that should result. Supply the relevant source and failure evidence. The model can propose the next operation or a code change, while the application provides repository access, execution and feedback.
For document extraction, identify the required fields and how to represent missing information. A useful record can separate the document identifier, source statement, interpreted requirement and unresolved question. The maker's service card lists custom structured output and document question answering; the latter uses document processing and OCR to prepare text and structure before language-model analysis. A direct image question and an OCR-assisted document workflow should retain their own input preparation.
Function calling requires clearly described tools. The model selects a function and creates arguments; the application executes the operation and returns its result for the subsequent answer. The same logic applies whether the task is a lookup, a calculation or a coding operation. JSON formatting organizes an answer, while a tool call asks for an external action; the two should not be treated as interchangeable results.
The service card also lists predicted outputs, response prefixes, batching and agent conversations. Predicted outputs are useful when a document or code file must be regenerated with only a limited change and the rest of the content is known. Specify the edit and the material to preserve. Prefix continuation uses a known beginning of the response, while batching concerns submission of work rather than an additional reasoning mode.
Context and edition boundaries
Plan the written task, visual material, conversation and desired answer around the documented 256k context. The released usage example configures a 262,144-token context, while its 1,024-token generation example is not a separate maximum output capacity. The sources read do not provide an independent hard answer-length limit to substitute for the chosen task length.
Small 4 has its own 119B mixture-of-experts architecture and hybrid modes. It should not inherit the dense 128B architecture of Medium 3.5 or the separate Instruct and Reasoning editions of Ministral 3. The maker also releases distinct quantized and speculative-decoding artifacts; those are separate deployment artifacts rather than different content modalities. Preserve the named Small 4 release and the mode requested for the actual explanation, structured record or code result.
", "aboutText": "Mistral Small 4 combines general instruction following, reasoning and coding in a single multimodal model. The maker describes it as unifying the Instruct, Magistral reasoning and Devstral coding families. It accepts text and images and returns text, with function calls and JSON output available for tool-assisted applications.\n\nArchitecture and key features\n\nThe release has 119 billion total parameters and activates 6.5 billion per token. Its mixture-of-experts architecture contains 128 experts, with 4 active, and the maker documents a 256k context window. The active parameter count and number of experts describe how the model is organized; they are distinct from the amount of text or image content included in one task.\n\nThe model provides instruction and reasoning functionality in the same checkpoint. The maker also identifies vision, system-prompt adherence and multilingual support across dozens of languages, including English, French, Spanish, German, Italian, Portuguese, Dutch, Chinese, Japanese, Korean and Arabic. A text instruction can therefore ask about an image or combine a written requirement with visible evidence, with the answer returned as text.\n\nA visual task can provide a document page and ask for the values relevant to a named condition. Keep the labels and units readable and state whether the result should preserve the original wording, summarize it or compare it with another source. An interface task can pair a screenshot with the user's goal and request the relevant visible control and the evidence supporting a proposed next step.\n\nChoosing instruction or reasoning mode\n\nThe released card documents reasoning effort none for an immediate instruction-style answer and high for reasoning, with high recommended for complex prompts. The choice is made per request within the same Small 4 model. An ordinary classification or short rewrite can have a different answer contract from a mathematical, visual or coding problem that needs a developed explanation.\n\nThe maker recommends temperature 0.7 for high reasoning effort. For none, it specifies temperatures between 0.0 and 0.7 according to the task. These settings describe the documented modes and do not turn reasoning effort into a guarantee of a correct result. Define the assumptions, output form and relevant source material before choosing how much reasoning the task requires.\n\nFor a worked problem, provide the full condition and ask for the important justified steps followed by the final expression. For a code task, provide the requirement, the affected function and a concrete input; request the proposed implementation separately from the explanation and examples. The maker's usage demonstrations include instruction following, a calculation tool applied to an image and visual reasoning, illustrating how text and visual evidence can enter these different tasks.\n\nCoding, documents and tools\n\nThe model is positioned for codebase exploration and software-engineering agents, general assistants, document understanding and research. A coding-agent request can name the module to change, the interface to preserve and the behavior that should result. Supply the relevant source and failure evidence. The model can propose the next operation or a code change, while the application provides repository access, execution and feedback.\n\nFor document extraction, identify the required fields and how to represent missing information. A useful record can separate the document identifier, source statement, interpreted requirement and unresolved question. The maker's service card lists custom structured output and document question answering; the latter uses document processing and OCR to prepare text and structure before language-model analysis. A direct image question and an OCR-assisted document workflow should retain their own input preparation.\n\nFunction calling requires clearly described tools. The model selects a function and creates arguments; the application executes the operation and returns its result for the subsequent answer. The same logic applies whether the task is a lookup, a calculation or a coding operation. JSON formatting organizes an answer, while a tool call asks for an external action; the two should not be treated as interchangeable results.\n\nThe service card also lists predicted outputs, response prefixes, batching and agent conversations. Predicted outputs are useful when a document or code file must be regenerated with only a limited change and the rest of the content is known. Specify the edit and the material to preserve. Prefix continuation uses a known beginning of the response, while batching concerns submission of work rather than an additional reasoning mode.\n\nContext and edition boundaries\n\nPlan the written task, visual material, conversation and desired answer around the documented 256k context. The released usage example configures a 262,144-token context, while its 1,024-token generation example is not a separate maximum output capacity. The sources read do not provide an independent hard answer-length limit to substitute for the chosen task length.\n\nSmall 4 has its own 119B mixture-of-experts architecture and hybrid modes. It should not inherit the dense 128B architecture of Medium 3.5 or the separate Instruct and Reasoning editions of Ministral 3. The maker also releases distinct quantized and speculative-decoding artifacts; those are separate deployment artifacts rather than different content modalities. Preserve the named Small 4 release and the mode requested for the actual explanation, structured record or code result.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "0aee81b7deb93ebc5c63b8463583e5acb88a0f3779cbc4fd300725b13ad1ef4d", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "mistralai/mistral-small-2603:batchMistral Small 4 is a hybrid text-and-image model with instruction, reasoning and coding capabilities. Its 119B mixture-of-experts release activates 6.5B parameters per token and supports a 256k maker context, selectable reasoning effort, JSON and function calls.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Mistral Small 4 combines general instruction following, reasoning and coding in a single multimodal model. The maker describes it as unifying the Instruct, Magistral reasoning and Devstral coding families. It accepts text and images and returns text, with function calls and JSON output available for tool-assisted applications.
Architecture and key features
The release has 119 billion total parameters and activates 6.5 billion per token. Its mixture-of-experts architecture contains 128 experts, with 4 active, and the maker documents a 256k context window. The active parameter count and number of experts describe how the model is organized; they are distinct from the amount of text or image content included in one task.
The model provides instruction and reasoning functionality in the same checkpoint. The maker also identifies vision, system-prompt adherence and multilingual support across dozens of languages, including English, French, Spanish, German, Italian, Portuguese, Dutch, Chinese, Japanese, Korean and Arabic. A text instruction can therefore ask about an image or combine a written requirement with visible evidence, with the answer returned as text.
A visual task can provide a document page and ask for the values relevant to a named condition. Keep the labels and units readable and state whether the result should preserve the original wording, summarize it or compare it with another source. An interface task can pair a screenshot with the user's goal and request the relevant visible control and the evidence supporting a proposed next step.
Choosing instruction or reasoning mode
The released card documents reasoning effort none for an immediate instruction-style answer and high for reasoning, with high recommended for complex prompts. The choice is made per request within the same Small 4 model. An ordinary classification or short rewrite can have a different answer contract from a mathematical, visual or coding problem that needs a developed explanation.
The maker recommends temperature 0.7 for high reasoning effort. For none, it specifies temperatures between 0.0 and 0.7 according to the task. These settings describe the documented modes and do not turn reasoning effort into a guarantee of a correct result. Define the assumptions, output form and relevant source material before choosing how much reasoning the task requires.
For a worked problem, provide the full condition and ask for the important justified steps followed by the final expression. For a code task, provide the requirement, the affected function and a concrete input; request the proposed implementation separately from the explanation and examples. The maker's usage demonstrations include instruction following, a calculation tool applied to an image and visual reasoning, illustrating how text and visual evidence can enter these different tasks.
Coding, documents and tools
The model is positioned for codebase exploration and software-engineering agents, general assistants, document understanding and research. A coding-agent request can name the module to change, the interface to preserve and the behavior that should result. Supply the relevant source and failure evidence. The model can propose the next operation or a code change, while the application provides repository access, execution and feedback.
For document extraction, identify the required fields and how to represent missing information. A useful record can separate the document identifier, source statement, interpreted requirement and unresolved question. The maker's service card lists custom structured output and document question answering; the latter uses document processing and OCR to prepare text and structure before language-model analysis. A direct image question and an OCR-assisted document workflow should retain their own input preparation.
Function calling requires clearly described tools. The model selects a function and creates arguments; the application executes the operation and returns its result for the subsequent answer. The same logic applies whether the task is a lookup, a calculation or a coding operation. JSON formatting organizes an answer, while a tool call asks for an external action; the two should not be treated as interchangeable results.
The service card also lists predicted outputs, response prefixes, batching and agent conversations. Predicted outputs are useful when a document or code file must be regenerated with only a limited change and the rest of the content is known. Specify the edit and the material to preserve. Prefix continuation uses a known beginning of the response, while batching concerns submission of work rather than an additional reasoning mode.
Context and edition boundaries
Plan the written task, visual material, conversation and desired answer around the documented 256k context. The released usage example configures a 262,144-token context, while its 1,024-token generation example is not a separate maximum output capacity. The sources read do not provide an independent hard answer-length limit to substitute for the chosen task length.
Small 4 has its own 119B mixture-of-experts architecture and hybrid modes. It should not inherit the dense 128B architecture of Medium 3.5 or the separate Instruct and Reasoning editions of Ministral 3. The maker also releases distinct quantized and speculative-decoding artifacts; those are separate deployment artifacts rather than different content modalities. Preserve the named Small 4 release and the mode requested for the actual explanation, structured record or code result.
POST /v1/batchestexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldendpoint | Typestring | RequirementRequired | Values & limits /v1/chat/completions | Default— |
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-small-2603:batch | Default— |
Fieldrequests | Typebatch_item[] | RequirementRequired | Values & limits Minimum items: 1 | Default— |
Fieldrequests[].custom_id | Typestring | RequirementRequired | Values & limits | Default— |
Fieldrequests[].body.messages | Typemessage[] | RequirementRequired | Values & limits | Default— |
Fieldcompletion_window | Typestring | RequirementOptional | Values & limits 24h | Default— |
Fieldprovider | Typeobject|null | RequirementOptional | Values & limits | Default— |
Fieldrequests[].body.model | Typestring | RequirementOptional | Values & limits mistralai/mistral-small-2603:batch, mistralai/mistral-small-2603 | Default— |
Fieldprovider.only | Typestring[] | RequirementOptional | Values & limits mistral | Default— |
Fieldprovider.allow_fallbacks | Typeboolean|null | RequirementOptional | Values & limits false, null | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractendpoint, model, requests |
Parametermaterial_types | Contracttext |
Parameterrepresentation | Contractinline requests[]; each item has custom_id and body |
Parameterrequest_endpoint_profile | Contract/v1/chat/completions |
Parameterfile_material | ContractCaller may read actual UTF-8 JSONL locally into requests[]. No upload purpose, input_file_id or file reference is used. Missing/empty customer material stops preparation before POST. |
Parameterserialization_order | Contractendpoint, model, provider (if supplied), completion_window (if supplied), requests last |
Parameteroptional_controls | Contractprovider.only, provider.allow_fallbacks, completion_window |
Parameterschema_scope | ContractText Chat Completions bodies in the documented inline Batch envelope. |
Lifecycle: asynchronous
GET /v1/batches/{operation_id} · actual original create response.id; same user/key/group
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Context tokens, more than | Context tokens, up to and including | Charge |
|---|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Context tokens, more than— | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.00015 / 1K tokens Output · Output tokens $0.0006 / 1K tokens Input · Cache read $0.000015 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 1 | Rate schedule— | Context tokens, more than0 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.00015 / 1K tokens Output · Output tokens $0.0006 / 1K tokens Input · Cache read $0.000015 / 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}"\npython3 - <<'PY_REQUEST'\nimport json\nfrom pathlib import Path\nbody=json.loads('{"endpoint":"/v1/chat/completions","model":"mistralai/mistral-small-2603:batch","requests":[{"custom_id":"req-0001","body":{"messages":[{"role":"user","content":"Hello!"}],"max_tokens":16}}]}')\nPath("batch-request.json").write_text(json.dumps(body,ensure_ascii=False),encoding="utf-8")\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/batches \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @batch-request.json -D batch-response-headers.txt -o batch-create-response.json\nimport json, os\nfrom pathlib import Path\nfrom urllib.request import Request, urlopen\n\ndef prepare_requests(customer_path):\n path = Path(customer_path)\n if not path.is_file(): raise ValueError("Customer JSONL file is missing")\n items = [json.loads(line) for line in path.read_text(encoding="utf-8").splitlines() if line.strip()]\n if not items: raise ValueError("Customer JSONL contains no requests")\n ids = set()\n for item in items:\n if set(item) != {"custom_id", "body"}: raise ValueError("Each item needs custom_id and body")\n cid = item["custom_id"]\n if not isinstance(cid, str) or not cid.strip() or cid in ids: raise ValueError("custom_id must be nonempty and unique")\n ids.add(cid)\n if not isinstance(item["body"], dict) or not item["body"].get("messages"): raise ValueError("Supply actual text messages")\n supplied_model = item["body"].get("model")\n if supplied_model is not None and supplied_model not in ['mistralai/mistral-small-2603:batch', 'mistralai/mistral-small-2603']: raise ValueError("body.model must be an exact documented caller or wire ID")\n return {"endpoint":"/v1/chat/completions", "model":"mistralai/mistral-small-2603:batch", "requests":items}\n\nif __name__ == "__main__":\n material = os.environ.get("AILOOT_BATCH_REQUESTS_JSONL", "")\n if not material: raise SystemExit("Set AILOOT_BATCH_REQUESTS_JSONL to your actual customer file")\n body = prepare_requests(material)\n key = os.environ.get("AILOOT_API_KEY", "")\n if not key: raise SystemExit("Set AILOOT_API_KEY")\n request = Request("https://api.ailoot.ai/v1/batches", data=json.dumps(body, ensure_ascii=False).encode("utf-8"), headers={"Authorization":"Bearer " + key, "Content-Type":"application/json"}, method="POST")\n with urlopen(request) as response:\n raw = response.read()\n Path("batch-create-response.json").write_bytes(raw)\n print(raw.decode("utf-8"))\nimport json\nfrom pathlib import Path\nraw = Path("batch-status-response.json").read_bytes()\nresponse = json.loads(raw)\nif response.get("status") != "completed":\n raise SystemExit("Keep the original operation; read its status without resubmitting")\nresults = response.get("results")\nif not isinstance(results, list) or not results:\n raise SystemExit("Preserve the original response; completed results are missing")\nPath("batch-results.jsonl").write_text("".join(json.dumps(item, ensure_ascii=False) + "\\n" for item in results), encoding="utf-8")\n# Preserve batch-status-response.json with aggregate usage and every result/error.\ninline results[].response.body JSON
GET /v1/batches/{operation_id}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nBATCH_OPERATION_ID="$(python3 - <<'PY_ID'\nimport json\nfrom pathlib import Path\nfrom urllib.parse import quote\nresponse = json.loads(Path("batch-create-response.json").read_text(encoding="utf-8"))\noperation = response.get("id")\nif not isinstance(operation, str) or not operation: raise SystemExit("No actual original operation ID; preserve the response and do not resubmit")\nprint(quote(operation, safe=""))\nPY_ID\n)"\ncurl --fail-with-body --silent --show-error "https://api.ailoot.ai/v1/batches/$BATCH_OPERATION_ID" \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o batch-status-response.json\nKeep every complete returned response, file and content part.
Preserve the full original status JSON, every result/custom_id and complete response or error body. Save completed results[] as JSONL without filtering.
Preserve the original operation ID. 503 result_pending_check has X-Should-Retry:false; never resubmit an unknown original batch.
| Field | Type |
|---|---|
Fieldresults[].custom_id | Typestring |
Fieldresults[].response.body.choices[].message.content | Typestring|null |
Fieldresults[].error | Typeobject|null |
Fieldusage | Typeobject|null |
Fieldid | Typestring |
Fieldmodel | Typestring |
Fieldendpoint | Typestring |
Fieldstatus | Typestring |
Fieldrequest_counts | Typeobject |
Fieldresults[].id | Typestring |
Fieldresults[].response.status_code | Typeinteger |
Fieldresults[].response.request_id | Typestring |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid documented inline envelope, duplicate keys, item identity, or configured model capabilities conflict. | Next stepCorrect the indicated fields before any new submission. |
Response401 · authentication_error | ConditionInvalid API key. | Next stepUse the authorized Ailoot key. |
Response403 · permission_error | ConditionBatch group unavailable. | Next stepCheck key/group entitlement. |
Response422 · invalid_request_error | ConditionBatch uses balance billing; subscription creation is rejected. | Next stepUse the authorized balance-billed group. |
Response422 · price_unavailable | ConditionBatch input cannot be quoted. | Next stepPreserve response; use documented family input. |
Response402 · billing_error | ConditionBatch reserve unavailable. | Next stepResolve admission before a new request. |
Response503 · price_unavailable | ConditionBatch method price/native rates unavailable. | Next stepPreserve response; do not substitute prices. |
Response503 · api_error | ConditionExact supplier route unavailable. | Next stepPreserve response for route repair. |
Response503 · result_pending_check | ConditionOriginal result requires checking; X-Should-Retry:false. | Next stepKeep original operation_id/id and read its status; never repeat original POST. |
Response404 · not_found | ConditionBatch status operation absent or owned by another identity. | Next stepUse exact original id and same user/key/group. |
Ailoot Ultra mistralai/mistral-small-2603:batch
Use the method paths shown above.