With BYOK on OpenRouter, who bills the inference and what still leaves your credits?

## What BYOK actually changes By default, OpenRouter buys inference from providers and sells it to you out of your credit balance. With BYOK you insert your own credential: you add a provider API key in OpenRouter's settings, and requests that route to that provider are made **with your key**. Three things move as a result — who bills the tokens, whose quota applies, and what the gateway charges for its part. ## Who bills what - **The upstream provider bills you directly.** Tokens appear on that provider's invoice, at your account's rates. If you hold negotiated pricing, committed spend, a volume discount, or prepaid capacity with that vendor, BYOK is how you keep using it while still calling through one gateway API. - **OpenRouter charges a fee against credits.** Documented as a percentage — 5% of what the request would have cost through OpenRouter's own credits at the time of writing. It is small, but it is not zero, and it is charged per request. The practical implication people miss: **BYOK does not free you from maintaining a credit balance.** A drained balance still produces insufficient-credit failures on BYOK routes, because the fee cannot be collected. Teams that switch to BYOK and stop monitoring credits reintroduce the exact outage they thought they had removed. ## Reading it in usage accounting Enable usage accounting (`"usage": {"include": true}` on the request) and the response separates the two flows: - `usage.cost` — credits actually deducted from your OpenRouter balance. On a BYOK route this is the fee, not the token price. - `usage.cost_details.upstream_inference_cost` — the estimated amount the upstream provider will charge you for those tokens, which never touches your credits. A cost dashboard that sums only `usage.cost` across a BYOK fleet will report spend an order of magnitude below reality and look wonderfully efficient right up to the provider invoice. Sum both, and label them as separate ledgers, because they reconcile against different bills on different dates. ## Rate limits and quota move too On a normal route your throughput depends on the gateway's aggregate relationship with the provider. On a BYOK route it depends on **your** account's tier with that provider. That cuts both ways: an enterprise account with high quota gets far more headroom than the shared pool, while a fresh low-tier account gets less and will see provider rate-limit errors surface through the gateway. Capacity planning after switching to BYOK is a conversation with the provider, not with the gateway. Authentication failures also change shape. An expired, revoked or rotated provider key produces an auth failure from that provider on that route, while every non-BYOK route keeps working — a partial outage scoped to one vendor, which is confusing if you are not expecting it. Key rotation becomes a scheduled operational task with a real blast radius. ## When BYOK is worth it It earns its keep when: - You already have a provider contract, committed spend or discount you would otherwise strand. - Volume on one provider is large enough that a percentage fee on the full token price would exceed the flat routing fee. - Compliance or procurement requires a direct relationship, data-handling terms, or an invoice from the model vendor itself. - You want provider-side quota, dashboards or logging that only a direct account exposes. It is not worth it when you are exploring many models, when volume per provider is small, or when the whole point of the gateway was avoiding vendor accounts — you have just reintroduced the account sprawl you were paying to avoid, for a handful of providers. ## The hybrid pattern The common mature setup is mixed: BYOK for the one or two providers carrying the bulk of production volume under contract, credits for the long tail of models used in evaluation, fallbacks and low-volume features. That keeps the discount where the money is and keeps one-key convenience everywhere else — but it means your finance view must merge two ledgers, which is a reporting requirement worth naming before you build it.