AI
LLM Token Budget for a Small Engineering Team: Where It Goes
September 202612 min read
Photo by Nicolas1981 via Wikimedia Commons (CC BY-SA 3.0)
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.
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.
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.
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.
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.
Photo by Nicolas1981 via Wikimedia Commons (CC BY-SA 3.0)
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.
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 Session block the cost docs print for one session. Read the last two
# numbers first: they are the same conversation, sent again and again.
Total cost: $0.55
Total duration (API): 6m 20s
Total duration (wall): 6h 33m 10s
Usage by model:
claude-sonnet-4-6: 1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)
# 1.2k of that is what the developer typed. 940k is context re-sent.
# Wall time 6h 33m against 6m 20s of API time is the other tell: this is one
# session left open all day, so every turn carried everything before it.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.
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.
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.
# What every request in this repository carries before a file is opened.
wc -l -w -c CLAUDE.md ~/.claude/CLAUDE.md
# 398 2897 22748 CLAUDE.md
# 315 1865 14225 /Users/me/.claude/CLAUDE.md
# 713 4762 36973 total
# 36,973 characters is roughly 9,000 tokens at four characters per token.
# The docs ask for CLAUDE.md under 200 lines. The project file alone is 398,
# and the global file adds 315 that no project of mine can opt out of.
#
# 60 requests in a session x 9,000 tokens = 540,000 tokens of instructions,
# none of which are about the task in hand.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.
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.
# /usage prints this once the session has had a response back. It is the
# cheapest instrumentation you will ever install: it is already there.
Prompt cache (main): 14 requests - 91% of input tokens from cache
- 2 misses (last 6m 10s ago, 310.2k tokens re-cached)
- warm (1h TTL, last activity 40s ago)
# "91% of input tokens from cache" is the number to watch per session.
# A miss is counted when a request re-processed more than 5% and at least
# 2,000 tokens it could have read from cache.
# "310.2k tokens re-cached" was billed at the 1.25x five-minute write rate,
# so two misses are not a rounding error on a 300k-token prefix.
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.
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.
# .claude/agents/triage-search.md
# The model line saves money. The return contract saves more.
---
name: triage-search
description: Find which module owns a failing test. Returns a verdict, not excerpts.
tools: Read, Grep, Glob
model: haiku
---
Locate the file most likely to own the failing test named in the prompt.
Read whatever you need. None of it travels back with you.
Return exactly these three lines and nothing else:
file: one path
reason: one sentence, naming the symbol you matched on
next: the single command the main thread should run
# Wrong: "summarise what you found". A summary of nine files arrives as
# prose about nine files, and the main thread then re-sends that prose on
# every remaining turn -- which is most of what delegation was meant to avoid.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.
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.
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.
# Two variables and every session on this machine reports itself.
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=prometheus # scraped at localhost:9464/metrics
# claude_code.token.usage carries the two attributes a budget argument needs:
#
# type input | output | cacheRead | cacheCreation
# query_source main | subagent | auxiliary
#
# cacheRead over the sum of all four types is the share of input you are
# re-sending, per user, per model -- the same ratio /usage prints per session.
# query_source answers the question nobody can answer by feel: did delegation
# move work off the main thread, or did it just add a second bill?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.