Mistral Small 3 Instruct 2501 is the 24-billion-parameter instruction-tuned release of Mistral Small 3. It is fine-tuned from the separately named Small 24B Base 2501 model. The maker positions it for responsive conversational assistance, function calling and subject-specific adaptation, with text as both the input and the generated result.
Core features and training distinction
The model card documents multilingual support, conversational and reasoning capabilities, native function calling, JSON output and adherence to system prompts. Its context window is 32k, and it uses a Tekken tokenizer with a vocabulary labeled 131k. The context label concerns the text retained for the task, while the vocabulary label describes tokenization; they are different specifications.
The maker lists languages including English, French, German, Spanish, Italian, Chinese, Japanese, Korean, Portuguese, Dutch and Polish, with Russian also present in the released card's language metadata. Define the final language and any terminology that should remain unchanged. A translated explanation can retain identifiers, names and units while adapting the surrounding prose to the reader.
The release announcement states that Small 3 is not trained with reinforcement learning or synthetic data and distinguishes pretrained and instruction-tuned checkpoints. It describes the model as a foundation that can be further customized, rather than a hybrid checkpoint with the later Small 4 reasoning controls. This entry is the Instruct 2501 edition for following a conversational task.
Conversational and structured tasks
For a support-style assistant, provide the user's question, relevant reference material and the response rules. Ask for the action that answers the question and the condition under which it applies. A practical output can separate a concise reply from extracted fields the application needs for the next step, rather than mixing them in an unstructured explanation.
For classification, provide the permitted labels and the distinctions between them. For extraction, name the fields, expected types and representation for missing information. A record might contain the issue category, an identifier copied from the message and a short summary of the requested action. JSON organizes the result, while the field design and interpretation rules remain part of the supplied task.
For a coding explanation, include the function, relevant declarations and a concrete input. Ask what path through the code determines the result. For a mathematical explanation, define variables and assumptions and identify the expression or claim to establish. These text-based tasks can return a method, an explanation and the final artifact without assuming that the model itself runs the code or an external calculation.
System instructions and recommended settings
The card recommends a system prompt tailored to the intended assistant and a relatively low temperature, such as 0.15. Use the system instruction to define the role, style and answer rules, while the user message carries the actual problem or source material. Keep quoted instructions inside a document separate from the application's instruction about what to do with that document.
For an everyday assistant, specify whether the result should be a short answer, a structured record or a longer explanation. If a response will be parsed, request the record separately from optional prose. In a repeated document workflow, preserve the source identifier beside each result so that the application can return the correct material to the user.
Function calling and specialization
The model can select a described function and produce its arguments. The application executes the operation and returns the result with the corresponding tool call, after which the next answer can use that information. The card's example shows a conversation with previous tool use followed by a new question. This gives the assistant a way to request information from connected tools without treating a proposed call as a completed lookup.
Describe each function's purpose and required values clearly. A lookup task can name the information needed and return the actual tool result to the conversation; a text-processing function can supply a transformed passage for the next response. Keep the tool set related to the current process, and retain the link between the proposed operation and its result.
The maker also describes fine-tuning for subject-matter specialization. That process changes a model for a defined domain; providing a document in one conversation is instead source conditioning for that task. Supply the domain material and response requirements needed by the particular assistant rather than assuming a customization has already been performed.
Context and substantive limits
Small 3 2501 is a text-only model with a 32k context. The vision capability and 128k context introduced in Small 3.1 belong to the later release, and Small 4's hybrid modes likewise should not be transferred here. An image, audio recording or video must have its relevant content prepared through another component before this text task.
The card's 256- and 512-token generation settings are usage examples, not separate maximum output capacities. Keep the exact Instruct 2501 identity, tokenizer and requested result explicit. The useful final artifact is the answer, JSON record or proposed code whose meaning and format match the original written task.
", "aboutText": "Mistral Small 3 Instruct 2501 is the 24-billion-parameter instruction-tuned release of Mistral Small 3. It is fine-tuned from the separately named Small 24B Base 2501 model. The maker positions it for responsive conversational assistance, function calling and subject-specific adaptation, with text as both the input and the generated result.\n\nCore features and training distinction\n\nThe model card documents multilingual support, conversational and reasoning capabilities, native function calling, JSON output and adherence to system prompts. Its context window is 32k, and it uses a Tekken tokenizer with a vocabulary labeled 131k. The context label concerns the text retained for the task, while the vocabulary label describes tokenization; they are different specifications.\n\nThe maker lists languages including English, French, German, Spanish, Italian, Chinese, Japanese, Korean, Portuguese, Dutch and Polish, with Russian also present in the released card's language metadata. Define the final language and any terminology that should remain unchanged. A translated explanation can retain identifiers, names and units while adapting the surrounding prose to the reader.\n\nThe release announcement states that Small 3 is not trained with reinforcement learning or synthetic data and distinguishes pretrained and instruction-tuned checkpoints. It describes the model as a foundation that can be further customized, rather than a hybrid checkpoint with the later Small 4 reasoning controls. This entry is the Instruct 2501 edition for following a conversational task.\n\nConversational and structured tasks\n\nFor a support-style assistant, provide the user's question, relevant reference material and the response rules. Ask for the action that answers the question and the condition under which it applies. A practical output can separate a concise reply from extracted fields the application needs for the next step, rather than mixing them in an unstructured explanation.\n\nFor classification, provide the permitted labels and the distinctions between them. For extraction, name the fields, expected types and representation for missing information. A record might contain the issue category, an identifier copied from the message and a short summary of the requested action. JSON organizes the result, while the field design and interpretation rules remain part of the supplied task.\n\nFor a coding explanation, include the function, relevant declarations and a concrete input. Ask what path through the code determines the result. For a mathematical explanation, define variables and assumptions and identify the expression or claim to establish. These text-based tasks can return a method, an explanation and the final artifact without assuming that the model itself runs the code or an external calculation.\n\nSystem instructions and recommended settings\n\nThe card recommends a system prompt tailored to the intended assistant and a relatively low temperature, such as 0.15. Use the system instruction to define the role, style and answer rules, while the user message carries the actual problem or source material. Keep quoted instructions inside a document separate from the application's instruction about what to do with that document.\n\nFor an everyday assistant, specify whether the result should be a short answer, a structured record or a longer explanation. If a response will be parsed, request the record separately from optional prose. In a repeated document workflow, preserve the source identifier beside each result so that the application can return the correct material to the user.\n\nFunction calling and specialization\n\nThe model can select a described function and produce its arguments. The application executes the operation and returns the result with the corresponding tool call, after which the next answer can use that information. The card's example shows a conversation with previous tool use followed by a new question. This gives the assistant a way to request information from connected tools without treating a proposed call as a completed lookup.\n\nDescribe each function's purpose and required values clearly. A lookup task can name the information needed and return the actual tool result to the conversation; a text-processing function can supply a transformed passage for the next response. Keep the tool set related to the current process, and retain the link between the proposed operation and its result.\n\nThe maker also describes fine-tuning for subject-matter specialization. That process changes a model for a defined domain; providing a document in one conversation is instead source conditioning for that task. Supply the domain material and response requirements needed by the particular assistant rather than assuming a customization has already been performed.\n\nContext and substantive limits\n\nSmall 3 2501 is a text-only model with a 32k context. The vision capability and 128k context introduced in Small 3.1 belong to the later release, and Small 4's hybrid modes likewise should not be transferred here. An image, audio recording or video must have its relevant content prepared through another component before this text task.\n\nThe card's 256- and 512-token generation settings are usage examples, not separate maximum output capacities. Keep the exact Instruct 2501 identity, tokenizer and requested result explicit. The useful final artifact is the answer, JSON record or proposed code whose meaning and format match the original written task.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Prepare a reference-grounded support answer\n\nAnswer this customer question using only the reference: 'Can I change the pickup location after the parcel is handed to the carrier?' Reference: 'Before handover, support may change the pickup location. After handover, the recipient must request a change from the carrier; availability depends on its route.' Return a concise reply and the condition supporting it.A short customer reply plus the reference condition that determines the next contact.The reply directs the handed-over parcel's request to the carrier and does not promise that a change is available.mistralai/mistral-small-24b-instruct-2501Mistral Small 3 Instruct 2501 is a 24B text model for conversational instructions, structured extraction and tool-assisted applications. It provides a 32k maker context, multilingual responses, system-prompt support, JSON and native function calling in a distinct text-only release.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Mistral Small 3 Instruct 2501 is the 24-billion-parameter instruction-tuned release of Mistral Small 3. It is fine-tuned from the separately named Small 24B Base 2501 model. The maker positions it for responsive conversational assistance, function calling and subject-specific adaptation, with text as both the input and the generated result.
Core features and training distinction
The model card documents multilingual support, conversational and reasoning capabilities, native function calling, JSON output and adherence to system prompts. Its context window is 32k, and it uses a Tekken tokenizer with a vocabulary labeled 131k. The context label concerns the text retained for the task, while the vocabulary label describes tokenization; they are different specifications.
The maker lists languages including English, French, German, Spanish, Italian, Chinese, Japanese, Korean, Portuguese, Dutch and Polish, with Russian also present in the released card's language metadata. Define the final language and any terminology that should remain unchanged. A translated explanation can retain identifiers, names and units while adapting the surrounding prose to the reader.
The release announcement states that Small 3 is not trained with reinforcement learning or synthetic data and distinguishes pretrained and instruction-tuned checkpoints. It describes the model as a foundation that can be further customized, rather than a hybrid checkpoint with the later Small 4 reasoning controls. This entry is the Instruct 2501 edition for following a conversational task.
Conversational and structured tasks
For a support-style assistant, provide the user's question, relevant reference material and the response rules. Ask for the action that answers the question and the condition under which it applies. A practical output can separate a concise reply from extracted fields the application needs for the next step, rather than mixing them in an unstructured explanation.
For classification, provide the permitted labels and the distinctions between them. For extraction, name the fields, expected types and representation for missing information. A record might contain the issue category, an identifier copied from the message and a short summary of the requested action. JSON organizes the result, while the field design and interpretation rules remain part of the supplied task.
For a coding explanation, include the function, relevant declarations and a concrete input. Ask what path through the code determines the result. For a mathematical explanation, define variables and assumptions and identify the expression or claim to establish. These text-based tasks can return a method, an explanation and the final artifact without assuming that the model itself runs the code or an external calculation.
System instructions and recommended settings
The card recommends a system prompt tailored to the intended assistant and a relatively low temperature, such as 0.15. Use the system instruction to define the role, style and answer rules, while the user message carries the actual problem or source material. Keep quoted instructions inside a document separate from the application's instruction about what to do with that document.
For an everyday assistant, specify whether the result should be a short answer, a structured record or a longer explanation. If a response will be parsed, request the record separately from optional prose. In a repeated document workflow, preserve the source identifier beside each result so that the application can return the correct material to the user.
Function calling and specialization
The model can select a described function and produce its arguments. The application executes the operation and returns the result with the corresponding tool call, after which the next answer can use that information. The card's example shows a conversation with previous tool use followed by a new question. This gives the assistant a way to request information from connected tools without treating a proposed call as a completed lookup.
Describe each function's purpose and required values clearly. A lookup task can name the information needed and return the actual tool result to the conversation; a text-processing function can supply a transformed passage for the next response. Keep the tool set related to the current process, and retain the link between the proposed operation and its result.
The maker also describes fine-tuning for subject-matter specialization. That process changes a model for a defined domain; providing a document in one conversation is instead source conditioning for that task. Supply the domain material and response requirements needed by the particular assistant rather than assuming a customization has already been performed.
Context and substantive limits
Small 3 2501 is a text-only model with a 32k context. The vision capability and 128k context introduced in Small 3.1 belong to the later release, and Small 4's hybrid modes likewise should not be transferred here. An image, audio recording or video must have its relevant content prepared through another component before this text task.
The card's 256- and 512-token generation settings are usage examples, not separate maximum output capacities. Keep the exact Instruct 2501 identity, tokenizer and requested result explicit. The useful final artifact is the answer, JSON record or proposed code whose meaning and format match the original written task.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-small-24b-instruct-2501 | 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.0001 / 1K tokens Output · Output tokens $0.00016 / 1K tokens Input · Cache read — / 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.0001 / 1K tokens Output · Output tokens $0.00016 / 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}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "mistralai/mistral-small-24b-instruct-2501", "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-24b-instruct-2501',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-24b-instruct-2501',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-24b-instruct-2501
Use the method paths shown above.
mistralai/mistral-small-24b-instruct-2501Mistral Small 3 Instruct 2501 is a 24B text model for conversational instructions, structured extraction and tool-assisted applications. It provides a 32k maker context, multilingual responses, system-prompt support, JSON and native function calling in a distinct text-only release.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Mistral Small 3 Instruct 2501 is the 24-billion-parameter instruction-tuned release of Mistral Small 3. It is fine-tuned from the separately named Small 24B Base 2501 model. The maker positions it for responsive conversational assistance, function calling and subject-specific adaptation, with text as both the input and the generated result.
Core features and training distinction
The model card documents multilingual support, conversational and reasoning capabilities, native function calling, JSON output and adherence to system prompts. Its context window is 32k, and it uses a Tekken tokenizer with a vocabulary labeled 131k. The context label concerns the text retained for the task, while the vocabulary label describes tokenization; they are different specifications.
The maker lists languages including English, French, German, Spanish, Italian, Chinese, Japanese, Korean, Portuguese, Dutch and Polish, with Russian also present in the released card's language metadata. Define the final language and any terminology that should remain unchanged. A translated explanation can retain identifiers, names and units while adapting the surrounding prose to the reader.
The release announcement states that Small 3 is not trained with reinforcement learning or synthetic data and distinguishes pretrained and instruction-tuned checkpoints. It describes the model as a foundation that can be further customized, rather than a hybrid checkpoint with the later Small 4 reasoning controls. This entry is the Instruct 2501 edition for following a conversational task.
Conversational and structured tasks
For a support-style assistant, provide the user's question, relevant reference material and the response rules. Ask for the action that answers the question and the condition under which it applies. A practical output can separate a concise reply from extracted fields the application needs for the next step, rather than mixing them in an unstructured explanation.
For classification, provide the permitted labels and the distinctions between them. For extraction, name the fields, expected types and representation for missing information. A record might contain the issue category, an identifier copied from the message and a short summary of the requested action. JSON organizes the result, while the field design and interpretation rules remain part of the supplied task.
For a coding explanation, include the function, relevant declarations and a concrete input. Ask what path through the code determines the result. For a mathematical explanation, define variables and assumptions and identify the expression or claim to establish. These text-based tasks can return a method, an explanation and the final artifact without assuming that the model itself runs the code or an external calculation.
System instructions and recommended settings
The card recommends a system prompt tailored to the intended assistant and a relatively low temperature, such as 0.15. Use the system instruction to define the role, style and answer rules, while the user message carries the actual problem or source material. Keep quoted instructions inside a document separate from the application's instruction about what to do with that document.
For an everyday assistant, specify whether the result should be a short answer, a structured record or a longer explanation. If a response will be parsed, request the record separately from optional prose. In a repeated document workflow, preserve the source identifier beside each result so that the application can return the correct material to the user.
Function calling and specialization
The model can select a described function and produce its arguments. The application executes the operation and returns the result with the corresponding tool call, after which the next answer can use that information. The card's example shows a conversation with previous tool use followed by a new question. This gives the assistant a way to request information from connected tools without treating a proposed call as a completed lookup.
Describe each function's purpose and required values clearly. A lookup task can name the information needed and return the actual tool result to the conversation; a text-processing function can supply a transformed passage for the next response. Keep the tool set related to the current process, and retain the link between the proposed operation and its result.
The maker also describes fine-tuning for subject-matter specialization. That process changes a model for a defined domain; providing a document in one conversation is instead source conditioning for that task. Supply the domain material and response requirements needed by the particular assistant rather than assuming a customization has already been performed.
Context and substantive limits
Small 3 2501 is a text-only model with a 32k context. The vision capability and 128k context introduced in Small 3.1 belong to the later release, and Small 4's hybrid modes likewise should not be transferred here. An image, audio recording or video must have its relevant content prepared through another component before this text task.
The card's 256- and 512-token generation settings are usage examples, not separate maximum output capacities. Keep the exact Instruct 2501 identity, tokenizer and requested result explicit. The useful final artifact is the answer, JSON record or proposed code whose meaning and format match the original written task.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-small-24b-instruct-2501 | 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.0001 / 1K tokens Output · Output tokens $0.00016 / 1K tokens Input · Cache read — / 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.0001 / 1K tokens Output · Output tokens $0.00016 / 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 →
{\n "model": "mistralai/mistral-small-24b-instruct-2501",\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-24b-instruct-2501', '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-24b-instruct-2501', '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-24b-instruct-2501
Use the method paths shown above.
Technical example in English
Prepare a reference-grounded support answer\n\nAnswer this customer question using only the reference: 'Can I change the pickup location after the parcel is handed to the carrier?' Reference: 'Before handover, support may change the pickup location. After handover, the recipient must request a change from the carrier; availability depends on its route.' Return a concise reply and the condition supporting it.A short customer reply plus the reference condition that determines the next contact.The reply directs the handed-over parcel's request to the carrier and does not promise that a change is available.