unhardcoded vs LiteLLM.
LiteLLM is the open-source workhorse — a proxy you run, configured in YAML. unhardcoded keeps the open, self-host property but moves the model decision into a policy sent with each call. Open gateway versus open decision language.
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 what is open: the proxy you operate, or the decision 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 | Routing order you configure |
| Quality floor | Enforced per call, fails loud | Build it on logs |
| Decision audit | Replayable by fingerprint | Your logs / observability stack |
| 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.
LiteLLM is the open-source workhorse.
A proxy plus SDK that normalizes 100+ providers behind a single OpenAI-compatible interface, with routing, fallbacks, budgets, and rate limits all configurable in YAML. It is open source, self-hostable, and runs entirely over your keys — full control, no third party in the request path.
One interface, many providers
Normalizes 100+ providers behind an OpenAI-compatible API, so your app talks to one endpoint instead of a dozen SDKs.
Config you control
Routing order, fallbacks, budgets, and rate limits live in YAML you own. Nothing is hidden behind a vendor dashboard.
Self-hosted, your keys
Run it yourself over your own provider keys. The request path is yours end to end — full control, no middleman.
The route is an object, not a config.
With LiteLLM, you run and operate the proxy; the routing order and fallbacks are wired in config, out of band from any single request. There is no built-in per-decision audit of why a model was chosen against a stated floor — you build that on logs. unhardcoded keeps the open-and-self-hostable property but moves the decision into an open policy_ir sent with the call: the route is an object the request carries, not a proxy config you maintain.
LiteLLM open gateway
You operate the proxy and wire the routing order. The fallback chain is YAML you maintain; the request just hits the endpoint. To answer "why this model?", you reconstruct it from logs.
unhardcoded open decision language
Your backend generates a policy_ir and sends it 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 honest split is about who operates the routing and where the decision lives.
Choose LiteLLM when
You want an open, self-hosted proxy and are happy to operate it and wire the routing yourself. You value owning the request path and configuring fallbacks in YAML you control.
Choose unhardcoded when
You want the decision as a portable, auditable policy object — without operating routing infra. The route travels with the request, enforces a floor per call, and replays from a fingerprint. See where that pays off in cut model spend.
They can sit in the same stack.
This is not either-or. unhardcoded can run as the decision layer that expresses the route as policy and proves it with a trace, while you keep an open proxy where it fits. Both are 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.
unhardcoded expresses the model decision as an open policy sent with the call, picks the cheapest model that clears your floor over your own keys, and writes a replayable trace. Join the waitlist to try it.