> ## Documentation Index > Fetch the complete documentation index at: https://docs.aireserve.com/llms.txt > Use this file to discover all available pages before exploring further. # Bring your own key (BYOK) > Run some or all of your traffic on your organization's own provider API keys — billed by the provider directly, with AI Reserve governance intact. Your organization can bring its own provider API keys. When an admin saves a key for a supported provider, every request your organization sends to that provider's models — from any AI Reserve API key, coding tool, or web chat — is dispatched on **your** key, so the provider bills your account directly. Everything else about the platform keeps working: per-user attribution, analytics, quotas and access controls, team governance, and audit logging. Providers you have not configured are untouched: their traffic keeps running on platform keys with standard billing. BYOK is opt-in, per provider, and reversible at any time. ## Supported providers | Provider | Models it covers | Notes | | --------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | OpenAI | `gpt-*` (direct API) | | | Anthropic | `claude-*` served on Anthropic's API | `-bedrock` / `-vertex` variants are AWS/Google-billed and stay on platform keys | | xAI (Grok) | `grok-*` | | | DeepSeek | DeepSeek's own API legs (`deepseek-chat`, `deepseek-reasoner`, `deepseek-v4-pro-deepseek`) | Aggregator-served DeepSeek models (e.g. `deepseek-v4-flash` on Fireworks) stay on platform keys | | Moonshot (Kimi) | `kimi-*` / `moonshot-*` served on Moonshot's API | Aggregator-served Kimi variants stay on platform keys | A model is covered exactly when the provider **bills** for it. Models served through aggregators (Together, Fireworks, DeepInfra, …), AWS Bedrock, Google Vertex, or Azure are different billing relationships and are not covered by a maker key — the platform serves them as usual. Google Gemini is not yet supported: large file attachments are platform-managed in a way that is incompatible with customer keys today. Coverage applies to chat traffic on all three API surfaces — `/v1/chat/completions`, `/v1/messages` (Claude Code and Anthropic SDKs), and `/v1/responses` (Codex) — plus web chat. Embeddings, image, video, and audio endpoints stay on platform keys for now. ## Billing Requests served on your own key record **\$0** in AI Reserve usage — the provider bills your account directly, and charging our standard rate on top would double-bill you. The requests stay fully visible in analytics (tokens, models, users, teams) and are marked as BYOK in the usage ledger, so your spend reporting can separate platform-billed from provider-billed traffic. A platform fee for traffic served on customer keys is an **open pricing decision** — v1 deliberately charges \$0 and does not invent one. If a fee is introduced it will be announced explicitly; nothing in the current behavior implies or precludes it. Spend caps and budget alerts operate on platform-billed cost, so \$0 BYOK usage does not consume them — and, by the same token, an organization-wide spend cap does **not** limit BYOK traffic: use your provider account's own limits to cap provider-billed spend. Request-level quotas, model access rules, and team controls apply to BYOK traffic exactly as before. ## Security * Keys are encrypted at rest with AES-256-GCM (the same envelope scheme that protects other platform-held secrets) and decrypted only inside the gateway at the moment of dispatch. * After saving, a key is displayed only as its last 4 characters — it is never shown, exported, or included in API responses again. * Keys are never written to logs, error records, or analytics rows. * Saving, replacing, and removing keys are admin-only actions, recorded in both audit trails (the internal audit log and your organization's Activity page). ## Behavior details * **Fail-safe.** No key configured for a provider, or a key that cannot be decrypted, means traffic serves on platform keys exactly as today — never an error. * **No cross-provider fallbacks.** Requests on your key never fall back to a different provider (that would either move your traffic somewhere your key doesn't apply or send your key where it doesn't belong). If the provider has an outage, those requests return the provider's real error. Remove the key to restore platform serving — including configured fallback chains — at any time. One caveat: when the platform's own provider health checks reroute traffic away from a degraded provider before your key is applied, the rerouted requests may serve on a fallback provider you have no key for — those requests run on platform keys at standard platform rates, never on your key. * **Your key, your rate limits.** Traffic on your key runs under your provider account's rate limits and quotas, not the platform's pooled capacity. * **Invalid keys surface honestly.** If your provider rejects the key (for example after you revoke it upstream), requests to that provider fail with the provider's authentication error until you replace or remove the key — the platform does not silently switch you back to platform billing. * **Auto model routing.** Requests with `model: "auto"` pick the best model first and check keys second — auto can select a provider you have no key for, and those requests serve on platform keys at standard platform rates. Pin a covered provider's model when a request must ride your key. * **Propagation.** Saving, replacing, or removing a key applies within about a minute. ## Set it up 1. In the portal, open your organization's admin console and go to the **API Keys** tab. 2. Under **Provider keys**, choose **Add key** next to a provider and paste an API key from that provider's console. 3. Verify with a request to one of that provider's models — the usage row records \$0 and is marked BYOK. Replace a key in place at any time (for rotation), or remove it to return that provider's traffic to platform keys and standard billing.