Model routing decides which language model answers a prompt; tool routing decides which capability acts on the world and runs it. They sit at different layers of the same agent and neither replaces the other.
The names are close enough to cause real confusion, and the confusion is expensive: teams shopping for one sometimes buy the other.
Why it matters
| Model routing | Tool routing | |
|---|---|---|
| Chooses between | Language models and providers | Tools, skills and their providers |
| Optimizes for | Cost, latency, context length, capability of the model | Whether the job gets done, and at what per-call cost |
| Unit billed | Tokens in and out | A tool call, usually per successful call |
| Failure looks like | A worse or slower answer | A job not done, or done wrong |
| Typical product | OpenRouter | ToolRouter |
An agent normally wants both. The model router decides who thinks; the tool router decides who acts. Swapping the model does not give an agent a web crawler, and adding a crawler does not make the model cheaper.
"The OpenRouter for tools" is a description of the shape, not a claim of equivalence: one connection and one balance in front of many providers, applied to tools rather than models.
Related
- ToolRouter vs OpenRouter — the two products side by side
- What is a tool router?
- What is an MCP gateway?
- Every "OpenRouter for tools" compared
- ToolRouter glossary