Subscription coding agents run on rolling usage windows, and unused quota simply evaporates at reset. The right account to spend from is the one nearest its reset, not the coolest one.
I run coding agents across several subscription accounts, each with its own usage window that refills on a rolling schedule, a five-hour window and a seven-day window, typically, depending on the plan. For a long time I picked which account to spend from the way most people would: whichever one had the lowest utilisation right now. That instinct is wrong, and it took losing real capacity to notice why.
The windows are perishable. Whatever percentage of a plan sits unused when the window resets is not carried forward, banked, or credited anywhere. It is simply gone, and a fresh allowance starts from zero. That means an account sitting at fifty per cent utilisation with three weeks left on its cycle is, in a real sense, holding less spendable capacity than an account at fifty per cent with a reset landing tomorrow, because the second one is about to be handed an entirely new allowance tomorrow whatever happens today, while the first one has to find three weeks of work for the half it is holding or watch that half expire.
Once I started reading reset dates alongside utilisation, the right allocation stopped matching the intuitive one almost every time. The account that looks coolest, lowest usage, most headroom, is very often the one furthest from reset, which means its unused capacity has the longest runway to actually get spent before it matters. The account that looks hottest and therefore like the one to avoid is frequently the one about to hand back a clean slate anyway, so pushing more work onto it before reset costs nothing that would not have been lost regardless.
The practical rule I use now: spend the account nearest its reset first, provided it still has room for the task at hand, and treat distance-to-reset as at least as important a variable as current utilisation. A plan with quota reads two numbers, not one, and citing only the first, ‘this account is at eighty per cent’, is not a complete argument for avoiding it. Eighty per cent with six hours to reset is a non-issue. Eighty per cent with five days to reset is a real constraint. Reading only the first number and skipping the second is how a perfectly good account gets avoided for the wrong reason, on the same day a genuinely tight one gets overspent.
This matters more as the number of accounts grows. With one subscription there is no allocation problem, only a ceiling. With four or five, spread across different providers and different reset cadences, the allocation problem is real and the naive heuristic, send new work to whichever one looks least used, quietly wastes a meaningful fraction of total paid capacity every single cycle, because it never accounts for the plans that are about to reset with money left on the table. Multiply that waste across every cycle in a year and it stops being a rounding error.
None of this argues for treating quota purely as a scheduling problem to be automated end to end. There are reasons to keep specific work on specific accounts, separation of concerns, avoiding cross-contamination between projects, or simply a standing decision about which account does which kind of job, and those reasons should win over a raw optimisation for spend efficiency. But within whatever set of accounts is actually in play for a given task, the reset date deserves at least as much weight as the current bar.
The number that should worry me is not ‘how full is this account’ but ‘how much of this account will go unspent when it resets’. The first number invites the wrong instinct. The second one is the one that actually describes waste.