A model router should not feel like a slot machine. When a request goes to a different model, the developer and platform owner should be able to answer why. Policate makes the decision inspectable by keeping the scoring axes and candidate set visible.
Five axes, one decision
The router evaluates capability, cost, latency, reliability, and organization preference. Policies filter the candidate set first; routing then ranks the models that remain. A deep architectural review can favor capability while a bulk refactor can shift weight toward cost and latency.
That makes routing a product decision the company can tune, rather than a hidden heuristic that only appears in a bill at the end of the month.
A route is a scored decision, not a random pick
decision path| Task class | Primary | Fallback | Why this mix | Example / 1k requests | Illustrative saving |
|---|---|---|---|---|---|
| Repository search | Claude Haiku 4.5 | GPT-4o Mini | Fast retrieval and classification | $1.00 / 1k requests | 80–90% |
| Feature refactor | Claude Sonnet 4.6 | Claude Haiku 4.5 | Strong edits with a cheaper retry lane | $8.00 / 1k requests | 35–65% |
| Architecture review | Claude Opus 4.8 | Claude Sonnet 4.6 | Spend premium quality only where it matters | $24.00 / 1k requests | 10–35% |
Fallbacks are part of the contract
A good route is more than a winner. It includes an explainable fallback chain, region constraints, provider health, and an explicit reason a candidate was rejected. The same data powers the Gateway trace and the Direct runtime bundle, where the binary performs the local choice.
$ policate trace req_84f2