model: "auto" uses intent-based routing. Routor analyzes your prompt’s category, then selects the most suitable model for that category - balancing cost savings against near-frontier model quality - and returns the result. Models are matched to prompts by category, so each type of task goes to a model actually built for it.
Total routing overhead: under 10ms.
Intent-Based Routing
Routor reads what you’re actually asking for and matches it to the category of model built for that job - a coding task is matched against coding-strong models, a creative-writing task against writing-strong models, a quick factual question against fast, cheap models, and so on. Within that category, it picks the model that gives you the best combination of cost savings and quality close to the frontier - not just the cheapest option, and not the most expensive one by default either. No extra API call is made to figure this out. No credits are consumed for routing itself. The whole decision adds a few milliseconds before the model even sees your prompt.Automatic Failover
If the selected model fails, Routor automatically tries the next best model for that category - escalating all the way to a premium reference model if needed. Your request does not fail just because one provider had a bad moment. See Fallback & Auto-Failover for the full behavior.Three Routing Profiles
What “auto” Means
When you setmodel: "auto", Routor owns the model decision completely.
You can constrain it if needed:
"routor_profile": "direct" with a model ID. See Chat Completions for the full parameter list.
Routing Metadata
Every response includes aroutor object with the model that was used, its category, and the savings vs. a premium-model baseline. X-Request-Id is always sent as a header, and the full set of X-Routor-* headers is included when your deployment has DEBUG_ROUTING=1 set. Call the Debug Endpoint to see the routing decision for any prompt on demand.