Stop hardcoding model decisions: the hidden cost (and the fix)
Hardcoded model names quietly cost you money, agility, and auditability. Here is why — and how policy-based routing fixes it without an app rewrite.
The Policy Layer
Clear, practical writing on policy-based LLM routing: send the rules with the call, route to the cheapest model that meets them, keep your provider keys, and audit every decision.
This is our launch library — a foundational set published together, grouped below by where to start.
Start here
New to policy-based routing? Read these in order.What is an LLM policy router?
An LLM policy router enforces your rules on every model call — routing to the cheapest model that passes, over your own provider keys, with an auditable trace of every decision.
Send your first policy with the call: a 5-minute quickstart
Point the OpenAI SDK at one endpoint, build a policy_ir in your backend, send it with the call, and route to the cheapest model that passes your rules. Step by step.
Go deeper
The mechanism, the full guide, and the long-term vision.What is a policy_ir? The anatomy of a routing decision
A policy_ir is a runtime object — a JSON term your app sends with each call. Filter, rank, select, mutate, fallback: the five positions that decide which model runs.
Policy-based LLM routing: the complete guide
A complete guide to policy-based LLM routing — send a policy with each call, route to the cheapest model that meets your rules, keep your provider keys, and audit every decision.
The runtime policy layer: where LLM infrastructure is going
Our long-term vision: every LLM call carries its own policy. The runtime policy layer makes model decisions data — portable, auditable, and enforced over your keys.
Compare
How it differs from gateways and proxies.unhardcoded vs Portkey vs LiteLLM vs OpenRouter
How unhardcoded compares to Portkey, LiteLLM, and OpenRouter — where routing lives, your keys vs token resale, per-run pricing, open IR, and auditable traces.