Control, cap and account for every AI API call

• An address list per key, or allow-anywhere if you deliberately choose it — plus a ten-minute window that adds exactly one new address when nobody can name it in advance.
• Requests per minute, per day, per address, and a cap on concurrent requests.
• Dollar budgets over the key's lifetime or per month, week, day or hour, with the time each one resets.
• A tag for the environment a key belongs to, so a production key cannot be routed through a development vendor key by accident.
• Restrict a key to particular models, or let it follow the vendor key it routes through as that key's list changes.
• A per-key log of the addresses it was used from, of its requests, and of everything that was refused, with prompt and completion logging available per key when you want it.

• Every vendor key is tested against the vendor before it is saved.
• Secrets are encrypted with AES-256-GCM and are never returned by the API or written to logs.
• Each vendor key carries its own list of models, so one key can serve the cheap models and another the expensive ones. Narrowing a list says first which virtual keys would lose which models.
• Each vendor key can carry a monthly spend cap of your own, and a tag — development, staging or production.
• Pick a default key per vendor, or bind an organisation or a single virtual key to a specific vendor key.
• Spend is attributed to the vendor key that served it, so each vendor account can be reconciled on its own.

• Own-key requests are billed to you by the vendor; the gateway meters and caps them without deducting anything.
• Prepaid requests run on our vendor keys and are deducted from credit that can never go below zero.
• A monthly ceiling for the whole organisation, on top of each key's budgets.
• Daily reconciliation against Anthropic's and OpenAI's own usage reports, with differences flagged.

• A dashboard of spend and requests by period, provider, model, vendor key and virtual key.
• A Refusals page: everything the gateway turned away, what needs a look, and which of your limits are actually being hit and by how much.
• Keys, vendor keys with their model lists, aliases, members and usage in one place.
• Owner, admin and viewer roles, and invitations by email.
• Alerts for budgets, the ceiling, credit and vendor-key health, by email or signed webhook.
• An audit log recording who changed what, with the values before and after.

Every response carries x-gw-request-id and the model that actually served it in x-gw-model; a successful one also carries its exact cost in x-gw-cost-usd and the budget left in x-gw-budget-remaining-usd. Errors come back in the envelope your SDK already understands.