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.
ToolRouter and OpenRouter
OpenRouter provides access to language models. ToolRouter exposes specialist tools through MCP, CLI, and REST. An application can use a model from OpenRouter and tools from ToolRouter in the same agent.
Use the model service's current pricing to estimate inference spend, and ToolRouter pricing plus each tool page for execution costs. Token prices and tool-call prices have different units; comparing them as if they purchase the same outcome is misleading.
ToolRouter does not provide model inference or replace an assistant subscription. Some tools require provider credentials or permissions. For the gateway overview, see OpenRouter for tools.