How to Stop Claude Code Session From Costing More

How to stop one long Claude Code session from slowing down and costing more

One long Claude Code session dey slow down and cost more because every turn dey send the whole context again, and that context dey keep growing. The fix na hygiene wey you follow in fixed order. Run /context to see wetin dey fill the window, remove the items wey you dey pay for on every request, then use /clear between unrelated tasks and /compact with instruction inside one long task. Work in continuous stints, because cold prompt cache fit turn cheap read into full re-write of everything wey you don talk.

The token meter behind an agent session answer why the meter dey run at all.

Read /context before you change anything

No guess wetin go fill the window. Claude Code go tell you.

/context [all] dey show current context usage as colored grid, with suggestions to optimize tools wey dey use plenty context and memory bloat; all dey expand breakdown for each item for fullscreen mode. Read the result as five buckets.

• The system prompt. Na Claude Code own harness instructions. E no dey change for the session.
• Tool definitions. Na schema for every tool wey the agent fit call, including every connected MCP (Model Context Protocol) server.
• Memory files. CLAUDE.md and auto memory, wey load when session start.
• Files and tool results. Every file wey you read, and everything wey your commands print back.
• Message history. Your turns and the replies.

The first three na fixed tax wey every request dey pay for the whole session. The last two dey grow. Cut the fixed tax once, for the beginning; manage the growing part continuously.

Two strings go tell you say the window don full:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

The first one na hard limit, and dem go refuse the request; the matching API (application programming interface) error dey read Prompt is too long. The second one na compaction window, wey fit dey below the model real context window for a 1 million token model. Requests still dey succeed after am, so e na warning, no be refusal.

For paid plan, /usage dey add the other half. E dey flag behaviours like long context or cache misses, and assign recent usage to individual skills, subagents, and MCP servers. If e tell you say the allowance don finish, which limit window you dey wait for go decide whether trimming context fit help you now or whether you need another route back to work.

CLAUDE.md na permanent tax, so make e lean

Your CLAUDE.md dey load for context when session start and e remain there. If e get detailed deployment procedure, those tokens dey present while you dey fix typo for test file. Anthropic guidance na make you include only the essentials and keep the file below 200 lines.

Move procedures go skills. Skill dey load only when you invoke am, so workflow wey you run twice every week no dey cost anything for other days. Skills get their own budget after compaction: dem dey inject the bodies again, with limit of 5,000 tokens per skill and 25,000 altogether. The oldest ones dey drop first. Truncation dey keep the beginning of the file, so put the most important instructions near the top of SKILL.md.

The thing wey survive compaction dey decide where instruction suppose dey.

• The system prompt and output style no change, because dem no dey part of message history.
• The project-root CLAUDE.md, unscoped rules, and auto memory dey inject again from disk.
• Rule wey get paths: frontmatter dey lost until dem read matching file again.
• Nested CLAUDE.md for subdirectory dey lost until dem read file for that subdirectory again.
• Hooks no dey affect, because hook dey run as code and e never enter context.

So rule wey you depend on suppose dey inside project-root CLAUDE.md: Claude Code dey clear older tool outputs first, then e summarize, so instructions from early for the conversation fit get lost. Use /memory to edit memory. Claude Code dey hold the copy wey e load when session start, so trim wey happen mid-session dey keep prompt cache and e no apply until the next /clear, /compact, or restart. Context loss na only one reason rule fit stop to dey followed. So when rule clearly still dey inside the window but dem still ignore am, work through the other causes before you rewrite it.

/clear between tasks, /compact inside one

Dem command two look like say na the same thing, but cost dem no be the same at all.

/clear [name] starts new conversation with empty context. E no send any request, so e cost nothing. Pass name make e label the previous conversation inside /resume picker; /reset and /new na aliases. Use am immediately when you switch go unrelated task, because if you no do so, old task go dey send again, and billing go dey happen again, for every message of the new task.

/compact [instructions] frees context while e continue the same conversation: e summarize the history wey don happen and replace am. Use am inside one long task, where you still need continuity.

Always give /compact an instruction. Bare /compact dey summarize against default prompt wey no know which part of the work you still need. The one wey get instruction dey keep am:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

If you dey compact for the same reason every time, put standing instruction inside your project CLAUDE.md under # Compact instructions heading. For new session, /compact prints Not enough messages to compact.. This only mean say history never dey there yet.

