2026 CursorでOpenAI o1を呼び出した請求異常？まず実際の呼び出し経路を確認

OpenAIのResponses APIでは、回答本文とは別に推論トークンをusage情報として扱います。公式のUsage項目が請求と一致しない構成では、画面に見える回答量だけで費用を推定できません。今週は、まずCursor OpenAI o1の請求調査として、Cursor、LiteLLM、OpenAI APIの3層を同じ呼び出しIDで突き合わせてください。モデルを増やしたり、ローカル機器を追加したりするのは、その監査後です。

Last updated：2026年9月17日。 Cursorの自前APIキー対応範囲、OpenAI o1のusage仕様、LiteLLMのfallbackとコスト追跡、Qwen3-Coderの公式資料を基に確認しています。

対象読者と今回の判断

Cursor、モデル提供元、ゲートウェイの利用量を照合するチーム管理者向けの記事です。LiteLLMの経路、仮想キー、ログ保存を担当するプラットフォームエンジニアにも適しています。

Qwen3-Coderを通常のコーディングに使い、難しい推論だけをOpenAI o1へ送る方針を検討している技術責任者は、分流が本当に機能したかを回答結果ではなく記録で判定してください。

典型的な失敗は、Cursorの画面ではo1を選択し、LiteLLMにはfallbackが残り、OpenAI APIの請求だけが増え続ける状態です。ここで「o1の単価が高い」と即断すると、別名の誤変換、重複リクエスト、ローカル端点の失敗を見逃します。

請求調査の対象になる3つの境界

まず、各記録が何を表しているかを分けます。

• Cursorの利用記録：クライアントから見たモデル選択、操作、Agentの実行、ツール呼び出しを確認する材料です。画面に表示された名称は、最終的なプロバイダー側のモデルを保証しません。
• LiteLLMのゲートウェイログ：受信したモデル名、変換後のmodel_name、再試行、fallback、状態コードを確認する材料です。コスト追跡機能があっても、受信したusageが欠落していれば請求の完全な代替にはなりません。LiteLLM公式ドキュメントでも、統一インターフェース、再試行、fallback、コスト追跡は別々の機能として説明されています。
• OpenAI APIの利用量と請求記録：実際にOpenAI側で受理されたリクエストとusageを確認する材料です。OpenAI Usage APIの仕様を基準に、ゲートウェイの集計値と照合します。

照合キーは、リクエスト時刻、モデル識別子、仮想キー、リクエストIDを基本にします。どれかが欠けている場合は、増加傾向までは説明できても、特定の1操作が特定の請求へ結び付いたとは断言できません。

注意：Cursorの表示名、LiteLLMの別名、プロバイダー側の正式なモデル識別子は同じとは限りません。記録に「o1」と書かれているだけでは、実際の配備先を証明できません。

モデル名と接続方式の食い違い

Cursorで表示されるモデル名と、実際のバックエンドは別に検証します。自前APIキー、互換API、全体のBase URL、LiteLLMのmodel_name変換が重なると、画面上の選択がそのまま転送先になるとは限りません。

特に、Cursorの自前APIキーに関する公式文書では、OpenAIの対応範囲を標準的な非推論チャットモデルとして説明しています。そのため、Cursor公式の自前キー経由でOpenAI o1を直接利用できると前提にせず、どの接続方式で、どのゲートウェイを経由しているかを先に確定してください。

OpenAI側のo1資料には推論トークンの扱いが記載されています。OpenAI o1の公式モデル資料と、実際のAPI応答を照合し、次の状態を分けます。

• Cursorが送った表示上のモデル名。
• LiteLLMが受け取ったモデル名。
• LiteLLMが選んだプロバイダーと配備先。
• プロバイダーが返した正式なモデル識別子。
• 請求記録に現れたモデルとusage。

この5点のうち、最後の2点がないまま「o1に当たった」と判断するのは危険です。

推論トークンとusageの欠落

OpenAI o1の費用を、最終回答の文字数やコード行数から推定してはいけません。入力、キャッシュ入力、出力、推論関連のusageは別の項目として扱われるため、短い回答でも内部処理の記録が一致しない可能性があります。

