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": { "practical_html": "Technical example in English
Repair a last-line parser\n\nThis Python parser loses a final line without a trailing newline: def lines(text):\n return text.split("\\n")[:-1]\nReturn a corrected function that preserves nonempty final lines, avoids an artificial last empty line when text ends in a newline and returns [] for empty text. Include tests for all three cases.A corrected Python function, a short explanation and tests for newline, no-newline and empty input.Check that the last real line is retained and that only a trailing separator’s artificial empty entry is removed.mistralai/mistral-small-2603Mistral 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/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-small-2603 | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits Minimum items: 1 | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits Examples: system, user, assistant, tool, function Conditions: These roles are explicitly represented by Source compatibility types; the exact model role set remains model-specific. Model-specific | Default— |
Fieldmessages[].content | Typestring|content_part[]|null | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_calls | Typetool_call[] | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_call_id | Typestring | RequirementOptional | Values & limits Applies when: role=tool; use actual returned ID | Default— |
Fieldmessages[].name | Typestring | RequirementOptional | Values & limits | Default— |
Fieldmessages[].reasoning_content | Typestring | RequirementOptional | Values & limits Applies when: Round-trip actual returned reasoning where this model uses it | Default— |
Fieldmessages[].reasoning_details | Typeobject|array | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmax_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldmax_completion_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Fieldstream_options.include_usage | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtemperature | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtop_p | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldstop | Typestring|string[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools | Typefunction_tool[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools[].type | Typestring | RequirementOptional | Values & limits function Model-specific | Default— |
Fieldtools[].function.name | Typestring | RequirementRequired | Values & limits Applies when: function tool supplied | Default— |
Fieldtools[].function.description | Typestring | RequirementOptional | Values & limits | Default— |
Fieldtools[].function.parameters | TypeJSON_schema | RequirementOptional | Values & limits | Default— |
Fieldtool_choice | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldparallel_tool_calls | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldresponse_format | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning_effort | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldservice_tier | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldinstructions | Typestring | RequirementOptional | Values & limits Compatibility field | Default— |
Fieldfunctions | Typefunction[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldfunction_call | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldprompt_cache_options | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmodalities | Typestring[] | RequirementOptional | Values & limits text | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits Conditions: provider.options is rejected on this Ultra text route | Default— |
Fieldcache_control.ttl | Typestring | RequirementOptional | Values & limits Conditions: 1h is rejected in actual prompt-cache locations | Default— |
Text · UTF8 text
messages[].content
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages |
Parametermaterial_types | Contracttext |
Parametermessages | Contractmessage array with role/content shape |
Parameterfile_material | Contractactual UTF-8 document inserted as literal text; no file ID inferred |
Parameteroptional_controls | Contractstream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parametercontrol_scope | Contractmodel-specific; user function tools differ from hosted tools |
Parameteroutput_modalities | Contracttext |
Parameterhosted_operations | Contractfalse |
Parametermultimodal_input_binding | Contractnull |
Lifecycle: synchronous_or_streamed
Send exact model ID with messages.
Context length is not an output cap.
A text file may supply literal text; image/audio/file-object inputs need exact binding.
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.0003 / 1K tokens Output · Output tokens $0.0012 / 1K tokens Input · Cache read $0.00003 / 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.0003 / 1K tokens Output · Output tokens $0.0012 / 1K tokens Input · Cache read $0.00003 / 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,os\nfrom pathlib import Path\np=json.loads('{"model": "mistralai/mistral-small-2603", "messages": [{"role": "user", "content": "Explain the difference between an observation and a hypothesis in three sentences."}]}')\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\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model='mistralai/mistral-small-2603',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}])\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\nfrom openai import OpenAI\nimport os\nfrom pathlib import Path\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nwith client.chat.completions.stream(model='mistralai/mistral-small-2603',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}]) as stream:\n with Path("stream-events.jsonl").open("w",encoding="utf-8") as log:\n for event in stream:\n payload=event.to_dict(mode="json")\n log.write(json.dumps(payload,ensure_ascii=False)+"\\n"); log.flush()\n print(json.dumps(payload,ensure_ascii=False))\n final=stream.get_final_completion()\n save_result(final.to_dict(mode="json"),"stream-result")\njson or SSE
Keep every complete returned response, file and content part.
Keep every choice and its content/tool calls/reasoning. In SSE assemble deltas by choice/tool index, retain the final finish reason and usage.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldchoices[].index | Typeinteger |
Fieldchoices[].message.content | Typestring|null |
Fieldchoices[].message.tool_calls | Typetool_call[] |
Fieldchoices[].message.reasoning_content | Typestring |
Fieldchoices[].message.reasoning_details | Typeobject|array |
Fieldchoices[].finish_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra mistralai/mistral-small-2603
Use the method paths shown above.
mistralai/mistral-small-2603Mistral 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/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-small-2603 | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits user, assistant | Default— |
Fieldmessages[].content | Typestring | RequirementRequired | Values & limits | Default— |
Fieldmax_tokens | Typeinteger | RequirementRequired | Values & limits | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Text · UTF-8 text
messages[].content string
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages, max_tokens |
Parameteroptional_controls | Contractstream |
Parametermaterial_types | Contracttext |
Parametertext_file_material | ContractRead the actual UTF-8 document and put its text in the indicated input or message content string. |
Lifecycle: synchronous_or_streamed
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.0003 / 1K tokens Output · Output tokens $0.0012 / 1K tokens Input · Cache read $0.00003 / 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.0003 / 1K tokens Output · Output tokens $0.0012 / 1K tokens Input · Cache read $0.00003 / 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 →
{\n "model": "mistralai/mistral-small-2603",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'mistralai/mistral-small-2603', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'mistralai/mistral-small-2603', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON or SSE
Keep every complete returned response, file and content part.
Keep all content blocks, thinking signatures and actual tool-use IDs. Assemble all SSE block deltas; a first text block is not the complete output.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldid | Typestring |
Fieldmodel | Typestring |
Fieldcontent[] | Typetext|thinking|tool_use|other content block |
Fieldstop_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra mistralai/mistral-small-2603
Use the method paths shown above.
Technical example in English
Repair a last-line parser\n\nThis Python parser loses a final line without a trailing newline: def lines(text):\n return text.split("\\n")[:-1]\nReturn a corrected function that preserves nonempty final lines, avoids an artificial last empty line when text ends in a newline and returns [] for empty text. Include tests for all three cases.A corrected Python function, a short explanation and tests for newline, no-newline and empty input.Check that the last real line is retained and that only a trailing separator’s artificial empty entry is removed.