常駐コンテキストコスト

セッションが送信するすべてのリクエストは、会話の前に同じプレフィックスを帯びています。システムプロンプト、宣言されたすべてのツールのスキーマ、コンテキスト（QWEN.md）ファイル、そしてスキル一覧です。このプレフィックスはすべてのターンで課金されます。質問に答えるだけのターンでもそうです。このページでは、その計測方法と削減方法を説明します。

Token cachingはプレフィックスの_価格_を下げるものです。このページは_プレフィックス_を小さくするものです。両者は組み合わせられます — プレフィックスが小さければ、キャッシュ時のコストも安くなります。

何に対して課金されているかを確認する


/context detail

/context はカテゴリごとの内訳を出力します。detail を付けると項目ごとの行 — 各組み込みツール、各MCPツール、各コンテキストファイル、各リストされたスキル — が追加され、どの項目が最もコストが高いかを確認できます。セッションの最初のターンで確認してください。会話がまだ空で、見えているものがすべてプレフィックスの状態です。

カテゴリは /context が報告するものに、2つの管理用行を加えたものです：startupContext（最初のユーザーターンとして送信される環境ブロック）と、カテゴリが割り当てられない残差を明示的に示す行です。これにより、各部分の合計が常に全体と一致します。

ウィンドウの割合ではなくアイドルコストを使う

コンテキストウィンドウの割合は維持できる目標にはなりません。分母が任意だからです。同じ設定でも、1Mコンテキストのモデルでは6.5%、128kのモデルでは37%と表示されます — テキストは同じ、コストも同じ、なのに数値は大きく異なります。代わりに以下を使います：

アイドルコスト — 1つの質問をしてツールを一切呼ばないセッションの入力トークン数。

これはモデルにもウィンドウにも依存せず、ツールスキーマからコンテキストファイルへテキストを移動しても見かけ上改善できません。もう1つの有用な指標は会話がプレフィックスを上回るまでにかかるターン数です：償却に20ターンかかるプレフィックスは、5ターンのセッションでは決して償却されません。

レバー（対策）、効果の高い順

1. 使っていない機能をオフにする

ツールを登録する各機能は、そのツールのスキーマのコストをすべてのリクエストで支払います。最大の組み込みエントリはオプション機能に属するものなので、ワークフロー、ゴール、スケジュールタスク、レビューツールを使用しないデプロイでは、プロンプトをいくら編集するよりも、それらの機能をオフにする方が節約できます。これによりサブエージェントからもツールが除去されます。次のレバーでは必ずしもそうならない場合があります。

2. 実際の使用に合わせて先行読み込みツールを絞り込む

tools.eager は、初期リクエストにスキーマを残す組み込みツールの許可リストです。それ以外は遅延読み込みになります：登録はされたまま、/tools にも表示されたまま、呼び出しも可能ですが、モデルが必要になったときに tool_search で読み込みます。


{
  "tools": {
    "eager": [
      "read_file",
      "write_file",
      "edit",
      "glob",
      "grep_search",
      "run_shell_command",
      "skill",
    ],
  },
}

使用する前に知っておくべき4つのポイント：

無効化ではない。 格下げされたツールも引き続き到達可能です。ツールを除去したい場合は、ツール全体の permissions.deny ルールまたは tools.disabled を使用してください。
一部ツールは対象外 で、リストの設定に関わらず通常の読み込み動作を維持します：tool_search、structured_output、プランモードのライフサイクルツール（enter_plan_mode、exit_plan_mode、ask_user_question）、task_stop、MCPツール（mcp__*）、Computer Useツール（computer_use__*）。task_stop と Computer Use ファミリーはデフォルトでオンデマンドなので、制限しても節約になりません。MCPツールは tools.toolSearch.* とサーバーごとの includeTools / excludeTools フィルターで管理され、最初の3つのツールを削除する唯一の方法は permissions.deny です。
permissions.allow は節約にならない。 これは純粋な自動承認です：ツールの格下げ、非表示化、削除は行いません。承認モードも同様です。
tool_search が有効である必要がある。 ToolSearchが登録されていない場合 — tools.toolSearch.enabled: false、tool_search のdenyルール、またはDeepSeekモデルの自動オプトアウト — 許可リストはスキーマを保留しますが、それらを読み戻す手段がなくなり、格下げされたツールはそのセッションでは到達不能になります。

