unhardcoded vs Portkey.
Portkey is a polished hosted AI gateway. unhardcoded sends the routing rule with each call and writes a replayable trace. Both run on your own keys — the difference is where the model decision lives.
Where the model decision lives.
A fair, side-by-side read. Cost and percentage figures elsewhere on the page are illustrative.
| unhardcoded | Portkey | |
|---|---|---|
| Where the route is decided | Sent with the call (policy_ir) | Server config, conditional routing |
| Provider keys & billing | Your keys, your pricing | Your keys, your pricing |
| Choosing a model | Cheapest that clears your rules | Config strategy: load-balance, fallback |
| Quality floor | Enforced per call, fails loud | Content guardrails, no quality-score gate |
| Decision audit | Replayable by fingerprint | Logs & analytics |
| Open & self-host | Open policy_ir, self-host free | Open-source gateway, self-host free |
For the full landscape — gateways, observability, evals, and workflow builders — see where the model decision lives.
A mature hosted AI gateway.
Portkey gives you a unified API across providers, observability dashboards, guardrails, and caching — sat in front of your own keys. Its config object drives routing strategies like load balancing and fallbacks, so a platform team can manage provider traffic from one place.
The logging and analytics are genuinely useful: you get request-level visibility, latency and cost rollups, and a clear picture of what your application is sending where. If you want a polished gateway you don't have to operate yourself, it's a credible, well-built tool.
The rule travels with the request.
In Portkey the route lives in server config — one routing strategy shared across traffic, changed by editing that config. unhardcoded sends the rule with the call: your backend generates a policy_ir from the tenant, tier, and context in front of it, and the router picks the cheapest model that clears it. The quality floor is an explicit rule, not magic — if nothing passes, the request fails loud instead of quietly downgrading.
The other axis is the audit. Portkey records what happened in logs; unhardcoded encodes the decision itself as a portable, replayable object, keyed to a fingerprint you can replay months later. The trace below is that object.
Routing by requirement, not a hardcoded model string — see how it cuts spend in cut model spend.
You want a polished hosted gateway.
Choose Portkey when you want a hosted gateway with strong observability and a broad, config-driven routing strategy — load balancing, fallbacks, caching, and guardrails managed centrally. If the same routing default fits most of your traffic and your main need is visibility across providers, it does that job well.
Each call carries its own rules.
Choose unhardcoded when each call should carry rules that differ from the default — different tenants, tiers, regions, or quality floors deciding per request — and you need to prove which rule chose the model. The decision is a native policy object, not a config setting, and the trace replays it on demand. See it applied to cutting model spend.
They can sit side by side.
These aren't mutually exclusive. Run unhardcoded for the decision under a gateway, or keep Portkey-style observability alongside unhardcoded's replayable traces. One picks and proves the per-request model; the other gives you the operational dashboards. The model decision stays a portable policy either way.
Make the model decision a policy you can prove.
Keep your gateway for traffic if you like it. Let unhardcoded decide the model per request — cheapest that clears your rules, over your keys — and write a replayable trace of every call.