BYOK: Bring Your Own Key

developerz.ai is a thin orchestrator. We never proxy or resell inference tokens. You connect your own API key, from any of the providers below, or from any endpoint that speaks the OpenAI API. Every call is made on your key, straight to your provider: the coding calls from your own box, and triage plus a few background lanes from our side. We never resell or mark up tokens.

Why BYOK?

• Cost transparency: your provider invoice shows exactly what the agent spent. No markup, no hidden per-seat token fees.
• Model choice: pick the model that matches your cost/quality needs. Swap at any time without changing your policy file.
• Data residency: your code and issue text go directly to the provider you chose under your own account's data-handling terms.
• No vendor lock-in to us: if you stop using developerz.ai, your key and your data stay with the provider.

Supported providers

Every provider below is built in: pick it, paste the key, done. Anything else that speaks the OpenAI /chat/completions API works too, choose custom and supply the base URL. That includes self-hosted models, gateways, and providers we have not listed.

The default endpoint is what the key hits when you do not set a base URL. The dashboard asks for one where there is no default (custom, alibaba) and offers it for the zai and kimi coding-plan paths.

This table is generated from the same provider table the resolver uses, so it cannot drift from what the product accepts. Model ids are not listed: they change faster than any docs page, and the dashboard's model picker is the live list.

Metered keys vs coding plans

Most keys are metered: you pay your provider per token, and each session's spend is recorded against your account as it runs. Some providers also sell a flat-rate plan, billed as a subscription rather than per token:

The path matters for the two coding plans: z.ai serves its metered API on the same host, so a key on api.z.ai/api/paas/v4 is metered while api.z.ai/api/coding/paas/v4 is the flat-rate plan. The Token Plan host is the opposite: it serves nothing but its subscription, so the host alone classifies it. We classify the key from its endpoint when you add it. A flat-rate key books $0 per token, so its sessions add nothing to your monthly spend cap below.

Any other endpoint is classified metered. If a key is really a subscription the URL cannot reveal (a gateway you run in front of subscription plans, say), declare it: kind: "subscription" when you add the key, or re-stamp an existing one with PATCH /v1/billing/keys/:id/kind (PATCH /v1/me/keys/:id/kind for a personal key).

Self-hosting a router

multi-ai-router is an open-source (MIT) server you run yourself. It pools the AI subscriptions and API keys your team already pays for behind one endpoint that speaks both the OpenAI and the Anthropic API, and hands out named, revocable keys of its own, so the real provider logins never leave your server. It is still BYOK: developerz.ai calls your router with a key your router minted, and your router calls the providers.

To point developerz.ai at it today:

1. Mint a key for developerz.ai in your router's console.
2. In Keys, add a key with provider custom, paste the router key, and set the base URL to your router's OpenAI-compatible base, https://<your-router>/v1.
3. Verify it. The check lists models from <base>/models, which the router scopes to the key you presented.

The router must be reachable from the public internet: a base_url on localhost or a private address is refused when you add the key. The key is classified metered, like any custom endpoint. If your router pools flat-rate subscriptions, declare the key subscription as described above so its sessions book $0.

Use custom, not the router provider, for a router you host: the router provider does not yet take your own router's URL.

Adding your key

1. Open the dashboard and go to Keys (/account/keys) for keys the whole account shares, or My keys (/account/my-keys) for your own.
2. Choose your provider, paste the API key, and set the base URL where the form asks for one: always for custom and alibaba, optionally for a zai or kimi coding plan.
3. Click Save. The key is encrypted with AES-256-GCM before being stored; the plaintext is never written to disk or logs after the initial save.
4. Verify the key. We make one cheap call to the provider to prove the credential works before any agent session depends on it.

An account holds a pool of keys, not one per provider. Each key can carry a label, a priority, and a capability tier (smart / general / fast), and the dispatcher resolves one per task, so you can run a cheap model for triage and a strong one for code, or keep a second key of the same provider as a fallback. A key can be parked (inactive) without being revoked.

Key storage and security

• Keys are stored encrypted at rest (AES-256-GCM, unique data key and IV per row).
• Keys are decrypted in memory only at the moment the agent needs to make an API call.
• No key is ever logged, included in audit events, or sent to any third-party endpoint other than the one you configured.
• Key access is scoped to your account. GitHub App installation tokens cannot read keys.
• See the security doc for the full threat model.

Spend limits

There is no per-session cost cap. We do not stop a session because of what it has spent on your key: the key and the bill are yours, and a session killed halfway is paid for twice, once up to the kill and again for the re-run.

What exists instead:

The monthly cap is not a bill from us (under BYOK that spend is on your key, with your provider), and it cannot see spend that never went through a session, so provider-side limits are still worth setting. When the cap is reached, new sessions are not started until the window rolls or you raise the cap. Sessions already running finish, so concurrent sessions can take the total a little past the cap. See billing.

Rotating your key

1. Generate a new key in your provider's dashboard.
2. In Keys (or My keys), open the key's Rotate action and paste the new secret.
3. Click Save. We verify the new key against the provider before swapping it in, a key the provider refuses is rejected and nothing is written, so a typo can never leave your account with a dead credential.
4. Revoke the old key in your provider's dashboard.

There is no downtime during rotation, in-flight sessions complete with the old key; new sessions use the new key. Rotation replaces the secret in place. The key's provider and endpoint are fixed when it is created, so switching either means adding a new key rather than editing an existing one; its metered or subscription classification can be re-stamped as described above.