Product Use cases Compare Pricing Docs Blog
Read the docs Join the waitlist

Compare · unhardcoded vs OpenRouter

compare

unhardcoded vs OpenRouter.

OpenRouter is one key to a huge model catalog. unhardcoded is the model decision layer — it routes over your own provider keys by a policy you send with each call, and proves the choice with a trace.

at a glance

Access to many models, or an enforced model decision.

OpenRouter is about breadth of access through one account. unhardcoded is about where the routing decision lives, whose keys it runs on, and whether you can audit it later.

unhardcodedOpenRouter
Where the route is decidedSent with the call (policy_ir)Provider preferences per request, OpenRouter picks the route
Provider keys & billingYour keys, your pricingOpenRouter's own provider accounts, billed for tokens
Choosing a modelCheapest that clears your rulesOne key to a large catalog, optional cheapest-route optimization
Quality floorEnforced per call, fails loudNot enforced — a cheap route can land beneath your bar
Decision auditReplayable by fingerprintGeneration logs, but the routing decision is not an open object
Open & self-hostOpen policy_ir, self-host freeClosed platform

Figures and routing outcomes elsewhere on this page are illustrative. See the full landscape on the compare hub.

what OpenRouter is good at

One key to a very wide catalog.

OpenRouter is convenience. One account and one API key give you access to a large catalog of models across providers, with automatic provider selection and provider preferences per request. For prototyping, breadth of access, and one-key simplicity, it is genuinely hard to beat — you try a new model by changing a string.

One account, many providers

A single key reaches a broad catalog spanning multiple providers — no per-provider onboarding to start experimenting.

Automatic provider selection

OpenRouter picks a route for you, and you can express provider preferences per request when you want a say.

Breadth for prototyping

Swap among many models behind one endpoint while you are still figuring out which one your workload needs.

where unhardcoded is different

Your keys, an enforced floor, a replayable decision.

The axis isn't access — it's billing, control, and proof. OpenRouter routes through its own provider accounts and bills you for tokens, typically with a markup — you are not using your own provider keys or your own pricing. unhardcoded runs over your own provider keys and provider pricing.

Keys & billing

Inference runs on your provider accounts at your negotiated pricing. unhardcoded prices per run, not per token, and never resells inference.

An enforced quality floor

OpenRouter's cheapest optimization picks an inexpensive route but does not enforce a quality floor you defined — a request can land beneath your bar. unhardcoded filters on the bench_intelligence score (surfaced 0–100), fails loud when nothing clears it, and never silently downgrades.

A decision you can audit

OpenRouter offers generation logs, but it is closed and the routing decision is not an open object you control. unhardcoded writes a trace — candidates, the rejecting rule, the winner, fallback — replayable by fingerprint pol_8f41c2 (sigma-pol/v1).

The decision follows the four verbs filter → rank → select → fallback, and you can preview it with no inference: GET /x/fields and POST /x/rank. See how spend drops on cut model spend.

when to choose OpenRouter

Widest catalog behind one key.

Reach for OpenRouter when one-key access to the widest catalog is the priority, you are comfortable with token billing through its accounts, and you are prototyping or want breadth without wiring up each provider yourself.

when to choose unhardcoded

Your keys, an enforced floor, a replayable decision.

Reach for unhardcoded when the app needs to run on your own provider keys and pricing, enforce a quality floor that fails loud rather than quietly picking a worse model, and prove which model answered and why — replayable months later from the policy_ir that was sent.

trace · req_8f41c2200 OK
selectedgemini-3.5-flash
reasonfloor ≥ 0.9 cleared, tools ✓, cheapest survivor
rejecteddeepseek-v4-flash · below bench_intelligence floor
cost$0.018 · ↓71% vs gpt-5.5 baseline · illustrative
policyon your keys · fingerprint pol_8f41c2 · sigma-pol/v1
use them together

Breadth to explore, policy to decide.

They aren't mutually exclusive. Use OpenRouter's one-key breadth to discover which models suit a workload, then express the production decision as a policy over your own keys — enforced and traced. unhardcoded decides which model clears your rules; you keep whatever supply you reach it through.

See where the model decision lives across the field on the compare hub, or watch spend drop on cut model spend.

Keep the access. Own the decision.

Route over your own provider keys, enforce the quality floor, and replay every model decision from its fingerprint. Join the waitlist and we'll get you set up.

No SDK rewriteYour provider keysEvery request traced