The Token Donor protocol

The Token Donor protocol

Leader 1 5 16
calendar_today agoschedule2 min read

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.

6 Comments

3 votes
1
2 votes
1
1
1
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.

More Posts

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

Your Tech Stack Isn’t Your Ceiling. Your Story Is

Karol Modelskiverified - Apr 9

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelskiverified - Apr 23

Why Prompt Engineering Is Just an Expensive Way to Be Incompetent

Karol Modelskiverified - May 21

The Sovereign Vault — A Comprehensive Guide to Protocol-Driven AI

Ken W. Algerverified - Jun 4
chevron_left
1.4k Points22 Badges
ThailandRoninForge.org
4Posts
14Comments
5Connections
Senior Software and ML Engineer, Engineering Manager, curious being .... I like people and riddles.

Related Jobs

Commenters (This Week)

5 comments
2 comments
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!