Token Economics Starts With What a Session Carries

When a team’s Claude Code bill comes in higher than expected, Anthropic’s documentation names the usual suspects. Unexpected spend on per-token billing, it says, “usually traces back to long sessions that were never cleared or to Opus left as the default model.”

The reason sits in how the tool works. Claude Code “sends your full conversation with every request,” so the history rides along with every question, every file it reads and every tool it runs. Most of that history is re-read from a cache at a much lower rate, which keeps a long session far cheaper than it would otherwise be. But the cache doesn’t last. After a break longer than its lifetime, five minutes by default on per-token billing, the next message “reprocesses your full context” without the cache discount. And the cheaper rate is still charged on everything the session has piled up. The documentation puts it simply: “Token costs scale with context size.”

That’s where token economics meets your teams’ daily work, and the usual instinct about it is only partly right. That instinct says trimming what an AI tool carries saves money at the cost of quality, so the careful choice is to keep everything in. Anthropic’s own engineers describe a pressure running the other way, which they call context rot: “as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.”

So a session that drags everything along can cost more and get less sharp. What follows is a routine designed to cut what a session carries without cutting what the next task needs, and a way to check on your own work whether it does both.

What a session pays for

Models are priced by the token, a small chunk of text, and each request is paid on input and output. Input is everything the model is given for that request: the standing instructions, the conversation so far, the files and tool results it has pulled in. Output is what it writes back, including any reasoning it does first, and output costs more. On Anthropic’s price list, Claude Opus 5.5 charges $4 per million input tokens and $20 per million output tokens, Claude Sonnet 5.5 charges $2 and $10, and on both a cache hit costs 5% of the base input price.

How that reaches your company depends on how you buy. A team on per-token billing, through the API or a cloud provider, sees it as spend. On Anthropic’s Team and Enterprise plans, Claude Code usage draws from each member’s seat allowance instead, so a heavy session uses that allowance up faster rather than adding to an invoice, unless the company has turned on usage beyond it.

Most of this stays out of sight unless someone runs Claude Code’s /usage command or opens the plan’s usage report. Whether a smaller model is good enough for a given job is its own question, one we took up in asking the phase rather than the model.

A routine for leaner sessions

Run it as a pilot before anyone writes it into a standard, because we haven’t tested it as a whole, and none of the sources it draws on did either. The commands are Claude Code’s, since its documentation is specific enough to cite. If your team works in Cursor or another tool, the commands may differ, but the reasoning carries over. The steps follow the life of a session: what you decide before it starts, what loads every time, what each request adds, and what to do when it fills up. Two people carry it. You commission the pilot and make the call at the end. A technical owner runs it, from setting it up to logging the results.

1. Pick one workflow and decide what counts as done. Choose a piece of work your team repeats, such as a class of bug fixes or a recurring report, and write down the bar a result has to clear to be accepted. Name the technical owner who’ll run the pilot. They fix the default model and its effort setting, how hard it reasons before answering, so neither changes halfway. That’s also why Anthropic’s other suspect, the default model, stays out of this pilot: change it at the same time and you can’t tell which change did the work. Then, before changing anything else, they log a couple of weeks of those tasks as they run today: how many cleared the bar, how much rework they needed and how long they took. That’s your before.

Without that bar, the only thing you can measure is usage, and less usage might just mean less work.

2. Fix what loads every time, then keep it apart from what’s true today. Of everything a session carries, start here, since it’s the part your team writes that’s paid on every request of every session. Claude Code loads standing instructions from files when a session starts, and two of them matter most here. A personal one (~/.claude/CLAUDE.md) holds working preferences that apply across all your projects. A project one (CLAUDE.md in the project’s folder) holds what anyone on that project needs: what it’s for, its conventions, the decisions that stand.

Anthropic suggests keeping each file under 200 lines, and its documentation says Claude treats these files “as context, not enforced configuration,” so an instruction like “ask before deleting files” is guidance, not a lock. Claude Code also keeps an auto memory, notes it writes itself from your corrections, which raises its own question of where an agent keeps what it learns.

What changes day to day belongs somewhere else, in a short handoff note: where the work stands, what’s still open, where the evidence is and what comes next. Put “next step” into the standing file and it’ll still be sitting there, wrong, three weeks later.

The standing file also shapes every answer, and every answer joins the history the next request carries. Here are five lines from a real personal file written to save tokens, quoted as written:

Skip acknowledgments (“Got it”, “Sure”).

No repeating the user’s question back.

Answer only what was asked. Skip context, alternatives, caveats unless requested.

No defensive error handling unless asked.

Prefer short answers. One line beats three.

