An access key is the pass you issue to a person, a program or a contractor. Through it they use the models, but never see your vendor keys. Every key has its own spending limits and its own list of allowed models, so one glance at the “Access Keys” section is enough to understand who may use what, and how much has already been spent.
Why separate keys
You could simply hand everyone the vendor key. But then you would not know who exactly is spending the money, and you could not close one person’s access without touching the rest. A key per person solves both tasks:
- The master vendor key never leaves your side — it stays only on the server.
- Access closes precisely — a contractor’s key is revoked instantly, the rest keep working.
- Spending is counted per person — the list shows how much was spent per day, week, month and in total.
What a key looks like
A key is assembled from the constant prefix proxyagent-, the name you gave it (lowercase, spaces replaced with dashes), and 24 random characters. For example, a key named “Claude Code” comes out something like proxyagent-claude-code-a1b2c3d4e5f6g7h8i9j0k1l2.
The key is shown once
The ready key is visible exactly once — at creation and at regeneration. The database keeps only its irreversible fingerprint (a SHA-256 hash) and the last 8 characters for identification. That means a key cannot be looked up after the fact: if it is lost, the only way out is to regenerate it.
Regeneration revokes the old key instantly: as soon as the new one is issued, the old one stops working that same second. The old records in the log remain — they still show the key’s name.
Spending limits
A key can carry up to four spending limits — all in dollars, all optional. While a limit is not set, spending is unlimited.
- Daily — from the start of the current day.
- Weekly — from Monday.
- Monthly — the calendar month.
- Total — for the whole lifetime of the key.
Before every request the product looks at what has already been spent and checks the limits in order: daily, weekly, monthly, total. The first one reached produces a refusal with a clear text, for example Spend limit exceeded: daily $12.50 of $10.00. A limit of zero blocks everything — a convenient way to instantly “switch off” a key without deleting it.
Two honest subtleties. The request that crossed the limit runs to the end and is charged in full — it is the next one that gets blocked. And the refusals themselves cost nothing: a blocked request adds no spending to any period, so blocking never deepens the violation.
Restricting models
A key can be allowed not every model but a specific list. While the list is empty, everything is allowed. If it holds at least one model, a request to any other one is refused with Access to model '{name}' is not allowed for this key — without substituting another model: no “similar” model will silently appear here.
The order of the checks matters: the product first finds the model and only then looks at the list. So the model restriction fires before the spending limit — and that is correct: there is nothing to count against a model the key may not use anyway.
Restricting channels
A separate list sets which channels the key may use for ordinary traffic through the proxy service. While the list is empty, there are no restrictions. If it holds channels, the key uses only those, and when none of them works — it does not reach the internet directly, it simply gets a refusal. This protects against accidentally exposing your address: a restricted key never goes past the channels you named.
What the list shows about a key
- The name and the key’s last 8 characters — to tell apart keys with similar names.
- Spent per day, week, month and in total.
- Restrictions — which models and channels are allowed.
- State — whether the key is active or deactivated, and when it was last regenerated.
Deactivation and deletion
Deactivation closes access at once and completely — from the very next request — but the key and its history stay in place. If the person comes back, switching it back on is just as simple: the very same key starts working again, no need to issue a new one.
Deletion removes the key for good, together with its restrictions. The request log rows remain and still name the old key — the history does not disappear.
Next: how to describe the models your programs talk to — in the Models & Prices section.