Here is a question I could not answer well for a long time: how do you let someone lend you an API key without ever seeing it?
Not "promise not to look." Actually not see it.
That is what the SpiderGate™ Vault does. Keys go in encrypted. A key you contribute never appears on my screen, and it keeps working when the key next to it dies.
The problem is not storage. It is everyone else's keys.
Your own keys are easy. You paste them once and forget them.
The trouble starts when a key belongs to someone else. A teammate has the Groq account. A client holds the OpenRouter billing. A contractor owns the Mistral plan. You need the capacity. Nobody wants to paste a live secret into a chat window, and you should not want them to.
So keys end up in .env files, on four machines, in two password managers, and in one message thread from March. Then one rate-limits at 2am and every request behind it stops.
Contribute a key without exposing it
You send an invite. The other person gets a link, opens it on their own machine, and pastes the key there. No login. No account with us.
The key is encrypted before it is stored. What I see afterwards is a preview — the first four characters and the last four. That is the whole surface.
As of July 2026, 31 keys have arrived this way.
The same flow handles the awkward case: a key that has died. The contributor gets a re-authentication link and replaces it in place. Same slot, same settings, same history. You do not rebuild anything.
Three kinds of key, and they do not mix
This is where most key managers stop, and it is the part that matters for money.
A key is one of three things:
Free — a free-tier account. Pools freely.
Subscription — a flat monthly plan like a Codex or MiniMax coding plan. Pools, because the fee is already paid.
Pay-as-you-go — metered, billed per token. Never pools.
That last rule is enforced in the database, not in a code review. A paid key cannot be shared into the pool: a trigger coerces the flag, a constraint backs it up, and the write API rejects the attempt outright. Three layers, because one tenant quietly spending another tenant's money is the failure you cannot apologise your way out of.
As of July 2026 the vault holds 75 active keys across 15 providers — 47 free, 4 subscription, 13 pay-as-you-go. Fifty of them are pooled.
The pool keeps going when one key stops
Every request picks a key the same way: healthy first, then least-used today, then least-recently-used. Cheap to compute, and it spreads load without a scheduler.
Failure is the interesting half. Three consecutive errors and a key is marked unhealthy and dropped from selection. The next request does not notice. It picks the next healthy key and goes.
Over the last 30 days, 68 different keys served 169,581 requests through that rotation.
You can see what each key costs you
Every request is logged against the key that served it. So spend is per key, not one number for the month.
In the last 30 days the busiest contributed key ran 9,825 requests for $65.63. Total across the pool was $414.97. When something looks wrong, you can see which key it was.
Subscription plans meter differently, and the vault meters them differently too — usage counts against the plan's own rolling window rather than a dollar amount. Fifty-two keys carry a live window count today.
Where to find it
The vault is at Dashboard → Gate → Vault. Add a key, send an invite, or check what a key has spent.
Agents can drive the same surface. The manage-vault skill ships in @spideriq/admin-skills, and the key endpoints are documented in the SpiderGate manual.
If you have been meaning to get your keys out of a .env file, start with one. The pool gets better every time somebody does.
SpiderGate routing is built on LiteLLM by BerriAI, an open-source router. Provider names are the trademarks of their respective owners and imply no affiliation.