When you buy model access directly, you hold API keys in your own provider accounts and pay each vendor separately. Bring-your-own-key (BYOK) keeps that arrangement while still giving you a single gateway in front of the keys you already own.
What BYOK means
Under BYOK, you do not buy tokens from the gateway at a markup. You plug in the API keys for your existing OpenAI, Anthropic, Google, or other accounts, and the gateway routes requests through those accounts using your keys.
The spend stays in your accounts, where you may have negotiated rates, credits, or existing quotas. The gateway adds a single routing and billing layer on top.
How key injection works technically
Under the hood, BYOK is straightforward. You register a key with the gateway, it is stored so it can be attached to outbound requests, and the gateway injects it into the provider call it makes on your behalf. Your app never sees the provider key at all — it only holds the gateway's key, and the gateway swaps in the right provider credential per route.
Why teams choose BYOK
Keep-your-own-keys appeals when:
- You already have committed spend or discounted rates with a provider.
- You need your spend to stay under your own negotiated contracts for compliance or procurement reasons.
- You have credits or free tiers you want to continue using.
In those cases, moving to a gateway's pooled billing would leave money on the table, so BYOK is the right fit.
Security considerations
Handing your provider keys to any third party is a trust decision, and it is worth being deliberate:
- Store keys encrypted at rest, and never in logs or error messages.
- Scope keys to the narrowest permission that still works for your traffic.
- Rotate keys on a schedule, and revoke any you no longer need.
A gateway should treat your keys as secrets, not as configuration strings.
Managing spend across keys
BYOK means you still watch several vendor bills, not one, so build yourself a single view of them. Track spend per key, per model, and per project, and set alerts when any key approaches its quota. A gateway that reports per-request usage per provider makes this manageable; without it you are reconciling a handful of dashboards by hand and guessing where a spike came from. Treat key-level reporting as a hard requirement when you evaluate BYOK.
What the gateway adds on top of your keys
Even with your own keys, a gateway still earns its place by doing the things your keys can not do alone:
- One endpoint that fronts all your provider accounts.
- Automatic failover across your keys when one provider errors or rate-limits.
- Consolidated usage reporting, even though each vendor bills separately.
- One place to manage which model each task should use.
You keep the pricing benefits of your direct accounts and gain the operational simplicity of a single interface.
The trade-offs to weigh
BYOK is not strictly better — it is a choice:
- You are responsible for each provider's billing and quota management.
- Price differences between providers remain separate, so cross-vendor cost comparison is on you.
- Your gateway must support key injection per request or per route, which not all do.
Pooled billing is simpler when you have no existing provider commitments; BYOK wins when you already hold the keys and the rates.
Getting set up
If you already maintain provider accounts, connect your keys and keep using them through one endpoint. Read the docs to see how models and routing work, or check pricing to compare pooled billing against keeping your own keys.