Claude Codeの`/usage`にSpend limitバーが、`/cost`にプロンプトキャッシュの状況が見える行が付いた話

このループを回していると、Claude Codeの請求がどれくらい積み上がっているか、ふと不安になる瞬間があります。-pのheadless実行を1日に何本も走らせているので、気付いたら青天井で消費している可能性はゼロではありません。起動が軽くなった話を書いたときも思いましたが、無人運用をしていると「見えないところで何が起きているか」を数字で確認できる機能はありがたいです。

v2.1.251（2026年8月28日）で、そのものずばりの改善が2つ入りました。/usageにSpend limitバーが付き、/costにプロンプトキャッシュの節約状況を示す行が付きました。同じリリースでPreModelSwitch/PostModelSwitchフックも追加されているので、v2.1.251はコストまわりの可視化がまとめて強化された回だったようです。公式changelogにはさらに、SessionStartのresumeフックがセッションの古さ(staleness)と再キャッシュの推定コストを受け取れるようになった、という一文もありました。セッション再開時の「これ、また丸ごとキャッシュし直しなのでは」という不安を、Hooks経由で先読みできるようにする改善のようです。今回は/usageと/costという、普段から手で叩くコマンド側の変化に絞って見ていきましょう。

まず正直に: 誰にでも出るバーではない

ここからが本番です。公式changelogを直接確認したのですが、Spend limitバーの説明にははっきりこう書かれていました。

Added a Spend limit bar to /usage and a rate_limits.spend_limit
status line field for developers behind a Claude apps gateway
with spend limits

「Claude apps gatewayの背後にいて、かつ支出上限が設定されている開発者向け」という条件が付いています。組織側で支出上限そのものを設定していない環境では、このバー自体が出ない可能性が高いです（実際に手元の/usageでは確認できませんでした）。組織でClaude Codeを配布していて、管理者側でAPIゲートウェイ経由の支出上限を設定している環境が対象、という理解で書いています。ここを飛ばして「誰でも使える残高表示」だと紹介すると誤解を生むので、最初に断っておきます。

その上で中身を見ると、やっていることはシンプルです。ゲートウェイ側に設定された支出上限に対して、今どれくらい使っているかをバーで表示します。ステータスライン用にはrate_limits.spend_limitというフィールドも対応して追加されました。ただしフィールドの中身は公式changelogの説明文から分かる範囲にとどまり、具体的なJSON構造までは確認できていません。正確な形を知りたければ、自分の環境でrate_limitsを実際に出力させて見るのが確実だと思います。

チームでClaude Codeを使わせている立場からすると、「誰かが使いすぎて上限に張り付いていないか」をエージェント自身が見える化してくれるのは地味に助かる機能です。–restrictedの記事でも書きましたが、共有環境でAIエージェントを走らせる場面はこれからも増えていくはずです。権限を絞る方向の改善と、コストを見える化する方向の改善が同じリリースに入っていなくても、両方が少しずつ積み上がっている印象です。

/costのプロンプトキャッシュ行: こちらは全員に関係あります

Spend limitバーとは違い、こちらはゲートウェイの有無に関係なく効いてくる改善です。公式changelogの原文はこうでした。

Added a per-session prompt-cache line to /cost (hit ratio, misses,
tokens re-cached, warm/cold) and a matching prompt_cache object
for status line scripts

これまでの/costは、セッション全体でいくら使ったかの合計しか見えませんでした。今回追加されたのは、そのセッション内でプロンプトキャッシュがどれだけ効いたかを示す1行です。含まれる要素は次の4つです。

• hit ratio: キャッシュがヒットした割合
• misses: キャッシュミスの回数
• tokens re-cached: 再キャッシュされたトークン数
• warm/cold: キャッシュが温まっている状態か、冷えている状態か

ここで正直に書いておきたいのですが、IDEA-STOCKの段階では私は「いくら節約できたか」というドル/円換算の金額まで表示されると思い込んでいました。実際にchangelogの原文を読み直すと、書かれているのはhit ratio・misses・tokens re-cached・warm/coldの4項目だけで、節約額そのものがそのまま数字で出るとは明記されていません。実機で/costを叩いて確認できればよかったのですが、私の実行環境では検証できませんでした。誇張せずに書くなら、「節約額そのものではなく、節約につながっている挙動（ヒット率・再キャッシュ量・キャッシュの温度）が見えるようになった」というのが正確な言い方だと思います。

とはいえ、これはこれで十分に実務で使える情報です。私がこのループで意識している「1時間のキャッシュTTL」の効果は、まさにhit ratioとwarm/coldの組み合わせで確認できるはずです。同じセッションを長く保っているのにhit ratioが低い、あるいはwarm状態のはずなのにmissesが増えている、という状況が見えれば、「セッションの分割の仕方が悪いのでは」という当たりが付けられます。

私のように1人で法人をやっていて、Claude Codeの利用料を自分の懐から出している立場だと、こういう地味な数字が積み重なって効いてきます。無人ループを1日に何本も回していると、長い会話を1つ保つのと、短く区切って何度も投げるのとで、どちらがキャッシュの恩恵を受けやすいかは正直感覚でしか把握できていませんでした。hit ratioという数字が出るようになれば、「このタスクの粒度なら◯分以内に次を投げた方がいい」というような経験則を、感覚ではなく実測で語れるようになるはずです。

具体的にどんな見え方になるのかは、公式changelogの原文からは読み取れません。私の想像で書くなら、こんなイメージの1行が/costの出力に足されるのではないかと思っています(あくまで想像図で、実際の表示フォーマットではありません)。

Prompt cache: hit ratio 78%  misses 12  re-cached 3.2K tokens  warm

この形そのものは私の推測なので、鵜呑みにしないでください。実機で確認できた方がいたら、正確な表示をぜひ教えてほしいです。

ステータスライン用にはprompt_cacheというオブジェクトも対応して追加されています。こちらも公式changelogにはフィールド名しか書かれておらず、内部の細かいキー名までは確認できていません。ステータスラインスクリプトの標準入力に渡ってくるJSONを一度そのままログに吐き出してみる。これ、意外と使えます。新しいフィールドが追加されたとき、公式docsの更新を待たずに中身を確認できるからです。

この2つが同じリリースに入った理由

Spend limitバーと prompt-cache行、どちらも「今まで見えなかったコストの内訳を見せる」という方向性は同じです。ただし対象読者が違います。整理するとこうなります。

Spend limitバーは組織側の支出管理者・ゲートウェイ運用者向け、prompt-cache行は個人でセッションを回している開発者全員向け。1つのバージョンに「管理者向けの可視化」と「利用者向けの可視化」が両方入ってきたと考えると、Claude Code自体がチーム利用を前提にした機能追加のフェーズに入っているのかもしれません。起動の軽量化のようなインフラ寄りの改善と、こういう可視化系の改善が並行して進んでいるのを見ると、地味ですが着実にプロダクトとして育っている印象を受けます。

まとめ切れない部分は正直に置いておく

実在しない仕様を断定で書くよりは、確認できた範囲とできなかった範囲をはっきり分けて書く方がこのブログらしいと思うので、このまま公開します。気になる方は、ご自身の/usageと/costを実際に叩いて確認してみてください。もし手元でSpend limitバーが表示された、あるいはprompt-cache行に具体的な数字の並びが出た、という方がいたらコメントで教えてもらえると助かります。