2026 Cursor 調 OpenAI o1 帳單異常？先查真實呼叫鏈

先做 Cursor OpenAI o1 帳單排查，不要急著增加本地模型：本週先以請求時間、模型標識、虛擬金鑰與 request ID 串起 Cursor、LiteLLM 和模型供應方三層紀錄，確認實際命中、重試與回退路徑，再決定修規則、回滾代理或擴充 Qwen3-Coder。這個順序特別適合已看到「介面選了 o1、網關顯示 fallback、帳單卻持續增加」的團隊。

如果您負責核對 Cursor、模型供應方與網關用量，或維護 LiteLLM 路由、金鑰及日誌，本文可直接作為排查框架；若只是偶爾使用 AI 程式工具，則不必先搭建完整的審計鏈。

提醒： Cursor 介面顯示 OpenAI o1，不足以證明請求最後真的命中 o1。Cursor 官方自有 API 金鑰文件目前將 OpenAI 支援範圍描述為標準、非推理聊天模型，因此必須先確認實際接入方式與後端部署，而不能把介面名稱當成供應方帳單證據。Cursor 自有 API 金鑰支援範圍

先固定三層帳務邊界

同一個使用者操作，可能同時留下 Cursor 用量紀錄、LiteLLM 網關紀錄，以及 OpenAI API 用量紀錄。三者的用途不同：Cursor 反映客戶端發出的操作與模型選擇；LiteLLM 反映代理收到的請求、路由、重試和 fallback；供應方紀錄才是其自身計費與 usage 欄位的依據。把三份資料直接相加，容易把同一請求重複計算。

每筆紀錄至少要保留請求時間、模型標識、虛擬金鑰、request ID、HTTP 狀態碼與上游目標。若代理在轉送時沒有保留原始 request ID，或只輸出聚合後的總量，我們最多只能判斷某段時間的趨勢，不能斷言某一次 Cursor 操作究竟歸屬哪個模型。

OpenAI 的 Usage API 文件可用來理解供應方用量查詢的資料邊界；它不是 LiteLLM 日誌的替代品，仍要以時間窗、金鑰和請求識別欄位完成交叉核對。OpenAI Usage API 參考

模型身份與別名映射

常見失敗案例是：Cursor 顯示 o1，LiteLLM 的設定卻把某個通用別名映射到另一個部署；或者全域 Base URL 讓請求先進入代理，再由代理依預設模型處理。另一種情況是自有金鑰本身不在 Cursor 官方文件列出的支援範圍內，團隊卻把「能看到模型名稱」誤認為「已完成官方直連」。

透過 API 代理後，怎樣確認實際使用哪個模型？
不要只看 Cursor 的下拉選單。先從 LiteLLM 日誌找出該時間窗內的 model_name、上游端點和 request ID，再到供應方回應或用量紀錄核對 response model。若三層沒有共同識別欄位，應把結果標示為「模型身份未完全確認」，而不是填上一個看似合理的 o1。

OpenAI 的 o1 模型資料明確涉及推理 Token；Cursor 的模型說明則是客戶端可用模型與使用方式的參考，兩者都不能取代實際代理日誌。OpenAI o1 模型資料 及 Cursor 模型說明 可作為核對入口。

推理 Token 與重試放大

OpenAI o1 的費用判斷不能依可見回答長度估算。輸入、快取輸入、輸出，以及推理相關 usage，應以官方回應欄位與帳務紀錄核對；若代理把 usage 截斷、改名，或只保留聚合總量，就只能標註「相容性待確認」，不能自行補算推理 Token。Responses API 的 usage 與推理 Token 欄位

重試與回退則是另一個成本漏口。Cursor Agent 的多輪執行、工具呼叫失敗、代理重試，可能讓一次使用者操作產生多筆上游請求。要把同一任務的時間戳、狀態碼、重試原因、目標模型和 request ID 放在同一條鏈上，才能區分：

• 上游暫時失敗後的可靠性回退；
• 同一請求因逾時而再次送出；
• 依規則把任務分流到另一模型；
• Cursor 因工具操作失敗而重新啟動一輪 Agent。

