# LLM Token Budget for a Small Engineering Team: Where It Goes

> An agentic coding bill tracks the context you re-send, not the code you produce. The four consumers of a token budget, and which you pay for every turn.

URL: https://www.matthewswong.com/en/blog/llm-token-budget-engineering-team/

- Author: Matthews Wong (https://www.matthewswong.com/en/about/)
- Published: 2026-09-12
- Updated: 2026-09-12
- Category: AI

> **Key takeaway:** An agentic coding budget scales with the context re-sent per turn, not with the code produced. Always-loaded instructions and conversation history are paid on every request, a bulky tool result joins the prefix permanently, and only the completion is paid once. Prompt caching charges cached reads at 0.1x base input rather than nothing, so instrument before optimising.

The number that started this was 22,748 — the byte count of the CLAUDE.md in this repository. I measured it while trying to work out why the cheapest-looking sessions were not the cheapest ones, and the arithmetic was immediate. Those bytes, plus a global instruction file of another 14,225, ride along in every request a session makes, whether the request is a three-character typo fix or a refactor across nine files. Nothing about that cost is proportional to the code that comes out of it.

This post is about where a small team's agentic coding budget actually goes, argued from the four things that consume it. The intuition that spend tracks generated code is wrong, and it is wrong in a way that changes what you do about it. Every mechanic here comes from Anthropic's own documentation — the cost page, the prompt caching reference, the subagent and telemetry pages — and every number is either quoted from those or measured with wc on this repository.

## The bill is turns times context, not lines of code

One line of usage output shows the whole shape of the problem. The example the cost documentation prints for a single session reads 1.2k input, 5.3k output, 940.0k cache read and 50.0k cache write. The fresh input — what the developer actually typed that session — is a rounding error against 940,000 tokens of context read back out of the cache. The unit of cost in an agentic session is the turn, and the size of each turn is whatever the conversation had grown to by the time that turn fired.

The documentation's budgeting figures follow from that shape: around 13 US dollars per developer per active day and 150 to 250 dollars per developer per month across enterprise deployments, with 90 per cent of users staying under 30 dollars per active day. The useful part of that spread is the tail. One developer in ten sits above the 30-dollar line, and it is rarely the one shipping the most code — it is the one who leaves a session open all day, because the full conversation is sent with every request and each tool call sends another request carrying its results.

## Four consumers, and only one of them is your code

Split the bill into four consumers and the leverage becomes obvious, because two of them are paid once and two are paid on every single request. The difference between those two classes decides a monthly bill far more than any prompt-writing habit does.

| Consumer | When you pay for it | What controls its size |
| --- | --- | --- |
| Always-loaded instructions | Every request, from session start | Lines of CLAUDE.md, plus whatever tool and server definitions load eagerly |
| Conversation history | Every request, in full | How long you go before clearing, and how much of it is tool output rather than talk |
| Tool results | Once on arrival, then on every request after it | Whether a file dump lands in the main thread or inside a subagent |
| The completion | Once, at the output rate | Length of the reply plus the thinking budget, which is billed as output |

The third row is the one that surprises people. A grep that returns forty file excerpts is not a one-off charge. Those excerpts are now part of the conversation, so they are re-sent for the rest of the session — sixty more turns carrying evidence you finished with on turn four. The fourth row has a trap of its own: extended thinking is billed as output tokens, and the default budget can run to tens of thousands of tokens per request depending on the model.

## My instruction footprint was twice the documented target

The always-loaded row is the one you can fix this afternoon, because it is a file you own. CLAUDE.md is read into context at session start, so every line in it is present on every request whether or not the current task has anything to do with it. The documented target is to keep that file under 200 lines by including only essentials. I measured mine rather than guessing.

Roughly 9,000 tokens, on every request, before a single file is read. Sixty requests in a working session is 540,000 tokens of instruction re-send, and that is the honest way to read a cache hit — cached reads are charged at 0.1x the base input price, not at zero. The fix is relocation, not deletion. Skills load on demand only when invoked, so moving the parts of an instruction file that serve one specific workflow into a skill keeps them available while taking them out of the per-request floor.

> Relocation only pays if the destination is genuinely conditional. Moving 200 lines into a skill that every session invokes anyway moves those tokens later in the request rather than out of it, and now costs a tool call to fetch them. Check which of your skills actually stay dormant during ordinary work before congratulating yourself on a shorter CLAUDE.md.

## Caching makes the re-send cheap, not free

Prompt caching is what makes an agentic session affordable at all, and the mechanics are worth stating precisely, because the vague version leads teams to stop caring about context size. Cache reads are charged at 0.1x the base input price. A five-minute cache write is 1.25x that price and a one-hour write is 2x. Hits require the prompt segments to be 100 per cent identical up to and including the cached block, and the cache follows a hierarchy of tools, then system, then messages, where a change at one level invalidates that level and everything after it.

Two consequences for a budget. First, the prefix has to be stable to be worth anything, so anything that rewrites the front of a request — an edited tool definition, a server toggled on — pays the write premium again on the next turn. Second, a gap is a cost event. The lifetime is measured from the start of the request that writes or reads the entry and is refreshed for free on every use, so an active session stays warm; when it lapses, the next message reprocesses the whole context at the write rate. On an API key or a cloud provider the default lifetime is five minutes, and lunch is longer than five minutes.

*The band to argue about is the tool result: it is charged once on arrival and then carried in the re-sent prefix for every remaining turn of the session.*

## A cheaper model is a correctness decision, not a concession

The framing that wastes money is treating model choice as a quality dial you turn down once the bill arrives. The better question is whether a task has a verifiable answer that a smaller model can reach, because when it does, the larger model is not buying accuracy — it is buying a longer thinking budget nobody needed. The documentation is blunt about the default: Sonnet handles most coding tasks well and costs less than Opus, and Opus is for complex architectural decisions and multi-step reasoning. Four task classes belong on the cheaper model on merit.

- Mechanical edits with one right answer — renaming a symbol across files, adding a missing null check, applying a codemod the compiler will grade for you.
- Generated boilerplate text — commit messages, changelog entries, a docstring derived from a signature. The reviewer is the diff, and the diff is in front of you.
- First-pass triage — which module owns a failing test, which of nine candidate files mentions a config key. The grader is the test run immediately afterwards.
- Bulk transformation of structured input — folding a log dump into a table, extracting the failures out of test output. The shape is fixed, so the answer is checkable.

What those four share is a cheap grader. When the compiler, the test suite or the diff tells you within seconds whether the output is right, a wrong answer costs a retry rather than a bad merge, so the expected cost of the smaller model really is lower and not merely its list price. Subagents take a model field, which makes this configuration rather than discipline. Effort is the other dial: lower it with the effort command for simple work, and on models with a fixed thinking budget set MAX_THINKING_TOKENS, remembering that adaptive-reasoning models ignore a nonzero budget and want an effort level instead.

## Delegation is a cost control because a summary is never re-sent

Delegating verbose work to a subagent is usually explained as a context-window trick — the noise stays out of the main conversation. The budget version of the argument is stronger. Isolating high-volume operations keeps the verbose output in the subagent's context while only the relevant summary returns, and because the main thread's prefix is re-sent on every later turn, the saving is not the difference in one request. It is that difference multiplied by every turn left in the session.

Which is why the return contract matters more than the act of delegating. A subagent that reads nine files and hands back a verdict has moved nine files off the recurring bill; one that hands back the excerpts it read has moved nothing and added a second inference to pay for. Delegation also has a ceiling. Agent teams spawn a separate instance per teammate, each with its own context window, and the documentation puts them at roughly 7x the tokens of a standard session when teammates run in plan mode. A narrow subagent with a three-line contract and a team of five are not the same instrument.

> Write the return contract into the subagent definition as an exact output shape — three named lines, or a single verdict — rather than asking for a summary. A summary of nine files tends to arrive as prose about nine files, which is most of what you were trying not to pay for on every subsequent turn.

## Per seat or pooled is an organisational answer, not a technical one

Teams ask whether to give each developer their own budget or pool it, and the mechanics only get you halfway. On a Claude for Teams or Enterprise plan, each member's usage draws from a per-seat allowance that resets on a rolling five-hour window and a weekly window, shared with Claude chat, so the seat is the unit whether you like it or not. On the Console, usage is billed per token to the organisation through a workspace that carries its own spend limits, so there the pool is the unit and per-user numbers come from the dashboard or the analytics API.

Concurrency is where it gets interesting. The documented per-user rate-limit recommendation falls from 200k to 300k tokens per minute at one to five users, down to 15k to 20k at 100 to 500 users, because fewer people use the tool at the same moment as a team grows. Those limits apply at the organisation level rather than per person, so an individual can temporarily consume more than their calculated share while colleagues are idle. On pure efficiency that argues for pooling. The counter-argument is not technical: in a pool, one runaway loop is everyone's problem, and no report will tell you whose loop it was unless you set up attribution first. If you pay contracted rates, set the modelPricing managed setting so the figures your developers read match the invoice you receive.

*Notice that the inline panel has the cheapest single turn and the dearest session, which is exactly the trade that a per-turn view of cost hides from you.*

## Instrument before you optimise

Every recommendation above is conditional on which consumer dominates your team's sessions, and that varies by codebase, tooling and habit. Guessing is the expensive part: a team that spends a morning trimming its CLAUDE.md when the spend was really in forty-file tool results has done real work and changed nothing. Measure first, then pick the consumer with the largest share, then change one thing.

Three numbers are enough to start. Tokens per session, viewed as a distribution rather than a mean — the documented one user in ten above 30 dollars per active day is exactly the population worth reading. The share of input served from cache, which the usage command now prints directly, alongside the miss count and whether the cache is warm right now. And the split by query source, which is the only honest test of whether delegation moved work off the main thread. For a team, OpenTelemetry export is the one route that streams per-user token and cost metrics into your own stack on every provider, and the insights command writes a local report over up to 200 recent sessions if you want the qualitative picture first.

The rule I apply now, before changing anything, is to name the consumer and then name whether it is paid once or on every turn. Almost every change that worked moved tokens from the second class to the first — instructions into a skill, evidence into a subagent, a finished task into a fresh session. Almost every change that did nothing was a slightly smaller version of something I was already paying for sixty times over.

## Sources

- Claude Code documentation — Manage costs effectively
- Claude API documentation — Prompt caching
- Claude Code documentation — Monitoring usage with OpenTelemetry
- Claude Code documentation — Subagents
- Claude Code documentation — Model configuration

## Source links

- https://code.claude.com/docs/en/costs
- https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- https://code.claude.com/docs/en/monitoring-usage
- https://code.claude.com/docs/en/sub-agents
- https://code.claude.com/docs/en/model-config

## FAQ

### What actually drives the cost of an agentic coding session?

The number of turns multiplied by the size of the context each turn carries, not the amount of code produced. The full conversation is sent with every request, and each tool call sends another request carrying its results, so a long session that writes one line can outspend a short one that writes a module. The session example in Anthropic's cost documentation shows 1.2k fresh input tokens against 940k read back out of cache, which is the whole argument in one line.

### Does prompt caching make a long-running session effectively free?

No, it makes the re-send cheap. Cache reads are charged at 0.1x the base input token price, so a big prefix read sixty times is still real spend. Writes cost more than a normal input token, at 1.25x for the five-minute lifetime and 2x for the one-hour lifetime, so every cache miss also carries a premium.

### How much should we budget per developer for agentic coding?

Anthropic's cost page reports around 13 US dollars per developer per active day and 150 to 250 dollars per developer per month across enterprise deployments, with costs staying under 30 dollars per active day for 90 per cent of users. Treat those as a starting point, not a forecast, because the spread is wide and depends on model choice, codebase size and session habits. The documented advice is to run a small pilot group and measure your own baseline before a wider rollout.

### Is putting some tasks on a cheaper model a quality compromise?

Not when the task has a cheap grader. Mechanical edits, commit messages, first-pass triage and bulk transformation of structured input are all checked in seconds by a compiler, a test run or the diff itself, so a wrong answer costs a retry rather than a bad merge. The documentation's own default is that Sonnet handles most coding tasks well and Opus is reserved for complex architectural decisions, and a subagent takes a model field so the routing is configuration rather than discipline.

### Should each developer have their own token budget, or should we pool it?

That is an organisational decision more than a technical one. On Teams and Enterprise plans usage draws from a per-seat allowance on rolling five-hour and weekly windows, while on the Console it is billed per token to the organisation through a workspace with its own spend limits. Rate limits apply at the organisation level, so pooling is more efficient when usage is bursty, but it also means one runaway loop is everyone's problem unless per-user attribution is set up first.

---

- HTML version: https://www.matthewswong.com/en/blog/llm-token-budget-engineering-team/
- Bahasa Indonesia: https://www.matthewswong.com/id/blog/llm-token-budget-engineering-team/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json