Human Tokens: The cost of attention
Human attention is the most valuable resource in the building, and it is the scarce input in software delivery. Token spend arrives itemized to the penny, so it gets minimized. The engineer hours wrapped around it arrive on no invoice at all, so they get spent freely. Teams are optimizing the cheap, printed line item while the expensive, unprinted one runs uncapped.
The Slack test
Take the prompt someone gave the agent, verbatim, and paste it into Slack as a DM to a coworker. "hey build the billing thing." Nothing else. No repo, no acceptance criteria, no deadline.
You know what your coworker does with that. Confused emoji. A meeting invite. Or, if they're new and eager, three days of the wrong thing built confidently. The model does the third one immediately, and an hour later somebody posts that Claude sucks at billing.
"Claude is bad at X" usually decomposes into failures you'd diagnose on sight if a manager caused them:
- No context. The coworker equivalent is a contractor on day one, no repo access, no domain knowledge. You would never say "build the billing feature" to that person and walk away.
- No acceptance criteria. "Make it good" fails with people too. You don't notice, because the person asks a question first.
- No feedback loop. People one-shot an agent and judge the first draft. Nobody grades an engineer's first draft as their ceiling.
One concession before anyone offers it as a rebuttal: the clarifying question is the part humans do better, and it isn't a rounding error. A person spends four seconds asking "which billing, subscriptions or invoices?" and prevents the wrong build entirely. An agent spends real tokens producing a wrong build you then have to detect. That's a genuine gap in the tooling, and it's closable in the harness: a clarify-first gate that blocks the run until the question is answered, not just an instruction the model may skim past. My claim is about the distribution of failures, not about blame: most of the "Claude is bad at X" complaints I see are attached to prompts that would have failed a human too.
What agents changed is visibility. A vague spec to a person gets silently repaired by their context and their questions, and you never learn what it cost. A vague spec to an agent gets filled in with the agent's guesses instead of your colleague's context, and the distance between what you said and what you meant comes back as an itemized bill. The agent invoice is the first line-item statement anyone has ever received for their own communication.
The bottleneck moved
Price the humans the way the API prices the model. A fully loaded senior engineer runs about $150k of salary times 1.4 of overhead, call it $210k a year, call it $100 an hour. A token is roughly 0.75 words.
| Throughput | Cost per 1M tokens | |
|---|---|---|
| Human reading (input) | ~250 wpm ≈ 20k tokens/hr | ~$5,000 |
| Human typing at sustained maximum (output) | ~50 wpm ≈ 4k tokens/hr | ~$25,000 |
| Claude Opus 5 (current API pricing) | thousands of tokens/min | $5 in / $25 out |
Both human rows are ceilings. Nobody reads for eight straight hours and nobody types 50 words a minute all day, so real numbers are worse than these. The ceiling is enough to make the point: at a sustained working maximum, a human generates tokens about 1,000 times more expensively than the model does. The tool that runs this arithmetic on your own numbers is Human Tokens.
Most of a good engineering day is reading, deciding, and arguing, none of which shows up as words typed. (Why no "realistic daily output" row? See the claims I'm not making, below.)
So the sharpest person in the room asks the only question worth asking:
If generation got a thousand times cheaper, why hasn't engineering output gone up a thousand times?
Because the multiplier is per token, not per outcome. Generation collapsed in price. Verification, judgment, and coordination did not, and those are now what limits throughput. The cheap resource got cheaper and the expensive one didn't move, which means the whole game is how well you spend the expensive one.
One thing said plainly, because a room will infer the other version if you let it: this is an argument for protecting engineer attention, not for needing fewer engineers.
What the $50 feature actually cost
At those rates $50 buys around 2 million output tokens. The complaint I keep hearing is that a feature "cost $50 in tokens," delivered with the outrage of a surprise utility bill.
$50 was never the price. The price is the tokens plus the human time wrapped around them: writing the spec, reading the diff, sending it back, reading it again. Two hours of that is $200. Count the runs you threw away too, because you remember the accepted run and forget the two you killed at minute three, and those still cost spec time and tokens. So call the feature $250. Against two loaded engineer-days at $1,600, that's a good trade. It's roughly a 6x trade, not the 30x one you get by comparing tokens to salary and pretending supervision is free. The smaller number is the one that survives a hostile question.
The prompt is human tokens too
The spec is human output, billed at the human rate. A careful 500-word prompt is half an hour of loaded engineer time, about $50 of the priciest tokens a team buys, and frequently more than the agent's entire bill for the task it produces.
Cost per outcome = (human tokens × ~$25,000/M) + (agent tokens × $25/M)
(The human coefficient is the typing ceiling. Careful composition runs about triple, which is how that 500-word prompt gets to $50.)
The first term is a thousand times pricier, so every optimization worth doing is the same optimization: reduce the marginal human tokens per outcome. There are two ways to spend a human token.
- Consumed. A one-off prompt. You pay the full spec cost on every run, forever.
- Capitalized. A skill, a CLAUDE.md, a checklist, a script. Written once at the human rate, then re-read by agents indefinitely at $5 per million, about a tenth of that when cached. Per-outcome human cost divides by the number of uses and trends toward zero.
The case for writing things down usually gets made as taste. It's accounting. Written context converts human token spend from an operating cost into a capital asset: pay the expensive judgment once, replay it mechanically.
The onboarding comparison is usually rigged in the agent's favor, so run it straight. A human acquires context once over months and then uses it free for years. An agent re-buys context every session. Caching cheapens the re-reads inside a session, and across sessions the context gets bought again at full price. Per unit of context, the human is the better deal. Where written context wins is elsewhere: a person's onboarding lives in their head and leaves when they do, while a skill can be read, diffed, corrected, and handed to every agent at once. One is amortized per human. The other is amortized per fleet.
What I'm not claiming
- No human output-per-day figure. Knowledge-work value isn't authored tokens, and any number I picked would deserve the objection it got.
- No claim that an agent "read" your codebase the way you read a book. Long-context degradation is real. What it does is locate and use information across a corpus nobody could skim in the time available, which is a different and sufficient claim.
- The clarifying-question gap is real, and it's a defect in current tooling rather than proof that users are the problem.
Spend it where it pays
Right now most teams spend the expensive token flat: every PR gets a reviewer and roughly the same attention, whether the diff renames a CSS class or alters a payment path. Once you've priced the attention, the next question writes itself: where does it actually pay?
That question has its own essay: Agents review everything, humans review red. Different budget, same money.