定額プランの最上位モデルを枯渇させずに使う「二段レーン」設計

誰向けか

コーディングエージェント CLI（Codex CLI / Claude Code / その他 agentic CLI）を定額サブスクリプションで回していて、 最上位モデルが追加されたが 5時間枠・週枠の消費が既定モデルより桁違いに速いという状況にある人。

「全部を最上位モデルにする」と数日で枠が尽き、「一切使わない」と長時間タスクの完遂率が上がらない。 その中間を人手の判断ゼロで取るためのレーン設計。

前提となる観測事実（なぜ二段にするか）

最新世代のエージェント向けモデルは、純粋な知能指標では既存モデルと数ポイント差しかないのに、 長時間・多ツールのタスク完遂ベンチでは 1.3〜2 倍の差がつくことがある。 つまり効くのは「短い実装」ではなく「E2E・マイグレーション・横断リファクタのような、 途中で失敗して復帰しながら最後までやり切る」タスク。ここだけに当てれば枠が保つ。

さらに同一モデルでもハーネス（メモリ・文脈管理・圧縮・ツールループ）の差で完遂率が大きく動くので、 モデルを上げる前に、まずレーン分けと退避・昇格の自動化に投資する方が費用対効果が高い。

設計

委譲の入口スクリプト（delegate.mjs 等）に、純関数のレーン判定を1つ足す。

decideLane({ lane, model, promptText, timeoutSecs, review, topCooldownMs })
  → { slug, effort, reason }

判定順（上から優先）:

1. --model <slug> の明示指定 → そのまま使う（クールダウンも無視して再試行できる唯一の経路）
2. --lane top / --lane base の明示 → その通り
3. 指示ファイルの先頭 40 行に <!-- lane: top --> があれば上位、<!-- lane: base --> があれば既定
4. --review（コードレビュー用途）→ 既定モデル。レビューは枠を食う割に差が出にくい
5. --timeout が 45 分以上 → 上位（長時間タスクは定義上そこが効く領域）
6. 指示本文に長時間性キーワードが 2 種類以上（migration E2E refactor 横断 全ファイル 根本原因 等）→ 上位
7. それ以外 → 既定モデル

上位モデルがクールダウン中なら 1 以外はすべて既定モデルへ降格し、理由を stderr に1行出す。

退避（上限に当たった時）

上位モデルで usage limit を検出したら:

• provider-cooldown.json に 上位モデル専用のキーで reset 時刻を書く（既定モデルのキーと分ける。ここを共有すると片方の枯渇で両方止まる）
• 上限到達を 1 行ずつ追記ログに残す（上書き保存の JSON だけだと「24h に何回当たったか」が後から数えられない）
• 同じ指示を既定モデルで 1 回だけ再実行する。ここで外部の従量課金 API へ落とさない（定額枠の中で完結させる）
• 既定モデルでも上限なら、そこで初めて従来のフォールバック連鎖へ

昇格（既定モデルが失敗した時）

auto レーンで既定モデルを選び、結果が次のいずれかなら、上位モデルで1 回だけ再実行する:

• 非ゼロ終了 / タイムアウト / 編集を期待したのに diff が空

3 つ目が重要。エージェント CLI は「何もせず exit 0」で終わることがあり、 終了コードだけ見ていると失敗を成功として数えてしまう。

可視化

使用量台帳に model（<cli>/<slug>）・lane・escalated を必ず残し、 日次コストレポートに「上位 N セッション / 既定 M セッション / 上位の上限到達 24h 何回」を出す。 この 1 行があるかどうかで、閾値を勘で動かすか実測で動かすかが変わる。

運用の初期値と調整

• 最初は上の閾値（45 分・キーワード 2 種）で始める
• 1 週間後にレポートを見て、上位モデルの上限到達が 24h に 2 回以上出続けるならキーワード閾値を 3 種へ上げる
• 逆に上位が 24h 0 回で長時間タスクの失敗が残るなら 45 分を 30 分へ下げる

落とし穴

• 既存呼び出しとの互換: --lane も --model も付けない従来の呼び出しは、既定モデルの挙動と完全一致にする。昇格は「失敗した時だけ」に限る
• シェルを 1 層も通さない: 指示本文は必ず stdin かファイルで渡す。argv に載せるとバッククォートや $() が展開され、指示から必要なファイル名が消える
• -c key="value" に空白を入れない: Windows の shell:true 起動では引数がエスケープされず、空白があると値が割れる
• CLI のバージョン要件: 新モデルは CLI の特定バージョン以降でしか model 一覧に出ない。「アカウントに無い」と結論する前に CLI を更新して model 一覧を取り直す
• ランタイム検出のタイムアウト: 別環境（WSL 等）越しに CLI を起動する構成では、コールドスタートが検出プローブのタイムアウトを超えると 「CLI が無い」と誤判定し、機能が制限された別経路へ静かに落ちる。exit 0 を成功と見なさず、git log / git diff の実体で確認する

検証

• レーン判定は純関数として切り出し、全分岐（明示・ヘッダー・レビュー・長時間・キーワード・既定・クールダウン降格）を単体テストする
• 起動引数の組み立ても関数に切り出し、-m <slug> と effort 指定が入ることをテストする
• 実機で 1 回だけ read-only の疎通を流し、ヘッダーの model: 行と台帳の記録の両方で上位モデルが使われたことを確認する