Hacker News new | ask | show | jobs
Show HN: key-carousel - Key rotation for LLM agents (github.com)
5 points by EmptyDrum 108 days ago
I think in-process key management is the right abstraction for multi-key LLM setups. Not LiteLLM, not a Redis queue, not a custom load balancer.

The failure modes are well-understood: a key gets rate-limited, you wait, you try the next one. Billing errors need a longer cooldown than rate limits. This is not a distributed systems problem — it's a state machine that fits in a library. The problem is everyone keeps solving it with infrastructure instead. Spin up LiteLLM, now you have a Python service to maintain. Reach for Redis, now you have a database for a problem that doesn't need one. key-carousel manages a pool of API key profiles with exponential-backoff cooldowns: 1min → 5min → 25min → 1hr for rate limits, 5hr → 24hr for billing. Falls back to OpenAI or Gemini when Anthropic keys are exhausted. Optional file persistence. Zero dependencies.

2 comments

The "infrastructure instead of a library" pattern is everywhere in the LLM tooling space right now. We went through the same decision point, stood up LiteLLM, ran it for a week, then ripped it out because the operational surface wasn't worth it for something that's really just a retry loop with state. The cooldown tiers make sense; the one thing I'd watch is key exhaustion behavior when all profiles are in backoff simultaneously, does it block or surface an error immediately?
fyi - this was built inspired by how OpenClaw manages llm-keys. I liked their idea and improved on it. Feedback is welcome.