$ man context-wiki/model-selection

すべての AI モデルが同じわけではない。速くて安いものもあれば、賢くて高いものもある。タスクに合わないモデルを使えば、お金を無駄にするか、ひどいアウトプットが出るかのどちらかだ。単純なフォーマット変換に高性能モデルを使うのは、壁のペンキ塗りにシニアアーキテクトを雇うようなもの。複雑なアーキテクチャ設計に高速モデルを使うのは、ビルの設計をインターンに任せるようなもの。モデルをタスクに合わせる。それが戦略のすべてだ。

パターン

高速モデル(Sonnet クラス)が向いているタスク：フォーマット変換、ファイルのパターンスキャン、シンプルなコード修正、コピー&ペーストで対応できる作業、単純なデータ変換。これらのタスクは入力が明確で、出力も明確で、曖昧さが少ない。 高性能モデル(Opus クラス)が向いているタスク：アーキテクチャの意思決定、複雑なデバッグ、深いリサーチの総合分析、繊細なトーンが求められるクリエイティブコンテンツ、各ステップが前のステップに依存するマルチステップ推論。これらのタスクには曖昧さがあり、トレードオフを伴い、判断力が必要だ。 デイリートラッカーがモデルの使用状況を記録しているので、どこで使いすぎているかが分かる。Sonnet で十分なタスクに Opus を使っていたら調整する。Sonnet のセッションでひどい結果が出ていたら、もっと高性能なモデルが必要だったということだ。

プロのコツ

並列エージェントを起動するとき、タスクごとにモデルを割り当てる。オーケストレーションエージェント(すべてを調整する役割)はデフォルトの高性能モデルを使う。依存関係やコンテキストについて推論する必要があるからだ。単純な作業をするサブエージェント(既存ページと同じページを作る、設定ファイルを更新する、ビルドチェックを実行するなど)は高速モデルを使う。重い創造的作業をするサブエージェント(自分の声で 17 本のウィキ記事を書く、新機能のアーキテクチャを設計するなど)は高性能モデルを使う。 これはケチっているわけではない。効率を上げるためだ。単純なタスクを 30 秒で完了する高速モデルの方が、同じタスクに 2 分かかる高性能モデルより優れている。5 つのエージェントを並列で動かしているとき、速度は重要だ。

フォーミュラ

高性能モデルのセッションコストは高速モデルの約 3-5 倍。1 日中ビルドしていると、この差は積み重なる。デイリートラッカーがモデル使用量を計算し、異常値をフラグする。公式はシンプルだ。各タスクに対して 2 つの質問をする。(1) このタスクには推論や判断が必要か? もしそうなら高性能モデルを使う。(2) このタスクは機械的またはパターンベースか? もしそうなら高速モデルを使う。迷ったら、まず高速モデルで試す。アウトプットが悪ければ、高性能モデルにアップグレードする。安い方で試してからアップグレードする方が、何でもデフォルトで高い方を使うよりずっといい。