「セッション上限です」と言われて追加クレジットを買ったのに、また同じところで止まる——その上限、あなたが当たっている枠とは別かもしれない

Claude Code で、裏側の副作業者(サブエージェント)を何本か走らせている人に、こういうことが起きる。副作業者が「You've hit your session limit - resets at 7pm」のようなメッセージで次々に止まる。ところが、同じセッションの本体の作業は何時間も普通に動き続けている。/status を見ても、契約している購読の枠にはまだ余裕がある。示された時刻まで待っても、何も変わらない。仕方なく追加の利用クレジットを買うと、いったんは動く。だがまた同じところで止まり、しかも——止まって捨てられた副作業者が使ったぶんのトークンは、ちゃんと課金されている。

この事故は GitHub の起票 #74006 で、当事者の詳しい観測つきで報告がある。挙動そのものは報告者のものなので伝聞として書き、確認のしかたは手元で組んで確かめた範囲で書く。

何が起きているのか

報告者の観測を整理すると、こうだ。

1. 本体のセッションの繰り返しは、何時間も一度も止められずに動いた(朝3時台から昼前まで20回のコミット、14時以降も止まらず)。
2. その裏で、副作業者だけが「セッション上限、X時にリセット」で終端的に殺された。時刻は 8am → 2:10pm → 7pm と回るのに、待っても解けない。
3. /status は、そのあいだずっと購読の枠に余裕を表示していた。
4. 追加のクレジットを$100買うと、次の副作業者は動いた。だが16.4分(61回の道具呼び出し)走ったのち、また同じ「セッション上限」で殺され、その 374,904 トークンは買ったばかりのクレジットから引かれ、成果物はゼロだった。さらに$50足して、合計$150を「回避」のために払った。そのあいだも /status は購読の枠を「余裕あり」と表示し続けた。

つまり、待っても解けず、買っても解けないのに、殺された作業のぶんは課金される。示された上限と、実際に当たっている上限が食い違っている疑いが濃い。

なぜ起きるのか——「大量の並行のあとの死」と「孤立した死」は分けて考える

ここが一番大事なところだ。報告者は、同じセッションで起きた複数の死を、あとから使用量の記録で切り分けている。全部が同じ原因ではない。ここを混ぜると、直さなくていい枠を疑ったり、効かないクレジットを買ったりする。

大量の並行のあとの死は、素直に枠の枯渇かもしれない。 最初の二回の死の直前には、桁違いの並行があった。一回目は12本の検証の副作業者が約7分で約240万トークンを燃やした直後に、13本目が殺された。二回目は約35分で15本・約330万トークンが走り終えた直後だった。これだけの並行が短時間に走れば、共有の枠が本当に尽きた可能性は高い。この場合の「上限」は実在で、紛らわしいのは、副作業者ごとにリセットの時刻の投影がばらつく(8時→14時10分→19時)ために、一つの枠なのに複数の別々の上限が当たっているように見えることだ。

説明がつかないのは、孤立した死のほうだ。 三回目の死は毛色が違う。並行はゼロ、たった一本の副作業者が、買ったばかりの追加クレジットの上で16.4分・374,904トークン走って、同じ「セッション上限」で殺された。しかも /status は購読の枠に余裕を表示したまま。直前に大量の並行があったわけでもない。枠の枯渇では説明がつかない。

この孤立した死の周りにあった唯一の異常な信号が、補助のモデルの不在だった。同じセッションの中で、逐語でこう出ていた(一つ目は本体の承認の判定で、二つ目は完了した副作業者の点検で)。

