Claude Code Token Usage: What Your Team Can and Cannot See

Search “Claude Code token usage” and the first page is one developer looking at one session on one laptop. Anthropic’s own cost page is the best of it, a long inventory of every lever and every report. The rest is token hygiene: switch to Sonnet, lower the effort, clear the context, trim your CLAUDE.md, install a usage tracker. All of it is correct, and none of it answers the question that makes an engineering leader type the query, which is not “why did my session cost $4” but “we have thirty developers on this, what are they spending, on what, and did it ship anything”.

This post starts where the ranking pages start, with where the tokens go, because the mechanics explain most of the surprise. Then it works up a level at a time: what a developer can see, what a manager can see, where every one of those reports stops, and how YAGNI puts developers and Agents on one Usage page that answers in tickets rather than tokens. Every price and feature below was read from Anthropic’s own pages on October 21, 2026, and is linked, because they move.

Where do Claude Code tokens actually go?

Three facts about how Claude Code bills explain nearly every “why was that so expensive” moment.

Every turn resends the whole conversation. Per Anthropic’s prompt caching docs, the CLI sends the full context to the model on each request: the system prompt, your CLAUDE.md, every tool definition and MCP server schema, every file it has read, and every earlier turn. Your new message is a rounding error on top. Input tokens, not output, are where the usage lives.

Most of that input is served from the prompt cache, until it is not. The prefix that has not changed since the last turn is read from cache at a fraction of the input price. On Anthropic’s pricing page, as of October 2026, Opus 5.5 is $4 per million input tokens, $20 per million output tokens, $5 per million to write the five-minute cache, and $0.20 per million to read it. A change anywhere in the prefix recomputes everything after it: switching models, changing effort, adding an MCP server, or compacting. On a subscription the main conversation’s cache lives for an hour within plan usage; on an API key or on usage credits it is five minutes, and subagents get five minutes even on a subscription.

Output includes thinking. The visible answer and the tool calls are output tokens, and so is the model’s reasoning, which Anthropic bills as output. The token count that spins in the status line is the output of the current turn only; it does not show what Claude Code sent.

Here is one turn, late in a session with 80,000 tokens of accumulated context, a 1,500-token question, and 2,000 tokens of output and thinking, priced on Opus 5.5 at the list prices above:

What the turn sends	Warm cache (the turn before was minutes ago)	Cold cache (first turn, or after a break on the API)
80,000 tokens of context	Cache read, $0.016	Cache write, $0.40
1,500 tokens of new input	Cache write, $0.0075	Cache write, $0.0075
2,000 tokens of output and thinking	$0.04	$0.04
The turn	About $0.06	About $0.45

The same question costs seven times more after lunch. Multiply by forty turns a session and a context that grows with every file read, and a developer’s afternoon on an API key is a few dollars on a warm cache and tens of dollars on a cold one. Anthropic’s own benchmark, on its cost page, is about $13 per developer per active day and $150 to $250 per developer per month across enterprise deployments, with 90% of users under $30 a day.

Why does usage climb in a long session?

Anthropic’s cost page has a section with this title, and it is the most useful part of the SERP, so here is the short version.

• The context is the bill. A one-line question in a session that has been open all day draws usage for the whole conversation. /clear between unrelated tasks costs nothing and resets the whole base.
• A break costs a cache miss. Walk away past the cache window and the next turn reprocesses everything at the full input price. /compact after a cold cache does the same, once, on purpose.
• Subagents start from zero. A subagent runs in its own context window, its first request reads none of the parent’s cache, and its cache lives five minutes. The CLI’s own multi-instance feature, several sessions working together as teammates, uses about seven times the tokens of a standard session when the teammates run in plan mode, per the same page.
• Background work is usage too. Scheduled tasks, goal check-ins, and cross-session messages each draw on the allowance when they fire, though Anthropic puts background use at typically under $0.04 a session.
• The default model is the expensive one. Since CLI version 2.1.280 the default on every plan is Opus 5.5, per Anthropic’s model configuration docs, and the default context window is a million tokens, auto-compacting at about 967,000. A session that would once have hit the 200,000-token wall and compacted now keeps growing, at the same per-token price, until it is enormous.

None of this is a defect. It is what an agent that reads your repository and remembers the conversation costs. The problem is that most of it is invisible to the person paying for it.

How do you check your own Claude Code token usage?

Inside a session, /usage is the whole toolkit, per Anthropic’s command reference. /cost and /stats are aliases. It shows, as of October 2026:

