Claude Code Pro Max 5xプラン、適度な利用でも1.5時間で割り当てを使い切る問題

• Pro Max 5x（1Mコンテキスト） プランで、適度なレベルのQ&Aや開発作業だけでも 1.5時間でトークン上限超過 が発生
• 原因として cache_read トークンが全量比率（1.0x） で計算される不具合が指摘され、キャッシュ効果が失われて急激な消費が発生
• バックグラウンドセッションの自動呼び出し、自動圧縮（auto-compact）、大規模コンテキスト入力 が複合的に消費速度を押し上げる
• コミュニティは キャッシュTTL短縮（1時間→5分） および キャッシュ無効化（cache busting） 現象を主要因と分析
• Anthropic は デフォルトコンテキスト縮小（400k）、UX改善、非アクティブ呼び出しの最適化 を進めており、ユーザーフィードバックを収集中

---

Pro Max 5xプランの急激な割り当て消費問題

• Pro Max 5x（claude-opus-4-6、1Mコンテキスト） プランで、中程度のQ&Aや軽量な開発だけでも 1.5時間で割り当てが枯渇する現象 が報告された
  • それまでの5時間の高負荷開発では通常の消費だったが、リセット後に急激な消費が発生
  • 環境は Claude Code CLI on WSL2、単一セッション（自動圧縮2回）で発生
