Where the model decision lives.
The real question isn't who can pass JSON with a request — it's whether the model decision itself is a native, replayable policy object over live model supply.
Most of these tools solve a different problem.
Each solves a different problem, and you may run several at once. The grouping below is by what each one is for — gateways move traffic, eval tools measure models, workflow tools build flows. unhardcoded sits at the layer where a single call's model is chosen and proven.
Routes and observes traffic through a hosted gateway, configured server-side. unhardcoded moves the choice into a policy you send with each call — and writes a replayable trace of why a model won.
An open-source proxy where you wire the model and fallback order in config. We're open-core too — but the open part is the decision language (policy_ir), not just the gateway that forwards the call.
One API to many models; it bills inference through its own account and pricing layer. unhardcoded runs over your own provider keys and provider pricing, and the decision is a policy you can audit — not just a route.
Logs, traces, and analytics for the calls you already make. It tells you what happened; a policy_ir trace records why this model — which candidates were filtered, by which rule, and the fingerprint to replay it.
Measures model quality offline and in production. That's complementary: bring your own scores in as the bench_intelligence field unhardcoded filters on, so the quality floor is yours, not ours.
They build the multi-step graph — the orchestration, tools, and state. unhardcoded decides which model executes each node by policy. They build the graph; we route every step underneath them.
Six questions about the model decision.
unhardcoded next to three gateways on the axes that decide where a model choice lives. Each is a credible tool; these are design tradeoffs, not knocks. Cost and percentage figures elsewhere on the site are illustrative.
| unhardcoded | Portkey | LiteLLM | OpenRouter | |
|---|---|---|---|---|
| Where the route is decided | Sent with the call (policy_ir) | Server config | Proxy config (YAML) | Provider preferences |
| Provider keys & billing | Your keys, your pricing | Your keys | Your keys, self-host | Its own account & pricing |
| Choosing a model | Cheapest that clears your rules | Manual fallbacks | You wire the order | Cheapest route, may miss floor |
| Quality floor | Enforced per call, fails loud | Config level | Config level | Provider-controlled |
| Decision audit | Replayable by fingerprint | Logs & analytics | Build it yourself | Generation logs |
| Open & self-host | Open policy_ir, self-host free | Proprietary config | Open-source proxy | Closed |
The quality floor is a catalog field, bench_intelligence, a 0..1 score (top models ≈ 0.6) — explicit, inspectable, and yours to override. See how the floor cuts spend or how a policy routes one call.
Pick the tool that matches the job.
Use gateways to manage traffic. Use eval tools to measure models. Use workflow tools to build flows. Use unhardcoded when the app needs to express the model decision as policy at runtime — and prove it with a trace.
Want the long form? Read unhardcoded vs Portkey, LiteLLM & OpenRouter on the blog.
Make the model decision a policy you can prove.
Send the rule with the call, route to the cheapest model that clears your floor over your own keys, and replay every decision by fingerprint. That's the layer the gateways, eval tools, and builders leave open.