I spent a Saturday morning aligning account pins across my fleet of machines, and every single fix was cosmetic. Worse than cosmetic, actually. Each one quietly worked against the system I had built.
Here is the setup. I run Claude Code through a small wrapper script I wrote
called cl. Every invocation, cl reads each account’s remaining rate-limit
budget from disk and launches the session against whichever account has the
most headroom. A rate limit is like a monthly data cap: run out and you wait.
Spreading sessions across several accounts is how one person gets the
throughput of several. I wrote about building that load
balancer a
while back.
Each box also has a global file, sitting in the home directory, that names one account as the account. A leftover from before the balancer existed. And whenever I noticed that file disagreeing with the account a box had actually been using, I “fixed” it: switched the global pin to match, felt tidy, moved on.
The file nobody reads
The Saturday in question, I was mid-fix on the third box when I finally asked the obvious question: what reads this file?
The answer was nothing. My wrapper sets an environment variable per invocation that points Claude Code at the chosen account’s own directory, so the global default in the home directory is never consulted. It is vestigial, the way your appendix is vestigial: present in every box, load-bearing in none.
So my morning of alignment had changed bytes on disk that no code path would ever open. That is the embarrassing half of the story.
The worse half: alignment re-pins the load
The point of a balancer is that every pick is dynamic, made fresh, from live headroom. A pinned preference is the opposite: it concentrates. Whatever account gets pinned absorbs session after session until its budget is gone, while the others sit idle with full tanks.
My hand “fixes” were not switching the global file to match reality. They were switching real sessions onto one account, by hand, in the name of consistency. If concentration is ever the actual problem, the fix is more healthy accounts in the pool, not tidier pins. I learned the discovery version of this lesson when the fourth account did not exist yet: the roster must be scanned, not hardcoded. This was the same lesson one level down. The pick must be fresh, not reconciled.
The bug that was actually worth hunting
There is exactly one consistency bug in this design, and it is not a mismatched pin. It is a box where the wrapper silently stops being dynamic at all.
I found one. A stray line in that box’s local shell config, sourced after
everything else, defined cl as a plain alias instead of my balancer
function. An alias is just text substitution: type cl, get whatever the
alias says. This one bypassed the headroom scoring entirely and launched every
session against a single hardcoded account. The box looked normal in every
casual check, because sessions started fine. It just pinned 100 percent of
its load onto one account for weeks, and the only symptom was that account
running dry faster than its peers.
The audit that matters, then, is one command: ask the shell what cl actually
resolves to. Function that scores headroom: healthy. Alias to a fixed path:
the balancer is dead on that box and nobody got paged.
Align the resolver, not the pin
That is the sentence I keep: align the resolver, not the pin. The resolver is the thing that makes the choice. The pin is a fossil record of a choice made long ago. Reconciling fossils feels like maintenance and changes nothing you can observe, except when it quietly concentrates your load.
If you run anything that rotates across accounts, keys, or endpoints, try the one-command audit yourself. Ask each box what its entrypoint resolves to. The boxes that answer with a function are load-balancing. The boxes that answer with an alias are pinned, and a pinned box does not announce itself. It just drains one account and lets you call it a mystery.