• The session block. Input, output, cache read and cache write tokens per model, with a dollar figure the CLI computes locally at list price. Anthropic’s own caveat: the figure is an estimate, the Console usage page is authoritative, and on Pro and Max “the session cost figure isn’t relevant for billing purposes”, because plan usage is included.
• The plan usage breakdown. On Pro, Max, Team and Enterprise, what is counting against the five-hour and weekly limits, attributed to skills, subagents, plugins and individual MCP servers, with recommendations such as trimming a 49,000-token CLAUDE.md. The figures come from local session history on that machine, so other devices and claude.ai are not included.
• /context. A grid of what is in the context window right now, with the heavy tools and memory bloat called out.

Outside a session, the open-source ccusage reads the same local history and turns it into daily, weekly, monthly and session reports, with the five-hour billing blocks drawn in. It is one developer’s view of one machine, by design: the costs are estimates from token counts and public prices, and the CLI keeps its logs for 30 days by default, so the history is short.

This is where the ranking pages stop, and for a solo developer it is enough. A manager needs the next level.

How does an engineering manager see Claude Code usage across a team?

Anthropic offers five reports, and which ones you get depends on how your org pays. All five, as of October 2026, from the cost page, the analytics page and the monitoring page:

Report	Who gets it	What it shows	What it leaves out
Spend report in org analytics	Team and Enterprise plans	Estimated spend per user and per model, CSV export, refreshed daily with a one-day delay	Usage inside the seat allowance, which is never metered in dollars. It shows usage-credit spend only, and only once credits are turned on
Claude Code Analytics dashboard	Team and Enterprise plans	Lines of code accepted, suggestion accept rate, daily active users, sessions, commits and pull requests with the GitHub integration	Token counts and cost per user. For those, Anthropic points you at OpenTelemetry or the spend report
Enterprise Analytics API	Enterprise plan only, Admin API key	Daily per-user records: sessions, lines added and removed, commits, pull requests, tokens by type per model, estimated cost in cents	Everything on a subscription seat. The API covers API usage only and is “not available on the Teams plan”
OpenTelemetry export	Any setup where the developer enables it	claude_code.cost.usage and claude_code.token.usage with user, model, terminal, agent, skill and MCP server attributes, near real time	A stack to send it to, and a developer who did not turn it off. Anthropic calls the cost metrics approximations
Console usage page	API key accounts	Spend this month per user, workspace spend limits	The seats, if the same developers also have them

Two things follow. First, if your developers are on Team seats, the honest answer to “what did Priya spend on Claude Code last month” is “we do not know, unless she ran out of allowance and bought credits”. The seat hides it. Second, the moment your org adds anything that runs unattended, a review in CI or an agent on a schedule, it needs its own API key, which is a second meter with its own report. We did the seat arithmetic in the Claude Code Team plan and the per-plan prices in how much Claude Code costs; the short version is that the cheapest plan is also the one you can see least of, and YAGNI was built for the people who noticed.

What can none of these reports tell you?

Every report above has the same shape: a person, a model, a day, a number. That is the grain the vendor meters in. It is not the grain a manager budgets in.

Spend per unit of work. A manager asks what the payments migration cost, whether the retry loop on the checkout bug was two attempts or nine, and whether the plan review on Tuesday saved the build it sent back. The spend CSV answers none of those. It says a developer spent $38 on Opus. Translating people and models into tickets and releases is a spreadsheet someone maintains by hand, until they stop. On YAGNI the translation is the case file.

Retries. The expensive token is the one spent redoing work. A session that starts from the wrong assumption about why the ticket exists costs a build, a review, a send-back and a second build, and the reviewer’s hour is the part no meter sees. No usage report distinguishes a clean build from four retries of the same change. The fix is not a cheaper model but context: a YAGNI Agent reads the decision ledger behind the ticket before it plans, and does not take the round trip. Context engineering for coding agents is the long version.

One meter. Developers on seats, automation on an API key, and a third bill if anyone also runs Codex or Cursor. Nowhere do a developer’s session and an agent’s work sit side by side on one page, priced the same way.

That gap is what YAGNI’s Usage page is built around, so the rest of this post is about the meter.

How does YAGNI show spend per developer and per Agent?

YAGNI is additive to Claude Code, not a replacement for it. It reads the GitHub, Jira, Linear and Slack the team already pays for and ships approved work back into them. Two things change: what the session runs on, and what the record shows.

The same Claude Code, on YAGNI’s meter. YAGNI Code is the developer’s own coding agent, a CLI and desktop app on vetted US-hosted open-weight models at 60% or more under comparable frontier API rates. The same routing is open to Claude Code through YAGNI’s wire adapter, one command from the terminal:

