Where the model decision lives.
The important question is not only which models are available. It is where the decision lives — who chooses the model, on whose keys, and whether you can see why. New here? The policy travels with the request. unhardcoded routes to the cheapest model that passes your rules, over your own provider keys, and records the decision in a trace.
The model choice has to live somewhere.
Most comparisons argue over which models a tool can reach. The axis that actually matters is where the choice is made, on whose keys it runs, and whether you can replay why.
In your app code
The model name and fallback order are hardcoded in the application. Every change — a new model, a cost rule, a per-tenant exception — becomes engineering work, a deploy, and a guess about what shipped.
- Decision buried in branches
- Every rule change is a deploy
- No record of why a model ran
Inside someone else's conductor
You call one endpoint and trust the host to pick. Convenient — but the decision lives in a system you don't control. You may not know which model ran, why it ran, or what it cost you, and inference is often billed through their account.
- Decision is server-side and opaque
- Often their keys, their pricing
- Logs of what, rarely why
In explicit policy
The decision is a policy you send with the request, executed at runtime over your own provider keys, and recorded in the trace. The cheapest model that passes your rules wins — and the trace shows which were accepted, rejected, or skipped, and why.
- Sent with the call, your keys
- Lowest-cost passing model wins
- Replayable by fingerprint
The same axis, one row at a time.
The three places the decision can live, on the questions that decide who is actually in control of a single call. These are design tradeoffs, not knocks; any of these can be the right choice. Cost figures elsewhere on the site are illustrative.
| In app code | Closed orchestrator | In policy (unhardcoded) | |
|---|---|---|---|
| Where the decision is made | Hardcoded in the app | Server-side, host's | Sent with the call (policy_ir) |
| Whose keys it runs on | Your keys | Often the host's account | Your keys, your pricing |
| How the model is chosen | Whatever you wired | The host decides | Cheapest that passes your rules |
| Quality floor | Up to you to enforce | Whatever the host applies | Enforced per call, fails loud |
| Can you replay why | Build it yourself | Logs of what, rarely why | Replayable by fingerprint |
| Open & self-host | It's your code | Closed | Open policy_ir, self-host free |
The quality floor is a catalog field, bench_intelligence, a 0..1 score with a floor like ge 0.5 (top models ≈ 0.6) — explicit, inspectable, and yours to override. See how the floor cuts spend or how a policy routes one call.
Most of these tools are complementary.
You can run a gateway, an eval tool, and a workflow builder alongside unhardcoded. They move traffic, measure models, and build flows. unhardcoded answers a different question: where the model decision lives — in explicit policy, not app code or someone else's conductor.
Want the long form? Read unhardcoded vs Portkey, LiteLLM & OpenRouter on the blog.
Move the decision into policy you control.
Point your existing SDK at one endpoint, send a policy with the call, and keep your provider keys. The lowest-cost model that clears your rules wins, and every decision leaves a trace you can replay.