ハクソク

世界を動かす技術を、日本語で。

プロマックス5倍のクオータが1.5時間で消耗、使用は控えめにもかかわらず

2026年4月12日原文(github.com)

概要

  • Pro Max 5xプラン での Claude Code 利用時、 クォータの異常な早期消費 を報告
  • cache_readトークン が本来より高いレートでカウントされている疑い
  • バックグラウンドセッション による予期しないクォータ消費
  • 1Mコンテキストウィンドウ による消費加速
  • 改善提案 としてトークンカウント方法の明確化や可視化などを提示

Pro Max 5xプランにおけるClaude Codeのクォータ異常消費の詳細

  • クォータリセット直後、通常利用（Q&Aや軽度の開発作業）でも 1.5時間でクォータを使い切る現象
  • リセット前は 重度の開発作業 （複数ファイル実装やグラフパイプライン、マルチエージェント）で 5時間かけて消費、これは想定内
  • cache_readトークン が 本来の1/10レート でなく フルレート でカウントされている疑い
  • これにより プロンプトキャッシュのコストメリットが消失、クォータ消費が加速
  • 各APIレスポンスのusageオブジェクト からトークン消費を詳細に計測

計測結果の比較

  • ウィンドウ1（15:00-20:00/重度開発）

    • APIコール数：2,715
    • cache_read：1,044Mトークン
    • cache_create：16.8Mトークン
    • 入力/出力トークン：8.9k / 1.15M
    • ピークコンテキスト：966,078トークン

  • ウィンドウ2（20:00-21:30/通常利用）

    • APIコール数：222
    • cache_read：23.2Mトークン
    • cache_create：1.4Mトークン
    • 入力/出力トークン：304 / 91k
    • ピークコンテキスト：182,302トークン

  • 他のバックグラウンドセッション

    • token-analysis：296コール, 57.6M cache_read
    • career-ops：173コール, 23.1M cache_read
    • 合計：691コール, 103.9M cache_read

問題点の整理

  • cache_readトークンのカウント方法

    • 期待値：1/10レートでカウント
    • 実際：フルレートでカウントされている模様
    • 結果： 数百回のAPIコールで即座にクォータ枯渇

  • バックグラウンドセッションのクォータ消費

    • アクティブでないセッションでも 自動コンパクトやフック処理でAPIコールを継続
    • ユーザーが操作していなくてもクォータ消費が続く

  • 自動コンパクトによる消費スパイク

    • コンテキストが上限付近で 自動的に高コストなAPIコールを発生
    • ユーザー操作なしで大量トークン消費

  • 1Mコンテキストウィンドウの問題

    • 1回のAPIコールで最大約96万トークン消費
    • cache_readがフルレートカウントならキャッシュの意味が薄れる

再現手順

  • Opusモデルで Claude Code を Pro Max 5x プランで起動
  • ~/.claude/rules/に 約30ファイル（19kトークン固定オーバーヘッド） を用意
  • ツール多用プロジェクト で作業、/contextコマンドでコンテキスト増加を確認
  • 200-300回のツールコール後、クォータを確認→大幅に減少
  • 他のターミナルで2-3セッションを開いたまま にする
  • クォータリセット直後でも、アクティブ利用が少なくても短時間でクォータ枯渇

期待される動作・実際の動作

  • cache_readトークン は 1/10レート でカウントされるべき
  • バックグラウンド/アイドルセッション はクォータ消費が最小限であるべき
  • 自動コンパクト で極端なクォータ消費が起きないこと
  • Pro Max 5x は 通常利用で2-3時間以上持続 するべき
  • 実際は 1.5時間でクォータ枯渇、 バックグラウンドセッションが78%消費、 cache_readフルレートカウントが疑われる

改善提案・要望

  • cache_readのクォータカウント方法を明確化 ：公式ドキュメントで明示
  • レート制限は実効トークン数で行う ：cache_readは1/10レートでカウント
  • セッションのアイドル検出 ：アイドル状態のセッションはクォータ消費を抑制、または警告表示
  • クォータ消費のリアルタイム可視化 ：cache_read, cache_create, input, outputごとに分かりやすく表示
  • コンテキストサイズからクォータ消費を事前見積もり ：操作前に消費予測を提示

まとめ

  • クォータ消費速度が異常 で、 cache_readのカウント方法 が主因と考えられる
  • バックグラウンドセッション や 自動コンパクト も消費加速要因
  • 改善にはトークンカウント方式の見直しと可視化、セッション管理の強化が必須

Hackerたちの意見

自分も下位モデルでも似たような問題を経験してる。公正な取引ってのは、交換される商品の公正で透明な測定が必要だよね。今月中にサブスクリプションをキャンセルするつもり。

└

そうそう、Claude Codeは「トークンを消費」して、コンピュータがスリープ中でもセッションを開始するんだ。何も始まってないのに、「今何時？」で10%も消費することもある。

元々の問題が実際の根本原因を指摘してるのに、Anthropicが「計画外でクローズ」しちゃったのが怖い。 https://github.com/anthropics/claude-code/issues/46829

└

