この記事は、所与のものとして受け止めている不満、すなわち Claude Code のクォータがユーザーの予想よりも速く消費されているという不満から始まり、それに対する最も一般的な反応はかえって逆効果だと論じる。/clear に手を伸ばしたり、作業の各ステップの後に新しいセッションを始めたりすることは身軽になるように感じられるが、記事の主張は、それがたいてい定価でのコンテキスト再構築を引き起こし、会話を続けた場合よりも高くつくというものである。
議論は全面的に トークンキャッシュ（トークンキャッシュ）の仕組みに依拠している。モデルはステートレスであり、毎ターン入力全体を読み直す。そこで記事はその入力を、固定部分（システム指示、ツール定義、CLAUDE.md のプロジェクトルール）、会話履歴、そして新しいメッセージに分ける。稼働中のセッションでは最初の 2 つは変化しないのでキャッシュにヒットするが、新しいセッションを始めると蓄積されたキャッシュを破棄し、記事がおよそ 50,000 トークンと見積もるプレフィックスを再構築するためのコストを支払うことになる。キャッシュは変化していないプレフィックスにしか一致せず、キャッシュの読み取りは再計算のおよそ 10 分の 1 のコストで済むため、記事は通常の助言を逆転させる。継続することがデフォルトであり、新しいセッションを始めることは条件付きの最適化なのである。
記事の 2 つ目の標的は 1M コンテキストウィンドウであり、記事はこれがクォータを使い果たす主要な原因になりつつあると述べる。それは長いコンテキストに割増料金が課されるからではなく（記事はその割増は撤廃されたと述べる）、キャッシュミスのコストがコンテキスト長に比例して増えるからであり、そのためキーボードから 1 時間離れるだけで 1M トークンのセッションは丸ごと再構築になってしまう。
要点
- 記事の中心的な逆転は「キャッシュが温かく、タスクが変わっていないうちは継続し、キャッシュが期限切れになったとき、タスクが切り替わったとき、あるいはコンテキストがノイズで満ちたときに再スタートせよ」というものであり、クリアではなく継続をデフォルトの習慣とする。
- 記事はキャッシュに 2 つの条件を挙げる。一致はプレフィックスのみかつ完全一致であるため、先頭のほうで何かを変えるとそれ以降のすべてが無効になる。そしてキャッシュされたエントリは期限切れになる。その有効期間について記事は Claude Code チームから伝えられた値として、メインエージェントは 1 時間、サブエージェントは 5 分であり、ヒットのたびにタイマーがリセットされると伝えている。
- 記事は、Claude Code はキャッシュ利用率が最も高いフレームワークであるという Claude Code チーム自身の評価を引用し、また別に、1 時間ほどアイドル状態だった大きなセッションは再スタートする価値があるという Anthropic 社員の助言を伝えたうえで、その要となる語は アイドル だと指摘している。
- 直感に反する 3 つの節約が論じられている。複雑なタスクを一度で正しく仕上げるために拡張思考をオンにしておくことは、各ラウンドがコンテキスト全体を再送するため、安価な修正を 3 ラウンド繰り返すよりもおそらく安くつく。逆に、単純なタスクでエフォートを下げることはすぐに効果が出る。そしてファイルを貼り付けるよりもファイルパスを渡すほうがよい。最も安いトークンはコンテキストに一度も入らないトークンだからである。
- 1M ウィンドウについて記事は、Anthropic が長いコンテキストの割増料金を撤廃したため 1M と 200K は同じコストであること、チームがキャッシュ期限切れの問題を認め、デフォルトを 400K に下げることを検討していること、そして日常的なセッションの大半は 80〜120K でコンパクションされ、200K にすら達しないことを報告している。記事自身の推奨は、ウィンドウはそのままにしつつ
CLAUDE_CODE_AUTO_COMPACT_WINDOWで控えめな自動コンパクションのしきい値を設定することである。逆の選択、つまりより大きなウィンドウを完全にオフにする方法としてはCLAUDE_CODE_DISABLE_1M_CONTEXTが示されている。 - 記事の 6 つの運用ルールは次のとおりである。定型作業には Sonnet を優先する（記事は Opus の入力コストを Sonnet のおよそ 1.7 倍、トークン消費率をおよそ 2 倍としている）。キャッシュはモデルごとなので、セッションの途中でモデルを切り替えない。CLAUDE.md は公式の 200 行というガイダンスの範囲内に収め、状況依存の指示はスキルに移す。両端で完全なスキーマを注入する MCP サーバーよりも
ghのような CLI を優先する。まず計画にトークンを使う。そしてpermissions.denyを使って、モデルをnode_modules、ビルド出力、大きなデータファイルに近づけない。 - 委任について記事は、サブエージェントと Agent Teams を区別する。サブエージェントは独立したコンテキストを持ち、要約だけを返すため、詳細な出力が後のターンの負担になることはないが、その代わりにキャッシュの有効期間は 5 分である。一方 Agent Teams では、各メンバーが独自のコンテキストを持つ別々のインスタンスであり、記事の主張ではプランモードでの消費は標準的なセッションの数倍に達し（記事はコミュニティの推定としておよそ 7 倍という数字を挙げている）、アイドル状態のメンバーも消費を続ける。
- 記事は公式の 3 つの説明を伝えている。コンテキストが 256K を超えると消費が加速するというのは事実では ない こと（記事は、この印象はアイドル状態から再開したセッションが大きなキャッシュミスを起こしたことによるものだとしている）、Sonnet 3.7 以来存在していたマルウェアチェックのプロンプトはモデルのリリースごとに評価されて退行を引き起こしておらず、Opus 4.6 で削除されたこと、そして適応的思考は原因から除外されたことである。あわせて、チームがまだ調査中であり、内部の指標を盲目的には信頼していないという声明も伝えている。
- 記事の数字のいくつかは、著者が計測したものではなくコミュニティの報告から伝えられたものである。別のユーザーが Bedrock 上で算出したセッションあたりのコスト、Agent Teams のプランモードに関するおよそ 7 倍という推定、サードパーティの Codex プラグインが同等のタスクをおよそ 3 分の 1 のトークンで完了するという主張、そしてコンテキスト長が出力を劣化させるとされるしきい値がそれにあたる。
背景
この記事はプロンプトキャッシュの一般的な解説としてではなく、Claude Code のユーザーに向けて書かれている。その説明の仕掛け、すなわち図書館を訪れるたびに同じ 500 ページの報告書を読み直す研究者というたとえは、ステートレスなモデルがなぜ変化していない入力に対して再び課金するのかを考えたことのない読者に向けたものである。
記事の締めくくりで述べられている視点は、クォータの引き締めはベンダー固有のものではなく、おそらく業界全体の傾向だというものである。著者は、現在を補助された計算資源の時代の終わりとする他者の表現を伝え、そのうえで、どのプロバイダーが最も長く補助を続けるかに賭けるよりも、コスト構造を理解することのほうが労力の使い道として優れていると論じる（この部分は著者自身の見解である）。記事は、読者自身のセッションがどのくらいの長さ続くのかを問いかけて終わっており、確定したリファレンスではなく、進行中のコミュニティの議論における議論の材料として位置づけられる。