tools.visible は、デフォルトでは遅延読み込みのツールであっても、事前に宣言しておきたい1つのツール用の脱出ハッチです。

3. シナリオのガイダンスをコンテキストファイルからスキルへ移動する

コンテキストファイルは、それが適用されるすべてのセッションのすべてのリクエストに、関連性のフィルタリングなしで連結されます。スキルは名前と説明のみがリストされます — ある計測サンプルでは、84スキルが平均約55トークンでした — そして呼び出されたときに本体が読み込まれます。また paths: でゲートされたスキルは、一致するファイルに触れられるまでリストされさえしません。

コンテキストファイルには常に真実であるものだけを残してください — アイデンティティ、用語、ハード制約 — 「XをするときはYをする」はスキルまたは paths: 条件付きルールに記述します。/context detail は各コンテキストファイルの名前を表示し、拡張機能のファイルについてはそれを所有する拡張機能の名前も表示します。

4. システムプロンプト、最後に

ベースプロンプトはすでに常駐カテゴリの中で最小であり、その約3分の1は編集すべきでないセキュリティと権限のテキストです。また、セッションが実際に宣言したツールのみを記述するようになったため、ツール表面をトリミングするとわずかに無料で縮小されます。--system-prompt で全体を置き換えることは可能ですが、このページの中で最もリスクの高い変更です。行う場合は、アップグレードごとにアップストリームのプロンプトの差分を確認してください。

注意点

サブエージェントも遅延ツールを受け取る。 明示的なツールリストを宣言しないサブエージェントは、遅延ツールを含めすべての登録ツールのスキーマを受け取り、ToolSearchを経由しません。tools.eager と permissions.deny がそれに到達する唯一の制御手段です。プリロードしきい値は対象外です。
バックグラウンドメモリエージェントには6つのツールが必要（read_file、grep_search、glob、run_shell_command、write_file、edit）。1つでも拒否すると、エラーではなくサイレントに劣化します。
トークンは消えるのではなく移動する場合がある。 grep_search と glob を取り上げると、モデルはシェル経由で grep や find を使うかもしれず、その出力が会話に_land_します。新しい出力は最初に送信されたときに入力トークンを追加し、それを含む変更されていない履歴は後続のリクエストでプロバイダーのプレフィックスキャッシュにヒットするかもしれません。変更は、タスクごとの総入力トークン数、プロバイダーが報告するキャッシュ済みおよび未キャッシュの入力、および実際の請求額で判断し、プレフィックスだけでは判断しないでください。
再開されたセッションは必要なものを再送信する。 格下げされたツールが再開されたセッションの履歴に現れると、そのスキーマは自動的に戻ります。拒否されたツールは戻りません。
セッション途中で公開された遅延ツールはプレフィックスキャッシュを無効化する。 関数宣言はプレフィックスの最前部に配置されるため、1つの公開でプレフィックス全体が書き換えられ、そのターンのプロンプト全体が再計算されます。遅延セットのプリロード（tools.toolSearch.threshold）は、コストとして毎回それらのスキーマを保持することでこれを回避します。threshold: 0 は、セッションが本当にそれらを必要としない場合にのみ勝ります。
プレフィックスキャッシュモデルではトレードが反転する。 ディスカウントが安定したプレフィックスに依存するモデルでは、プレフィックスを同一に保つことが小さくするより価値があります。DeepSeekモデルがこの理由でToolSearchを自動的にオプトアウトするのはそのためです。
スコープが漏洩する。 設定はそれらを読み取るすべてのクライアント（CLI、Web Shell、serve）に適用されるため、デプロイごとのツール表面には独自のスコープ設定が必要です。

節約を確認する

変更前のアイドルコストを記録する：新しいセッションで、簡単な質問を1つ、最初のターンに /context を実行。
1つずつレバーを適用してセッションを再起動し繰り返す — これらの設定のほとんどは起動時に読み込まれます。
独自のタスクセットで機能が生存したことを確認する：ツール呼び出しの成功率、tool_search が呼ばれる頻度、タスクの成果。モデルが探すことを思いつかない格下げツールは大きなエラーを出しません。ただ使われなくなるだけです。
プレフィックスだけでなく請求額を確認する — トークンが会話に移動する件の注意点を参照。