結論：安価なモデルを標準、高価なモデルを例外にする
Fireworks AIの結果では、Kimi K3とFable 5の総合性能は近い一方、得意分野と実行コストは大きく違いました。 オラクルルーターは72～96％をKimi K3へ送り、解けない長い裾野をFable 5で補いました。
93％と最大50倍は実運用ルーターの保証値ではありません。 オラクルルーティングは両モデルを実際に走らせ、正解したモデルのうち安い方を後から選ぶ理論上の上限です。本番ルーターは実行前に予測して選ぶため、誤振り分け、再試行、待ち時間、運用費を含めて検証する必要があります。
2段階ルーティングの基本設計
Tier 1Kimi K3で分類しやすい修正、ターミナル、記号処理、低リスク作業を実行。
判定テスト、lint、型検査、制限時間、自己信頼度で成功・失敗を機械判定。
Tier 2失敗、重要変更、UI・可視化、複数言語の難問をFable 5へ送る。
モデルを選ぶ時の入力信号
| 信号 | Kimi K3候補 | Fable 5候補 |
|---|---|---|
| タスク種別 | 記号計算、開発ツール、長時間ターミナル | ウェブ開発、データ可視化 |
| 言語 | JavaScript、Rustで比較上拮抗 | Java、Python、C++の幅 |
| リスク | 元に戻せる、小さな差分 | 重要設計、顧客影響、判断が曖昧 |
| 検証 | 自動テストで正誤が分かる | 人のレビューやデザイン判断が必要 |
フォールバックは「失敗後に全部やり直し」にしない
- 最初のモデルが読んだファイル、試した変更、テスト結果を構造化して保存する。
- 時間、ターン数、トークン、同じエラーの反復に上限を置く。
- 上限に達したら作業を止め、Fable 5へ失敗理由と途中結果を渡す。
- 高性能モデルでも解けなければ人へ戻し、無限再試行を防ぐ。
本番で記録する指標
品質テスト通過率、レビュー修正数、再発率。
費用入力・出力・キャッシュ・再試行・人件費。
時間応答時間、完了時間、待機、タイムアウト。
実験ではKimi K3がSWEで多くのトークンを使い、Fable 5がターミナルで長引きました。「常に軽いモデル」は存在しないため、タスク別に測ります。
確認した情報源
よくある質問
Codexの中でKimi K3へ自動切り替えられますか？
この記事は複数モデルを扱う独自エージェント基盤の設計です。Codexの標準画面がKimi K3へ自動切り替えるという意味ではありません。
最初からFable 5だけ使う方が安全では？
重要案件では合理的な場合があります。ただし不得意なタスクでループが長引くと、費用と時間が増えるため実測が必要です。
ルーターはAIで作る必要がありますか？
最初は言語、リポジトリ規模、タスク種別、予算、失敗回数などの明示ルールでも始められます。