No BYOK: One nRouter Key Instead of Ten Provider Keys

The position: nRouter does not accept your provider keys. You get one sk-nrouter-… key and a credit balance; we hold and manage every provider account behind it. Bring-your-own-key is not a feature we are missing — it is a model we deliberately rejected.

BYOK is the default assumption for an LLM gateway and it has a genuinely strong case, so this post makes that case properly before answering it, then states what our choice costs you and names the teams who should pick BYOK anyway.

The position

Two shapes, side by side:

BYOK        your app → gateway → (your OpenAI key, your Anthropic key,
                                  your Bedrock role, your Vertex service account…)
                                  ↑ you own every one of these

nRouter     your app → one sk-nrouter-… key → every provider in the catalog
                                  ↑ we own every one of these

The difference is not cosmetic. In the BYOK shape the gateway is a router with opinions; the provider bills you directly, and the gateway can only ever observe what you spend. In our shape the gateway is the billing surface, which is what makes one bill, one balance and one reconcilable ledger possible at all.

What we were asked for instead

Put the ask at full strength. BYOK is not a naive request:

1. "We already have committed spend." A team with an enterprise agreement or prepaid capacity at a provider has money on the table. BYOK draws it down; our model does not. This is the single best argument against us and it is unanswerable on its own terms.
2. "We already have the vendor relationship." Legal has reviewed the provider's data-processing terms. Security has approved the account. Adding a second commercial entity in the data path restarts a review that already finished once.
3. "We want the provider's rate, not a reseller's." With BYOK you know exactly what the model costs because the provider invoices you. Any intermediary is a place a margin could hide.
4. "We do not want spend concentration." If a gateway holds the keys and the gateway goes away, your access goes with it. Keeping your own accounts is a continuity control.

Point 3 deserves a direct answer rather than a rebuttal, and it gets one below: we charge a platform fee on top and take no margin on the model rate, which is a checkable arithmetic claim, not a promise.

What that would cost you

Here is what "you keep your keys" actually hands you, per provider, forever:

The last row is the one that hurts most and gets noticed last. A provider bill tells you that your organization spent an amount. It does not tell you that the support-summarization feature spent most of it, or that one customer's agent loop accounts for a third. Rebuilding that attribution on top of N invoices is the work described in attributing spend by team, customer and feature and in multi-agent cost tracking — and with BYOK it is your work, every month, forever.

BYOK does not remove complexity. It relocates it to you and calls the relocation freedom.

The reconciliation problem, worked

Consider a modest setup: four providers, three teams, one month.

• The provider view: four invoices, four totals, four billing cycles that do not align, at least one denominated in a currency you did not choose. Nothing in any of them mentions a team.
• The team view: you need three numbers — one per team — that sum to the four totals, with each request attributable to the team that made it.

To get from the first to the second you need a per-request record carrying the model, the token counts, the provider's rate at the time of the call, and the authenticated identity of the caller. That record is exactly what a gateway produces. What it cannot produce under BYOK is a guarantee that its record reconciles to the invoice, because the invoice is generated somewhere the gateway does not sit.

With one balance the question collapses. There is one number, one ledger, and every row in the ledger names the team, the key and the model that caused it — how to read it. Reconciliation stops being a monthly project and becomes a query.

What we do instead

The mechanism, and the surface that implements each part:

• One key, one balance. An sk-nrouter-… key and credits. The quick start is a base-URL change to https://api.nrouter.ai/v1 plus NROUTER_API_KEY; existing OpenAI-compatible clients need no rewrite — authentication has the detail.
• We open and maintain the provider accounts. Anthropic, OpenAI and AWS Bedrock are live, alongside the rest of the catalog on models. A new model appears because we did the onboarding, not because you filed a ticket.
• Virtual keys with real limits. You mint as many keys as you want, each scoped to a team, each with its own budget and RPM/TPM ceiling — the design rationale is in virtual keys vs master key and the operational guide is API key management.
• No margin on the model rate. The fee is charged on top, at purchase, and the credits land in full — markup-free credits is the arithmetic, and Every Feature on Every Plan: We Charge a Fee, Not a Gate is why the fee is the only thing plans change.
• Failure releases the hold. Credit is reserved before the call and settled against the real cost after it, so a provider failure does not leave you charged for a request that never completed: reserve-and-settle.
• Failover without your keys. Because we hold every credential, a fallback chain can cross providers mid-incident. Under BYOK that is only possible for providers you have already onboarded yourself.

Blast radius: two leaked keys, compared

The security argument runs against intuition, so make it concrete. Suppose a key ends up in a public repository.

Under BYOK, those provider keys also have to travel into the gateway's systems to be useful — so the "we keep our own keys" framing already involves handing credentials with unbounded spend authority to a third party. Our model inverts it: the credential you hold is capped and revocable, and the unbounded ones stay in one managed place instead of being copied into every customer's integration. The controls you would use in practice are budget caps and RPM and TPM rate limiting per key, team, and org.

The trade we are making

The honest ledger of what our choice takes from you.

You cannot spend your committed capacity. If you have prepaid or negotiated capacity with a provider, we cannot draw it down. That money stays unspent while you also pay us. For a team with a large commitment, this alone should decide the question against us.

You cannot negotiate your own provider rate. Volume pricing you could win directly is not available through us. Our answer is a 0% platform fee on Pro and enterprise terms above that, but it is our leverage, not yours.

