Seat-based AI tooling has an idle capacity problem nobody budgets for

If your company buys per-seat AI coding subscriptions, you are almost certainly paying for a lot of capacity that expires unused every week, while some of your engineers hit their limit on Tuesday.

Both things are true at once, and that combination is what makes it a distribution problem rather than a spending problem.

Why the distribution is so uneven

Usage is bursty and it correlates with role in a way that seat allocation does not.

Someone mid-migration will saturate a subscription for two weeks and then barely touch it for a month. Someone in meetings four days a week has a seat that is nearly untouched. A designer or a QA engineer who was given a seat during a rollout may never have opened it.

Meanwhile the allowance does not roll over. Unused capacity is not banked, it just stops existing, and it stops existing quietly. There is no line item for it and no alert.

The wrong fix, which everyone tries first

Share a login. One account, shared credentials, anyone can run anything.

This is worth naming explicitly because it is the natural first idea and it is bad in four separate ways. It breaks attribution, so you cannot tell who ran what. It makes the rate limit collective, so one person's big job blocks everyone. It makes revocation all-or-nothing. And it generally violates the terms you agreed to when you bought the seats.

The second wrong fix is buying more seats to relieve the pressure, which increases the amount of idle capacity you are paying for. You will feel like you solved it, because the person who was blocked stops complaining.

Move the task instead of the account

The version that works is unglamorous: when someone is out of capacity and someone else has plenty, move the work item, not the credentials. The second person runs it on their own subscription, under their own identity, and the attribution stays intact.

That requires the task to be portable, which is the actual cost. A task that only its author can run - because the brief lives in their head - cannot be moved no matter how much capacity is idle elsewhere. So the prerequisite for using spare capacity is writing tasks down properly, which is annoyingly the same prerequisite as everything else in this area.

Be honest about the two kinds of value

This is where I would push back on most write-ups of the idea, including some enthusiastic internal ones.

Recovered output is real: work got done that otherwise would have waited. Worth having.

Cash saved is usually not real. You only save money if you would otherwise have bought more seats. If you were not going to, then using idle capacity costs the same as not using it, and reporting a saving is fiction. It is a throughput gain, not a cost reduction, and the two get conflated constantly because one of them sounds better in a board update.

There is a third thing, harder to measure and possibly the most valuable: someone who was blocked stops being blocked, which changes what they attempt next.

This write-up models the whole thing with the assumptions visible, including a ten-seat worked example and an explicit separation of recovered output from genuine cash savings. I would read the section on why an allowance percentage is not enough before quoting a utilisation number to anybody, because a percentage hides exactly the burstiness that makes the problem interesting.

And if you do try it: run it as a pilot designed so it can come out negative. The failure mode of this idea is not that it does not work - it is that it is impossible to disprove once someone has announced it.