TL;DR
私はRouteSmithを作りました。コーディングエージェントを使っていても、ユーザーに対してあまりにも多くの手作業によるルーティングを求めてしまうからです。
「この機能を計画して実装し、テストを追加してドキュメントを書いてください」という指示は、1つのタスクではありません。ワークフローです。
RouteSmithは現在のホストを検知し、プロンプトをタスクタイプに分解し、それらのタスクを能力クラスにマッピングして、ホストが実際に対応できるものを使ってルーティングします。ホストが切り替えに対応しているなら、RouteSmithは具体的なモデルを提案できます。対応していないなら、RouteSmithは「切り替えが行われた」かのようにごまかすのではなく、正直にフォールバックします。
特に以下に役立ちます:
- コーディングエージェントを始めたばかりの人
- モデルのトレードオフを先に学びたくない「雰囲気コーダー」
- 複数タスクが混ざったプロンプトを扱うソロビルダー
- 測定可能で、設定できるルーティングを求める上級ユーザー
あなたをずっとイラつかせ続けた問題
私は同じ瞬間に何度もぶつかりました。
コーディングエージェントを開いて、大きな1つのプロンプトを渡すようにしていました：
「この機能を計画して、実装して、テストを追加して、ドキュメントを書いて、そして結果をレビューして。」
最初はスムーズに感じました。
しかし、その流れは壊れました。
私は機能のことを考えるのをやめて、頭の中でルーティングを始めてしまったのです。
例えば次のような疑問です：
- 計画には、より強い推論モデルを使うべきなのか？
- コーディングには別のものを使うべきなのか？
- なぜ最も重いモデルでドキュメントと整形をやらせているのか？
- このホストは、私が考えているように切り替えに対応しているのか？
それが本当の問題でした。
プロンプトは1つのタスクではありません。いくつかの異なる仕事をひとまとめにしたものです。
RouteSmithとは何か
RouteSmithは、コーディングエージェント向けのホスト対応型のルーティングレイヤーです。
これは別のコーディングエージェントではありません。
APIゲートウェイでもありません。
混在したプロンプトと、ホストが実際に持つ能力との間に入ります。
基本的な流れは次のようになります：
- 現在のホストを検知する
- プロンプトをタスクタイプに分類する
- タスクタイプを能力クラスにマッピングする
- それらの能力をホストネイティブのモデルまたは戦略に解決する
- 依存関係の順序を保持する
- 結果を追跡し、時間とともにルーティングを改善する
「ホスト対応（Host-Aware）」が重要な理由
ここが、私が特に重視している部分です。
マルチモデルのワークフローについての会話が多すぎると、ホストの存在が薄れてしまい、「どの環境も同じ操作面（コントロールサーフェス）を公開している」かのように扱われます。
そんなことはありません。
Claude Code、Cursor、Copilot、Codex、Gemini CLI、Aiderはすべて同じ振る舞いをしません。実際のモデル切り替えに対応しているものもあります。モデル選択の見せ方が異なるものもあります。ホスト主導の度合いがずっと高いものもあります。
だからRouteSmithは、単純なルールに基づいて作られています：
ホストが真実（唯一の根拠）である。
ホストが動的な切り替えに対応しているなら、RouteSmithはタスクを具体的なモデルへルーティングできます。
ホストが対応していないなら、RouteSmithはそれを偽りません。ルーティングのロジックはそのまま保ち、代わりにプロンプト戦略を適用します。
この誠実な挙動は、偽のユニバーサルな抽象化よりもずっと重要です。
対象者
このプロジェクトは、すでに「推論モデル」「コーディングモデル」「高速なユーティリティモデル」「コスト最適化したルーティング」の違いを知っている人だけのものではありません。
それらのことをこれから知る人にも向いています。
1. コーディングエージェントを始めた人
エージェントツールを使っているものの、いつモデルを切り替えるべきか分からないなら、RouteSmithはその判断負担を減らすために作られています。
2. 雰囲気でコーディングする人
あなたのスタイルが「結果を平易な英語で説明して、先へ進む」なら、RouteSmithはプロンプトを塊（blob）ではなくワークフローとして扱うので役に立ちます。
3. ソロビルダーと創業者
自分自身で計画、実装、テスト、ドキュメント、レビューまで行っているなら、タスクに応じたルーティングがすぐに役立つようになります。
4. 上級ユーザー
ポリシーの上書き、プラグイン、テレメトリ、パフォーマンスを意識したルーティング、そしてホストの制約に関心があるなら、RouteSmithはそれらを扱う余地も用意しています。
短くまとめると：
RouteSmithは、最初から「モデルのルーティングの専門家」になる必要なしに、マルチモデルのワークフローの恩恵を得たい人のためのものです。
具体例
初心者が次のように打ち込むとします：
認証付きのシンプルな家計簿トラッカーを作って、テストを追加して、READMEを書いてください。
これがたいてい意味しているのは、例えば次のようなことです：
- 機能の構造を計画する
- アプリを実装する
- テストを書く
- 結果をドキュメント化する
これらは別種の作業です。
RouteSmithは、それをそういうものとして扱えます。
概念的なルートは、例えば次のようになります：
planning -> deep_reasoning
coding -> coding
testing -> coding
documentation -> balanced
そしてホストアダプタが、それが実際には何を意味するかを決めます。
ホストが切り替えに対応しているなら、RouteSmithは各ステップに対して具体的なモデルを提案できます。
対応していない場合でも、「モデル制御ができた」と嘘をつかずに、タスクに応じた戦略はそのまま保持します。
内部ではどう動くか
決定論的な計画
RouteSmithは、プロンプトを次のようなタスクタイプに分類します：
- planning（計画）
- analysis（分析）
- coding（コーディング）
- testing（テスト）
- refactor（リファクタリング）
- documentation（ドキュメント化）
- formatting（整形）
- review（レビュー）
この計画は決定論的です。要求の形を理解するだけのために、ライブなAPI呼び出しは必要ありません。
能力クラス
モデル名へ直接ハードコードしてルートを決めるのではなく、RouteSmithはタスクを次のような能力クラスへマッピングします：
deep_reasoningcodingbalancedfast
これにより、システムはホスト間で移植可能になります。
依存関係を考慮した実行
混在したプロンプトは単なるリストではありません。テストは実装に依存することが多いです。ドキュメントは通常、変更に追随します。レビューは後で行われます。
RouteSmithはその順序を崩しません。
パフォーマンスを意識したルーティング
RouteSmithはさらに、ローカルのテレメトリも記録します：
- 使用したモデル
- ホスト名
- タスクタイプ
- 能力クラス
- 成功または失敗
- 所要時間
- テレメトリの出所
このデータは表示のためだけではありません。
返却形式: {"translated": "翻訳されたHTML"}十分な証拠によって、デフォルトモデルがある能力に対して弱いことが示され、かつ利用可能なより良いホスト側オプションが存在する場合、RouteSmithは弱いモデルの優先度を下げることができます。
それにより、パフォーマンス追跡がアクティブなルーティングシグナルになります。
他のツールと比べると
ここでの有用な捉え方は「RouteSmith vs 他のすべて」ではないと思います。
有用な捉え方は、隣り合うツールが異なる層を解決しているということです。
エージェント製品
Claude Code、Cursor、Aiderはエージェント製品です。これらは、コーディング作業を実際に行うためのツールです。
RouteSmithはそれらの置き換えを目指しているわけではありません。
APIおよびゲートウェイ基盤
LiteLLMとPortkeyは別の課題を解決します。API層でのマルチプロバイダーのルーティング、制御、可観測性です。
それは有用ですが、RouteSmithが存在する層とは同じではありません。
ルール、スキル、指示
指示の入力面は振る舞いを形作るのに役立ちますが、それ自体がルーティングの頭脳になっているわけではありません。
RouteSmithは、コーディングエージェントのワークフローのためのホスト対応のルーティング層として、これらの層の間に位置します。
簡単にまとめるなら：
- コーディングエージェントが欲しいならClaude Code、Cursor、またはAiderを使う
- API層でのルーティングやゲートウェイ制御が欲しいならLiteLLMまたはPortkeyを使う
- ホストの実在する制約の中で、より賢くルーティングされた混合タスクのコーディング指示が欲しいならRouteSmithを使う
実際に何を提供するのか
主な利点は目新しさではありません。レバレッジです。
RouteSmithは次を支援します：
- モデルのマイクロマネジメントを減らす
- 混合プロンプトをより構造化する
- ホスト固有の制約を尊重する
- 初心者が、モデル知識を深く持たなくても、より良いルーティングの恩恵を受けられるようにする
- 上級者にテレメトリ、ポリシー、パフォーマンスを考慮した適応を提供する
使ってみる
pip install routesmith
routesmith detect-host
routesmith explain "この機能を企画し、実装し、テストを追加し、ドキュメントを書いてください"
routesmith run "この機能を企画し、実装し、テストを追加し、ドキュメントを書いてください"
routesmith stats
そして、より大きなワークフローの中でツールとして使いたい場合は：
routesmith serve-stdio
最後に
コーディングエージェントのワークフローで面白いのは、もはやモデルだけではありません。
実務の周囲にあるルーティング層こそが重要なのです。
もしプロンプトに、企画、コーディング、テスト、ドキュメント作成、レビューが含まれているなら、それを未分化の1つの要求として扱うのは、ソフトウェア開発が実際に起こる方法とは相性がよくありません。
RouteSmithが埋めようとしているギャップはそこです。
Githubリンク: github.com/sidrat2612/routesmith
PyPIリンク: pypi.org/project/routesmith
