Product Use cases Compare Pricing Docs Blog
Read the docs Join the waitlist
compare · unhardcoded vs Portkey

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.

at a glance

Where the model decision lives.

A fair, side-by-side read. Cost and percentage figures elsewhere on the page are illustrative.

unhardcodedPortkey
Where the route is decidedSent with the call (policy_ir)Read from a server-side config object
Provider keys & billingYour keys, your pricingYour keys, your pricing
Choosing a modelCheapest that clears your rulesRouting strategy in config — load balancing, fallbacks
Quality floorEnforced per call, fails loudGuardrails on input/output; not a per-call selection gate
Decision auditReplayable by fingerprintLogs and analytics of what happened
Open & self-hostOpen policy_ir, self-host freeHosted gateway (open-source gateway available)

For the full landscape — gateways, observability, evals, and workflow builders — see where the model decision lives.

what Portkey is good at

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.

where unhardcoded is different

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 per-request rule with the call: your backend generates a policy_ir from the tenant, tier, and context in front of it, and the router runs filter → rank → select → fallback over the live catalog to pick the cheapest model that passes.

The quality floor is explicit, not magic — a catalog field, bench_intelligence, a 0..1 score enforced as ["cmp","bench_intelligence","ge",0.5]. If nothing clears it, the request fails loud instead of quietly downgrading. You can preview which models pass and which rule rejected the rest with GET /x/fields and POST /x/rank — no inference spent.

The other axis is the audit. Portkey records what happened in logs; unhardcoded encodes the per-request decision as a portable, replayable object. Every run writes a trace — candidates considered, which rule rejected each, the winner and why, the fallback path, cost vs baseline — keyed to a fingerprint (pol_8f41c2, sigma-pol/v1) you can replay months later.

trace · req_8f41c2 200 OK
selectedgemini-3.5-flash
reasontools ✓, score 0.54 ≥ floor, cheapest survivor
rejecteddeepseek-v4-flash · score 0.42 < floor 0.5
cost$0.018 · ↓71% vs gpt-5.5 baseline (illustrative)
policyfingerprint pol_8f41c2 · sigma-pol/v1

Routing by requirement, not a hardcoded model string — see how it cuts spend in cut model spend.

when to choose Portkey

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.

when to choose unhardcoded

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.

use them together

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.

See the full comparison landscape

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.

No SDK rewriteYour provider keysOpen policy_irEvery run traced