Sort them one by one. The first two cut output and lose little in a running conversation. The next two save tokens by cutting things the work may need: the caveat that would have stopped a bad call, the error handling a production system can’t do without. The last is fine for a quick question and wrong for a design review. Then do the same with every line of your own file: keep, narrow or delete.

One more check belongs here, because these files are paid for again and again. The same text splits into a different number of tokens depending on the language it’s written in and the model reading it. Anthropic’s glossary says the number of characters a token represents “depends on the model and the language,” and that its newer tokenizer, the part that splits text into tokens, produces about 30 percent more tokens for the same text than earlier models. If your team keeps standing files and specs in more than one language, count them in each before you decide which one they live in. Anthropic’s token-counting tool is free and counts with the tokenizer of the model you name.

3. Keep each request lean. The less each request adds, the slower a session fills and the less there is to sort when a checkpoint arrives, so this goes before the checkpoint decision. The waste here comes in small pieces:

• Attachments sized to the task. In Anthropic’s PDF documentation, a page typically uses 1,500 to 3,000 tokens of text depending on how dense it is, and because each page is also converted into an image, it’s charged as an image too. Send the pages or the text a task needs, unless its charts or layout matter.
• Specific requests. Ask for the change you want rather than “improve this codebase,” a vague request that Anthropic says triggers broad scanning.
• Side questions out of the main thread. Claude Code’s /btw answers from what’s already in the session, and “the question and answer never enter the conversation history.” It can’t read files or run anything, and if a side question settles something, say it again in the main thread or it’s gone.
• Noisy work handed off. Long test runs or log files can go to a subagent, a helper the tool starts with its own separate context, so only a summary comes back, knowing that the subagent’s own requests still count toward usage.
• Answer length apart from reasoning effort. A short-answers instruction trims what the model writes, while how hard it thinks is a separate setting.

4. At each checkpoint, choose: continue, compact or start fresh. This is the center of the routine, and it depends on the first three: the handoff note from step 2 is what makes starting fresh workable, and the lean requests from step 3 decide how often you get here. Three moments call for the decision: a phase of the project ends (the spec is agreed and building starts), the model starts drifting back to settled questions, or the session nears the edge of its context window, the most a model can handle in one call. Claude Code also compacts on its own as a session approaches that limit, so the point of the checkpoint is to decide before it does and steer what’s kept.

Continue if what’s in the session still serves the next task. Compact if you need the continuity but noise has piled up, and tell the tool what to keep rather than letting it guess: /compact followed by something like “keep the decisions we made, the open issues and the next step.”

Start fresh if the next task can run from the handoff note. Before you do, the owner checks the note against the decisions and the work itself, because a new session starts without the conversation, and a mistake in the note gets carried forward as fact. Then the new session’s first job is to restate the goal and the constraints, which catches a misreading before it turns into work.

Neither move is free. Anthropic’s documentation notes that compacting a large context “is itself a large request,” because the tool reads everything it summarizes, and its engineers warn that overly aggressive compaction can lose “subtle but critical context whose importance only becomes apparent later.” Starting fresh with /clear costs nothing in the moment, but the next session pays to rebuild what it needs. That’s why the choice sits at a checkpoint and isn’t written as a rule.

5. Judge it by accepted work, then decide. It needs a few weeks of results under the same setup, so it closes the routine. Log the same tasks under the routine and compare them with your before: how many results cleared the bar, how much rework they needed and how long they took. Usage is a rougher reading. Anthropic’s reports break it down by person, not by task, so compare the pilot team’s usage in the pilot weeks with the weeks before, as a second check rather than a precise cost per result.

It’s indicative rather than proof, since no two tasks are quite alike. But it tells you whether to expand the routine, change it or drop it, and that call belongs with whoever commissioned the pilot.

Context rot on real work is unproven

The routine is built from Anthropic’s documentation and its engineers’ account of how models handle long contexts. Context rot comes from benchmark studies, so how much it costs on any particular task is unknown, and that’s what step 5 is there to find out. Compacting and starting fresh both lose something, and a checked handoff note is meant to reduce that loss, not end it. The prices and token counts here are Anthropic’s, they change with each model, and other vendors price and count differently. Context isn’t the only dial either. What the model writes, its reasoning included, is billed at the higher output rate, which is why step 1 holds the model and effort setting fixed rather than ignoring them.

What the pilot adds is a habit the model can’t supply for itself: someone deciding, at each checkpoint, what the next task needs to see. The meter on AI work runs on everything the model is handed to read, and by its makers’ own account so does the strain on its attention, which makes what a session carries a lever worth testing on the bill and the quality of the work at once.