Mistral Medium 3 is Mistral AI's multimodal model for professional work involving text, visual understanding and code. The original release highlights coding and STEM tasks together with adaptation to enterprise knowledge and workflows. It accepts textual and visual material and produces text, including a document explanation, structured record or proposed implementation. The maker's fixed identifier for this edition is mistral-medium-2505.
Context and professional source material
The model page lists a 128k context window. Use that context to retain the source passages, conversation and instructions that determine the requested artifact. For a document comparison, identify which source is the current requirement, which is the proposed revision and which question should be resolved. Request the supporting document and section beside each finding.
A practical explanation task can provide a procedure and a user's question, then ask for the relevant action and the condition that makes it applicable. A technical analysis can include source data, definitions and the criterion to compare. The goal is a result tied to the supplied material rather than a general description of the topic.
Structured outputs and functions
The page lists structured outputs and function calling. For extraction, define the field names, types and representation for missing source information. A useful record can separate the identifier, source statement, interpretation and unresolved question. Mistral's shared guidance distinguishes JSON mode from a custom schema and requires an explicit request for the desired JSON format.
Function calling connects the model's interpretation with operations described by the application. The model chooses a function and prepares arguments, the application executes the function, and its result becomes context for the next answer. A lookup can supply a missing reference value; a calculation can supply a result needed by the explanation. Keep the result associated with the operation that produced it, rather than treating the proposed call as an executed action.
Document and visual questions
Document question answering is also listed for this edition. The maker's documented workflow prepares a document's text, structure and formatting with OCR before language-model analysis. Ask about the particular requirement, passage or relationship needed by the task. For several documents, retain their identities and request a comparison with the source location alongside each conclusion.
For visual material, pair the image with a defined question and retain the labels, units and regions needed to answer it. A chart can ask for a comparison between named series; a diagram can ask which connection supports a supplied requirement. A readable document image and an OCR-prepared document are different input preparations, even where both serve the same question-answering goal.
Editing, prefixes and workflows
The model page lists predicted outputs, response prefixes, batching and agent conversations. Predicted outputs use known content when most of a document or code file should remain while a limited part changes. Supply the existing content, specify the edit and identify the material to preserve. This is different from asking the model to create an entirely new document.
A response prefix supplies a known beginning for the assistant's generated text, which then continues from that beginning. Batching changes how tasks are submitted, while an agent/conversation interface manages a connected workflow. The listed built-in tools belong to that maker interface; they do not add another content modality to the underlying model or perform an action without the connected environment.
Coding and domain adaptation
For a programming request, provide the requirement, affected function, relevant declarations and expected input and output. Ask for the proposed change, its assumptions and examples that distinguish the intended behavior. A debugging question can include the failure evidence and ask which path through the source explains it. Repository access, code execution and application of the change come from the surrounding development tools.
The original announcement describes custom post-training and fine-tuning for domain-specific enterprise contexts and knowledge bases. That is a distinct adaptation process, not a claim that a particular organization's documents are already known to the default model. For a source-conditioned answer, supply the relevant documents and terminology directly with the task and define the response rules.
Edition and result boundaries
This entry retains Medium 3's 2505 identity and 128k context. The architecture count and configurable hybrid reasoning controls later documented for Medium 3.5 are not part of this edition's stated specification. The exact model page does not publish a parameter count or separate hard maximum answer length to borrow from a later release.
Prepare the intended result before the request: an explanation, structured extraction, revised section or proposed code. Keep the textual and visual evidence, source identities and any connected tool results explicit so the answer can be inspected and used in the next application step.
", "aboutText": "Mistral Medium 3 is Mistral AI's multimodal model for professional work involving text, visual understanding and code. The original release highlights coding and STEM tasks together with adaptation to enterprise knowledge and workflows. It accepts textual and visual material and produces text, including a document explanation, structured record or proposed implementation. The maker's fixed identifier for this edition is mistral-medium-2505.\n\nContext and professional source material\n\nThe model page lists a 128k context window. Use that context to retain the source passages, conversation and instructions that determine the requested artifact. For a document comparison, identify which source is the current requirement, which is the proposed revision and which question should be resolved. Request the supporting document and section beside each finding.\n\nA practical explanation task can provide a procedure and a user's question, then ask for the relevant action and the condition that makes it applicable. A technical analysis can include source data, definitions and the criterion to compare. The goal is a result tied to the supplied material rather than a general description of the topic.\n\nStructured outputs and functions\n\nThe page lists structured outputs and function calling. For extraction, define the field names, types and representation for missing source information. A useful record can separate the identifier, source statement, interpretation and unresolved question. Mistral's shared guidance distinguishes JSON mode from a custom schema and requires an explicit request for the desired JSON format.\n\nFunction calling connects the model's interpretation with operations described by the application. The model chooses a function and prepares arguments, the application executes the function, and its result becomes context for the next answer. A lookup can supply a missing reference value; a calculation can supply a result needed by the explanation. Keep the result associated with the operation that produced it, rather than treating the proposed call as an executed action.\n\nDocument and visual questions\n\nDocument question answering is also listed for this edition. The maker's documented workflow prepares a document's text, structure and formatting with OCR before language-model analysis. Ask about the particular requirement, passage or relationship needed by the task. For several documents, retain their identities and request a comparison with the source location alongside each conclusion.\n\nFor visual material, pair the image with a defined question and retain the labels, units and regions needed to answer it. A chart can ask for a comparison between named series; a diagram can ask which connection supports a supplied requirement. A readable document image and an OCR-prepared document are different input preparations, even where both serve the same question-answering goal.\n\nEditing, prefixes and workflows\n\nThe model page lists predicted outputs, response prefixes, batching and agent conversations. Predicted outputs use known content when most of a document or code file should remain while a limited part changes. Supply the existing content, specify the edit and identify the material to preserve. This is different from asking the model to create an entirely new document.\n\nA response prefix supplies a known beginning for the assistant's generated text, which then continues from that beginning. Batching changes how tasks are submitted, while an agent/conversation interface manages a connected workflow. The listed built-in tools belong to that maker interface; they do not add another content modality to the underlying model or perform an action without the connected environment.\n\nCoding and domain adaptation\n\nFor a programming request, provide the requirement, affected function, relevant declarations and expected input and output. Ask for the proposed change, its assumptions and examples that distinguish the intended behavior. A debugging question can include the failure evidence and ask which path through the source explains it. Repository access, code execution and application of the change come from the surrounding development tools.\n\nThe original announcement describes custom post-training and fine-tuning for domain-specific enterprise contexts and knowledge bases. That is a distinct adaptation process, not a claim that a particular organization's documents are already known to the default model. For a source-conditioned answer, supply the relevant documents and terminology directly with the task and define the response rules.\n\nEdition and result boundaries\n\nThis entry retains Medium 3's 2505 identity and 128k context. The architecture count and configurable hybrid reasoning controls later documented for Medium 3.5 are not part of this edition's stated specification. The exact model page does not publish a parameter count or separate hard maximum answer length to borrow from a later release.\n\nPrepare the intended result before the request: an explanation, structured extraction, revised section or proposed code. Keep the textual and visual evidence, source identities and any connected tool results explicit so the answer can be inspected and used in the next application step.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Apply a procedure to a concrete case\n\nUse this procedure to answer the employee: 'Requests below 500 credits need team-lead approval. Requests of 500 or more need finance approval. Purchases must wait for approval.' Employee: 'My equipment request is exactly 500 credits; can my team lead approve it and can I order today?' Give the applicable rule and missing information.A short procedural answer citing the threshold and approval-before-purchase requirement.Exactly 500 falls under finance approval, and ordering today depends on approval actually having been received.mistralai/mistral-medium-3Mistral Medium 3 is a multimodal model for professional text, visual and coding tasks. Its 128k maker context and documented structured outputs, function calls, document questions and predictable edits support source-based explanations and application workflows.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Mistral Medium 3 is Mistral AI's multimodal model for professional work involving text, visual understanding and code. The original release highlights coding and STEM tasks together with adaptation to enterprise knowledge and workflows. It accepts textual and visual material and produces text, including a document explanation, structured record or proposed implementation. The maker's fixed identifier for this edition is mistral-medium-2505.
Context and professional source material
The model page lists a 128k context window. Use that context to retain the source passages, conversation and instructions that determine the requested artifact. For a document comparison, identify which source is the current requirement, which is the proposed revision and which question should be resolved. Request the supporting document and section beside each finding.
A practical explanation task can provide a procedure and a user's question, then ask for the relevant action and the condition that makes it applicable. A technical analysis can include source data, definitions and the criterion to compare. The goal is a result tied to the supplied material rather than a general description of the topic.
Structured outputs and functions
The page lists structured outputs and function calling. For extraction, define the field names, types and representation for missing source information. A useful record can separate the identifier, source statement, interpretation and unresolved question. Mistral's shared guidance distinguishes JSON mode from a custom schema and requires an explicit request for the desired JSON format.
Function calling connects the model's interpretation with operations described by the application. The model chooses a function and prepares arguments, the application executes the function, and its result becomes context for the next answer. A lookup can supply a missing reference value; a calculation can supply a result needed by the explanation. Keep the result associated with the operation that produced it, rather than treating the proposed call as an executed action.
Document and visual questions
Document question answering is also listed for this edition. The maker's documented workflow prepares a document's text, structure and formatting with OCR before language-model analysis. Ask about the particular requirement, passage or relationship needed by the task. For several documents, retain their identities and request a comparison with the source location alongside each conclusion.
For visual material, pair the image with a defined question and retain the labels, units and regions needed to answer it. A chart can ask for a comparison between named series; a diagram can ask which connection supports a supplied requirement. A readable document image and an OCR-prepared document are different input preparations, even where both serve the same question-answering goal.
Editing, prefixes and workflows
The model page lists predicted outputs, response prefixes, batching and agent conversations. Predicted outputs use known content when most of a document or code file should remain while a limited part changes. Supply the existing content, specify the edit and identify the material to preserve. This is different from asking the model to create an entirely new document.
A response prefix supplies a known beginning for the assistant's generated text, which then continues from that beginning. Batching changes how tasks are submitted, while an agent/conversation interface manages a connected workflow. The listed built-in tools belong to that maker interface; they do not add another content modality to the underlying model or perform an action without the connected environment.
Coding and domain adaptation
For a programming request, provide the requirement, affected function, relevant declarations and expected input and output. Ask for the proposed change, its assumptions and examples that distinguish the intended behavior. A debugging question can include the failure evidence and ask which path through the source explains it. Repository access, code execution and application of the change come from the surrounding development tools.
The original announcement describes custom post-training and fine-tuning for domain-specific enterprise contexts and knowledge bases. That is a distinct adaptation process, not a claim that a particular organization's documents are already known to the default model. For a source-conditioned answer, supply the relevant documents and terminology directly with the task and define the response rules.
Edition and result boundaries
This entry retains Medium 3's 2505 identity and 128k context. The architecture count and configurable hybrid reasoning controls later documented for Medium 3.5 are not part of this edition's stated specification. The exact model page does not publish a parameter count or separate hard maximum answer length to borrow from a later release.
Prepare the intended result before the request: an explanation, structured extraction, revised section or proposed code. Keep the textual and visual evidence, source identities and any connected tool results explicit so the answer can be inspected and used in the next application step.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-medium-3 | 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.0008 / 1K tokens Output · Output tokens $0.004 / 1K tokens Input · Cache read $0.00008 / 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.0008 / 1K tokens Output · Output tokens $0.004 / 1K tokens Input · Cache read $0.00008 / 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-medium-3", "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-medium-3',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-medium-3',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-medium-3
Use the method paths shown above.
mistralai/mistral-medium-3Mistral Medium 3 is a multimodal model for professional text, visual and coding tasks. Its 128k maker context and documented structured outputs, function calls, document questions and predictable edits support source-based explanations and application workflows.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Mistral Medium 3 is Mistral AI's multimodal model for professional work involving text, visual understanding and code. The original release highlights coding and STEM tasks together with adaptation to enterprise knowledge and workflows. It accepts textual and visual material and produces text, including a document explanation, structured record or proposed implementation. The maker's fixed identifier for this edition is mistral-medium-2505.
Context and professional source material
The model page lists a 128k context window. Use that context to retain the source passages, conversation and instructions that determine the requested artifact. For a document comparison, identify which source is the current requirement, which is the proposed revision and which question should be resolved. Request the supporting document and section beside each finding.
A practical explanation task can provide a procedure and a user's question, then ask for the relevant action and the condition that makes it applicable. A technical analysis can include source data, definitions and the criterion to compare. The goal is a result tied to the supplied material rather than a general description of the topic.
Structured outputs and functions
The page lists structured outputs and function calling. For extraction, define the field names, types and representation for missing source information. A useful record can separate the identifier, source statement, interpretation and unresolved question. Mistral's shared guidance distinguishes JSON mode from a custom schema and requires an explicit request for the desired JSON format.
Function calling connects the model's interpretation with operations described by the application. The model chooses a function and prepares arguments, the application executes the function, and its result becomes context for the next answer. A lookup can supply a missing reference value; a calculation can supply a result needed by the explanation. Keep the result associated with the operation that produced it, rather than treating the proposed call as an executed action.
Document and visual questions
Document question answering is also listed for this edition. The maker's documented workflow prepares a document's text, structure and formatting with OCR before language-model analysis. Ask about the particular requirement, passage or relationship needed by the task. For several documents, retain their identities and request a comparison with the source location alongside each conclusion.
For visual material, pair the image with a defined question and retain the labels, units and regions needed to answer it. A chart can ask for a comparison between named series; a diagram can ask which connection supports a supplied requirement. A readable document image and an OCR-prepared document are different input preparations, even where both serve the same question-answering goal.
Editing, prefixes and workflows
The model page lists predicted outputs, response prefixes, batching and agent conversations. Predicted outputs use known content when most of a document or code file should remain while a limited part changes. Supply the existing content, specify the edit and identify the material to preserve. This is different from asking the model to create an entirely new document.
A response prefix supplies a known beginning for the assistant's generated text, which then continues from that beginning. Batching changes how tasks are submitted, while an agent/conversation interface manages a connected workflow. The listed built-in tools belong to that maker interface; they do not add another content modality to the underlying model or perform an action without the connected environment.
Coding and domain adaptation
For a programming request, provide the requirement, affected function, relevant declarations and expected input and output. Ask for the proposed change, its assumptions and examples that distinguish the intended behavior. A debugging question can include the failure evidence and ask which path through the source explains it. Repository access, code execution and application of the change come from the surrounding development tools.
The original announcement describes custom post-training and fine-tuning for domain-specific enterprise contexts and knowledge bases. That is a distinct adaptation process, not a claim that a particular organization's documents are already known to the default model. For a source-conditioned answer, supply the relevant documents and terminology directly with the task and define the response rules.
Edition and result boundaries
This entry retains Medium 3's 2505 identity and 128k context. The architecture count and configurable hybrid reasoning controls later documented for Medium 3.5 are not part of this edition's stated specification. The exact model page does not publish a parameter count or separate hard maximum answer length to borrow from a later release.
Prepare the intended result before the request: an explanation, structured extraction, revised section or proposed code. Keep the textual and visual evidence, source identities and any connected tool results explicit so the answer can be inspected and used in the next application step.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-medium-3 | 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.0008 / 1K tokens Output · Output tokens $0.004 / 1K tokens Input · Cache read $0.00008 / 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.0008 / 1K tokens Output · Output tokens $0.004 / 1K tokens Input · Cache read $0.00008 / 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-medium-3",\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-medium-3', '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-medium-3', '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-medium-3
Use the method paths shown above.
Technical example in English
Apply a procedure to a concrete case\n\nUse this procedure to answer the employee: 'Requests below 500 credits need team-lead approval. Requests of 500 or more need finance approval. Purchases must wait for approval.' Employee: 'My equipment request is exactly 500 credits; can my team lead approve it and can I order today?' Give the applicable rule and missing information.A short procedural answer citing the threshold and approval-before-purchase requirement.Exactly 500 falls under finance approval, and ordering today depends on approval actually having been received.