LiteLLM fallback 為何會把普通任務送到 OpenAI o1？
LiteLLM 的 fallback、重試和成本追蹤是網關能力，不代表它會自動理解「這是簡單程式」或「這是複雜推理」。只要本地端點被判定為逾時、不可用、回應格式不相容，或路由規則把某個別名指向 o1，普通任務也可能進入雲端。必須查看觸發條件與原始錯誤，不能把一般 fallback 包裝成智能任務分級。LiteLLM 官方網關、重試與 fallback 文件

Qwen3-Coder 分流漏口

本地 Qwen3-Coder 能正常回應，卻不代表常規編碼請求都走本地。最常見的漏口包括：健康檢查只測試服務存活，沒有測試實際模型別名；上下文格式不相容，導致請求在路由前被拒絕；本地端點回應稍慢而觸發逾時；以及 Cursor 發出的模型名稱沒有對應到 LiteLLM 預期的 model_name。Qwen3-Coder 的官方資料可用來核對其介面與模型使用邊界。Qwen3-Coder 官方資料

本地 Qwen3-Coder 已正常回應，為何雲端費用仍在增加？
因為「至少有一筆本地成功」與「所有常規請求都命中本地」是兩個不同命題。應用相同、最小化的測試任務分別驗證三條路徑：本地成功、明確升級至 OpenAI o1、本地失敗後回退。每條路徑都要能在 Cursor、LiteLLM 和供應方紀錄中還原；只看最終回答成功，無法判斷中間是否曾經發出雲端請求。

可用下列條件列表作為本週決策工具：

• 若本地端點健康、model_name 映射正確，而且常規請求的上游紀錄沒有雲端命中，則保留目前分流規則，進入品質觀察。
• 若本地失敗後回退，但每次回退都有明確錯誤、時間與 request ID，則保留 fallback，同時限制可回退的模型與金鑰範圍。
• 若普通請求在沒有本地錯誤的情況下仍進入 o1，則先修正別名、Base URL 或條件順序，不要先增加本地硬體。
• 若usage 欄位在代理層遺失、模型身份無法核實，則暫停以帳單作精確成本結論，必要時回滾代理。
• 若上述證據均完整，但本地端點穩定性確實成為瓶頸，則才進入常駐設備與彈性 Mac 算力的下一輪評估。

上線驗收與方案評分

修復後不要以「回答看起來正確」作為唯一通過條件。我們建議把驗收拆成四個部分：模型命中符合規則、失敗回退可解釋、usage 可以追蹤、金鑰權限隔離，而且程式品質沒有明顯退化。

評分可採「通過、待觀察、回滾」三種結果，而不必虛構金額或命中率：

• 通過：五項證據均可還原，o1 只在明確條件下命中。
• 待觀察：路由正確，但本地錯誤仍偶發；先縮小流量並保留完整日誌。
• 回滾：模型身份、usage 或金鑰歸屬無法核實，繼續運行會使帳務責任不清。

經驗： 若代理只留下最後一次回應，沒有原始 request ID、重試原因和上游模型欄位，任何「已節省成本」的結論都不具備可稽核性。

先修路由，還是改用 Mac 算力

若目前方案是把 Cursor、代理和本地模型服務疊在同一台開發機或臨時雲端環境上，常見缺點是：資源與開發工作互相搶用、端點重啟後路由狀態不一致、金鑰與日誌權限難以分離，並且遇到長時間本地推理時缺少穩定的交付與維護邊界。這些問題不會因為把 o1 單價換算得更仔細就自動消失。

因此，若審計結果顯示根因只是別名或 fallback 規則錯誤，應先修網關，不必租用或購買設備；若本地節點才是穩定性瓶頸，才值得比較常駐 Mac 與彈性 Mac 算力。需要確認本地推理環境的人，可以先參考 本地模型推理環境的驗收思路；若要評估 Mac 作為開發與推理節點，也可查看 Mac 本地 AI 算力實測方向。

對於需要臨時測試環境、短期驗證 Qwen3-Coder 分流，或不想先承擔常駐設備維護的人，租用 JexMac 的 Mac 環境會比讓現有開發機長期承受本地推理更容易隔離問題；但若團隊是長期穩定重負載，或必須接觸特定實體介面，自購設備仍可能更合適。先完成呼叫鏈驗收，再根據本地節點是否真的成為瓶頸決定方案，會比直接擴容更可靠。

最後更新於 2026 年 9 月 17 日；模型支援範圍、o1 usage 欄位、LiteLLM fallback 行為與 Qwen3-Coder 資料已依上述官方文件核實。