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": null, "copy_sha256": null, "copy_source": null, "html_sha256": "1ee5be0d815f0fcda2078184fd45247ad720be543d59bc6bdf0356bd49098e22", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "mistralai/voxtral-small-24b-2507-sttVoxtral 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/audio/transcriptionsaudiotext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/voxtral-small-24b-2507-stt | Default— |
Fieldinput_audio | Typeobject | RequirementRequired | Values & limits | Default— |
Fieldlanguage | Typestring | RequirementOptional | Values & limits | Default— |
Fieldtemperature | Typenumber | RequirementOptional | Values & limits Minimum: 0 Maximum: 1 | Default— |
Fieldresponse_format | Typestring | RequirementOptional | Values & limits json, verbose_json | Defaultjson |
Fieldtimestamp_granularities | Typearray | RequirementOptional | Values & limits | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, input_audio |
Parametermaterial_types | Contractaudio |
Parametermaterial_conditions | ContractRead an actual WAV file and encode its real bytes for the declared JSON input_audio; no multipart route is advertised for this exact JSON-only declaration. |
Lifecycle: synchronous_result_then_owned_library
GET /v1/media/tasks/{task_id} · actual returned task_id or media library record
GET /v1/media/assets/{asset_id}/content
GET /v1/media/assets
GET /v1/media/assets/{asset_id}
The displayed rates estimate the cost before generation. The final charge is calculated from the cost recorded for the original generation. Measured output duration and forecast quantities are not the final billable quantity.
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 | Forecast quantity | Billing unit | Charge |
|---|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Forecast quantity— | Billing unit— | Charge Input · Input tokens · Estimate for comparison only — / 1K tokens Output · Output tokens · Estimate for comparison only — / 1K tokens Input · Cache read · Estimate for comparison only — / 1K tokens Input · Cache write · Estimate for comparison only — / 1K tokens Input · Cache write, 1 hour · Estimate for comparison only — / 1K tokens |
| Configurationinput audio second | Rate schedule— | Forecast quantity— | Billing unitper input audio second | Charge Input · input audio second · Estimate for comparison only $0.0001 per input audio second |
| ConfigurationEstimated generation cost | Rate schedule— | Forecast quantityone generation estimate | Billing unit— | Charge Output · Estimated generation cost · Estimate for comparison only $0.0001 estimate before generation This estimate is not an additional charge or a fixed rate for the completed generation. |
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}"\n: "${AILOOT_AUDIO_FILE:?Set the path to your actual WAV recording}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\nimport base64\naudio=Path(os.environ['AILOOT_AUDIO_FILE']).read_bytes()\nif not (audio[:4]==b'RIFF' and audio[8:12]==b'WAVE'): raise SystemExit('Supply an actual WAV audio file')\nif len(audio)>26214400: raise SystemExit('Use a documented supported large-file flow')\nrequest={'model': 'mistralai/voxtral-small-24b-2507-stt', 'input_audio': {'data': '${BASE64_ACTUAL_WAV_BYTES}', 'format': 'wav'}}\nrequest['input_audio']['data']=base64.b64encode(audio).decode('ascii')\nPath('request.json').write_text(json.dumps(request,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/audio/transcriptions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o response.bin\n# Keep the complete original response and headers. Read every returned segment, word and usage field.\n# Preserve actual operation/task/asset IDs; continue reads of the original result without resubmitting.\nGET /v1/media/tasks/{task_id}GET /v1/media/assets/{asset_id}/contentGET /v1/media/assetsGET /v1/media/assets/{asset_id}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/media/assets \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o owned-assets.json\n# Preserve every returned asset and follow its exact signed content URL. Do not construct a signed token.\nKeep every complete returned response, file and content part.
Retain the complete response and headers, every actual output, original returned identifiers and all usage fields. Recover the original operation without submitting creation again.
Keep the returned X-Client-Request-ID for reconciliation. Read only actual returned task_id/asset_id values or the owned media library; never build a task URL from the operation ID and never resubmit creation.
| Field | Type |
|---|---|
Fieldtext | Type |
Fieldusage | Type |
Fieldsegments[] | Type |
Fieldwords[] | Type |
Fieldspeaker fields | Type |
Fieldtimestamps | Type |
Ailoot Ultra mistralai/voxtral-small-24b-2507-stt
Use the method paths shown above.