その返答、全然意味不明だし、AIが書いたみたい。 > 3月6日の変更でClaude Codeが高くなるんじゃなくて、安くなるんだ。リクエストごとに1時間のTTLがあれば、むしろ高くつくかも。すごくAIっぽい。 > 1時間をデフォルトに戻すか、設定可能にする？ どこでも1時間だとリクエストのミックスによって総コストが増えるから、グローバルなトグルは計画してないんだって。トグルを表示しないのは、何パーセントかのリクエストでコストが上がるから？

└

なんで怖がるの？ソフトウェアが悪くなったら、使うのやめればいいじゃん。

└

カジノがギャンブラーからたくさんお金を稼いでる時、顧客が負けることなんて気にしないよね。だって、機械はあなたに不利に設定されてるから。Anthropicは「トークン」という形で「知識」を売って、あなたはサイコロを振ったり、ルーレットを回したり、もう一度試すためにコインを入れたりしてお金を使う。後で制限を追加して、モデル（彼らのギャンブルマシン）を簡素化して、間違った答えにお金を払わせる。制限に達したり、Anthropicが使用制限を変更したりすると、彼らは気にせずに使用を一時停止する。もしそれが嫌なら、お金を節約してローカルのLLMを使えばいいよ。

このパーティーで音楽が徐々にフェードアウトして、明かりが点くのが怖い。ここ数年は、補助金付きのGenAIコンピュートの黄金時代だったかもしれないね。Google Gemini/Antigravityの範囲にいない人たちは、ここ1ヶ月ほどで、プロやウルトラの顧客（自分も含めて）に対する明らかな期待の裏切りに対して、Googleから軽蔑されているのを経験してる。 [1] 自分はGoogle Proのサブスクリプションを払ってるけど、なんかストックホルム症候群みたいなもんで、忠誠心とバグであってほしいという希望があるから。GoogleがGoogleで、良い製品を自ら焼き払うわけじゃないと信じたい。今はKiroをIDEに、CodexをCLIに使ってて、この新しい環境に満足してるよ。 [1] https://github.com/google-gemini/gemini-cli/issues/24937

└

まあ、最初からリアルな長期契約じゃないってのは明らかだったよね。過去1〜2年で、無料のコンピュート時代が終わったときに使えるようなライブラリを作ってきた。これが理にかなったアプローチだと思う。無料のトークンを使って、サービスが使えなくなった時に欲しいものを作る。もしサービスが消えたら、手でコードを書く楽しみが戻ってくるけど、夢見たビルディングブロックは手に入る。もし消えなかったら、無駄にはならないし、クールなライブラリは残る。

└

ライトが点灯してると＝出力に広告が入るってこと。年末には最新の情報が出るけど、大きなコストを先延ばしにはできないよ。

└

結局、もっと効率的な技術やハードウェアが見つかって、AI企業が原子力発電所を所有するようになると思う。そして、今の10倍の能力を持つモデルを提供し続けるだろう。評価額はすでに、これらの企業が原子力発電所を運営し、新しいハードウェアや技術の開発を資金提供し、モデルの能力を10倍に引き上げることができるところまで達している。

└

そうだね、アンチグラビティはすぐにプロのクォータを使い果たしちゃうよ。$20/月のプランだと、1時間で使い切ることもあるし、その後5日間待たないとリフレッシュされない。だけど、フラッシュクォータはもっと寛大だと思う。STM32G474用のトリオドライブFOCシステムを作ってて、基本的にプロンプトを使って進めてるんだけど、5時間の時間枠内でフラッシュクォータを完全に使い切ったことはまだない。自分でやるよりもずっと早く作業が進むよ。問題を解決するためにいろいろ試してくれるから、根気強さが大きいね。完璧ではないけど、かなり良いと思う。デバッグや無駄になった試みから残ったゴミを片付けるために戻ってくることが多いけど、それでも最初から考えるよりはずっと楽だよ。最近までAIコーディングに懐疑的だった私が言うんだから、間違いないよ。先週末、友達からチュートリアルをもらって、AIにすべてをテストさせるように指示する必要があるって教えてもらった。ハードウェアインループのユニットテストを立ち上げることが、このプロジェクトの生産性の大きな転機になった。開発ボードの周辺機器も自分で配線して、ユニットテストが実際の外部デバイスに接続されているふりができるようにしたんだ。20年間プログラミングをしてきたから、AIが行き詰まっているときに手を差し伸べることができるのが助けになっていると思う。でも、まあ、これが私の経験だよ。フラッシュとプランモードだけを使っていて、$20/月のクォータを使い切ることもなく、自分で書いていたら3倍の速さで物事を進めていると思う。

└

同じくイライラしてるGoogle AI Proのサブスク仲間だよ！最初はGemini CLIとアンチグラビティの5時間制限がすごく気に入って、1年間分払ったんだけど、いい決断だと思ってたのに。その後の数ヶ月で、5時間の制限が大幅に削減されちゃって（今は存在すらしてないかも）、1-2時間で完全に使い切れる非現実的な週次制限が導入されて、月ごとのAIクレジットシステムも追加されて、どこでもウルトラにアップグレードするための広告が出るようになった。少なくともGeminiのモバイルアプリやウェブアプリは、プロジェクトの計画や日常的な使用にはまだちょっと役立つかな。ストレージも2TBから5TBに増えたけど、私にはそれすら使いこなせてない。

Hacker Newsで議論の続きを見る