監査では、最小のコード修正タスクを1件だけ実行し、次の順番で保存します。

1. Cursor側の開始時刻と表示モデルを記録します。
2. LiteLLMの受信ログから仮想キー、リクエストID、model_nameを抜き出します。
3. 転送ログからプロバイダー、実際のモデル、状態コードを確認します。
4. 応答のusageに入力、キャッシュ入力、出力、推論関連の項目が残っているか確認します。
5. OpenAI API側の利用量と請求記録を、同じ時刻帯と識別子で照合します。

usageが「total」だけに集約されている、推論項目が別名へ変換されている、ストリーミング途中で欠落している場合は、互換性未確認として扱います。欠落した数値を独自計算して補うと、監査記録の精度を下げます。

再試行とfallbackによる費用漏れ

Cursor Agentでは、1回の操作が単一のAPI呼び出しとは限りません。ツール呼び出しの失敗、コンテキストの再送、ゲートウェイの再試行、別モデルへのfallbackが連続すれば、最終回答が1つでも途中のクラウド呼び出しは複数になります。

ここでは、同じ時間帯のログを次の情報で並べます。

• 開始時刻と終了時刻。
• リクエストIDと親操作ID。
• HTTP状態コードまたはプロバイダーエラー。
• 再試行の理由。
• 最初の対象モデルとfallback先。
• usageの有無。
• Cursorへ返された最終状態。

「ローカルが遅いからo1へ送る」という設定は、タスクの難易度を理解する自動分類ではありません。単にタイムアウトや接続失敗を条件にした信頼性回退です。難しい処理だけをo1へ送りたい場合は、別途明示的な分流規則と監査用の判定理由が必要です。

Qwen3-Coder分流の漏れ

Qwen3-Coderが正常に応答したという事実だけでは、操作全体がローカルで完了したとはいえません。Qwen3-Coderの公式資料を参照しつつ、ローカル端点の健康状態、モデル別名、タイムアウト、コンテキスト互換性を確認します。

次の3経路を個別に再現してください。

• ローカル命中：Qwen3-Coderの正式な端点へ送られ、クラウド側に同一操作の余分な呼び出しがない。
• 明示的なo1昇格：規則上の条件を満たしたため、判定理由とともにOpenAI o1へ送られている。
• ローカル失敗後の回退：タイムアウトやエラーを記録した後、LiteLLMのfallbackとしてo1へ送られている。

各経路は、最終回答の内容ではなく、ログの連鎖で証明します。ローカル応答が成功していても、別のAgentステップがクラウドへ送られていれば請求は増えます。

請求経路の判定チェックリスト

監査後の判断を担当者ごとの感覚に任せないため、次の項目を上から確認してください。チェックを付けられない項目が残る場合は、OpenAI o1の利用継続や機器追加を決めず、該当する確認作業へ戻ります。

• [ ] Cursorの表示モデル、LiteLLMの受信モデル、転送先の正式なモデル識別子が同じ呼び出しIDで結び付いています。結び付かない場合は、別名とBase URLを先に確認します。
• [ ] リクエスト時刻、仮想キー、リクエストID、状態コード、親操作IDを保存しています。欠落がある場合は、単一操作と単一請求の対応を断定しません。
• [ ] OpenAI API側のusageに入力、キャッシュ入力、出力、推論関連の項目があり、LiteLLMの記録でも欠落や改名がありません。確認できない場合は、費用を回答文字数から補算しません。
• [ ] Qwen3-Coderのローカル命中、明示的なo1昇格、ローカル失敗後のfallbackを、それぞれ別の最小タスクでログから再現できます。最終回答だけが成功している場合は未達です。
• [ ] fallbackの理由がタイムアウトや接続失敗などの信頼性回退なのか、明示的なタスク分流なのかを区別できています。区別できない場合、fallbackを自動的な難易度判定とは扱いません。
• [ ] 仮想キーの権限と用途が分離され、担当部署や環境ごとの請求を追跡できます。共有キーだけで識別できない場合は、先にキー分離へ戻します。
• [ ] 上記をすべて満たし、コード品質にも明らかな低下がありません。この場合は現在の経路を継続します。ローカルの安定性だけが問題なら、常駐機器または弾力的なMac算力を比較します。
• [ ] 1つでも重要項目を復元できません。この場合は代理経路をロールバックし、監査可能な構成へ戻します。根因が不明なまま機器やモデルを追加しません。

