Portkey alternative: every governance feature on every tier, free for life

The short answer: Portkey and nRouter ship broadly the same governance surface, and this is the closest comparison in the cluster. The difference is where that surface sits. Portkey distributes guardrails, evals, prompt management and budgets across plan tiers; nRouter puts all of them on every plan and varies only the platform fee.

Most comparison posts are about a capability the other product lacks. This one is not, and pretending otherwise would waste your afternoon. Portkey is a mature gateway with a real governance feature set, an open-source gateway you can run yourself, and a longer compliance track record than ours. If you are looking for a reason to believe Portkey cannot do the thing you need, you will probably not find it here.

The argument is narrower and it is about packaging. When a control is plan-dependent, buying it is not the only cost of using it — and that second cost is the one that does not appear on anybody's pricing page.

Side-by-side feature gating

Portkey's rows read "available, plan-dependent" rather than "missing" on purpose. They ship these features. The claim in this post is about which plan they sit on and what that does to how you use them — not about absence.

Portkey is a trademark of Portkey AI. nRouter is not affiliated with or endorsed by Portkey. All claims are sourced from their public pricing or documentation on the dates linked below; if any have changed, email hello@nrouter.ai and we will update.

What "plan-dependent" costs beyond the price

The subscription line is the visible cost and usually the smaller one. Four effects show up wherever a control is tier-gated, in any product, ours included if we ever did it:

It converts an experiment into a procurement. Wiring a jailbreak check on one endpoint to see whether it fires on real traffic is a twenty-minute task. Wiring it after an upgrade approval is a two-week task, and most of the two weeks is spent justifying a control nobody can yet measure the value of, because measuring it required the control. Teams resolve that loop by not running the experiment.

It pushes governance behind the launch instead of into it. The natural time to add a per-team ceiling is the week you give a second team a key. If that week is also a plan-change week, the ceiling gets deferred "until we upgrade" — and the upgrade happens after the incident that would have justified it.

It makes the trial unrepresentative. Evaluating a gateway on a plan that excludes half the governance surface tells you about routing, not about the product you would be operating. Whatever you learn in that trial, you re-learn after the purchase.

It makes the pricing conversation a feature conversation. Renewal stops being about volume and becomes about which controls you keep. That is a conversation nobody enjoys on either side.

None of this makes tiering wrong — it is the standard way to build a software business, and the alternative has to pay for itself some other way. Ours does, and that argument lives at every feature on every plan: we charge a fee, not a gate rather than being restated here: the short version is that the fee is not where the long-term margin comes from, so gating features to protect it would be protecting the wrong thing.

What Portkey does better

Three places Portkey is genuinely ahead of us, and the first two are the reasons most of our lost deals to them were correctly lost.

1. You can run their gateway yourself. Portkey publishes an open-source gateway (github.com/Portkey-AI/gateway) and documents self-hosted and hybrid deployments on portkey.ai/docs. If your compliance posture says customer prompts never leave your VPC, that is a deployment shape nRouter simply does not have — we are a hosted product and we are not planning a self-host SKU. Our reasoning is in managed LLM gateway vs self-hosted: why we carry the pager, but reasoning is not a substitute for a deployment target you are required to have.
2. A longer compliance track record. Portkey publishes its security and compliance posture on its own site; ours is honest and shorter — SOC 2 Type II is in progress, not certified — and we say so on /security and /trust rather than implying otherwise. If your procurement gate is a completed attestation report dated before your contract starts, we will not clear it this quarter and Portkey may. The control-by-control view of what a gateway has to prove is in a SOC 2 checklist for LLM gateways.
3. Breadth of integrations and a longer catalogue tail. Portkey documents 250+ models and a wide framework and observability-sink integration surface (portkey.ai/docs). nRouter serves a smaller list — every entry priced, because an unpriced call is reported as unpriced and never as $0 — and our framework coverage is the mainstream set (/docs/frameworks). Check /models against your production shortlist before you plan anything; a gateway that cannot serve your model is not cheaper, it is unusable.

Read that as the honest boundary of the argument. This post is about fee shape, about governance being ungated, and about how many vendors sit on your invoice — not about Portkey being a weak gateway. It is not.

The fee shape and the crossover

There is one nRouter number to put next to a Portkey plan: the platform fee. 4% on pay-as-you-go, 0% on Pro at $50/mo or $500/yr, charged on top of provider spend. No governance feature sits behind it, which is why it is the only number the comparison needs; the full plan table is on /pricing.

The crossover is one division. Pay-as-you-go costs 4% of provider spend, so the monthly Pro subscription pays for itself when 4% of monthly spend clears $50 — that is $50 ÷ 0.04 ≈ $1,250/mo of provider spend. On the annual plan ($500/yr, about $41.67/mo) the same division gives ≈ $1,042/mo. Below the crossover, pay-as-you-go is cheaper. Above it, the flat fee wins and the percentage stops applying at all.

We are not publishing a comparative dollar figure against Portkey, because their pricing varies by plan and a stale quote in our favour is worse than no quote. Do it yourself with two inputs: the Portkey plan you would need for the controls you actually want, and 4% of your provider spend.

The two error codes a ceiling returns

Governance is only as good as its failure behaviour, so here is ours in full rather than as an adjective.

Budget ceilings exist at four scopes — organisation, team, user and individual key — and they do not all fail the same way. When an organisation, team or user ceiling is exhausted, the request is refused before it reaches a provider:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{ "error": { "code": "budget_exceeded" } }

When an individual key's own ceiling is the one that trips, it is a rate-shaped refusal rather than a payment-shaped one:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json

{ "error": { "code": "key_budget_exceeded" } }

