モデルルーティングとトークン節約
どのモデルを使うか
- Sonnet（デフォルト、作業の約90％）：編集、バグ修正、テスト、既知コードのリファクタリング、git、ドキュメント、README/TROUBLESHOOTINGの更新、
npm run checkの実行。 - Opus（効果が見込める場合のみ）：複数モジュールにまたがる新機能、アーキテクチャやデータフローの変更、Sonnetで一度試して原因が判明しなかったバグ、セキュリティレビュー、大規模な移行。まず短い計画（最大約30行）を書いてから、Sonnetで実行すること。
- Haiku：純粋な検索、grep-and-report、ログの要約、ファイルの一覧表示。サブエージェントに
model: haikuで委譲すること。 - スタイル、命名、1ファイルの変更のためにOpusにエスカレーションしない。Sonnetの試行が2回失敗した場合のみ1回エスカレーションし、その後Sonnetに戻す。
品質を落とさずにトークンを節約する方法
- まず
PLAN.mdを読む。次にタスクが関わるファイルだけを読む。ファイルを開く前にGrep/Globを使い、ファイル全体ではなく行範囲を読む。 node_modules、dist-electron、release、logs、data、package-lock.json、.envは絶対に読まない。npm run checkは最後に1回だけ実行し、編集のたびに実行しない。繰り返し作業中は単一のテストファイル（npx vitest run tests/<file>）を実行する。- 長いコマンド出力は
Select-Object -First 40/-Last 40でパイプし、完全なログをダンプしない。 - 編集したばかりのファイルを再読しない。会話内で既に確立した事実を繰り返さない。
- 返信は短く保つ：何が変わったか、何が確認されたか、ユーザーが次にすべきことだけ。
- 広範な検索やログの読み取りはサブエージェントに任せ、その結論だけをメインコンテキストに入れる。
- セッションごとに1タスク。トピックが変わったら長い履歴を引きずらずに新しいセッションを開始する。
- 正確性に影響するチェック、テスト、ファイルの読み取りをトークン節約のために決して省略しない。