People dey confuse two costs here. The summarization request share your prefix, so e read the existing cache instead of processing the history again, and most of the time dey go to generating the summary. Compacting large context still be large request, because the conversation wey dem dey summarize na the input. The turn after compaction no be the slow part: e rebuild the cache for much shorter prompt.

Two cheaper commands dey available. /rewind [description] rolls back code and conversation to checkpoint; for path wey you wan abandon completely, e better pass compacting, because e truncate back to prefix wey don already dey cached. /recap append summary as command output instead of replacing history, so cached prefix remain intact.

If automatic compaction dey fire again and again, e go print this:

Autocompact is thrashing: the context refilled to the limit...

Compaction succeed, but file or tool output refill the window several times one after another, so Claude Code stop retrying. To recover, read the oversized file with line ranges, run /compact with focus wey remove the large output, move that work go subagent, or use /clear if the earlier conversation don finish.

MCP servers na fixed overhead

Every MCP server wey you connect dey add cost to every request for the whole session. You go pay whether you call am or not.

Claude Code dey reduce this wahala. By default, e dey defer MCP tool definitions, so na only tool names enter context until Claude use one specific tool. Run /context to see the real cost of your servers, and run /mcp disable <name> to remove one wey you no go use today. If you dey run your own MCP servers for VPS, the same calculation limit how many tools one server suppose expose.

Do this when session dey start. While definitions remain deferred, connecting or disconnecting server only append to the conversation, and the cache remain available. If definitions load into the prefix instead, because tool search dey off or one server no dey use deferral, the same change make the next request read everything again.

Filter tool output wey too long before e enter context

Tool result na input, and system go resend that input for every later turn. Test run wey dump 20,000 tokens of output no be one-time cost: you go pay for am again every turn until e comot from the window.

Filter am for source. Hook wey reduce test run to only failures before Claude see am go turn that whole output into few hundred tokens, for this turn and every time system resend am:

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

Hooks no dey enter context by themselves, because dem dey run as code. Do this for any tool wey output pass one screen. Same logic apply to 3,000-line file: ask for the line range wey you need, because the whole file go remain for the window once e arrive.

Agent go read only the files we specify, and delegate noisy work

Prompt wey name the file and the symptom go read that file. Open request to tidy the project go make the agent read anything wey e decide say relevant, and every read go remain inside the context window.

Delegate work wey get plenty output to a subagent. Test runs and log processing both dey use real context; subagent go keep that output for its own window and return only summary. The tradeoff be say subagent go build its own cache with no hits for the first call, and e go use the five-minute cache lifetime even for subscription. Delegation dey reliably protect your main context. But e no always reduce total tokens.

Cache clock: work for stretches

Prompt caching na wetin make resend affordable: na 0.1x of base input rate to read the prefix, compared with 1.25x to write am, or 2x to write am for the one-hour lifetime. Each use refreshes the entry without extra cost, so the clock starts again from the last use. Those multipliers show the shape of the bill but no be the total amount, so pair dem with wetin one million tokens actually cost to turn full context window into dollar figure.

Which lifetime you get depend on how you authenticate. Na this be why general statement say "your cache expires after five minutes" no correct.

• For Claude subscription, Claude Code requests the one-hour lifetime automatically.
• Once you pass your plan limit and start using usage credits, dem go bill you for that usage, so e go return to five minutes.
• For API key or cloud provider, e stays at five minutes. ENABLE_PROMPT_CACHING_1H=1 opts into the one-hour lifetime, while FORCE_PROMPT_CACHING_5M=1 forces am back to five minutes.

The rhythm advice remain the same either way: work in continuous stretches, because idle gap wey pass the lifetime go make your next turn write the whole accumulated prefix again. A detached Claude Code session for tmux no cost anything while e idle, but na the warm cache the idle time dey give up.

Some actions discard the cache while you still dey work: switching models, changing effort level, turning on fast mode, connecting or disconnecting an MCP server, enabling or disabling a plugin, denying entire tool, compacting, and upgrading Claude Code. /model na the usual surprise, because each model get its own cache. So the next request go read the whole history without cache hits even though the content remain identical. Dem bill this re-read with the destination model rates, so if you switch to Fable mid-session, e charges your whole accumulated history at Fable 5 published input rate.

Editing files, editing CLAUDE.md, invoking skills and commands, running /recap, rewinding, and spawning a subagent all keep the cache. E dey limited to one machine and one directory, so two sessions for different directories no fit use each other's cache. This scope follow the CLI instead of your account, so none of am carries over to Claude desktop app. For Linux, na separate beta install alongside the CLI.

