Model router
A traffic controller that sends each AI request to the cheapest model capable of doing that particular job.
See it
What it is
A model router sits in front of several models and chooses which one gets each request. The useful version does more than round-robin traffic: it checks what the task needs, such as vision, tool calling, context size, latency, or a quality tier, then sends it to the cheapest model that clears those requirements. A fallback can retry on another model when the first service is unavailable.
Reach for routing when one model is wasteful for your whole workload. Simple extraction, moderation, and classification may fit a small model, while difficult reasoning or image input earns the expensive one. Start with explicit rules you can inspect, log every decision, and compare cost and quality by route before training a learned classifier. OpenRouter made the hosted version familiar: one endpoint, one key, dozens of models behind it.
Gotcha: the router becomes part of model quality. A cheap misroute can look like a random model failure, and two models may disagree on prompt format, tool schemas, or supported parameters. Gate each route with the same evals, keep a manual override, and use fallbacks for transport or capacity failures, not as a loop that keeps shopping for a nicer answer.
Ask AI for it
Build a TypeScript model router in front of the OpenAI Responses API. Define a configuration table for each allowed model with input and output price, context limit, vision support, structured-output support, and an eval-backed quality tier. Classify each request from explicit metadata, reject models missing a required capability, then select the lowest estimated-cost candidate that meets the requested tier. Log the route, reason, estimated cost, latency, and outcome. Retry once on 429 or 5xx responses using the next eligible model, but never reroute a successful low-quality answer automatically.