Mistral Medium 3.1 is a multimodal Mistral AI edition for textual and visual understanding. The maker describes this revision as improving tone and performance within the Medium 3 line. It accepts text and images and produces text: an explanation, document answer, structured record or proposed function call. The maker's fixed identifier for this edition is mistral-medium-2508.
Context and the specific edition
The model page documents a 128k context window. Use it to keep related source passages, image evidence, the conversation and the user's task together. Identify the document roles and the question to answer before supplying a large collection. A long context can support a focused comparison while the final artifact remains a short table or revised section.
Medium 3.1 retains its own specification. The 256k context, dense 128B architecture and configurable hybrid reasoning modes described for Medium 3.5 should not be assigned to this entry. The 3.1 page does not provide a parameter count or a separate maximum answer-length figure that can be safely substituted from the later model.
Structured output and functions
The maker lists structured outputs, function calling and predicted outputs among this edition's features. For a structured extraction task, define the required fields, expected types and treatment of information absent from the source. A record can contain the document identifier, the statement extracted, its source location and the question that remains. Ask for the record alone when a program will parse it, or keep a prose explanation separate when someone must inspect the interpretation.
Mistral's shared structured-output documentation distinguishes JSON mode from a custom schema. JSON mode requires an explicit instruction about the desired JSON format, while the custom route defines a more specific structure. This is formatting of the text result, not a new content modality or an external action.
For functions, the application defines the available operation and arguments, the model selects an appropriate call and prepares values, and the application executes it. Its result then becomes information for the next answer. A document assistant can use a lookup to obtain missing reference data, but only if the surrounding application supplies that lookup and returns its actual result. Keep the proposed call and the returned data associated with one another.
Predicted edits and response prefixes
Predicted outputs are useful when most of the desired result is already known, such as a document or code file needing a limited edit. Provide the existing content and describe the change precisely, including what must remain unchanged. A request might update one section's terminology or replace one implementation detail while preserving the rest of the document. The prediction contains expected output content rather than a completed change applied to a file.
The model page also lists response-prefix continuation. In the maker's chat documentation, a prefix supplies a known beginning for the assistant's response, after which generation continues. A known beginning and a predicted body solve different preparation problems. Batching and agent/conversation interfaces are likewise workflow features, rather than separate image, audio or reasoning editions of Medium 3.1.
Document and visual questions
The listed document-QnA workflow combines OCR-prepared text, structure and formatting with language-model analysis. Ask about the particular condition, passage or relationship required by the task. A comparison can identify the source documents and request shared statements, conflicts and unresolved details, retaining the source location beside each finding.
The maker's vision guide explicitly includes Medium 3.1. A direct visual question can provide a readable chart, document image or screenshot and ask what visible evidence supports a conclusion. Preserve axes, units, labels and the context around a cropped field. If several images are supplied, identify their order and role rather than leaving the model to infer which is the original, revision or reference.
For example, pair a written process requirement with a screenshot and request a table of visible matches, differences and questions requiring more information. Another task can supply two versions of a document and ask for a revised passage that preserves their shared conditions while resolving a named inconsistency. These are proposed applications of the documented visual, document and editing capabilities, with the required result defined in advance.
Preparing the final artifact
Give the assistant a clear role, the source material to use and the form of the answer. Keep durable response rules distinct from the document being examined, and state the final language and terminology. A useful response can separate an extracted fact, its source and an interpretation, making it easier to inspect than a single merged summary.
The documented result remains text. External tools, file changes and further document processing belong to the application connected to the conversation. Preserve the named Medium 3.1 edition and its 128k context, and request the explanation, structured record or targeted revision the next step actually needs.
", "aboutText": "Mistral Medium 3.1 is a multimodal Mistral AI edition for textual and visual understanding. The maker describes this revision as improving tone and performance within the Medium 3 line. It accepts text and images and produces text: an explanation, document answer, structured record or proposed function call. The maker's fixed identifier for this edition is mistral-medium-2508.\n\nContext and the specific edition\n\nThe model page documents a 128k context window. Use it to keep related source passages, image evidence, the conversation and the user's task together. Identify the document roles and the question to answer before supplying a large collection. A long context can support a focused comparison while the final artifact remains a short table or revised section.\n\nMedium 3.1 retains its own specification. The 256k context, dense 128B architecture and configurable hybrid reasoning modes described for Medium 3.5 should not be assigned to this entry. The 3.1 page does not provide a parameter count or a separate maximum answer-length figure that can be safely substituted from the later model.\n\nStructured output and functions\n\nThe maker lists structured outputs, function calling and predicted outputs among this edition's features. For a structured extraction task, define the required fields, expected types and treatment of information absent from the source. A record can contain the document identifier, the statement extracted, its source location and the question that remains. Ask for the record alone when a program will parse it, or keep a prose explanation separate when someone must inspect the interpretation.\n\nMistral's shared structured-output documentation distinguishes JSON mode from a custom schema. JSON mode requires an explicit instruction about the desired JSON format, while the custom route defines a more specific structure. This is formatting of the text result, not a new content modality or an external action.\n\nFor functions, the application defines the available operation and arguments, the model selects an appropriate call and prepares values, and the application executes it. Its result then becomes information for the next answer. A document assistant can use a lookup to obtain missing reference data, but only if the surrounding application supplies that lookup and returns its actual result. Keep the proposed call and the returned data associated with one another.\n\nPredicted edits and response prefixes\n\nPredicted outputs are useful when most of the desired result is already known, such as a document or code file needing a limited edit. Provide the existing content and describe the change precisely, including what must remain unchanged. A request might update one section's terminology or replace one implementation detail while preserving the rest of the document. The prediction contains expected output content rather than a completed change applied to a file.\n\nThe model page also lists response-prefix continuation. In the maker's chat documentation, a prefix supplies a known beginning for the assistant's response, after which generation continues. A known beginning and a predicted body solve different preparation problems. Batching and agent/conversation interfaces are likewise workflow features, rather than separate image, audio or reasoning editions of Medium 3.1.\n\nDocument and visual questions\n\nThe listed document-QnA workflow combines OCR-prepared text, structure and formatting with language-model analysis. Ask about the particular condition, passage or relationship required by the task. A comparison can identify the source documents and request shared statements, conflicts and unresolved details, retaining the source location beside each finding.\n\nThe maker's vision guide explicitly includes Medium 3.1. A direct visual question can provide a readable chart, document image or screenshot and ask what visible evidence supports a conclusion. Preserve axes, units, labels and the context around a cropped field. If several images are supplied, identify their order and role rather than leaving the model to infer which is the original, revision or reference.\n\nFor example, pair a written process requirement with a screenshot and request a table of visible matches, differences and questions requiring more information. Another task can supply two versions of a document and ask for a revised passage that preserves their shared conditions while resolving a named inconsistency. These are proposed applications of the documented visual, document and editing capabilities, with the required result defined in advance.\n\nPreparing the final artifact\n\nGive the assistant a clear role, the source material to use and the form of the answer. Keep durable response rules distinct from the document being examined, and state the final language and terminology. A useful response can separate an extracted fact, its source and an interpretation, making it easier to inspect than a single merged summary.\n\nThe documented result remains text. External tools, file changes and further document processing belong to the application connected to the conversation. Preserve the named Medium 3.1 edition and its 128k context, and request the explanation, structured record or targeted revision the next step actually needs.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Apply a narrow terminology edit\n\nRevise only the terminology in this paragraph: 'A subscriber can pause the plan. The subscriber keeps access until the current period ends. Support can help the subscriber resume.' Replace 'subscriber' with 'member', adapting capitalization, and keep every condition and sentence order. Return the revised paragraph alone, without claiming a file was modified.The complete revised paragraph with the requested terminology change only.The access-until-period-end condition and pause/resume distinction must remain intact.mistralai/mistral-medium-3.1Mistral Medium 3.1 is a text-and-image model for conversational answers, document questions and structured extraction. Its 128k maker context and listed function-calling, predicted-output and prefix features support source-based explanations and targeted editing 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.1 is a multimodal Mistral AI edition for textual and visual understanding. The maker describes this revision as improving tone and performance within the Medium 3 line. It accepts text and images and produces text: an explanation, document answer, structured record or proposed function call. The maker's fixed identifier for this edition is mistral-medium-2508.
Context and the specific edition
The model page documents a 128k context window. Use it to keep related source passages, image evidence, the conversation and the user's task together. Identify the document roles and the question to answer before supplying a large collection. A long context can support a focused comparison while the final artifact remains a short table or revised section.
Medium 3.1 retains its own specification. The 256k context, dense 128B architecture and configurable hybrid reasoning modes described for Medium 3.5 should not be assigned to this entry. The 3.1 page does not provide a parameter count or a separate maximum answer-length figure that can be safely substituted from the later model.
Structured output and functions
The maker lists structured outputs, function calling and predicted outputs among this edition's features. For a structured extraction task, define the required fields, expected types and treatment of information absent from the source. A record can contain the document identifier, the statement extracted, its source location and the question that remains. Ask for the record alone when a program will parse it, or keep a prose explanation separate when someone must inspect the interpretation.
Mistral's shared structured-output documentation distinguishes JSON mode from a custom schema. JSON mode requires an explicit instruction about the desired JSON format, while the custom route defines a more specific structure. This is formatting of the text result, not a new content modality or an external action.
For functions, the application defines the available operation and arguments, the model selects an appropriate call and prepares values, and the application executes it. Its result then becomes information for the next answer. A document assistant can use a lookup to obtain missing reference data, but only if the surrounding application supplies that lookup and returns its actual result. Keep the proposed call and the returned data associated with one another.
Predicted edits and response prefixes
Predicted outputs are useful when most of the desired result is already known, such as a document or code file needing a limited edit. Provide the existing content and describe the change precisely, including what must remain unchanged. A request might update one section's terminology or replace one implementation detail while preserving the rest of the document. The prediction contains expected output content rather than a completed change applied to a file.
The model page also lists response-prefix continuation. In the maker's chat documentation, a prefix supplies a known beginning for the assistant's response, after which generation continues. A known beginning and a predicted body solve different preparation problems. Batching and agent/conversation interfaces are likewise workflow features, rather than separate image, audio or reasoning editions of Medium 3.1.
Document and visual questions
The listed document-QnA workflow combines OCR-prepared text, structure and formatting with language-model analysis. Ask about the particular condition, passage or relationship required by the task. A comparison can identify the source documents and request shared statements, conflicts and unresolved details, retaining the source location beside each finding.
The maker's vision guide explicitly includes Medium 3.1. A direct visual question can provide a readable chart, document image or screenshot and ask what visible evidence supports a conclusion. Preserve axes, units, labels and the context around a cropped field. If several images are supplied, identify their order and role rather than leaving the model to infer which is the original, revision or reference.
For example, pair a written process requirement with a screenshot and request a table of visible matches, differences and questions requiring more information. Another task can supply two versions of a document and ask for a revised passage that preserves their shared conditions while resolving a named inconsistency. These are proposed applications of the documented visual, document and editing capabilities, with the required result defined in advance.
Preparing the final artifact
Give the assistant a clear role, the source material to use and the form of the answer. Keep durable response rules distinct from the document being examined, and state the final language and terminology. A useful response can separate an extracted fact, its source and an interpretation, making it easier to inspect than a single merged summary.
The documented result remains text. External tools, file changes and further document processing belong to the application connected to the conversation. Preserve the named Medium 3.1 edition and its 128k context, and request the explanation, structured record or targeted revision the next step actually needs.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-medium-3.1 | 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.1", "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.1',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.1',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.1
Use the method paths shown above.
mistralai/mistral-medium-3.1Mistral Medium 3.1 is a text-and-image model for conversational answers, document questions and structured extraction. Its 128k maker context and listed function-calling, predicted-output and prefix features support source-based explanations and targeted editing 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.1 is a multimodal Mistral AI edition for textual and visual understanding. The maker describes this revision as improving tone and performance within the Medium 3 line. It accepts text and images and produces text: an explanation, document answer, structured record or proposed function call. The maker's fixed identifier for this edition is mistral-medium-2508.
Context and the specific edition
The model page documents a 128k context window. Use it to keep related source passages, image evidence, the conversation and the user's task together. Identify the document roles and the question to answer before supplying a large collection. A long context can support a focused comparison while the final artifact remains a short table or revised section.
Medium 3.1 retains its own specification. The 256k context, dense 128B architecture and configurable hybrid reasoning modes described for Medium 3.5 should not be assigned to this entry. The 3.1 page does not provide a parameter count or a separate maximum answer-length figure that can be safely substituted from the later model.
Structured output and functions
The maker lists structured outputs, function calling and predicted outputs among this edition's features. For a structured extraction task, define the required fields, expected types and treatment of information absent from the source. A record can contain the document identifier, the statement extracted, its source location and the question that remains. Ask for the record alone when a program will parse it, or keep a prose explanation separate when someone must inspect the interpretation.
Mistral's shared structured-output documentation distinguishes JSON mode from a custom schema. JSON mode requires an explicit instruction about the desired JSON format, while the custom route defines a more specific structure. This is formatting of the text result, not a new content modality or an external action.
For functions, the application defines the available operation and arguments, the model selects an appropriate call and prepares values, and the application executes it. Its result then becomes information for the next answer. A document assistant can use a lookup to obtain missing reference data, but only if the surrounding application supplies that lookup and returns its actual result. Keep the proposed call and the returned data associated with one another.
Predicted edits and response prefixes
Predicted outputs are useful when most of the desired result is already known, such as a document or code file needing a limited edit. Provide the existing content and describe the change precisely, including what must remain unchanged. A request might update one section's terminology or replace one implementation detail while preserving the rest of the document. The prediction contains expected output content rather than a completed change applied to a file.
The model page also lists response-prefix continuation. In the maker's chat documentation, a prefix supplies a known beginning for the assistant's response, after which generation continues. A known beginning and a predicted body solve different preparation problems. Batching and agent/conversation interfaces are likewise workflow features, rather than separate image, audio or reasoning editions of Medium 3.1.
Document and visual questions
The listed document-QnA workflow combines OCR-prepared text, structure and formatting with language-model analysis. Ask about the particular condition, passage or relationship required by the task. A comparison can identify the source documents and request shared statements, conflicts and unresolved details, retaining the source location beside each finding.
The maker's vision guide explicitly includes Medium 3.1. A direct visual question can provide a readable chart, document image or screenshot and ask what visible evidence supports a conclusion. Preserve axes, units, labels and the context around a cropped field. If several images are supplied, identify their order and role rather than leaving the model to infer which is the original, revision or reference.
For example, pair a written process requirement with a screenshot and request a table of visible matches, differences and questions requiring more information. Another task can supply two versions of a document and ask for a revised passage that preserves their shared conditions while resolving a named inconsistency. These are proposed applications of the documented visual, document and editing capabilities, with the required result defined in advance.
Preparing the final artifact
Give the assistant a clear role, the source material to use and the form of the answer. Keep durable response rules distinct from the document being examined, and state the final language and terminology. A useful response can separate an extracted fact, its source and an interpretation, making it easier to inspect than a single merged summary.
The documented result remains text. External tools, file changes and further document processing belong to the application connected to the conversation. Preserve the named Medium 3.1 edition and its 128k context, and request the explanation, structured record or targeted revision the next step actually needs.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits mistralai/mistral-medium-3.1 | 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.1",\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.1', '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.1', '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.1
Use the method paths shown above.
Technical example in English
Apply a narrow terminology edit\n\nRevise only the terminology in this paragraph: 'A subscriber can pause the plan. The subscriber keeps access until the current period ends. Support can help the subscriber resume.' Replace 'subscriber' with 'member', adapting capitalization, and keep every condition and sentence order. Return the revised paragraph alone, without claiming a file was modified.The complete revised paragraph with the requested terminology change only.The access-until-period-end condition and pause/resume distinction must remain intact.