Every team with AI coding agents hits the same wall. Subscriptions meter usage, caps are per seat, and consumption varies wildly between developers who sit three meters apart. One exhausts the weekly allowance by Thursday; another has never seen a limit warning. The spread is habits, workflow, and automation, not seniority.
The known workaround, a second subscription per person, violates most terms of service, so file it under "ways to lose your account" and move on.
The interesting arrangement did not exist before. Developer 1 scopes a task into a GitHub issue and has no budget left to run it. Developer 2, who never hits the cap, picks it up with zero context and zero further input and spends leftover tokens until an agent ships it. One supplied the thought; the other supplied the compute. Call the second one the Token Donor. There was no pre-agent way to contribute electricity to an idea.
Zero context is the feature
A donated run has no follow-up channel. The donor will not ask what you meant by "fix the flaky test"; the agent does exactly what the issue says, so the issue must say something exact. A ticket a stranger's agent can execute is a ticket that was actually thought through. The industry chased that property for thirty years with templates and definition-of-ready checklists and never caught it. A billing cap caught it by accident. We could not buy good tickets. We accidentally rented them.
Two objections that bite
Who owns the bug at 2am? The issue author, every time. The donor is a power supply, not an approver, and nobody pages the CI runner.
Does this launder laziness into someone else's budget? No. The zero-context rule is the anti-laundering rule: a vague spec fails visibly, at the donor's expense, exactly once; after that, donors accept specifications, not apologies. Credit? Git shipped the Co-authored-by trailer years ago.
Route by numbers, not by feel
The one hard dependency: you must know who actually holds surplus. Self-report fails; the heaviest users are invariably certain they are frugal. Claude Code writes session logs locally, and a free in-browser analyzer of those logs breaks spend down per project and per git branch. Per-branch numbers end the argument.
The first donated run
The highest-value donated spec is deletion of the bloat the agents themselves added. Redundant comments that restate the line below them. Tests that assert the framework works. Defensive scaffolds for conditions that cannot occur. Nobody funds removal from a personal cap, which is exactly why it suits spare compute.
Prices per token may fall; the record of published model prices will tell you, not me. But agents spend more tokens per task with each generation, so caps tighten regardless. Token efficiency is the correct engineering instinct, not yet a recognized skill. It should be: the developer with tokens left on Friday is not underworked, they hold bandwidth the team can borrow.
A question for the comments, and be honest: are you the donor or the drain? Has anyone actually run a colleague's issue on their own budget, spec unseen, and watched it survive? If your team handles the Thursday problem with anything beyond a shared glare at the heaviest user, I want to read about it.
Top comments (2)
The Zero Context Token Donor Protocol:
You buried the lede. "Almost all real defects originated in the plan, not implementation" is a bigger claim than the token protocol, and it's the closing line rather than the thesis.
If it holds, the donor scheme isn't really about budget — it's a spec-review harness that happens to be funded out of someone else's quota. Which suggests a cheaper experiment: keep the zero-context rule, drop the donor. Author writes the ticket, hands it to their own agent, no follow-up permitted, and you see whether spec quality moves the same way. If it does, you've got the benefit without the ToS surface. If it doesn't, then the social cost of spending a colleague's budget was the actual forcing function — which is more interesting than the protocol, and a different post.
That line is not in the article and is a LLM hallucination. Nothing about defects originating in the plan appears in it, closing or otherwise, so I think you are working from a summary rather than the article. Worth flagging, because the rest of your comment is a fair read of what is actually there.
The claim I did make is narrower: a ticket a stranger's agent can execute is a ticket that was actually thought through. I did not measure defect origin and would not assert it without numbers.
On the ablation: I do not think it works. Write the ticket, hand it to your own agent, forbid follow-up. Nothing stops you reading the diff at minute two, amending the issue, and re-running. A self-imposed no-follow-up rule is an intention, not a constraint. The donor makes it physical: the channel does not exist, because the other person is asleep and has no stake in what you meant.
Your last branch survives that, though. If enforcement is the active ingredient rather than the budget, then any external executor does the job and the spare tokens are incidental. That is a real possibility and I cannot separate the two from one team's experience. What I can say is that the only version anyone actually runs is the one where the executor already had a reason to press enter.