How to Reduce Tokens on Long Agent Sessions

How do you reduce tokens on long agent sessions?

You reduce tokens on a long agent session by attacking the one thing that makes long sessions different from short ones: the transcript is re-sent on every single turn, so each token you let in early gets re-billed on every turn that follows. Trim what enters the context — searches instead of whole-file reads, filtered tool output instead of raw dumps, a pruned MCP manifest — and segment the session so the transcript never grows unbounded. That's the whole game. I spend my days building tooling that does exactly this, so let me be blunt about the mechanism first, because most "save tokens" advice skips it. A long session is not expensive because it's long. It's expensive because of how agentic loops re-read history. Get that wrong and you'll optimise the wrong thing. This is the long-session companion to How to reduce AI coding agent token usage. If you want the agent-agnostic foundations first, start there. Here I focus on the one variable that dominates once a session runs past, say, twenty turns: accumulated context.

Why do long sessions cost so much more than short ones?

Long sessions cost more because the per-turn input grows with the transcript, so total cost over a session grows roughly quadratically, not linearly. On every step of an agentic loop, the model re-reads the entire conversation so far — your prompts, its prior reasoning, and every tool result — before producing the next action. A read you incurred on turn 3 is paid again on turns 4, 5, 6 and so on until the session ends or the context is compacted. Put numbers on it. Say each turn adds about 2,000 tokens of new context (a couple of file reads, a command's output). By turn 30 the running transcript is ~60,000 input tokens, and you re-send all of it every turn. Sum the input across all 30 turns and you're billing on the order of 900,000 input tokens for a session whose unique content was only 60,000. That ~15x multiplier is the real cost of length, and it's why a single sloppy 15,000-token read early in a session is so much worse than the same read near the end. The context window is the ceiling here, not the budget. You can stay well under the window limit and still pay a fortune, because cost is the area under the curve of input-per-turn, not the peak. People stare at "context: 40% full" and feel safe. The bill disagrees. Two things partially soften this, and you should know their limits:

Prompt caching. A cache read costs roughly 10% of the normal input price, so the re-sent prefix of a stable transcript is cheap — if it stays byte-identical. The moment something mutates the early context (a tool whose output changes, an edited system prompt), the cache breaks from that point on and you pay full freight again. Caching rewards stability; long sessions are where stability quietly dies.
Native compaction. Most agents (Claude Code's /compact, Cursor's summarisation) will eventually summarise old turns. Useful, but lossy and reactive — it fires after you've already paid to accumulate the bloat, and it can drop the one detail you needed three turns later.

What's the single biggest lever?

The single biggest lever is keeping junk out of the transcript in the first place, because anything you exclude on turn N is excluded from every re-send after turn N. Prevention compounds; cleanup doesn't. In rough order of impact on a long coding session: 1. Search instead of read. The dominant source of accumulated bloat is whole-file reads the agent never needed. A 500-line file is ~5,000–7,000 tokens; an agent "getting oriented" might pull a dozen before writing a line. Semantic code search returns the three relevant functions instead of three whole files, which can be the difference between 600 tokens and 18,000 — and remember, on a long session you multiply that gap by every remaining turn. 2. Filter tool output. Long sessions run lots of commands, and raw command output is the worst kind of bloat: high-volume, low-signal, and sticky. A failing npm test can emit 15,000 tokens of stack traces and passing-test checkmarks when the agent needed the failing test name and the broken assertion — maybe 50 tokens. Output filtering keeps the signal and drops the cargo before it ever lands in the transcript. More on this in Output filtering for command logs. 3. Prune the MCP manifest. Every connected MCP server re-advertises its tool definitions every turn, used or not. On a short session that's a footnote; on a 40-turn session it's a constant tax paid 40 times. Disconnect servers you're not using this session, or use lazy loading so definitions are sent only when a tool is actually called. See MCP and Best MCP servers for Claude Code. 4. Compress what you must keep. When the agent genuinely needs a file's shape but not its bodies, context compression via skeletons — signatures, types, docstrings, minus implementations — keeps the useful structure at a fraction of the tokens.

How do you stop the transcript from growing unbounded?

You stop unbounded growth with discipline about session boundaries: end a session when its task is done, and start a fresh one for the next task instead of letting one chat absorb your whole afternoon. This is the cheapest optimisation that exists, and it requires no tooling. The instinct to keep one long-running chat "so it remembers context" is exactly backwards on cost. The agent doesn't remember for free — it re-pays for that memory on every turn. If task B doesn't actually depend on the transcript of task A, a new session is strictly cheaper and usually produces better output, because the model isn't distracted by stale context. Concretely:

One task, one session. Finish the feature, close the chat. The next bug fix starts clean.
Compact proactively, not reactively. If your agent supports manual compaction, trigger it at a natural breakpoint (tests green, feature done) rather than waiting for the auto-trigger that fires after the bloat is already paid for.
Hand off via artifacts, not transcript. If task B needs context from task A, write that context to a file — a short design note, a CLAUDE.md, a checklist — and let the new session read that ~300-token file instead of re-ingesting a 60,000-token transcript.
Watch input-per-turn, not just window fill. If each turn's input keeps climbing, you're accumulating. That curve, not the percentage-full bar, is your cost.

If you want to know what a token actually is and how text becomes them, the tokenizer glossary entry is the two-minute version; for the wider cost picture, see our breakdown of AI coding agent token costs.

What does this look like in real money?

It looks like the difference between a comfortable monthly bill and an uncomfortable one, and the model you pick scales the whole curve. At current API pricing — Claude Opus 4.8 at $5 / $25 per MTok (input / output), Sonnet 4.6 at $3 / $15, Haiku 4.5 at $1 / $5, GPT-5.5 at $5 / $30 — that 15x length multiplier hits hardest on the input side, which is precisely the side a long transcript inflates. Take the earlier example: a 30-turn session billing ~900,000 input tokens where only ~60,000 was unique. On Opus 4.8 input at $5/MTok, you paid about $4.50 for input you could have delivered as $0.30 of unique content — and that's before output. Prompt caching can claw back most of the re-sent prefix at ≈10% of input price, but only on the stable portion, and long sessions are where stability erodes. Cut the per-turn intake instead and you shrink the multiplier at its source, which caching then amplifies rather than rescues. Run your own numbers with the LLM token cost calculator before you assume any of this is too small to matter. For most people shipping daily, it isn't.

How to apply this today

Audit one real long session. Find your longest recent chat and ask: how much of that transcript was whole-file reads and raw command output? That's your recoverable bloat.
Turn on search-first retrieval. Default the agent to semantic search over reading whole files; reserve full reads for files it will actually edit.
Filter command output at the source. Pipe noisy commands through a filter so only the signal enters the transcript.
Prune MCP to this session's needs. Disconnect unused servers; lazy-load the rest.
Segment ruthlessly. New task, new session. Hand off via a small artifact, never the whole transcript.
Measure. Track tokens per session so you can see the levers working instead of guessing.

This is the workflow Tokenade automates so you don't have to babysit it: semantic search instead of eager reads, output filtering on tool calls, skeleton compression for structure-only reads, and lazy MCP loading — plus a savings dashboard that shows tokens saved per session, so the curve is visible instead of theoretical. It works with Claude Code, Cursor, Codex, Copilot, Windsurf and the rest, the free tier covers ~10M tokens a month, and it's source-available (MIT) so you can read exactly what it does to your context before you trust it with it.

What goes wrong (anti-patterns)

The most common mistake is optimising the peak instead of the area. People watch the context-window fill bar and relax when it's at 40%. But cost is input-per-turn summed over every turn, not the high-water mark. A session that hovers at 40% for 60 turns can cost more than one that spikes to 90% and ends in five. The second is treating compaction as prevention. Auto-compaction is a seatbelt, not a brake — it fires after you've already accelerated into the bloat. By the time it summarises, you've paid to accumulate everything it's about to throw away. The third is hoarding one eternal chat for the comfort of continuity. Continuity isn't free; you re-buy it every turn. If the next task doesn't truly depend on the last one's transcript, a fresh session is cheaper and sharper. The fourth is breaking your own cache for no reason. Prompt caching only pays off on a byte-stable prefix. If you keep editing the system prompt or running tools whose output jitters, you invalidate the cache mid-session and quietly pay full price on the re-sends. Stabilise the early context, then let it ride. If you're still in the "let's see what it does" phase of agent work, vibe coding and the discipline of context engineering are the two ends of the spectrum — and long-session cost is exactly where the second one starts paying for itself.

See also: