'Just Refactor This' Cost 40,000 Tokens — and Nobody Noticed Until the Bill Did

Day 1: The Token — What Your Agent Actually Spends When It Works

Hand an agent a task and something gets spent — not just money, attention too. Until you can eyeball roughly how many tokens a task should cost, you have no way to tell a normal run from one that's quietly gone off the rails. You'll only find out when the bill lands, or the context window slams shut mid-task.

Here's what plays out on almost every team in month one of using agents seriously. Someone drops a one-line PR comment — 'just refactor this.' The agent opens the file, then the files that import it, then the tests, then re-reads the whole pile again next turn, because the conversation carries forward every time. Forty minutes later: done. Quietly: 40,000 tokens burned. Nobody sized the task going in, so nobody noticed anything was off — until someone checked the usage dashboard, or the agent hit a wall mid-task.

What a token actually is

Forget the tokenizer internals for now — here's the version you actually need day to day. A token is roughly a word-chunk. Short, common words are usually one token; longer or rarer ones split into two or three. 'Refactor' is probably one token; 'unauthenticated' is probably three. Rough rule of thumb: 100 tokens ≈ 75 words of English.

• ▹Tokens are the billing unit — every model call is priced per token, input and output counted separately.
• ▹Tokens are the space unit too — a model's context window (how much it can 'see' at once) is measured in tokens, not characters or files.
• ▹Code tokenizes worse than prose — symbols, indentation, and identifier names often cost more tokens per character than plain English does.
• ▹Every turn resends the whole conversation so far as input — that's the real reason a long agent session gets expensive even when you never repeat yourself.

Why 'just refactor this' is deceptive

The instruction itself is cheap — 'just refactor this' is four tokens, tops. But the cost was never in what you typed. It's in what the agent has to do to satisfy it: open the file, open everything that imports it, open the tests, hold all of that in its head while it works out what 'refactor' should even mean here, then write the diff back out. Reading costs tokens. Carrying context across turns costs tokens — resent in full, every single turn. Reasoning costs tokens, especially for models that think a problem through before answering. Writing the output costs tokens. A four-word ask can trigger a long, expensive chain of actions, and that gap between what you typed and what it actually took is exactly where the surprise bill hides.

A rough mental model: what should this cost?

You don't need precision here — just a ballpark good enough that a number can actually surprise you. These are rough total-token ranges (input plus output, including everything resent across turns) for a single agent task:

• ▹Small — one file, a narrow fix, a rename, a one-line logic change: roughly 2,000–10,000 tokens.
• ▹Medium — a module-level refactor, a small feature across 3–8 files, adding tests to existing code: roughly 15,000–60,000 tokens.
• ▹Large — a cross-cutting refactor, anything touching multiple services or a big shared file, anything needing several back-and-forth turns: 60,000–300,000+ tokens, and you may need to reset context partway through.
• ▹If a task you'd have called 'small' comes in at 'large' numbers, that's a signal, not a shrug — either the ask was underspecified, the agent wandered down a wrong path, or it's reading far more than the task actually needs.

The management gap

Engineering teams spent the better part of a decade building the instinct for story points — how big is this ticket, how many days will a person need. Almost nobody has built the equivalent gut feel for agent-token-time. That's not a tooling problem — the usage dashboards already exist. It's a skill nobody's practiced yet: looking at a task and forming an expectation for what it should cost before you hand it off. Skip that step and one of two things happens. Either you get blindsided by the bill, or you overcorrect and start micromanaging every single agent call out of fear — which kills the exact productivity gain you brought agents in for.

Takeaway for Day 1

Before you hand a task to an agent, ask yourself 'what should this cost' the same reflexive way you'd ask 'how big is this ticket.' If the actual run comes in wildly over your estimate, treat that as a signal to stop and look — not a bill to shrug off. Tomorrow: why that cost has a hard ceiling on every single turn — the context window — and what happens the moment a task slams into it.

Extend your knowledge

• ▹If you use Claude Code, run /cost after a real task and compare the actual token count to the ballpark you guessed before you checked.
• ▹Read Anthropic's documentation on tokens and pricing to see exactly how input vs. output and context-window limits are defined for the models your team runs.
• ▹Pick one recent 'quick fix' PR comment your team handed an agent and reconstruct roughly how many files it must have read to satisfy it — that's your real cost driver, not the words in the comment.
• ▹Run this for one week: before assigning any agent task, write down small/medium/large. Check the actual usage afterward. Note where you were wrong.