DEV Community

Cover image for Budget Tokens Per Resolved Task, Not Per Seat
Basavaraj SH
Basavaraj SH

Posted on Edited on

Budget Tokens Per Resolved Task, Not Per Seat

The more useful reaction to high AI agent spending is to ask what unit that number should be divided by - because that choice determines whether your AI budget is defensible or just scary.

Per-Seat Budgets Hide the Only Number That Matters

Most teams inherit SaaS pricing habits: pick a per-user monthly cap, enforce it, call it governance. That works for tools with fixed compute per action. Agents break it. One agent run might cost $0.02 or $8.00 depending on how many times it re-reads a file, retries a failed tool call, or loops because the task was ambiguous. A per-seat cap tells you nothing about why - it just cuts people off mid-task and pushes heavy users to quietly expense a personal account.

The alternative is budgeting per resolved task: total token spend divided by the number of outcomes you actually wanted. Support tickets closed without escalation. Pull requests merged. Research briefs accepted by the person who asked for them. You gain variance in monthly spend but lose predictability. The benefit is a number you can compare against the manual cost of the same outcome, and visibility into which workflows are expensive rather than which people are.

Rejecting the per-seat model also means you can't do governance with a billing dashboard. You need task-level attribution, which is engineering work.

What Attribution Looks Like in Practice

The mechanism is a task ID carried through every model call, so usage rolls up by outcome instead of by user. Most SDKs support arbitrary metadata on requests:

response = client.messages.create(
 model="claude-sonnet-4-5",
 max_tokens=1024,
 metadata={"user_id": task_id}, # group spend by task, not seat
 messages=messages,
)
usage_log.append({
 "task_id": task_id,
 "tokens": response.usage.input_tokens + response.usage.output_tokens,
 "resolved": None, # set True/False when the task closes
})
Enter fullscreen mode Exit fullscreen mode

The resolved field is the part teams skip, and it's the part that makes the whole thing work. Without it you have a cost report. With it you have cost-per-resolved-task, plus its ugly sibling: cost-per-abandoned-task.

That second number is where the savings hide. In most agent deployments, a meaningful slice of spend goes to runs nobody used - the agent looped, produced something wrong, and a human redid the work. Those runs look identical to successful ones in a per-seat dashboard. Once you can see them separately, the fix is usually scoping or a cheaper model on the retry path, not a tighter budget.

Key Takeaways

  • Per-seat caps measure the wrong thing for agents, where cost per action varies by orders of magnitude within the same workflow.
  • Cost-per-resolved-task is comparable to the manual cost of the same outcome - that's the comparison a funding decision actually needs.
  • Tag spend on abandoned runs separately; it's usually the largest single lever and it's invisible in seat-based reporting.

What share of your agent spend goes to runs that nobody ended up using - and do you currently have any way to find out?


Sources referenced: Hacker News discussion on Garry Tan's AI agent token spending

Top comments (0)