Repository navigation
cruise: 利用上限で止まった後に続いたかを、トランスクリプトから数える（自動継続・人間・タイマー・止まったまま） #454
Description
何が起きるか
check-unattended-env.py は autoContinueAtUsageLimit: true が入っているかを見るだけで、上限の後に実際に続くかは一度も測っていない（#394 の R2-9 は残課題。同じ計画ファイルに「数時間の無人運転・利用上限の待機…1 周の検証では回せない」）。手元のトランスクリプトでは、9 月までは自動継続が 5 回起きていて、10 月からは 0 回。不在のときに上限で止まると、cruise はタイマーを張っていない限り止まったままになる。
実データ（2026-10-27。~/.claude/projects の全プロジェクト）
"error":"rate_limit" のレコード 113 件の、次に来たもの:
| 次に来たもの | 件数 |
|---|---|
| 記録の終わり | 31 |
| 人間の「継続」 | 23 |
ローカルコマンド（<local-command-caveat>） |
15 |
自動継続（Your claude.ai usage limit has reset. Continue the task…） |
7 行（重複を除いて 5 回） |
<task-notification>・cross-session など |
残り |
- 自動継続の 5 回は全部
spin/tfs-stocks、2026-08-27〜09-15。 再開の時刻はリセットの予告とほぼ一致（例: 「resets 2:10pm」→ 05:11Z） - 10 月以降は自動継続が 0 回——上限の後は人間の「継続」か、記録の終わり
- 今の user の settings（
~/.claude/settings.json・settings.local.json）にはautoContinueAtUsageLimitが無い。9 月に効いていたのが設定か、未設定のときの既定（aZt() ?? e==="absent"。dev-loop: 利用者が不在になる前の環境点検（許可・自動継続・通知・スリープ）（#389 から分割） #394）かは分からない——設定の履歴はトランスクリプトに残らない（交絡） - cruise の周が上限に当たった例は見つけていない（cruise の印で絞り込んではいないので「無い」とは言えない）
数え方は使い捨てのスクリプトで、error == "rate_limit" のレコードから次の user／assistant のレコードを取った。
受入基準
scripts/count-usage-limit-resumes.py（CI からは呼ばない——count-resume-recreations.pyと同じ形）を作る。上限のレコードごとに次に来たものを分類する（自動継続／人間の入力／タイマーや別のセッションからの入力／記録の終わり）。リセットの予告時刻と実際に再開した時刻の差も出す。--anonymizeを付けるscripts/test-count-usage-limit-resumes.py（変異テストを含む）。自動継続の文言と人間の「継続」を取り違える変異を殺せること- 実データで回して、期間ごとの内訳をこの Issue に貼る。設定の履歴は記録に無いので「設定が効いた」と書かない
- 陽性対照: user の層に
autoContinueAtUsageLimit: trueを明示したうえで、上限まで回したセッションで「自動継続」と分類される例を 1 件取る。上限は狙って起こせないので、取れなければこの項目は BLOCKED として残す（課金と待ち時間がかかる）- 測る前と後で、
~/.claude.jsonのcachedGrowthBookFeaturesのうちtengu_marble_heron・tengu_linked_cloverの値（キーが無いことも含めて）と、oauthAccount.billingTypeを記録して貼る——2.1.311 は設定がtrueでも、このフラグが外れているとき（killswitch）や、課金がusage_basedのときは待たない（解説）。自動継続が起きなかったときに、設定の問題と取り違えないため。キー名は版で変わりうるので、測る時点の本体の文字列で確かめる - 取れなかったときは、記録したフラグの値を添えて BLOCKED とする（「起きなかった」を「設定が効かない」と書かない）
- 測る前と後で、
- 3・4 の結果を
docs/plugins/dev-loop-cruise.md§5 とcheck-unattended-env.pyの「守らないこと」に反映する——trueで十分と言えるか、タイマーを保険として勧めるべきか
確かめていないこと
- 10 月に自動継続が 0 回になった原因（設定・本体の版（いまは 2.1.311）・課金の種類が交絡）
- cruise の周で上限に当たったときの、台帳と計画ファイルの状態
Activity
hdknr commentedon Oct 26, 2026
autoContinueAtUsageLimitの解説（本体 2.1.311 の文字列から。2026-10-27）出所は
~/.local/share/claude/versions/2.1.311の文字列だけ——公開ドキュメントではない。関数名は minify されたもので、版ごとに変わる。読み取ったことであって、動かして確かめたことではない。何をする設定か
設定の説明（そのまま）:
Your claude.ai usage limit has reset. Continue the task you were working on when the limit was reached; do not repeat work that is already complete.Your claude.ai usage is available again before the usage-limit reset. Continue the task …（分類のときはこちらも拾う）Usage limit reached · limit resets <時刻>とContinuing shortly · esc to cancel。Esc で取り消せる（Automatic continue cancelled …が出る）どこに書けば効くか
settings.jsonに書いても効かない/configの「Model & output」にある「Continue automatically at usage limit」が user の層に書き込む。この切り替えが/configに出るのは、値が未設定か user の層から来ているときだけ（managed・flag で決まっていると出ない）設定値 ?? (保存域でのキーの有無 === "absent")。キーの有無を調べられなければunknowableになって再試行する。未設定でもオンになる場合があるが、いつそうなるかは文字列からは読み切れない——check-unattended-env.pyが未設定を要対処にしているのはこのため。ちなみに/configの表示だけは未設定をtrueとして見せるtrueにしても待たない場合（#394 の R2-9 の中身）待つかどうかの判定は、設定のほかに少なくとも次を全部要求する:
usage_basedでない——手元の~/.claude.jsonはstripe_subscriptionなので、ここは満たすtengu_marble_heronのenabledとautoArm、キルスイッチのtengu_linked_clover（既定はオン）。フラグが外れていると、設定がtrueでもkillswitchとして待たない10 月に 0 回になったことの候補（確かめていない）
手元の
~/.claude.jsonのcachedGrowthBookFeaturesに、tengu_marble_heronもtengu_linked_cloverも無い。 無いときは{}が使われ、enabledは未定義になる——そう読めるなら、今の手元では設定に関係なく待たない。9 月に自動継続が起きていたことと合わせると、サーバ側のフラグが変わったことが 10 月の 0 回の候補になる。ただし確かめていない:
r()の中身は読んでいない）つまり、受入基準 4（陽性対照）が取れない理由は「上限は狙って起こせない」だけではない——フラグ次第で、取りに行っても起きない可能性がある。 取れなかったときに設定の問題と取り違えないように、測る前後で
cachedGrowthBookFeaturesの該当キーを記録することを基準 4 に足すのがよい。cruise の運用への含み
autoContinueAtUsageLimit: trueは必要条件で、十分条件ではない。フラグはリポジトリからも利用者からも動かせないCronCreateなどで同じ引数の/dev-loop:cruiseを起動し直す）を保険として張るのが今の作りでいちばん確実——台帳から再開するので、自動継続が起きても起きなくても続きは失われないdocs(plans): #454 の PR と起票（#456）
利用上限で止まった待ちが何で続いたかを数える（#454） (#455)
count-usage-limit-resumes.py: 遅い自動継続の線引き・素通りする変異・--tz で割れる組（#457） (#462)
hdknr commentedon Oct 27, 2026
受入基準 1〜3・5（計画ファイルの U1〜U13）は PR #455 で済み、残課題は #457（PR #462）で直した。受入基準 4（陽性対照:
trueを明示して自動継続を 1 件取る）は #456 へ移した——trueは 2026-10-27T13:36:33+09:00 に明示済み（#456 のコメント）で、上限に当たるのを待っている。同じものを 2 つの Issue で追わないため、ここは閉じる。