--- title: "Our First Claude Account's 20x Pool Ran Out Wednesday. We Spun Up a Second Account Mid-Week." canonical: https://dxdev.com/blog/mid-week-account-pivot/ datePublished: 2026-09-14 --- The 20x pool ran out mid-Wednesday, not at the end of a billing cycle. We'd already spent that morning tracing a 60% quota spike to a wide daytime spread of sessions plus one unattended overnight run, and shipped a usage-and-outcome tracking page so it wouldn't be a guess next time. That page turned out to be the thing that told us we weren't going to make it to Friday on the seat we had. The fix wasn't waiting for reset. We bought a second Max plan under a separate email login and had to make the whole cockpit seat-aware before it was useful for anything beyond a second terminal. ## What "seat-aware" actually meant The cockpit is the thing that tracks sessions, crons, and spend across every repo we run. It had exactly one assumption baked into it: one provider account. Sessions logged tokens but not which login spent them. Crons fired against whatever `claude` resolved to in the shell, which meant whichever account happened to be signed in at the time. There was no field for it because there had never been a second value. Standing up the new account meant: - Recording which account each session actually spent against, not inferring it after the fact. - Teaching the spend guards, the things that stop a cron from burning quota on a dead loop, to accept both accounts instead of hardcoding one. - Moving the crons that weren't the platform's own work onto the new login, so the exhausted seat's remaining pool stayed reserved for the platform. - Adding a daily check for expiring logins, because now there were two sessions that could silently expire instead of one. The whole thing took 7 minutes to land as a session, which sounds fast until you count what came right after it: 22 minutes fixing the second account not because the plan was wrong, but because a fresh login doesn't inherit anything. ## The account switch broke tools, not access We switched the primary terminal over to the new login and kept working, assuming a Claude account switch is just an auth token swap. It isn't. The new session was missing the chrome-devtools MCP tool entirely and had no project trust granted, so it was stopping to ask permission on things the original account had long since been told yes to. That's the wrong turn: we treated the account switch as instant and moved on to other tickets before checking it. Twenty minutes later, back at a different session, `chrome-devtools` wasn't in the tool list for a task that needed it. The actual cause was mundane, project trust and MCP server config live in local state keyed to the OS user profile, not to the provider account, so a new login starts with none of it. The fix was copying the config over and verifying a fresh process connected to all three MCP servers before trusting the seat for anything else. Cheap fix, but it cost a diagnosis we shouldn't have needed if we'd checked the new seat's tool list before routing real work onto it. ## The gap the drill actually found The account split happened inside a longer session that also split CI alerting into four per-business sweeps and added automatic failover for when a seat runs dry, the same failure mode we'd just lived through, now supposed to be handled without a manual pivot. We ran a drill during the pre-close to confirm the paging worked. It reached nine of fourteen crons. Not zero, which would have been an obvious break, and not fourteen, which would have meant it just worked. Nine. The five that didn't get paged weren't a pattern we could name in the moment, just crons that predated the alerting rewrite and never got wired into the new dispatch path. That's now a tracked gap in our issue tracker instead of a false confidence. The instinct after building failover is to mark it done because the code path exists and one test passed. The drill was the only reason we know it's actually a 9-of-14 system, not a 14-of-14 one. ## What's still manual The account attribution now works: every session and cron logs which login it spent against, visible on the tracking page we shipped that same morning. The failover logic exists. What doesn't exist yet is a single source of truth for "which crons are wired to which alerting path", which is exactly the kind of thing that looks fine until a real quota exhaustion hits the five crons nobody remembered to migrate. Multi-seat wasn't a feature we planned. It was a Wednesday-afternoon patch to keep the platform's own crons running while a side account absorbed everything else, and it's staying, because running one seat for everything was never going to survive a week like this one twice.