The problem
Model names don't belong in your application.
When model names are written through an application, the choice of model becomes an application concern — and every provider change, price shift, or new release turns into edits scattered across the codebase. Which model answers a given request is a decision that should live in one place, not in a hundred call sites.
What an application should express is the capability a request needs. Which model delivers it is infrastructure.
How it works
Ask for a capability; the router picks the model.
The router lets a request ask for a capability — fast reasoning, long context, structured output — and picks the model that serves it, across providers, behind a single surface. Swapping or upgrading a model is a routing decision, not an application change, and per-tenant overrides let different customers be served by different models without forking the code.
Because selection is by capability, the router keeps a product current: when a new model improves a capability, requests for that capability move to it, and the application inherits the improvement without a release.
- Requests declare a capability — fast reasoning, long context, and so on — not a specific model
- The router selects the model that serves it best, and can move between providers
- No application code changes when a model is swapped or upgraded
- Per-tenant overrides, so different customers can be served differently
- When a better model ships for a capability, the router adopts it
Stay on the best model, without the rewrites.
The router is one of the components our Services team builds AI-native products on. Tell us what you're building.