主機與憑證
按量付費的 OpenAI 請求使用 https://api.xiaomimimo.com/v1 與 api-key 標頭。Token Plan 使用專用主機和 tp-xxxxx 憑證。
繁體中文
MIMO 2.5 PRO API
逐一檢查 MiMo 2.5 Pro API 的連線欄位
可用的請求需要正確的小米主機、api-key 標頭、準確的模型 ID，以及 MiMo 接受的請求本體。本頁先從失敗症狀開始，再依序檢查 thinking、stream、上下文與供應商路由。
官方文件核對日期：2026-08-27。目前 Tabbit 模型選擇器沒有 MiMo-V2.5-Pro，因此 Tabbit 只作為另一條支援模型路徑介紹。
官方文件的實際內容
多數失敗請求都是契約欄位不合
小米文件列出兩組 Base URL、一個模型 ID，以及 OpenAI 和 Anthropic 相容格式。社群結果也出現供應商拒絕與只消耗輸入 token 卻沒有有效輸出的線索，但不能視為服務保證。
模型與請求本體
官方範例使用 mimo-v2.5-pro 與 /chat/completions。先確認 messages 合法，再調整採樣或 Agent 欄位。
推理也是狀態
深度思考會回傳 reasoning_content。工具呼叫的多輪對話必須在後續 assistant 訊息完整帶回此欄位，否則 API 可能回傳 400。
最小可用請求
先用 curl 驗證，再調整 SDK
這是官方 OpenAI 相容格式，縮減到可以確認路由的欄位。將金鑰放在 shell 環境變數，不要提交到程式庫。
可複製基線
curl --location --request POST 'https://api.xiaomimimo.com/v1/chat/completions' \
--header "api-key: $MIMO_API_KEY" \
--header "Content-Type: application/json" \
--data-raw '{"model":"mimo-v2.5-pro","messages":[{"role":"user","content":"Hello"}],"max_completion_tokens":1024,"stream":false}'官方範例也有 max_completion_tokens、temperature 1.0、top_p 0.95、stream false 與 penalty 欄位。深度思考可能強制使用建議的採樣預設值。
- 01
選擇帳戶路由
按量付費使用 https://api.xiaomimimo.com/v1。Token Plan 則改用訂閱成功後顯示的專屬 Base URL。
- 02
傳送小米驗證
使用 api-key: $MIMO_API_KEY 與 Content-Type: application/json。不要假設每個 OpenAI 客戶端都會把 Authorization 轉成文件所寫的標頭。
- 03
填入準確 ID
將 model 設為 mimo-v2.5-pro。第三方閘道可能使用其他 slug，請從供應商目前的目錄複製。
- 04
先送出一輪使用者訊息
從一則 user 訊息開始。確認回傳 completion 後，再加入 tools、thinking 和 stream。
思考、串流與上下文
三個會改變回應形狀的控制項
把 API 行為當作測試依據。空白的最終答案可能是客戶端只讀取 content，而文字仍在 reasoning_content 中，也可能是思考耗盡了預算。
thinking.type
傳送 {"type":"enabled"} 或 {"type":"disabled"}。小米列出的 mimo-v2.5-pro 與 mimo-v2.5 預設開啟。Python SDK 中應把非標準欄位放入 extra_body。
stream 與結束標記
啟用串流後，reasoning_content 分片先到，content 分片隨後到。累積兩個欄位，在 finish_reason 出現時結束，並處理 [DONE] 前的 usage 分片。
上下文與預算
不要猜測文件未確認的 context window 數字。讓完整 messages 符合目前模型和帳戶限制。max_completion_tokens 同時涵蓋思考與最終答案，長思考會壓縮答案空間。
小米說深度思考時自訂 temperature 和 top_p 不會生效，建議值是 1.0 和 0.95。如果客戶端仍傳送這些欄位，請檢查伺服器回應，不要假設自訂值生效。
路由差異
官方 API、Token Plan 與閘道不是同一份契約
OpenAI 相容只描述請求形式，不代表計費、模型別名、標頭、配額、審核或串流行為相同。每次失敗都記錄主機與供應商。
| 檢查項目 | 小米官方 | 閘道或其他供應商 |
|---|---|---|
| OpenAI Base | https://api.xiaomimimo.com/v1 | 使用供應商目前的 Base URL |
| Token Plan | https://token-plan-cn.xiaomimimo.com/v1，憑證為 tp-xxxxx | 通常不能與按量付費金鑰互換 |
| 模型欄位 | mimo-v2.5-pro | 複製供應商目前的準確 slug |
| 驗證 | api-key: MIMO_API_KEY | 依供應商文件使用標頭和金鑰格式 |
| 限制與政策 | 查看小米帳戶用量和 API 控制台 | 查看供應商配額、審核、RPM、TPM 與並發 |
狀態碼清單
用回應碼縮小排查範圍
一次只改一個變數。重試前保存請求主機、模型、回應本體與時間戳。
請求本體格式錯誤、欄位不支援、messages 無效，或工具呼叫歷史遺漏 reasoning_content。
重播最小請求，檢查 JSON、model、messages、thinking 的位置，以及 reasoning_content 是否完整帶回。
金鑰遺失、過期、前綴錯誤，或標頭不正確。
從環境變數載入目標金鑰，使用文件的 api-key 標頭。不要列印金鑰。
帳戶或路由沒有權限，或閘道政策拒絕請求。
確認小米帳戶、方案主機、模型權限、供應商政策和審核結果。
主機路徑或模型別名在目前路由不存在。
檢查 /v1/chat/completions、Base URL 和目前模型目錄，不要重複拼接 /v1。
超過速率、token、並發或帳戶配額。
查看目前控制台或供應商限制，使用帶抖動的退避並降低平行請求。
請求很快回傳但 content 空白，或串流回應看似卡住。
記錄每個 delta，包括 reasoning_content 和 finish_reason。提高 max_completion_tokens，檢查串流解析，並用 thinking disabled 測試。
不需要 API 時的瀏覽器路徑
把 Tabbit 用在問題上，不要先處理金鑰管線
目前 Tabbit 選擇器沒有 MiMo-V2.5-Pro，因此不能承諾一鍵整合。如果目標是研究、理解網頁或比較多個答案，請選擇選擇器中實際存在的模型，讓 API 排錯和瀏覽器工作流分開。
01
選擇已列出的模型
新分頁會顯示模型選擇器。選一個目前可用的模型，不必建立小米金鑰或複製 Base URL。
02
帶入網頁上下文
直接詢問目前頁面，或從瀏覽器輸入框引用頁面和檔案。這解決的是另一種問題，不等於原始 API 請求。
03
並排比較答案
Tabbit 可以並排顯示支援模型的回答，也能用 Deep Research 收集來源和執行步驟。
選擇哪條路徑
API 控制力與瀏覽器上下文
如果你擁有自己的整合，使用小米 MiMo API。如果只是想處理網頁並使用支援模型，Tabbit 的路徑更短。
| 需求 | MiMo API | Tabbit |
|---|---|---|
| 憑證 | 建立並保護小米或供應商金鑰 | 使用選擇器中已開放的模型 |
| 請求控制 | 選擇主機、模型、本體、思考、工具與串流 | 從瀏覽器上下文直接提問 |
| 工具狀態 | 正確保存 assistant 的 reasoning_content | 不必手動重播原始 API 訊息 |
| 網頁研究 | 自行建立搜尋、擷取和引用管線 | 使用網頁和 Deep Research 流程 |
MIMO API 常見問題
第一次請求失敗後最常問的事
MiMo 2.5 Pro 官方端點是什麼？+
按量付費的 OpenAI 相容介面使用 https://api.xiaomimimo.com/v1，後面呼叫 /chat/completions。Token Plan 有獨立的 Base URL。
小米文件使用哪個 API Key 標頭？+
官方 curl 使用 api-key: $MIMO_API_KEY。金鑰應放在環境變數，閘道則要確認是否規定其他標頭。
應該傳送哪個模型 ID？+
小米範例使用 mimo-v2.5-pro。閘道可能發布不同別名，請使用供應商目錄中的準確 ID。
如何開啟或關閉深度思考？+
傳送 thinking.type 為 enabled 或 disabled。OpenAI Python SDK 中把非標準欄位放進 extra_body。小米說兩款 V2.5 模型預設開啟。
為什麼最終答案空白或很慢？+
思考會消耗 completion 預算並增加延遲。串流回應中 reasoning_content 先於 content 到達。累積兩者，設定足夠的 max_completion_tokens，並檢查 finish_reason。
為什麼後續工具呼叫回傳 400？+
啟用深度思考並呼叫工具時，小米要求把先前完整的 reasoning_content 放入下一次請求的 assistant 訊息。遺漏會讓上下文不完整。
MiMo 是否有可以直接寫入客戶端的固定上下文視窗？+
不要從第三方頁面複製未確認的數字。查看目前小米模型和帳戶限制，並為思考和最終輸出留下空間。
可以直接在 Tabbit 使用 MiMo-V2.5-Pro 嗎？+
目前 Tabbit 選擇器沒有列出該模型。API 請使用小米或閘道，瀏覽器研究和頁面任務則選擇 Tabbit 目前列出的模型。
準備好不再猜下一個 400 了嗎？
先重播最小的小米請求，再逐一加入 thinking、tools 和 streaming。需要瀏覽器工作時，選擇 Tabbit 的支援模型，不必先建立 API 金鑰。
模型可用性和供應商限制可能變更。正式上線前請重新查看官方文件。