To check whether caching dey work, read current_usage. cache_creation_input_tokens was written at the cache write rate, while cache_read_input_tokens was served at roughly one-tenth of the standard input rate. High read-to-creation ratio na good sign. If creation remains high turn after turn, something inside your prefix dey change continuously.

Bigger context window go fix this?

Partly. Plenty current models support context window wey fit reach 1 million tokens, and compaction still dey work the same way for the bigger limit. The cost calculation no change, because full prompt still dey send again and billing still dey happen for every turn. Bigger window only decide when you must take action; good hygiene decide the cost. If na bill be the problem, instead of the limit, which Claude plan fit the way you dey work go decide whether you dey spend dollars or plan allowance.

Context editing and compaction for API no be the same thing

If you dey build your own agent on the Messages API, no slash commands dey, and na you go implement am yourself. Plan for this work from the beginning, because API no get free tier apart from small signup credit, so dem go bill every turn of untrimmed history complete. The provider wey you build on go determine this calculation before any trimming happen. So, if you never decide, calculate the cost of the same workload for both APIs instead of comparing only the advertised per-token rates. Two server-side features fit do the work, but dem no be the same feature.

Context editing dey selectively clear specific content from conversation history as e dey grow. E replace each cleared result with placeholder text so Claude go know say something don remove. E still dey beta: send anthropic-beta: context-management-2025-06-27 and configure strategies under context_management.edits. clear_tool_uses_20250919 dey clear tool results, while clear_thinking_20251015 dey manage thinking blocks. The default for trigger na 100,000 input tokens, keep na the last 3 tool uses, and clear_tool_inputs na false. This mean say inputs stay, and na only results go.

Compaction dey generate summary and replace the complete conversation history with am. E still dey beta too: send anthropic-beta: compact-2026-01-12 and use edit type compact_20260112. The default trigger na {"type": "input_tokens", "value": 150000}, and the value must be at least 50,000.

Compaction get one handoff rule wey fit quietly break agents. The response dey start with a compaction content block wey hold the summary, followed by the normal text block. You must pass that block back for later requests. The API go then drop every content block wey come before am. For practical use: append the whole of response.content, no be only the text.

Anthropic documentation calls server-side compaction the main strategy for managing context inside long-running conversations. E describes context editing as the option for finer control over the content wey go clear. Check model support first. The current Opus, Sonnet and Fable models support compaction; claude-haiku-4-5 no support am, and the compaction page get the current list. Neither beta dey control Claude Code own /compact. Its documentation describes that one as one-time summarization request wey the client sends.

FAQ

Why my Claude Code session dey slow and cost more the longer e dey run?

Na because dem dey send the complete conversation again for every turn. So, one-line question for session wey don dey open since morning go carry everything wey happen that day. Prompt caching dey keep am cheap while cache still warm, for 0.1x of the base input rate when dem dey read am. Once one turn miss the cache, dem go write the same prefix again for 1.25x. Run /context to see wetin dey fill the window, and read wetin Claude Code session dey bill you for to understand how e work.

Wetin be the difference between /clear and /compact for Claude Code?

/clear dey start new conversation with empty context. E no send any request, so e no cost anything. Na the correct choice between tasks wey no relate. /compact dey keep the same conversation and replace the history with summary. So na the correct choice inside one long task. Give am focus, like /compact keep only the plan and the diff, because the instruction decide wetin go remain.

How I fit see wetin dey use up my Claude Code context window?

Run /context, or /context all for the complete breakdown per item. E dey show system prompt, tool definitions, MCP servers, memory files, and history as colored grid. E also dey suggest tools wey dey use plenty context and memory bloat. For paid plan, /usage fit also show recent usage for individual skills, subagents, and MCP servers.

I suppose use 1 million token context window instead of compacting?

Bigger window go only delay the problem; e no solve am. Several current models dey run 1 million token context window, including Opus 4.8 and Sonnet 5. Compaction still dey behave the same way for dem. Every turn still dey send the complete prompt again and still dey bill you for am. So, 400,000-token conversation expensive whether e fit inside the window or not.

Wetin be the difference between context editing and compaction for Claude API?

Context editing selectively dey clear old content, mostly tool results. E dey leave placeholder text where each one dey before, so Claude know say dem remove am. Compaction dey generate summary and replace the complete history with that summary. Anthropic documentation call compaction the main strategy for long-running conversations. E describe context editing as the fine-grained option. Both na betas with their own headers. Both separate from Claude Code /compact.