• claude-opus-4-8[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash right now.
• Note: claude-opus-4-8[1m] (the safety classifier) was unavailable when reviewing this subagent's work.

これが指すのは、副作業者の経路が、あなたのセッションのモデル(たとえば claude-fable-5)とは別の、補助のモデル(承認の安全を判定する分類器など)に依存している、ということだ。ここからは、まだ提供側に確認されていない筋の通る仮説として読んでほしい。この補助のモデルの容量や在庫が尽きて副作業者が殺されているのに、表示される「セッション上限」のエラーと /status は、どちらもセッションのモデルの枠を指している——という筋なら、孤立した死の観測の食い違いがつながる。セッションのモデルの枠は一度も尽きていないから、待っても解けない。そしてこの補助のモデルの容量は、購読の枠にも追加の利用クレジットにも直接は対応していない。だからクレジットを買っても当たっている上限には効かず、殺された副作業者がそこまでに使ったトークンだけが、そのクレジットから引かれる。表示のずれが、そのまま二重の出費に変わる。

追加のクレジットを買う前に、当たっている上限を自分で確かめる

真に直すべきなのは提供側だ。エラーの文言と /status が、拒否した上限の正体(購読の枠か、追加のクレジットか、補助のモデルの容量か)を名指しすること。そして、上限で破棄した作業のぶんを課金しないか、途中で保存して再開できるようにすること。報告者もそれを求めている。

それが入るまで、手元でできるのは「買う前に確かめる」ことだ。次の三つが同じセッションで揃っているかを見る。

1. 補助のモデルが不在という文言(上の逐語)が出ている。
2. 副作業者が「セッション上限」で殺されている。
3. /status は購読の枠に余裕を表示している。

この三つが揃うなら、拒否しているのは補助のモデルの容量である可能性が高い。その場合、追加のクレジットを買っても解けない。だからまず確かめる。セッションのログ(道具の結果や、作業の使用量のまとめの行)を流し込むと、この共起を判定する最小の形はこうだ。手元で、補助の不在・副作業者の死・孤児化したトークンの三つを含む場面を作って走らせ、判定が出ることと、副作業者の死だけで補助の不在が無い場合はきちんと区別されることを確かめた。

#!/bin/bash
# セッションのログを標準入力に流し込むと、「セッション上限」での副作業者の死が、
# 補助のモデルの容量に起因する疑いが濃いかを判定する。買う前の確認に使う。
aux=0; killed=0; orphan=0
while IFS= read -r l; do
  echo "$l" | grep -qE 'is temporarily unavailable, so auto mode cannot determine the safety|\(the safety classifier\) was unavailable' && aux=1
  echo "$l" | grep -qE "hit your session limit" && echo "$l" | grep -qE '\[[^]]+\] (failed|error)' && killed=1
  t=$(echo "$l" | grep -oE 'subagent_tokens[^0-9]*[0-9]+' | grep -oE '[0-9]+$')
  e=$(echo "$l" | grep -oE 'agents_error[^0-9]*[0-9]+' | grep -oE '[0-9]+$')
  [ -n "$t" ] && [ -n "$e" ] && [ "$e" -ge 1 ] && orphan=$((orphan+t))
done
if [ "$aux" = 1 ] && [ "$killed" = 1 ]; then
  echo "補助のモデルの容量が原因の疑いが濃い。クレジットを買う前に /status と突き合わせよ(孤児トークン: ${orphan})"
elif [ "$killed" = 1 ]; then
  echo "副作業者は上限で死んだが補助の不在の兆候は無い。まず /status の枠を確認せよ"
else
  echo "判定不能(該当の兆候なし)"
fi

これは上限を止めない。補助のモデルが不在なら、副作業者は殺され続ける。止められるのは「示された上限に釣られて、効かないクレジットを買い続ける」部分だ。 当たっている上限がどれかが見えれば、$150を払う前に、それが購読の枠でもクレジットでもないと分かる。

まとめ

• 副作業者の「セッション上限」の死は、少なくとも二種類ある。直前に桁違いの並行(数百万トークン)があったなら、共有の枠が本当に尽きた可能性が高い(紛らわしいのはリセットの時刻の投影がばらつくことだけ)。だが、並行がなく、一本だけが、しかもクレジットの上で殺され、/status は余裕——この孤立した死は、枠の枯渇では説明がつかない。
• 孤立した死の周りにあった唯一の異常が、補助のモデル(安全の分類器など)の不在だった。まだ提供側に確認されていない筋の通る仮説は、副作業者を殺しているのがこの補助のモデルの容量で、エラーと /status はセッションのモデルの枠を指している、というもの。その容量は購読にもクレジットにも直接は対応しないので、買っても解けず、殺された副作業者のトークンだけが課金される=表示のずれが二重の出費になる。
• 手元でできるのは、買う前に「補助の不在・副作業者の死・/statusの余裕」の共起を確かめること。共起があれば、効かないクレジットを急いで買わない。共起がなく死だけなら、まず /status の枠を見る。真の修正は提供側(エラーと /status が上限の正体=どのモデルのどのプールかを名指しする・破棄した作業を課金しない・容量が戻ったら副作業者を再開する)。

---

こうした「表示と実態がずれて、気づかないうちにお金が溶ける」型の事故と、その手元での備えを、無料の hook 集 cc-safe-setup にまとめて公開している。導入は次の一行だけだ。

npx cc-safe-setup

さらに、この費用のずれの事故を含め、Claude Code で実際に起きた事故を「症状 → 検出 → 復旧 → 予防」の順にまとめた買い切りの本(Anthropic公式ガイドにない事故防止・¥800)も出している。裏の作業者が起動しただけで利用枠が焼き切れる事故や、購読なのに黙って従量課金される罠など、費用の暴走の系統は複数の章で扱っている。第3章まで無料で試し読みでき、以降も月ごとに新しい事故を追記して、購入者には無償の更新で届く。