yagni connect claude-code

It writes Claude Code’s own settings file, so the developer keeps the CLI, their CLAUDE.md, their skills and MCP servers, and the workflow they have. After a restart the session runs on YAGNI’s models, and every token it spends lands on YAGNI’s Usage page beside everyone else’s. A router places each step of the work on the cheapest of four lanes that holds quality; the LLM router post walks through a ticket step by step. YAGNI publishes no rate numbers, and does not say which models serve which lane; the rate card is shared on a call, and the only public claim is the floor.

No seats. A developer with zero usage costs zero. There is nothing hidden inside an allowance because there is no allowance: every developer and every Agent is metered on the one rate card, so the “we do not know” answer above does not exist on YAGNI.

The Usage page. It is the report an admin forwards upward: spend, the parked-at-frontier benchmark, and savings, per developer and per Agent, on the one rate card, with each Agent’s spend broken out by the job that spent it. It opens on a matrix, Teams as rows and Agents as columns, with totals both ways and a toggle that reprices the same work at the parked-at-frontier benchmark, so the savings column is arithmetic rather than a brochure claim. Open an Agent and the page lists its largest runs, each with the pull request it belongs to. A member sees their own spend without admin access; the sidebar meter is its first line.

The brakes are a person’s. A daily spend ceiling in YAGNI’s Workspace settings stops the meter, per-developer budgets sit under Spending, and a Team’s Pause stops every job on the Team at once.

What does a ticket cost when an Agent Team carries it?

The per-ticket answer comes from the Team. An Agent Team on YAGNI mirrors one of your engineering teams and reports to one accountable person. A ticket moves through six stages, each owned by one Agent: Bailey, the Product Manager, proposes it from the backlog in Jira or Linear with evidence; Reeve, the Staff Engineer, plans it, reading the ticket, the linked Slack thread and the Team’s decision ledger first; a person approves the plan; Wright, the Builder, builds it to a draft pull request in a sandbox; Proctor, the Reviewer, posts one review a person can read; Fletcher, in beta, boots the environment and walks the change in a browser; a person merges; and Harper, the Chronicler, posts what shipped to Slack with the receipts attached.

Every one of those runs is metered on the same rate card as the developers, and the ticket’s case file shows what the workspace was charged for each of them. So the questions the spend CSV cannot answer are rows on a page:

The manager’s question	Where the answer is on YAGNI
What did PAY-212 cost, end to end?	The ticket’s case file: the proposal run, the plan, each build run, the review, the QA walk, and the total
Was the plan send-back cheaper than the build it prevented?	Two rows on the same case file
What did Proctor’s reviews on the checkout repository cost this month?	The Agent drill on Usage, by job, with each review’s pull request
What does Priya’s Claude Code spend look like next to the Team’s?	The same Usage page, the same rate card, one range
Which developers and Agents are over budget?	Per-developer budgets under Spending, the daily ceiling, and the sidebar meter

The three clicks of a supervised ticket, accept the proposal, approve the plan, merge, do not change with the price of the lane. The meter decides what the work cost. It never decides whether the work ships. AI tools for engineering managers shows the same page from a manager’s morning.

How do you cut Claude Code token usage without losing the work?

Anthropic’s levers first, because they are free and they work, all from the cost page:

1. /clear between unrelated tasks. The context is the bill, and a fresh session costs nothing.
2. /model to Sonnet 5.5 for routine work and keep Opus 5.5 for architecture and multi-step reasoning. On the pricing page above, that halves the input and output price on every turn.
3. /effort down where the task is mechanical; thinking is billed as output.
4. Keep CLAUDE.md under about 200 lines and move the rest into skills that load on demand, and check /context when a session feels heavy.
5. Point subagents at Haiku 5.5 and give /compact instructions about what to keep.

Then the two levers no setting reaches. Context that prevents the retry: an agent that reads the Team’s decisions and the thread behind the ticket before it plans produces less off-target work, and off-target work is the expensive token. A meter that answers in tickets: a manager who can read what each ticket cost has a different budget conversation than one holding a per-model CSV.

Both are what YAGNI sells. Your developers keep Claude Code and run it on YAGNI’s models at 60% or more under comparable frontier API rates. The Agents on a Team take tickets from the backlog to a merged pull request under a plan a person approved. All of it lands on one Usage page, per developer and per Agent, broken out by job. If you want it run on your team’s numbers, book 30 minutes and bring your current plan and the number of active developers; we will send the arithmetic back, and the rate card with it. The offer itself is on the home page. The guide to what AI coding tools cost is where this meter sits inside the whole bill.