19 September 2026 · 0.1.0-alpha.6
A vendor key carries what it may be used for, and every refusal is recorded
- Each of your vendor keys now has its own model list. One key can serve the cheap models and another the expensive ones, which is what an organisation with a development key and a production key actually wants. Narrowing a list tells you first which virtual keys would lose which models.
- A vendor key can be tagged development, staging or production. A production virtual key can then only be routed through a production vendor key, and the editor refuses the mismatch when you save it rather than at three in the morning.
- A vendor key can carry a monthly spend cap of your own. Past it, requests through that key are refused — or fall back to the organisation default, if that is what the virtual key asks for.
- Every refused or failed request is recorded: which key, from which address, with which client, when and why, and never the secret. A new Refusals page says what needs a look — a revoked key still being called, someone trying wrong secrets, a key used from an address it has never worked from — and which of your limits are actually being hit, how often and by how much.
- A key is suspended automatically after five different new addresses in an hour, rather than after a count of attempts. One address retrying is a broken client; five new ones is a key in circulation. Wrong secrets never suspend a key, however many are tried.
- “Pin to the first address used” became a checkbox under the address list: add the next new address automatically, once, within ten minutes. It adds exactly one address and unticks itself.
- The tokens-per-minute limit on a key is gone. A cheap model returns a great many tokens for very little money, so the number never bounded what anyone set it to bound; requests per minute, budgets and the per-request cap do.
- The key wizard was rebuilt: the route is chosen before the models, and each step shows what you have chosen as you go.