• cache_read トークンが全量比率（1.0x）で計算される不具合 が主要因として指摘されている
  • 正常であれば cache_read は 1/10 の比率で計算されるべきで、そうでなければキャッシュ効果が失われる
  • セッションログ（~/.claude/projects/.../*.jsonl）の usage オブジェクトを通じてトークン使用量が分析された
• バックグラウンドセッションの自動呼び出し、自動圧縮（auto-compact）の高コスト処理、1Mコンテキストウィンドウの大規模入力 が複合的に作用し、消費速度を加速
• コミュニティ分析の結果、一部ユーザーは キャッシュTTL短縮（1時間→5分） および キャッシュ無効化（cache busting） 現象を主要因として指摘
• Anthropic チームは デフォルトコンテキスト縮小（400k）、UX改善、非アクティブ呼び出しの最適化 を進めており、ユーザーフィードバックを通じた追加データの収集を求めている

測定されたトークン消費量

• ウィンドウ1（15:00–20:00、5時間、高負荷開発）

  • API呼び出し 2,715回、Cache read 1,044M、Cache create 16.8M、出力 1.15M トークン
  • 有効入力（1/10 比率適用時）121.8M トークン
  • Express サーバー + iOSアプリ実装、graphify パイプライン、SPECベースのマルチエージェント調整 を実施

• ウィンドウ2（20:00–21:30、1.5時間、中程度の利用）

  • メインセッション（vibehq）: API 222回、Cache read 23.2M、Cache create 1.4M、出力 91k
  • バックグラウンドセッション（token-analysis、career-ops を含む）: 合計 691回呼び出し、Cache read 103.9M、出力 387k
  • 合計 13.1M 有効トークン（1/10 比率適用時） → 正常なら割り当て超過なし
  • 実際には 105.7M トークン（1.0x 計算時） → 1時間あたり 70.5M 規模で、割り当て枯渇と一致

主な問題の要約

• 1. Cache read トークンの料金上限計算の不具合

  • 期待: cache_read は 1/10 の比率で計算
  • 実際: 全量比率で計算され キャッシュ効果が無効化
  • 1Mコンテキスト環境では呼び出しごとに 100〜960k トークンが送信され、200回以上の呼び出しで数分以内に枯渇

• 2. バックグラウンドセッションによる共有割り当て消費

  • 非アクティブセッション（token-analysis、career-ops など）も自動圧縮・後処理呼び出しによって 共有割り当てを継続的に消費

• 3. 自動圧縮（auto-compact）の高コスト呼び出し

  • 圧縮前の全コンテキスト（約966kトークン）を cache_creation に送信し、最も高コストな呼び出しが自動発生

• 4. 1Mコンテキストウィンドウの副作用

  • 大規模コンテキストは呼び出しあたりのトークン数を急増させ、割り当て消費速度を加速

再現手順

1. Pro Max 5xプランで Opus モデルを使って Claude Code を実行
2. ~/.claude/rules/ に約30個のルールファイル（19kトークンのオーバーヘッド）を含める
3. ファイル読み取り・ビルド・テストなど、ツール中心の作業を行う
4. /context コマンドでコンテキスト増加を確認
5. 200〜300回の呼び出し後に割り当ての急減を確認
6. 別ターミナルで2〜3個のセッションを維持
7. リセット後も短時間で割り当てが枯渇することを確認

期待動作と実際の動作の比較

• 期待:

  • cache_read は 1/10 の比率で計算
  • 非アクティブセッションの消費は最小限
  • 自動圧縮は過剰な消費を引き起こさない
  • 中程度の利用なら 2〜3時間は継続可能

• 実際:

  • 1.5時間以内に枯渇
  • バックグラウンドセッションが 78% を消費
  • 合計 105.7M トークン送信により cache_read が全量比率で計算されたと推定

改善提案

1. cache_read 計算方式の明確化 — ドキュメントに実際の料金上限計算比率を明記
2. 有効トークン基準の制限 — cache_read を 1/10 比率で計算するよう修正
3. セッションのアイドル検知 — 非アクティブセッションの自動呼び出しを防止、または警告表示
4. リアルタイムのトークン消費可視化 — cache_read、cache_create、入力・出力別の使用量を表示
5. コンテキストベースのコスト予測 — 作業前に予想トークンコストを表示

コミュニティ分析と議論

• cnighswonger

  • claude-code-cache-fix インターセプターで24時間にわたり1,500回の呼び出しデータを収集
  • 3つの仮説（cache_read 0.0x、0.1x、1.0x）を検証した結果、0.0x モデルのみが5時間ウィンドウで一貫した結果（CV 34.4%） を示した
  • 結論: cache_read は 実質的に割り当てへほとんど影響せず、キャッシュは正常動作中
  • ただし単一アカウントのデータであり、追加検証が必要

• henu-wang

  • キャッシュTTLが1時間から5分に短縮されたリグレッション 以降、セッションを一時停止するたびに cache_create が発生し、12.5倍高いコスト を引き起こすと指摘
  • コンテキストが長くなるほどコストは非線形に増加
  • 暫定対策として 短いセッション維持、/compact コマンドの積極利用、CLAUDE.md に主要コンテキストを事前ロード を提案

• bcherny（Anthropic チーム）

  • 1Mコンテキストウィンドウ利用時、プロンプトキャッシュミスのコストが高い ことを認めた
  • UX改善（長期セッション再開時に /clear を促す）と デフォルトコンテキストを400kに縮小 する案を試験中
  • マルチエージェント・プラグイン利用時に非アクティブ作業がトークンを過剰消費する事例を確認し、自動整理とスケジューリング改善 を進めている

• wadabum

  • 新規セッションでキャッシュがまったくヒットしないバグ（#47098, #47107）を指摘
  • git status ベースのシステムプロンプトと CLAUDE.md ブロックがセッションごとに変わり、キャッシュ無効化（cache busting） が発生
  • cnighswonger はインターセプターが一部の並び順安定化を行うものの、git-status 問題は別途修正が必要だと回答

コミュニティ提案の要約

• RockyMM: セッションが上限に達したら自動要約して再開を促し、TTLを10分に短縮
• mikebutash: Proプランでは5時間あたり2回しかプロンプトできないと報告し、v2.1.81 へのロールバックと cache-fix の導入 で3〜4倍の改善を確認
• wutlu: 作業ごとにセッションを初期化して問題を緩和
• dprkh: デバッグモードのスキル（Skill.md）共有で原因特定を支援

結論

• Pro Max 5xプランの 急激な割り当て枯渇問題は、キャッシュ動作、TTLリグレッション、コンテキスト膨張、バックグラウンド呼び出しの複合的影響 によるものと確認された
• コミュニティは cache_read 計算不具合よりも、キャッシュ無効化とTTL短縮が主要因 との分析を示している
• Anthropic チームは コンテキスト既定値の縮小、キャッシュUX改善、非アクティブ呼び出し最適化 を進めており、ユーザーフィードバック（/feedback）を通じた追加データ収集を求めている

[kimjoin2]

品質で見れば代わりになるものもなく、
簡単なパッチでもっと使えるようになるといいですね。

[GN⁺]

Hacker Newsの反応

• Claude CodeチームのBorisです。最近報告された問題を調査した結果、主な原因は2つあります

  1. 1Mトークンのコンテキストウィンドウを使う際、プロンプトキャッシュのミスが高コストです。現在キャッシュTTLは1時間なので、1時間以上席を離れるとセッションが期限切れになり、キャッシュ全体を再読み込みする必要があります。これを改善するためUX改善を展開しており、デフォルト値を400kに下げるオプションも検討中です。今すぐ試すなら CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude コマンドを使ってください
  2. プラグインやエージェントを同時に多く実行するとトークンの無駄が発生します。これを解決するため、UX改善と、重要度の低い作業の自動整理およびスケジューリングを進めています
     問題を経験しているユーザーは /feedback コマンドでフィードバックを送ってもらえるとデバッグに役立ちます
  • Boris、今コミュニティに上がっているユーザー体験談は単なる例外ではありません。Jeff Bezosが言ったように、データではなく逸話が真実を語るときがあります。メトリクスが間違っていないか真剣に見直すべきです
  • なぜ急にこんな問題が起きたのか不思議でしたが、調べてみるとプロンプトキャッシュTTLが1時間から5分に短縮されたのが原因でした。新しくセッションを始めても結局すべてを再構築しなければならず非効率です。キャッシュ失効を監視しなければならない構造はCCの哲学に反しています
  • 自分の場合、最も深刻なリグレッションはシステムプロンプトが毎回ファイルをマルウェア検査しようとする部分でした。そのせいでトークンが急速に消費され、"not a malware" という応答が延々と返ってきました。こういう設計は判断ミスです。結局プロジェクトを中断してQwenに移りましたが、かなり良いです
  • /clear の通知は解決策ではありません。キャッシュを消しても結局また再構築が必要なのでコストは同じです。UXでユーザーを小さいコンテキストへ誘導するのはサービス品質の低下です。コストの問題なら価格かアーキテクチャを直すべきです
  • OpenAIは問題が起きると使用量上限をリセットしてくれましたが、Anthropicにはそうした措置がありません。今回は意図的だという印象です

• 最近Claudeは目に見えて遅く非効率になっていました。ファイルを指定しても5分以上探索ループに入り、セッション制限にもすぐ達します。1日3回使うだけで週間上限の25%が消えます。なので100ドルのCodexプランに移りましたが、精度と寛大さの面ではるかに良いです。ただCodexの口調が気に障るのでAgents.mdに別途指示文を追加しました。UIの感覚は以前のClaude Codeのほうが良かったですが、バックエンドのデバッグや複雑な問題解決ではCodexが優勢です。今はCodexとCursorの20ドルプランを比較してみることを勧めます

  • 私も似たような経験をしました。Claudeが数日前は止まったように考え込むばかりだったのに、翌日には正常に動きました
  • Codex Businessプラン（30ユーロ）を使っていますが、最近クォータが減った気がします。それでもClaude Codeよりは依然としてずっと良い条件です
  • 現在Opus、Haiku、Sonnetモデルのconfidence scoreの挙動を比較中です。Opusは中程度の難易度の作業で最も効率が良いです
  • CC、Gemini-cli、Codexを使ってみましたが、CCがまだ一番優れています。CursorやAiderの組み合わせのほうが良いのか気になります
  • AIコーディングはコンテキストの浪費が激しいので、カスタムサンドボックスで範囲を制限すると効率が上がります

• issueをざっと見て、Anthropicがチケットを早く閉じる理由が分かりました。大半はAIが生成したノイズに見えます。自分の対策は次の通りです

  1. すべてのセッションでmax thinkingを有効にして不要な経路探索を減らす
  2. セッションを常にアクティブな状態に保つ。キャッシュが5分で失効するとトークンを再構築しなければならない
  3. 200kトークンを超えたらすぐcompactを実行する
     Anthropicが1Mモデルを強制適用したのが最大の不満です
  • 私もissueを見て笑いました。おそらくClaude Codeに「なぜトークンを使い切ったのか調査しろ」とやらせた結果でしょう
  • ある人はthinkingをオンにしろと言い、別の人はオフにしろと言う。どちらもトークン節約になるというのは皮肉です
  • キャッシュがランダムに無効化されるバグが核心です。APIクライアントが加入者キャッシュを早期終了させているようです。そのうえ入力トークンの料金もこっそり上げています
  • 私も確認しました。max effortが役立ちます。コンテキストを25%以下に保つのが重要です。キャッシュ失効状態を確認する方法があるのか気になります
  • /model opus や /model sonnet コマンドで1Mモデルを無効にできます

• もう補助金時代の終わりが近づいている気がします。Google Geminiコミュニティでも最近クォータ縮小への不満が噴出しています（issueリンク）。私も結局Kiro IDEとCodex CLIの組み合わせに移って満足しています

  • こうした変化は予見されていました。無料トークンの時代に必要なライブラリをあらかじめ構築しておくのが賢い戦略でした
  • Anthropicは今や企業顧客中心へ移行中で、OpenAIも似た道を歩んでいます。RedditやDiscordではオープンモデルや中国製の代替を探す動きがありますが、完全な代替品はありません
  • antigravityはプロクォータを急速に消費しますが、flashモードはずっと寛大です。STM32プロジェクトを進めながら3倍速い生産性を得られました
  • 結局この流れの先には出力に広告が付く時代があるのかもしれません
  • 昔の3ドルのUberタクシーを思い出します

• 根本原因を指摘したissueが**"Not planned" で閉じられた**のが不安です

  • 返信内容がAIが書いたように不自然です。「1時間TTLのほうが高コスト」という理屈も変です。トグルを提供しない理由がコストだというのは納得しにくいです
  • わざわざ怖がる必要はありません。品質が悪くなったら使わなければいいだけです
  • Anthropicはカジノのようにトークンを売り、ユーザーが金を失っても気にしない構造だと見ています。こうしたモデルが嫌ならローカルLLMを使うほうがよいと思います

• バージョン2.1.34にロールバックしたらクォータ問題とキャッシュ問題の大半が解決しました。
  ~/.claude/settings.json に "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1 などを追加し、他のバージョンは削除しました。
  Adaptive thinkingはまだ未完成ですが、今後改善されれば役立ちそうです。それでもCodexへ移るか悩んでいます

  • 私も ~/.bashrc に CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1 などを設定しています

• 下位モデルでも似た問題がありました。公正な取引は透明な測定から始まると思います。今月の購読は解約予定です

  • コンピュータがスリープ状態のときにもセッションが始まってトークンが消費されることがありました。「今何時？」のような簡単な質問でも10%を使ってしまいます

• 今年の税務申告をAIエージェントで試してみました。Opus 4.6、Codex 5.4、Antigravity 3.1をそれぞれ20ドルプランで使いました。
  Codexは12分で完璧に処理し、Antigravityは1ページ抜けていましたがすぐ修正できました。Claude Codeは利用上限超過で停止し、再試行後も誤差がありました。期待外れでした

  • 私も似た実験をしましたが、私の場合はClaudeが会計士レベルの正確さでした。同じ作業でもセッションごとに結果が違うのが興味深いです。非決定的ソフトウェア時代のカスタマーサポートは本当に見慣れない体験です

• Redditに投稿された更新告知以降、Claudeは日常的なコーディングに使えないほど変わってしまいました。Proアカウントのクレジットが1時間で尽きてしまい、GeminiやChatGPTに戻りました

• 結局Anthropicのトークン課金構造は一般ユーザーに不利なように設計されているようです。実際に使ってみると、彼らがどれだけ多くのお金を欲していたのかすぐ分かります