MiMo-V2.6-Pro · workflow
For mimo-v2.6-pro, the official workflow is “the model returns a complete assistant message, including reasoning_content and tool_calls → the client executes the tools → appends the role: tool results → requests the model again,” repeating until the current turn produces no more tool calls.
Use MiMo-V2.6-Pro for {{TASK}}: pin {{MODEL_ID}} and {{INPUT_FORMAT}}, follow {{TOOL_STEPS}}, then check the result against {{ACCEPTANCE}}.
Replace every variable before running and write the actual values into the acceptance record.Replace before running: {{TASK}}, {{MODEL_ID}}, {{INPUT_FORMAT}}, {{TOOL_STEPS}}, {{ACCEPTANCE}}
Use MiMo-V2.6-Pro for {{TASK}}: pin {{MODEL_ID}} and {{INPUT_FORMAT}}, follow {{TOOL_STEPS}}, then check the result against {{ACCEPTANCE}}.
For mimo-v2.6-pro, the official workflow is “the model returns a complete assistant message, including reasoning_content and tool_calls → the client executes the tools → appends the role: tool results → requests the model again,” repeating until the current turn produces no more tool calls.
Suitable tasks: Tasks requiring live information, external functions, coordination across multiple tools, follow-up questions, and multi-step agent orchestration.
Unsuitable tasks: Side-effecting operations such as payments, deletion, sending messages, or changing permissions without user confirmation; tool execution permissions are not automatically made safe by the model.
Applicable model versions: mimo-v2.6-pro. The web search page also lists other MiMo versions, but the code and conclusions in this document target Pro only.
Applicable clients, agents, or APIs: An OpenAI Chat Completions-compatible API. The official web search page explicitly says that this plugin does not currently support other API protocols.
Recommended reasoning tier and parameters: Explicitly set extra_body={"thinking": {"type": "enabled"}} for multi-turn tool calling, and make sure max_completion_tokens covers the combined length of reasoning and the final answer; under deep thinking, do not rely on custom temperature or top_p values.
The following schema comes from the official “multi-turn tool calling under deep thinking” example, whose model ID is explicitly mimo-v2.6-pro. The tool functions themselves must be implemented by the client; the schema does not represent already-granted execution permissions.
import json
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ.get("MIMO_API_KEY"),
base_url="https://api.xiaomimimo.com/v1",
)
tools = [
{
"type": "function",
"function": {
"name": "get_current_weather",
"description": "Get the current weather for a given city",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City name, e.g. Beijing",
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
},
},
"required": ["location"],
},
},
},
{
"type": "function",
"function": {
"name": "get_time",
"description": "Get the current time in a given timezone",
"parameters": {
"type": "object",
"properties": {
"timezone": {
"type": "string",
"description": "Timezone, e.g. Asia/Shanghai",
}
},
"required": ["timezone"],
},
},
},
]This is the reusable core of the official example. messages.append(assistant_message) must retain the complete assistant message; do not save only content or only the tool arguments.
def get_current_weather(location: str, unit: str = "celsius") -> str:
# Replace this with a real business service; the sample data is not a weather fact.
weather_data = {
"Beijing": "Sunny 25°C",
"Shanghai": "Cloudy 22°C",
"Shenzhen": "Rainy 28°C",
}
return weather_data.get(location, f"Weather unknown for {location}")
def get_time(timezone: str) -> str:
from datetime import datetime
return datetime.now().strftime(f"%Y-%m-%d %H:%M:%S ({timezone})")
TOOL_MAP = {
"get_current_weather": get_current_weather,
"get_time": get_time,
}
def run_turn(messages, turn_num, max_requests=8):
request_num = 0
while True:
request_num += 1
if request_num > max_requests:
raise RuntimeError("tool loop exceeded the local safety limit")
response = client.chat.completions.create(
model="mimo-v2.6-pro",
messages=messages,
tools=tools,
extra_body={"thinking": {"type": "enabled"}},
)
assistant_message = response.choices[0].message
# Retain reasoning_content, content, tool_calls, and their order.
messages.append(assistant_message)
if not assistant_message.tool_calls:
return assistant_message.content
for tool_call in assistant_message.tool_calls:
name = tool_call.function.name
if name not in TOOL_MAP:
raise PermissionError(f"tool is not allowlisted: {name}")
args = json.loads(tool_call.function.arguments)
result = TOOL_MAP[name](**args)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": result,
})
messages = [
{
"role": "user",
"content": "How is the weather in Beijing today? What time is it now?",
}
]
run_turn(messages, turn_num=1)
# Continue reusing the same messages in the second turn; the first turn's
# reasoning_content, content, tool_calls, and tool results remain in history.
messages.append({
"role": "user",
"content": "How about Shanghai? And is it hotter or colder than Beijing?",
})
run_turn(messages, turn_num=2)Web search is not a custom Function. The official mimo-v2.6-pro example uses type: "web_search" and controls one request with max_keyword, force_search, limit, and an approximate location:
completion = client.chat.completions.create(
model="mimo-v2.6-pro",
messages=[
{"role": "user", "content": "What will the weather be like in Wuhan tomorrow?"},
],
max_completion_tokens=1024,
stream=False,
extra_body={"thinking": {"type": "disabled"}},
tools=[
{
"type": "web_search",
"max_keyword": 3,
"force_search": True,
"limit": 1,
"user_location": {
"type": "approximate",
"country": "China",
"region": "Hubei",
"city": "Wuhan",
},
}
],
tool_choice="auto",
)Enable the web service plugin in the Xiaomi MiMo console (only the web search workflow requires it), and read the API key from an environment variable.
Use a strict JSON Schema for custom functions: list the function name, purpose, parameter types, enum values, and required fields; the client should register only functions that are allowed to execute.
Send tools and the user message. Enable thinking.type=enabled for complex multi-step tasks; with the Python SDK, put thinking in extra_body, not in a top-level OpenAI standard parameter.
When an assistant message arrives, first add the complete message to messages, then parse tool_calls. If there are multiple calls, validate each name and its arguments; independent, side-effect-free reads may be executed in controlled parallel, then append the corresponding role: tool messages in the original call order.
After appending all tool results, request mimo-v2.6-pro again. Repeat “request → execute → append” until the assistant has no tool_calls, then return content to the user.
A follow-up question in the next turn must append a new role: user message to the same history; do not discard the earlier assistant message containing reasoning_content.
Validate response.model == "mimo-v2.6-pro", finish_reason, tool names, JSON arguments, tool_call_id mappings, and the final content on every turn; record input/output tokens, the number of tool calls, errors, and elapsed time.
Add a local maximum request count, timeout, cancellation, retry, and cost cap. The official example demonstrates the loop but does not publish a dependable maximum number of tool-calling turns or parallel calls.
The official documentation lists mimo-v2.6-pro as supporting thinking.type values of enabled and disabled.
In the official example's first turn, get_current_weather and get_time are called together; the client executes the tools, appends their results with role: "tool", and sends another request. The second turn appends a user follow-up while retaining the first turn's context.
The official documentation requires that, when deep thinking is enabled and the history contains tool calls, a subsequent user-interaction turn must fully return reasoning_content if the assistant contains tool calls; omitting it can cause the API to return 400 and may also reduce instruction following or increase hallucinations.
The official documentation says that streaming responses output reasoning_content deltas first and content deltas afterward; to use them across turns, the client should concatenate and persist the corresponding fields.
The official documentation says custom temperature and top_p are unsupported under deep thinking, which uses the recommended defaults of 1.0 and 0.95; max_completion_tokens limits both reasoning and the final answer.
The official example explicitly uses model="mimo-v2.6-pro" and type: "web_search".
The page says web search supports forced search and intent recognition; force_search=true prevents the model from answering directly when it decides that search is unnecessary.
The page says one search may call the web plugin multiple times with multiple keywords; max_keyword limits the maximum number of keywords per turn and controls call frequency and cost. The example value is 3.
The page says web search can be mixed with custom Functions and other tools; the model determines call priority and necessity. The first streamed packet returns search sources, and both streaming and non-streaming modes return search and summary content.
The official example response has model set to mimo-v2.6-pro and returns source fields under annotations as url_citation.
reasoning_content is a history field for deep-thinking multi-turn tool calling and must not be deleted just because the user cares only about the final answer; the entire tool-call history must be persisted.
The official example shows two independent tools returned in one assistant response, but does not promise parallel calls of any arbitrary size; production implementations should set a concurrency limit and default write operations to serial execution with a second confirmation.
The weather dictionary and time function in the official code only demonstrate the tool-execution interface; they are not official weather data and do not represent a measurement of the model's web-search capability.
The model should only propose tool calls and must not receive direct database, filesystem, network, or account permissions. Production systems should implement an allowlist, JSON Schema validation, least privilege, user confirmation, timeouts, auditing, and redaction.
The web search plugin must be enabled separately; the model may decide that search is unnecessary, and the official documentation says changes to the cache switch may take up to 5 minutes to take effect. To verify forced search, inspect annotations/url_citation in the response rather than checking only for HTTP 200.
This workflow targets the hosted API's mimo-v2.6-pro; the templates and behavior of the local MiMo-V2.6-Pro-RL checkpoint, mimo-v2.6-pro-ultraspeed, or mimo-v2.6-flash must not be substituted directly.
The official documentation does not publish a complete business tool server, concurrency limit, maximum loop count, or security policy; max_requests=8, the allowlist, and permission checks in this document are client-side safety guardrails, not Xiaomi service-side limits.
The official text requires that multi-turn tool calling “must fully return the reasoning_content field.”
The official web search page says: “mixed multi-tool calling,” which can be used together with custom Functions.
The official web search example uses mimo-v2.6-pro as the model and shows max_keyword: 3, force_search: True, and tool_choice="auto".
Xiaomi MiMo official documentation · Source date: 2026-09-22 · Edited: 2026-09-22
Read the original sourceMiMo-V2.6-Pro
Run this guide in the environment listed above. Downloading does not transfer the template or establish model availability for your account.