修正後の合否判定

今週の検証は、金額の目標値ではなく、次の条件で判定します。

• すべての条件を満たす場合は継続：実際のモデル命中が規則と一致し、fallback理由を復元でき、usageがプロバイダー記録まで追跡でき、仮想キーの権限が分離され、コード品質に明らかな低下がない場合です。
• 一部だけ満たす場合は規則を調整：ローカル命中は確認できるものの、タイムアウトで頻繁にo1へ回る、またはusage項目が途中で失われる場合です。先に健康判定、再試行上限、ログ保存を直します。
• 経路を復元できない場合は代理をロールバック：モデル識別子、リクエストID、usageのいずれも結び付かず、請求の説明責任を果たせない場合です。推測で分流を続けるより、監査可能な構成へ戻す方が安全です。

判定後に初めて、常駐ローカル端点が適切か、弾力的なMac算力を使うべきかを検討します。ローカルノードの安定性が実際のボトルネックでないなら、機器を増やしても請求経路の問題は解決しません。チーム内の接続権限や運用手順は、JexMacのサポート情報と併せて整理すると、環境変更と監査手順を分離できます。

FAQ

CursorをAPIプロキシ経由で使った場合、実際に呼び出されたモデルはどう確認できますか？

Cursorの画面上のモデル名だけでは判定できません。リクエスト時刻、リクエストID、仮想キー、LiteLLMのmodel_name、プロバイダー側のモデル識別子を突き合わせます。Base URLや別名変換がある場合は、ゲートウェイの受信記録と転送記録を分けて保存し、最終的な配備先まで確認してください。

LiteLLMのfallbackで通常の作業がOpenAI o1へ送られる原因は何ですか？

LiteLLMのfallbackは、一次モデルの失敗やタイムアウトなど、設定された条件に応じて別モデルへ送る仕組みです。タスクの難易度を自動判定する分類器ではありません。通常作業がo1へ流れる場合は、ローカル端点の健康状態、タイムアウト、モデル別名、再試行条件をログで確認します。

OpenAI o1の推論トークンをゲートウェイのログとどう照合しますか？

回答文の長さから推論トークンを推定してはいけません。OpenAI APIのusage記録と請求データを基準にし、ゲートウェイが入力、キャッシュ入力、出力、推論関連のusageを完全に保持しているかを確認します。項目が欠落または集約されている場合、そのリクエストは金額を再計算せず、互換性未確認として扱います。

ローカルのQwen3-Coderが正常応答なのに、OpenAI APIの費用が増えるのはなぜですか？

ローカル応答が成功していても、同じ操作中にCursorの別リクエスト、ツール呼び出し、ゲートウェイの再試行、別経路のfallbackが発生している可能性があります。成功した最終回答だけで判断せず、同じ時刻帯の全リクエストを、状態コード、対象モデル、再試行理由、リクエストIDで再構成してください。

JexMacを検討する前の分岐

現在の構成が、共有された固定環境、制限されたローカルGPU資源、または監査できないAPIプロキシに依存している場合、原因を追いにくく、端点停止時の回復も遅くなります。とくに、実際のモデル識別子が残らないこと、ローカル環境を常時稼働させる管理負担、負荷の集中時に処理能力を増やしにくいことは、長期運用で無視しにくい欠点です。

一方、長期にわたり安定した高負荷を処理し、物理的な周辺機器や固定ネットワークが必要なら、自前設備の方が適する場合もあります。今回の監査で「問題はローカル端点の安定性だけ」と確認でき、短期間の検証環境や変動する処理量が必要になった段階では、JexMacのMacレンタル案内を比較対象に加える価値があります。請求の根因が未確認のまま借り増すのではなく、まず呼び出し経路を証明してから、常駐機器と弾力的なMac算力を選んでください。

よくある質問