How We Tamed 30 Claude Accounts — and Why We Built AiKey

"My Claude got rate-limited. Anyone have a spare account?" Five replies in a developer group chat, all saying "Nope, I'm capped too." That moment crystallized a problem we'd been watching for months: multi-account LLM chaos was draining teams, and nobody had built the right abstraction yet.

We didn't start AiKey to sell API management software. We started it because we were drowning in our own mess.

Here's what our setup looked like a few months in:

• 30+ LLM accounts across 3 providers: OpenAI, Anthropic, Google
• Keys scattered across .env files, CI/CD variables, Slack DMs, and one Confluence page we'd all forgotten about
• Some accounts sat at 30% utilization all month. Others hit their RPM cap by week two.
• A former team member's key kept running for a month after they left
• Zero visibility into who was spending what, on which model, for which project

The numbers were ugly. Datadog's report confirms we weren't alone: 60% of LLM call failures are rate limits, not model errors. The majority of your AI calls aren't failing because the model is down — they're failing because your quota ran out and your engineering side had no idea.

The Breaking Point

Anthropic started banning users with multiple Max subscriptions. Not people using sketchy third-party tools — legitimate users paying $200/month per account, banned with no warning.

One post about it got 542,000 views on X. The developer's exact words: "You pay full price, you pay multiple times, and they treat you like a criminal."

OpenAI wasn't better. Their risk model now factors IP reputation as a core signal. One flagged datacenter IP can take down every account on that segment.

The "just buy more accounts" playbook was dead.

What We Tried

| Approach | What it looked like | Where it broke |
|----------|-------------------|----------------|
| Manual rotation | List of keys, try next on 429 | Config changes for every quota hit, no visibility |
| Nginx proxy | Multiple upstreams, round-robin | Still guessing at quota, manual leak response |
| Credential pool | Abstract keys into one logical resource | Better routing, but still "managing keys" not "managing quota" |

The real insight came when we realized: the problem was never "too many keys." It was that our physical resources (keys) were directly coupled to business requirements (who uses what, how much).

The Abstraction That Worked

1. Virtual Credentials

Instead of handing out raw API keys, we built a layer that issues derived, policy-bound credentials. One physical key can spawn multiple virtual keys. Each virtual key gets its own parameters — daily cap, monthly cap, rate limit, model whitelist, project binding.

2. One Pool, Many Windows

Your team's 30 accounts become one logical quota pool. From that pool, you slice 30 controlled exits. Each developer only sees their window. One window runs dry? Others are unaffected.

3. Revoke in Seconds

Old way: key leaks → physical key exposed → cloud provider console → payment method changes. New way: virtual key leaks → one-click revoke → physical key untouched. Audit shifts from "some key spent $200" to "Alice's project consumed $87, 58% of budget."

The result isn't flashy. It's what should have existed from day one: your team's AI resources look like one pool, not thirty scattered keys.

Where We Are Now

We open-sourced the personal edition. It's free. No catches.

macOS:

curl -fsSL https://aikeylabs.com/zh/i/ih09 | sh

Windows (cmd):

curl.exe --ssl-no-revoke -fsSLo "%TEMP%\aikey-w.ps1" https://aikeylabs.com/zh/iw/ih09 && powershell -ExecutionPolicy Bypass -File "%TEMP%\aikey-w.ps1"

Windows (PowerShell):

$f="$env:TEMP\aikey-w.ps1"; curl.exe --ssl-no-revoke -fsSLo $f https://aikeylabs.com/zh/iw/ih09; & $f

Enterprise: [email protected]

If your team is dealing with multi-account chaos, we'd love to hear your war stories. This problem is way more common than anyone admits.