unhardcoded vs LiteLLM.
It comes down to where the routing decision lives. LiteLLM is an open proxy you run, with the routing wired in your config or SDK. unhardcoded keeps the open, self-host property but moves the decision into a policy sent with the call and recorded in a trace.
Same open spirit, a different open object.
Both run entirely over your own provider keys, with no third party in the request path. The difference is where the decision lives: in a proxy config you operate, or in a policy the request carries.
| unhardcoded | LiteLLM | |
|---|---|---|
| Where the route is decided | Sent with the call (policy_ir) | Wired in proxy config (YAML) |
| Provider keys & billing | Your keys, your pricing | Your keys, your pricing |
| Choosing a model | Cheapest that clears your rules | Config routing: cost, latency, order |
| Quality floor | Enforced per call, fails loud | No native quality gate |
| Decision audit | Replayable by fingerprint | Built-in logging, no per-decision replay |
| Open & self-host | Open policy_ir, self-host free | Open proxy, self-host free |
Figures and cells throughout this page are illustrative. See the full grid on the compare hub.
A config you operate, or a policy the request carries.
LiteLLM is the open-source workhorse: one OpenAI-compatible endpoint over your keys, with routing and fallbacks you wire in config. unhardcoded keeps that open, self-host property but moves the route out of config and into a policy sent with the call — so every decision is enforced per request and recorded.
LiteLLM open gateway
You operate the proxy and wire the routing order. The fallback chain is config you maintain, out of band from any single request. To answer "why this model?", you reconstruct it from logs.
unhardcoded open decision language
Your backend sends a policy_ir with the call. The router runs filter → rank → select → fallback against a live catalog, picks the cheapest model that clears your floor, and writes a replayable trace.
The floor is the catalog field bench_intelligence, surfaced as a 0..1 score — inspect it with GET /x/fields or preview a pick with POST /x/rank before production.
When LiteLLM, and when unhardcoded.
They solve adjacent problems. The split is about who operates the routing, and whether you need the decision itself to be auditable.
Choose LiteLLM when
You want an open, self-hosted proxy and are happy to operate it and wire the routing yourself. Owning the request path and configuring fallbacks by hand is the point.
Choose unhardcoded when
You want the decision as a portable, auditable policy — without operating routing infra — and a trace you can replay when someone asks why a model was used. See where that pays off in cut model spend.
They can sit in the same stack.
This is not either-or. unhardcoded can be the decision layer while you keep an open proxy where it fits — both bring-your-own-keys, so neither stands between you and your providers.
More side-by-sides on the compare hub · economics on pricing.
Keep the proxy if you like it. Make the decision auditable.
Move the route out of config and into a policy sent with the call — over your own keys, traced every time. Join the waitlist to try it.