Load-balancing Claude Code subscriptions

I had a row of Claude Code agent sessions fanned out across tmux panes — tmux splits one terminal into many, each pane its own agent — and one after another they came back walled. The subscription had burned through its rate-limit budget, the rolling cap on how many exchanges you get per time window, and every agent drawing from it was starving the others.

The fix that stuck: a small auto-balancer — a program that picks which account to route each session to — spreading work across several subscription accounts. It scores each account by remaining headroom (how much quota is left) and reset proximity (how close that quota is to refreshing) instead of picking by a hard threshold.

The design lesson worth keeping: no threshold cliffs in the scoring function. My first version did exactly that. It used a 30-minute window — within 30 minutes of reset, bonus; further out, nothing. That’s a cliff, a score that snaps from full credit to zero at an arbitrary line. An account six hours from reset scored zero while one at 29 minutes got full credit, even though six-hours-out is still perfectly usable. Wrong turn. I ripped the buckets out and made every term a smooth function of its inputs — a single time-constant decay, one curve that fades as reset nears, tuned by a single constant — rather than a bucketed policy guess about what counts as “soon.”

I wrote the whole thing up in full here: I Built a Load Balancer for My Claude Code Subscriptions.

Open threads

• Cross-machine fairness when the same account is shared across boxes.
• Whether reset-proximity should decay on a per-account or per-pool basis.