Neither code is invented for the occasion; both are being used for what HTTP already says they mean. 402 Payment Required is RFC 9110 §15.5.3, reserved for exactly the payment case, and 429 Too Many Requests is RFC 6585 §4, defined around a condition that clears with time. Picking the codes that way is what lets an off-the-shelf client library do something sensible with each one before you have written any handling at all.

The distinction is not cosmetic and your client should not collapse it. A 402 means the tenant is out of budget and retrying will not help — the fix is a human decision about money. A 429 with key_budget_exceeded means this particular key is capped while the organisation still has funds, which is exactly what you want when one reselling customer's job goes into a loop and four other customers must keep working. Retrying the 402 burns your retry budget on a decision no client can make.

Which ceiling catches which failure is worked through in four budget ceilings for an LLM gateway, and the client-side handling in handling 429 and 402. Per-customer key issuance is in virtual keys vs the master key.

All four ceilings are on every plan. That is the whole argument of this post expressed as a status code: the thing that stops a runaway spend is not something you can be one tier away from having.

Switch cost: one base URL, one API key

Both products are OpenAI-compatible, so the client change is two lines:

  const client = new OpenAI({
-   baseURL: 'https://api.portkey.ai/v1',
-   apiKey: process.env.PORTKEY_API_KEY,
+   baseURL: 'https://api.nrouter.ai/v1',
+   apiKey: process.env.NROUTER_API_KEY,
  });

No SDK rewrite and no schema migration. Message arrays, tool calls and streaming consumers are unchanged. The honest caveat is that the client change is the easy part and the policy move is the real work — the next section is about that.

Migrating Portkey configuration

Two of those rows deserve more than a table cell. Guardrail definitions do not port mechanically — the field shapes are similar enough that most teams script the bulk of a prompt-library conversion in an afternoon, but a guardrail is a policy and a policy that was reviewed against one schema needs reviewing against another. Budget the review, not just the conversion.

And retiring provider keys is a behavioural change, not a cleanup. If your security model currently rests on holding those credentials yourself, read why we do not support BYOK before the migration meeting rather than during it. It is the single most common objection at this step and it deserves a considered answer, not a shrug.

When nRouter is the right choice

Two or more should be true:

• You are on, or shopping, a Portkey plan primarily to unlock governance features rather than for volume.
• Your provider spend is near or above the crossover above, where a percentage fee and a flat fee change places.
• You want every control available during the trial, so what you evaluate is what you would operate.
• You resell an AI feature and need per-customer keys with their own ceilings and their own failure code.
• Managing provider credentials yourself is overhead you would rather delete than defend.

When to stay on Portkey

Not a straw man. These are the buyer-states where we would tell you to stay put, and we would rather say it here than three weeks into a migration:

• Self-host or in-VPC is a hard requirement. Portkey has that shape and we do not. Nothing else on this page outweighs it.
• You need a completed SOC 2 Type II report today. Ours is in progress. If your security review will not accept "in progress" plus a controls walkthrough, the answer is no for now, and you should know that on the first call.
• A model you depend on is not in our catalogue. Check /models first, not last.
• You are deep in Portkey's config-as-code. If your guardrails, fallback chains and prompt library are versioned in your repo against their schema and reviewed by people who know it, the migration is not one afternoon — it is one afternoon plus a re-review of every policy. That can still be worth it above the crossover, but price it honestly.
• Your spend is a few hundred dollars a month and routing is all you need. The fee delta is below noise at that scale, and the governance surface you would be switching for is one you have not started using.

Try it

Pay as you go starts at $5. Add a card, load your first $5, and a $10 first-purchase bonus lands with it — $15 in credits, once per organisation. Every control in the table above is live on that first $5, which is the point: the trial is the product.

→ Get started at nrouter.ai/signup

If you would rather see the side-by-side before signing up, the dedicated comparison page is at /vs/portkey — same data as the table above, with structured markup so answer engines can cite it directly.

Questions? Drop into the public nRouter Slack — #support for migration questions, #feature-requests if there is a Portkey capability you want next.

See also

• nRouter vs Portkey — the high-intent comparison page, kept in lockstep with the table above.
• Every Feature on Every Plan: We Charge a Fee, Not a Gate — the full answer to how a gateway that gates nothing pays for itself.
• Managed LLM Gateway vs Self-Hosted: Why We Carry the Pager — the reasoning behind the one deployment shape Portkey has and we do not.
• Four budget ceilings for an LLM gateway — which ceiling catches which runaway, and what each returns.
• A SOC 2 checklist for LLM gateways — the control-by-control view behind the compliance row.
• Helicone alternative — the adjacent comparison for teams shortlisting observability-first gateways alongside this one.
• LLM gateway buyer's guide 2026 — the taxonomy to place both products in before you shortlist.

Sources

All Portkey and provider claims above are sourced from each vendor's public pricing or documentation page, and the standards citations from the RFCs themselves. Every link below was re-checked on 2026-08-23. If a vendor updates their tiers and we have not refreshed, email hello@nrouter.ai and we will re-audit within one business day.

• Portkey pricing: portkey.ai/pricing
• Portkey docs: portkey.ai/docs
• Portkey guardrails: portkey.ai/docs/product/guardrails
• Portkey prompt library: portkey.ai/docs/product/prompt-library
• Portkey open-source gateway: github.com/Portkey-AI/gateway
• RFC 9110 §15.5.3, 402 Payment Required: datatracker.ietf.org/doc/html/rfc9110 — the HTTP semantics an organisation, team or user ceiling is using.
• RFC 6585 §4, 429 Too Many Requests: datatracker.ietf.org/doc/html/rfc6585 — the semantics a per-key ceiling is using, and the retry expectation that comes with them.
• nRouter served models: nrouter.ai/models
• nRouter pricing: nrouter.ai/pricing

Portkey is a trademark of its owner. nRouter is not affiliated with or endorsed by Portkey.