MiMo API 的 OpenAI 兼容接入 —— 以及它的默认思考

MiMo 是小米的模型家族 —— 通用版 mimo-v2.5 与 Pro 档，官方声明 1M token 上下文、原生 OpenAI 与 Anthropic 双格式。通过 DaoXE，用 GET /v1/models 里的 MiMo ID 调 /v1/chat/completions，与其他家族共用同一个 key —— 你的账号到底载哪些 MiMo ID，以实时列表为准，别当默认。成本分流见最便宜 API 教程。

通过 DaoXE 调用 MiMo#

Chat 路径：/v1/chat/completions，用 Authorization: Bearer。MiMo 默认思考：厂商文档写明 thinking 字段（enabled/disabled），当前 v2.5 系列 ID 的出厂状态就是开启。思考开启时采样被锁定 —— 自定义 temperature/top_p 会被强制按官方推荐值 1.0/0.95 生效 —— 而管住「思考+回答」总预算的是 max_completion_tokens。

curl --fail-with-body --show-error --silent \
  https://daoxe.com/v1/chat/completions \
  -H "Authorization: Bearer ${DAOXE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_EXACT_MODEL_ID",
    "max_tokens": 64,
    "messages": [{"role": "user", "content": "Say hello in one sentence."}]
  }'

# MiMo reasoning IDs think by DEFAULT, lock temperature/top_p, and 400 if a
# tool-call round drops reasoning_content. max_completion_tokens (not max_tokens)
# is the cap that covers thinking + answer.
from openai import OpenAI

client = OpenAI(base_url="https://daoxe.com/v1", api_key="YOUR_DAOXE_KEY")
r = client.chat.completions.create(
    model="YOUR_EXACT_MODEL_ID",   # a mimo-* id from GET /v1/models
    messages=[{"role": "user", "content": "2+2? Think briefly, then answer."}],
    max_completion_tokens=2048,    # thinking + answer share this budget
    # thinking is ON by default; to opt out explicitly:
    extra_body={"thinking": {"type": "disabled"}},  # non-standard: extra_body
)
msg = r.choices[0].message
print(getattr(msg, "reasoning_content", None))  # thinking trace
print(msg.content)                              # final answer
print(r.usage.completion_tokens_details.reasoning_tokens)  # thinking spend

MiMo 如何暴露思考内容#

MiMo 把思考轨迹放在消息上独立的 reasoning_content 字段里 —— 与 DeepSeek 同型，而 usage.completion_tokens_details.reasoning_tokens 报告开销。两点使它成为推理家族里最严的一个：不发 thinking: {"type": "disabled"} 思考就一直开着；多轮契约是强制的而非建议 —— 丢掉 reasoning_content 的工具调用回合直接 400，而 DeepSeek 式 API 是性能退化或文档仅口头警告。非标准的 thinking 字段能否穿过某条中转路径、reasoning_content 是否保留，正是要验证的事 —— 绑定客户端前先发一次测试调用。

MiMo 特有的注意点#

• 思考是默认态，不是可选项。 thinking 字段（{"type": "enabled"} / {"type": "disabled"}）是非标准字段 —— 用你 SDK 的 extra-body 发送，而且不发送就意味着 v2.5 ID 的思考保持开启。默认按纯文本回答解析的客户端，要么显式关掉，要么得能解析 reasoning_content。
• 工具循环里丢 reasoning_content 直接 400。 厂商原话说得很硬：多轮 agent 对话带工具调用时，每一轮回传的 assistant 消息必须完整带回 reasoning_content，否则 API 返回 400 错误。文档还按协议点名了受影响客户端 —— OpenAI 侧的 Cursor、Roo Code、Codex、Zed、Goose 等；Anthropic 侧的 OpenCode、Kilo Code 等。重建历史要用原始消息对象，别用截断摘要。
• 思考开启时采样参数收下但忽略。 自定义 temperature/top_p 不报错 —— 会被静默强制为 1.0/0.95。在 thinking 请求上调它们是无效操作，别再惯性带了。
• 管预算的是 max_completion_tokens，不是 max_tokens。 上限覆盖思考加回答，预算给小了，长思考之后回答会被截断。准确 ID 永远从 GET /v1/models 读。

这要花多少钱#

验证你拿到的是真模型#

先证明端点可用，再怀疑客户端 —— 这一步失败，改任何设置都没用：

export DAOXE_API_KEY="your_api_key"

# List the exact model IDs your account can call
curl --fail-with-body --show-error --silent \
  https://daoxe.com/v1/models \
  -H "Authorization: Bearer ${DAOXE_API_KEY}"

先确认连通，再（MiMo 思考时会强制自己的采样配置）把固定 prompt 与官方 MiMo API 对比，确认模型档位：

常见问题#