You depend on our catalog. A model we have not onboarded is a model you cannot call today, and "we will add it" is not something we will write in the present tense to make this paragraph easier. Models is the honest list; if what you need is not there, ask before you build.

You add a commercial entity to the data path. That is a security review you would not otherwise run. We publish what we can to make it short — security, trust and the SOC 2 checklist for gateways, with SOC 2 Type II in progress rather than complete. Say the awkward thing plainly: this is a real cost of our model, not a formality.

Your exit is a migration, not a config change. Though it is a small one: the API is OpenAI-compatible, so leaving is a base URL and a key. The keys you would need on the other side are the ones you never opened, and that is the one place where BYOK's continuity argument genuinely lands.

Who this is wrong for

Use a BYOK gateway, and we will not try to talk you out of it, if:

• You hold significant committed provider spend. Enterprise agreements, prepaid capacity, or reserved throughput you must consume. This is the clearest disqualifier and it is not close.
• Your provider relationship is contractually load-bearing. If your customer contracts name a specific provider account, or your data-processing terms are negotiated directly with a provider, inserting us breaks something you already built.
• You have negotiated rates we cannot match. At sufficient volume, a direct discount can exceed any fee difference. Do that arithmetic; it is a legitimate reason to route around us.
• You must call models we do not serve. Self-hosted weights, an in-house fine-tune with bespoke auth, or a provider outside our catalog. Related reasoning on the infrastructure axis: Managed LLM Gateway vs Self-Hosted: Why We Carry the Pager.

If none of those describe you, the trade is one key against N accounts, one bill against N invoices, and a capped credential against an uncapped one — and that is the trade we optimized for on purpose.

How you can hold us to it

Every claim above is checkable without asking us:

1. Verify there is no margin. Compare what a request cost you against the provider's published rate for that model and the token counts in the response. The provider rate cards are in Sources; if our number is not derivable from theirs, send us the request id.
2. Watch where the fee lands. It is added on top at purchase, never taken out of the model rate. The amount you load arrives on your balance in full; the fee is its own line — markup-free credits.
3. Read the cost header. Every response carries x-nr-* headers with the per-request cost. When a call cannot be priced, that header is absent and the status header says unpriced, never a fabricated $0 — cost honesty is the full argument.
4. Cap a key and prove it bites. Set a budget below your next request's cost and confirm you are refused rather than quietly allowed: handling 429 and 402.
5. Revoke a key and time it. Revocation should stop that key and nothing else. If any other key or team is affected, our scoping is wrong.
6. Reconcile the ledger. Rows should sum to your balance movement, with each row naming the team, key and model — reading a spend ledger.
7. Test the exit. Point your client's base URL somewhere else and confirm your code did not need to change. A gateway that is easy to leave is a gateway making its case on merit.

Try it

One key, one call, one number — nothing to onboard with any provider first:

curl https://api.nrouter.ai/v1/chat/completions \
  -H "Authorization: Bearer $NROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"MODEL_FROM_YOUR_CATALOG","messages":[{"role":"user","content":"ping"}]}' \
  -i | grep -i '^x-nr-'

Then swap the model field for a different provider's model from models and send it again — same key, same base URL, no second account. Compare the two in the playground, then set a budget in budget controls and mint a scoped key in API key management.

Signup is card-required and takes a real $5 minimum charge with the platform fee on top. Start at signup, check the fee on pricing, or argue the committed spend case with us in the community — if BYOK is right for you, we would rather say so early.

See also

• Markup-free LLM credits — the arithmetic behind "we take no margin on the model rate", which is what makes no-BYOK defensible.
• Managed LLM Gateway vs Self-Hosted: Why We Carry the Pager — the same decision on the infrastructure axis; the two positions stand or fall together.
• Virtual keys vs master key — the blast-radius design that replaces a provider key in your hands.
• Cost honesty — why an unpriceable call is reported as unpriced rather than as zero, which is how you audit our billing.
• Every Feature on Every Plan: We Charge a Fee, Not a Gate — where our revenue comes from instead of a per-call margin.
• Attribute LLM spend by team, customer and feature — the reporting BYOK makes you rebuild from invoices.
• Pricing — the fee, the plans and the $5 minimum, from the source.

Sources

Verified 2026-08-23. Corrections to hello@nrouter.ai and we will update.

Provider and product names above are trademarks of their owners; nRouter is not affiliated with or endorsed by them. This post makes no claim about another gateway's BYOK implementation — the argument is about the two models, not about a named competitor. The provider pages below are cited for two things this post does assert: that each provider issues its own credentials and bills separately, and that our charged model rate is the provider's list rate, which is the check described above. nRouter's own figures (the 4% platform fee, the $50/mo and $500/yr Pro plan, the $5 minimum purchase) are authoritative on our pricing page rather than in this post.

• nRouter pricing: nrouter.ai/pricing
• nRouter model catalog: nrouter.ai/models
• Anthropic pricing: anthropic.com/pricing
• Anthropic API keys and authentication: docs.anthropic.com
• OpenAI API pricing: openai.com/api/pricing
• OpenAI API authentication: platform.openai.com/docs/api-reference/authentication
• AWS Bedrock pricing: aws.amazon.com/bedrock/pricing
• Google Vertex AI generative-AI pricing: cloud.google.com/vertex-ai/generative-ai/pricing