ClaudeのAPIを一晩で6,000ドル溶かした/loopコマンドの話

あるRedditユーザーが、目を覚ますとClaudeの利用限度額が枯渇していたと報告した。原因は、claude-opus-4-7上で/loop 30m check my PRsという単一のコマンドが26時間にわたって無人実行され、46回ループし、約6,000ドルを消費したことだ。根本原因は、プロンプトキャッシュの動作と長時間セッションの組み合わせにある。

以下が技術的な内訳である：

• 毎回コンテキストウィンドウが拡大する：APIコールのたびに会話履歴全体が送信される。最初のターンは数百トークンだが、46ターン目には80万トークンが送信される。各ターンで送信されたすべてのトークンに対して課金される。
• 約5分でプロンプトキャッシュが期限切れになる：Anthropicは会話履歴をキャッシュし、キャッシュウィンドウ内で再利用されると12.5倍割引を適用する。しかし、/loop 30mでは30分の間隔が5分のキャッシュTTLを超える。そのため、毎回のイテレーションで拡大し続けるコンテキスト全体を最初から再キャッシュするための高額な書き込みレートを支払うことになる。
• 出力がコンテキストに追加される：各ループの出力が会話に追加されるため、次回の再キャッシュはさらに大きくなる。20時間目には、セッションは約80万トークンに達していた。
• ダッシュボードの遅延が被害を隠す：Anthropicの利用ダッシュボードは報告に数日遅れがある。唯一のリアルタイムシグナルは利用制限通知メールだったが、その時点ですでに費用は発生していた。

このユーザーが提案する主要な防止策は以下の通り：

1. 停止条件を追加する：単に/loop 30m check my PRsと書く代わりに、/loop 30m check my PRs — stop when all are merged or after 3 hoursと書く。条件が満たされるとClaudeがループを終了する。
2. 無人タスクにはSonnetを使用する：Opusは出力トークンあたり約5倍高額である。PRチェックのようなポーリングタスクにはSonnetで十分。Opusは自分が同席するセッションに限定する。
3. ダッシュボードを信用しない：数日遅れる。リアルタイムの課金シグナルとしては利用制限メールに頼る。
4. 新しいセッションの方が安い：長時間セッションは、5分以上の間隔があるすべての呼び出しで全コンテキストの再キャッシュに費用がかかるため、コストが増大する。新しいセッションを開始するとコンテキストがリセットされ、これを回避できる。
5. max_turnsはループ制限ではない：これは単一イテレーション内のツール呼び出しチェーンを制限するものであり、ループの回数を制限するものではない。/loopに組み込まれている唯一の期限は、7日後の自動削除である。

ループはメインの会話内で実行されるため、同じセッションをアクティブに保つと、各ループ実行で必要以上に多くのトークンを読み書きすることになり、コストが指数関数的に増大する。

Claudeを/loopで自動化する場合は、常に停止条件を設定し、より安価なモデルを使用し、外部ツールで監視すること。キャッシュ割引は、呼び出しがTTL以内に十分頻繁に行われる場合にのみ有効である。