claude-code-router

You will reach for this when the tool you already like is tied to one expensive model. The trait that decides it day to day is that nothing about your habits changes: the same command, the same session, and a different model answering, so you can move an entire workflow onto cheaper inference without learning a new interface. Codex, Grok CLI, Kimi CLI, Kilo Code and OpenCode can all sit in front of it.

Pick it if switching agents costs you more than switching models. Pick OpenCode when you would rather have one program that speaks to every provider natively and skip the middle layer.

The risk is misrepresentation in the middle. Presenting capabilities a model does not natively have means the emulation's edges become the agent's bugs, and the agent cannot distinguish a model that answered badly from a shim that translated badly. Add automatic fallbacks and the run that failed may not have used the model you think it used. Debugging then involves three layers, only one of which you wrote.

What it does right: fallback models are an ordered list you declare, so degradation under a provider outage is a configured behaviour rather than an exception in your terminal.

The instructive property is observability. 1. Each request is recorded with the route that actually served it, so a claim about which model answered is checkable after the fact rather than inferred. 2. Latency and token counts sit beside it, which makes a comparison between two providers an experiment a reader can run on their own workload. 3. No benchmark is published, and none is needed, because the tool ships the instrument instead of the result.

That is the right order. Most projects publish a number and withhold the harness that produced it.

Value here is derivative. This exists because the same work costs very different amounts depending on who serves it, so the demand curve belongs to other companies' pricing decisions rather than to the maintainer. There is no revenue, no entity, and a permissive licence, which means enormous adoption converts to nothing at all.

The structural risk is upstream terms rather than competition: a subscription vendor that decides proxying is out of policy removes the category with a paragraph. No acquirer buys a router; they close the gap it exploits. Position: use it while the spread is wide, and keep your configuration portable.

Licensing is zero and the meter belongs to the providers we already pay, so nothing new appears on the invoice. What interests me is the credential pool and key rotation, because it lets one team hold provider keys centrally rather than sixty engineers pasting them into config files, and that alone answers half of a security questionnaire. A documented Docker Compose deployment means my platform team can run it as a service.

There is still no SSO in front of the console and no audit trail attached to a person. Approved with conditions: it runs as an internal service, and keys never leave it.

MIT and the whole thing is configuration. Custom providers take an arbitrary base URL, so the model I host myself is a first-class entry rather than a special case, and my keys stay in a file I version. It speaks MCP as a client, which means the servers I already run come along for the ride no matter which agent is in front. There is no vendor account anywhere in the path.

Forking is realistic and mostly unnecessary, which is the best combination. This is the layer that makes every closed agent on my machine slightly more mine.