Voxtral Small 1.0 24B 2507 adds audio input and speech understanding to a Mistral Small language-model backbone. It accepts audio and text and returns text, including a transcript, an answer about the recording, a translation or a structured summary. This is the named 24B speech-understanding edition, distinct from Voxtral Mini, transcription-optimized service variants and later Voxtral speech-generation or real-time releases.
Transcription and audio understanding
The model has a dedicated pure transcription mode. The maker states that it automatically predicts the source audio language by default and transcribes accordingly. Use this mode when the desired artifact is the spoken wording itself rather than an interpretation or summary. Identify whether the result should preserve the original language or be followed by a separately requested translation.
Audio understanding allows a question to be asked directly about a recording, without first chaining a separate speech-recognition model and text model. A request can ask which topic was discussed, what decision was stated or what information in the recording answers a specific question. The result can be a concise response or an organized summary, rather than a full transcript of every spoken word.
For a meeting summary, provide the recording and define the fields to return: topics, explicitly stated decisions and follow-up actions. Ask for names or dates only when the recording actually states them, and keep unresolved details separate from the decisions. For an interview, request the answer to a particular question and the surrounding context that makes it understandable. These output designs connect the audio task to a document someone can use afterwards.
Context, duration and languages
The maker documents a 32k-token context and audio up to 30 minutes for transcription, or 40 minutes for understanding. The two duration figures have different task scopes. Choose the desired operation before selecting the recording, and include the text instruction and conversation when planning the available context. A long recording and a long written answer both consume resources; the duration statement is not a separate unlimited answer-length promise.
The release identifies English, Spanish, French, Portuguese, Hindi, German, Dutch and Italian among its principal supported languages and provides automatic language detection. For speech translation, set the final language and any terms that should retain their original form. For a question about audio in one language, distinguish the language of the recording from the language in which the answer should be written.
Multiple recordings and follow-up questions
The card supports several audio inputs in a message and audio in multiple user turns. Give each recording an identifier and state its role when comparing them. A practical request might compare two versions of a spoken explanation, ask which conditions changed and return a table with a separate column for each recording. Identifiers help keep the model's findings associated with the right source.
A follow-up can retain the prior question and answer while asking for a narrower detail or supplying another recording. For example, first ask for the decisions from a discussion, then ask which decision relates to a particular requirement. The same release also demonstrates text-only and audio-only requests. Its text backbone can work on the written question or result, while the audio capability supplies evidence from speech.
Voice-driven functions
The maker describes function calling from spoken intent and labels the released card's function-calling example as experimental support. In this workflow, the application defines a function and its arguments, the model prepares a call from the request, and the application executes it and supplies the result. A voice-based lookup can therefore return a written answer using information from a connected tool. Function calling does not mean that the model automatically owns the external service or carries out an action merely by naming it.
Keep the function purpose and required information explicit. If the recording asks for an operation but omits a required value, the application still needs that value to execute the function. Separate the spoken request, proposed arguments and returned result so the next response can refer to the actual operation outcome.
Recommended settings and useful boundaries
For audio understanding and chat completion, the card recommends temperature 0.2 and top-p 0.95. For transcription, it recommends temperature 0.0. It explicitly states that system prompts are not supported in this released usage flow, so place the task and response requirements in the user input rather than transferring a system-prompt convention from another Mistral model.
Select a recording containing the material relevant to the question, keep audible speech clear and specify whether the result should be a transcript, translation, answer or summary. The documented output is text. A spoken response needs a text-to-speech component, and speaker identification, detailed diarization or word-level timestamps should not be inferred from the general audio-understanding claim for this exact release.
The card's 500-token generation examples are example settings, not a separately stated maximum output capacity. Preserve the 2507 edition, the task-specific duration guidance and the input language when preparing a repeatable workflow. The useful final artifact is the requested text, connected to the recording and formatted for the next document or application step.
", "aboutText": "Voxtral Small 1.0 24B 2507 adds audio input and speech understanding to a Mistral Small language-model backbone. It accepts audio and text and returns text, including a transcript, an answer about the recording, a translation or a structured summary. This is the named 24B speech-understanding edition, distinct from Voxtral Mini, transcription-optimized service variants and later Voxtral speech-generation or real-time releases.\n\nTranscription and audio understanding\n\nThe model has a dedicated pure transcription mode. The maker states that it automatically predicts the source audio language by default and transcribes accordingly. Use this mode when the desired artifact is the spoken wording itself rather than an interpretation or summary. Identify whether the result should preserve the original language or be followed by a separately requested translation.\n\nAudio understanding allows a question to be asked directly about a recording, without first chaining a separate speech-recognition model and text model. A request can ask which topic was discussed, what decision was stated or what information in the recording answers a specific question. The result can be a concise response or an organized summary, rather than a full transcript of every spoken word.\n\nFor a meeting summary, provide the recording and define the fields to return: topics, explicitly stated decisions and follow-up actions. Ask for names or dates only when the recording actually states them, and keep unresolved details separate from the decisions. For an interview, request the answer to a particular question and the surrounding context that makes it understandable. These output designs connect the audio task to a document someone can use afterwards.\n\nContext, duration and languages\n\nThe maker documents a 32k-token context and audio up to 30 minutes for transcription, or 40 minutes for understanding. The two duration figures have different task scopes. Choose the desired operation before selecting the recording, and include the text instruction and conversation when planning the available context. A long recording and a long written answer both consume resources; the duration statement is not a separate unlimited answer-length promise.\n\nThe release identifies English, Spanish, French, Portuguese, Hindi, German, Dutch and Italian among its principal supported languages and provides automatic language detection. For speech translation, set the final language and any terms that should retain their original form. For a question about audio in one language, distinguish the language of the recording from the language in which the answer should be written.\n\nMultiple recordings and follow-up questions\n\nThe card supports several audio inputs in a message and audio in multiple user turns. Give each recording an identifier and state its role when comparing them. A practical request might compare two versions of a spoken explanation, ask which conditions changed and return a table with a separate column for each recording. Identifiers help keep the model's findings associated with the right source.\n\nA follow-up can retain the prior question and answer while asking for a narrower detail or supplying another recording. For example, first ask for the decisions from a discussion, then ask which decision relates to a particular requirement. The same release also demonstrates text-only and audio-only requests. Its text backbone can work on the written question or result, while the audio capability supplies evidence from speech.\n\nVoice-driven functions\n\nThe maker describes function calling from spoken intent and labels the released card's function-calling example as experimental support. In this workflow, the application defines a function and its arguments, the model prepares a call from the request, and the application executes it and supplies the result. A voice-based lookup can therefore return a written answer using information from a connected tool. Function calling does not mean that the model automatically owns the external service or carries out an action merely by naming it.\n\nKeep the function purpose and required information explicit. If the recording asks for an operation but omits a required value, the application still needs that value to execute the function. Separate the spoken request, proposed arguments and returned result so the next response can refer to the actual operation outcome.\n\nRecommended settings and useful boundaries\n\nFor audio understanding and chat completion, the card recommends temperature 0.2 and top-p 0.95. For transcription, it recommends temperature 0.0. It explicitly states that system prompts are not supported in this released usage flow, so place the task and response requirements in the user input rather than transferring a system-prompt convention from another Mistral model.\n\nSelect a recording containing the material relevant to the question, keep audible speech clear and specify whether the result should be a transcript, translation, answer or summary. The documented output is text. A spoken response needs a text-to-speech component, and speaker identification, detailed diarization or word-level timestamps should not be inferred from the general audio-understanding claim for this exact release.\n\nThe card's 500-token generation examples are example settings, not a separately stated maximum output capacity. Preserve the 2507 edition, the task-specific duration guidance and the input language when preparing a repeatable workflow. The useful final artifact is the requested text, connected to the recording and formatted for the next document or application step.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Summarize a supplied meeting transcript\n\nSummarize this supplied transcript text: 'Ana: We will keep the current label. Ben: I will check the revised barcode by Tuesday. Ana: Shipping timing is still unconfirmed. Ben: Agreed.' Return topics, explicit decisions and follow-up actions. Separate the unresolved shipping date from decisions, and include owners or deadlines only when stated in the transcript.A meeting summary with topics, one decision, an owned action and an unresolved timing item.Check that keeping the label is the decision and shipping timing remains unconfirmed.mistralai/voxtral-small-24b-2507Voxtral Small 1.0 24B 2507 is a text-and-audio model for transcription, speech translation, questions and summaries. Its maker documents a 32k context, up to 30 minutes for transcription or 40 minutes for understanding, multiple audio inputs and text results.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Voxtral Small 1.0 24B 2507 adds audio input and speech understanding to a Mistral Small language-model backbone. It accepts audio and text and returns text, including a transcript, an answer about the recording, a translation or a structured summary. This is the named 24B speech-understanding edition, distinct from Voxtral Mini, transcription-optimized service variants and later Voxtral speech-generation or real-time releases.
Transcription and audio understanding
The model has a dedicated pure transcription mode. The maker states that it automatically predicts the source audio language by default and transcribes accordingly. Use this mode when the desired artifact is the spoken wording itself rather than an interpretation or summary. Identify whether the result should preserve the original language or be followed by a separately requested translation.
Audio understanding allows a question to be asked directly about a recording, without first chaining a separate speech-recognition model and text model. A request can ask which topic was discussed, what decision was stated or what information in the recording answers a specific question. The result can be a concise response or an organized summary, rather than a full transcript of every spoken word.
For a meeting summary, provide the recording and define the fields to return: topics, explicitly stated decisions and follow-up actions. Ask for names or dates only when the recording actually states them, and keep unresolved details separate from the decisions. For an interview, request the answer to a particular question and the surrounding context that makes it understandable. These output designs connect the audio task to a document someone can use afterwards.
Context, duration and languages
The maker documents a 32k-token context and audio up to 30 minutes for transcription, or 40 minutes for understanding. The two duration figures have different task scopes. Choose the desired operation before selecting the recording, and include the text instruction and conversation when planning the available context. A long recording and a long written answer both consume resources; the duration statement is not a separate unlimited answer-length promise.
The release identifies English, Spanish, French, Portuguese, Hindi, German, Dutch and Italian among its principal supported languages and provides automatic language detection. For speech translation, set the final language and any terms that should retain their original form. For a question about audio in one language, distinguish the language of the recording from the language in which the answer should be written.
Multiple recordings and follow-up questions
The card supports several audio inputs in a message and audio in multiple user turns. Give each recording an identifier and state its role when comparing them. A practical request might compare two versions of a spoken explanation, ask which conditions changed and return a table with a separate column for each recording. Identifiers help keep the model's findings associated with the right source.
A follow-up can retain the prior question and answer while asking for a narrower detail or supplying another recording. For example, first ask for the decisions from a discussion, then ask which decision relates to a particular requirement. The same release also demonstrates text-only and audio-only requests. Its text backbone can work on the written question or result, while the audio capability supplies evidence from speech.
Voice-driven functions
The maker describes function calling from spoken intent and labels the released card's function-calling example as experimental support. In this workflow, the application defines a function and its arguments, the model prepares a call from the request, and the application executes it and supplies the result. A voice-based lookup can therefore return a written answer using information from a connected tool. Function calling does not mean that the model automatically owns the external service or carries out an action merely by naming it.
Keep the function purpose and required information explicit. If the recording asks for an operation but omits a required value, the application still needs that value to execute the function. Separate the spoken request, proposed arguments and returned result so the next response can refer to the actual operation outcome.
Recommended settings and useful boundaries
For audio understanding and chat completion, the card recommends temperature 0.2 and top-p 0.95. For transcription, it recommends temperature 0.0. It explicitly states that system prompts are not supported in this released usage flow, so place the task and response requirements in the user input rather than transferring a system-prompt convention from another Mistral model.
Select a recording containing the material relevant to the question, keep audible speech clear and specify whether the result should be a transcript, translation, answer or summary. The documented output is text. A spoken response needs a text-to-speech component, and speaker identification, detailed diarization or word-level timestamps should not be inferred from the general audio-understanding claim for this exact release.
The card's 500-token generation examples are example settings, not a separately stated maximum output capacity. Preserve the 2507 edition, the task-specific duration guidance and the input language when preparing a repeatable workflow. The useful final artifact is the requested text, connected to the recording and formatted for the next document or application step.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/voxtral-small-24b-2507 | 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.0002 / 1K tokens Output · Output tokens $0.0006 / 1K tokens Input · Cache read $0.00002 / 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.0002 / 1K tokens Output · Output tokens $0.0006 / 1K tokens Input · Cache read $0.00002 / 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/voxtral-small-24b-2507", "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/voxtral-small-24b-2507',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/voxtral-small-24b-2507',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/voxtral-small-24b-2507
Use the method paths shown above.
mistralai/voxtral-small-24b-2507Voxtral Small 1.0 24B 2507 is a text-and-audio model for transcription, speech translation, questions and summaries. Its maker documents a 32k context, up to 30 minutes for transcription or 40 minutes for understanding, multiple audio inputs and text results.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Voxtral Small 1.0 24B 2507 adds audio input and speech understanding to a Mistral Small language-model backbone. It accepts audio and text and returns text, including a transcript, an answer about the recording, a translation or a structured summary. This is the named 24B speech-understanding edition, distinct from Voxtral Mini, transcription-optimized service variants and later Voxtral speech-generation or real-time releases.
Transcription and audio understanding
The model has a dedicated pure transcription mode. The maker states that it automatically predicts the source audio language by default and transcribes accordingly. Use this mode when the desired artifact is the spoken wording itself rather than an interpretation or summary. Identify whether the result should preserve the original language or be followed by a separately requested translation.
Audio understanding allows a question to be asked directly about a recording, without first chaining a separate speech-recognition model and text model. A request can ask which topic was discussed, what decision was stated or what information in the recording answers a specific question. The result can be a concise response or an organized summary, rather than a full transcript of every spoken word.
For a meeting summary, provide the recording and define the fields to return: topics, explicitly stated decisions and follow-up actions. Ask for names or dates only when the recording actually states them, and keep unresolved details separate from the decisions. For an interview, request the answer to a particular question and the surrounding context that makes it understandable. These output designs connect the audio task to a document someone can use afterwards.
Context, duration and languages
The maker documents a 32k-token context and audio up to 30 minutes for transcription, or 40 minutes for understanding. The two duration figures have different task scopes. Choose the desired operation before selecting the recording, and include the text instruction and conversation when planning the available context. A long recording and a long written answer both consume resources; the duration statement is not a separate unlimited answer-length promise.
The release identifies English, Spanish, French, Portuguese, Hindi, German, Dutch and Italian among its principal supported languages and provides automatic language detection. For speech translation, set the final language and any terms that should retain their original form. For a question about audio in one language, distinguish the language of the recording from the language in which the answer should be written.
Multiple recordings and follow-up questions
The card supports several audio inputs in a message and audio in multiple user turns. Give each recording an identifier and state its role when comparing them. A practical request might compare two versions of a spoken explanation, ask which conditions changed and return a table with a separate column for each recording. Identifiers help keep the model's findings associated with the right source.
A follow-up can retain the prior question and answer while asking for a narrower detail or supplying another recording. For example, first ask for the decisions from a discussion, then ask which decision relates to a particular requirement. The same release also demonstrates text-only and audio-only requests. Its text backbone can work on the written question or result, while the audio capability supplies evidence from speech.
Voice-driven functions
The maker describes function calling from spoken intent and labels the released card's function-calling example as experimental support. In this workflow, the application defines a function and its arguments, the model prepares a call from the request, and the application executes it and supplies the result. A voice-based lookup can therefore return a written answer using information from a connected tool. Function calling does not mean that the model automatically owns the external service or carries out an action merely by naming it.
Keep the function purpose and required information explicit. If the recording asks for an operation but omits a required value, the application still needs that value to execute the function. Separate the spoken request, proposed arguments and returned result so the next response can refer to the actual operation outcome.
Recommended settings and useful boundaries
For audio understanding and chat completion, the card recommends temperature 0.2 and top-p 0.95. For transcription, it recommends temperature 0.0. It explicitly states that system prompts are not supported in this released usage flow, so place the task and response requirements in the user input rather than transferring a system-prompt convention from another Mistral model.
Select a recording containing the material relevant to the question, keep audible speech clear and specify whether the result should be a transcript, translation, answer or summary. The documented output is text. A spoken response needs a text-to-speech component, and speaker identification, detailed diarization or word-level timestamps should not be inferred from the general audio-understanding claim for this exact release.
The card's 500-token generation examples are example settings, not a separately stated maximum output capacity. Preserve the 2507 edition, the task-specific duration guidance and the input language when preparing a repeatable workflow. The useful final artifact is the requested text, connected to the recording and formatted for the next document or application step.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/voxtral-small-24b-2507 | 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.0002 / 1K tokens Output · Output tokens $0.0006 / 1K tokens Input · Cache read $0.00002 / 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.0002 / 1K tokens Output · Output tokens $0.0006 / 1K tokens Input · Cache read $0.00002 / 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/voxtral-small-24b-2507",\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/voxtral-small-24b-2507', '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/voxtral-small-24b-2507', '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/voxtral-small-24b-2507
Use the method paths shown above.
Technical example in English
Summarize a supplied meeting transcript\n\nSummarize this supplied transcript text: 'Ana: We will keep the current label. Ben: I will check the revised barcode by Tuesday. Ana: Shipping timing is still unconfirmed. Ben: Agreed.' Return topics, explicit decisions and follow-up actions. Separate the unresolved shipping date from decisions, and include owners or deadlines only when stated in the transcript.A meeting summary with topics, one decision, an owned action and an unresolved timing item.Check that keeping the label is the decision and shipping timing remains unconfirmed.