How to make Claude Code fast and cheap

How to stop a long Claude Code session getting slow and expensive

Claude Code session dey slow and expensive because every turn dey re-send the whole context, and that context dey grow continuously. To fix am, you must follow this order. Run /context to see wetin dey fill the window, cut the items wey dey make you pay for every request, then use /clear for different tasks wey no relate, and use /compact with one instruction inside one long task. Work for small stints, because if prompt cache cold, e go turn cheap read to full re-write of everything wey you don talk.

Reason why the meter dey run na the token meter behind an agent session.

Read /context before you change anything

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

/context [all] go draw current context usage as colored grid, with optimization suggestions for tools wey get heavy context and memory bloat; all go expand the breakdown for every item for fullscreen mode. Read the result as five buckets.

• The system prompt. Claude Code instruction for itself. E dey fixed for the session.
• Tool definitions. The schema for every tool wey 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 e read, and everything wey your commands print back.
• Message history. Your turns and its replies.

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

Two strings dey 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 the request go fail; the matching API (application programming interface) error na Prompt is too long. The second one na compaction window, wey fit small pass the real context window for 1 million token model. Requests go still work pass am, so that one na warning rather than refusal.

For paid plan, /usage go add the other half, wey go flag things like long context or cache misses, and e go show which individual skills, subagents, and MCP servers dey use the usage.

CLAUDE.md na permanent tax, so make e light

Your CLAUDE.md dey load for context as soon session start and e go stay there. If e carry long deployment procedure, those tokens go dey consume space even when you dey fix typo for test file. Anthropic advice na make you carry only essential things and keep the file under 200 lines.

Move your procedures go skills. Skill go load only when you call am, so workflow wey you dey run twice a week no go cost you nothing for other days. Skills get their own budget after compaction: dem dey re-inject bodies, dem cap am for 5,000 tokens per skill and 25,000 in total, and dem dey drop oldest ones first. Truncation dey keep the start of the file, so put the most important instructions near the top of SKILL.md.

Wetin survive compaction na wetin go decide where instruction suppose dey.

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

So any rule wey you depend on, make e dey for project-root CLAUDE.md: Claude Code dey clear older tool outputs first before e summarize, so instructions from early part of conversation fit lost. Edit memory with /memory. Claude Code dey hold the copy wey e load for session start, so mid-session trim go keep the prompt cache and e no go apply until next /clear, /compact, or restart.

/clear for between tasks, /compact for inside one

Dis two look like dem be the same, but dem cost different amounts.

/clear [name] start new conversation with empty context. E no send any request, so e no cost anything. Give am name if you want label di old conversation for /resume picker; /reset and /new na aliases. Use am as you switch to another task wey no relate to di old one, because if you no do am, di old task go keep dey re-sent, and dem go keep dey bill you for every message for di new one.

/compact [instructions] free up context while you dey continue di same conversation: e summarize di history wey dey so and replace am. Use am inside one long task wey you still need continuity.

Always give /compact instruction. If you just use /compact, e go summarize using default prompt wey no know which part of di work you still need. If you give instruction, e go keep am:

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

If you dey compact for di same reason every time, put standing instruction for your project CLAUDE.md under # Compact instructions heading. For new session, /compact go print Not enough messages to compact., wey mean say no history yet.

Two costs dey confuse people for here. Di summarization request dey share your prefix, so e go read di existing cache instead of to reprocess di history, and most of di time na to generate di summary. Compacting large context still be large request, because di conversation wey dem dey summarize na di input. Di turn after compaction no be di slow part: e dey rebuild di cache for much shorter prompt.

Two cheaper commands dey exist. /rewind [description] roll back code and conversation back to checkpoint; for path wey you wan abandon entirely, e better pass compacting, because e truncate back to prefix wey don already cache. /recap append summary as command output instead of to replace history, so di cached prefix go stay intact.

If automatic compaction dey fire over and over, e go print dis one:

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

Compaction succeed, but one file or tool output refill di window many times for row, so Claude Code stop to retry. To recover, read di oversized file for line ranges, run /compact with focus wey go drop di large output, move dat work to subagent, or use /clear if di earlier conversation don finish.

MCP servers na fixed overhead

Every MCP server wey you connect dey add extra weight to every request for the whole session. You go pay for am whether you use am or you no use am.

Claude Code dey make am easy small. MCP tool definitions dey wait by default, so na only tool names dey enter context until Claude decide to use one specific tool. Run /context to see how much your servers dey cost, and run /mcp disable <name> to remove one wey you no go use today. If you dey run your own MCP servers on a VPS, the same math dey limit how many tools one server suppose show.

Do this one as you dey start session. Even though definitions dey wait, to connect or disconnect server dey just add to the conversation, and the cache go still dey. If definitions load into the prefix instead—because tool search don off or server no follow the deferral rule—that same change go make the next request re-read everything.

Filter how tool output take plenty before e enter context

Tool result na input, and every time you send new message, you go re-send that input again. If test run dump 20,000 tokens of output, e no be one-time cost: you go pay for am again for every turn until e commot for window.

Filter am for source. If you use hook wey go reduce test run to only the failures before Claude see am, you go turn that big wall of output to just few hundred tokens, for this turn and for every time you resend am:

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

Hooks no dey enter context because dem dey run as code. Do this for any tool wey output too long for screen. Same logic apply for 3,000-line file: ask for only the line range wey you need, because once the whole file enter, e go stay for window.

Control wetin agent dey read, and give noisy work to others

Prompt wey name file and symptom go read that file. Open request for to tidy project go read anything wey agent feel say important, and every one of those reads go stay inside window.

Give verbose work to subagent. Test runs and log processing dey consume real context; subagent go keep that output inside its own window and only return summary. The tradeoff: subagent go build its own cache wey no get hits for first call, and e go use five-minute cache lifetime even if you get subscription. Delegation dey protect your main context well well. E no dey always reduce total tokens.

The cache clock: work in stints

Prompt caching na wetin make resend cheap: 0.1x the base input rate to read the prefix, against 1.25x to write am, or 2x to write am if you want one-hour lifetime. Every time you use am, the entry refresh itself without extra cost, so the clock start again from last use.

The lifetime wey you go get depend on how you authenticate, na why to talk say "your cache expires after five minutes" no correct.

• If you get Claude subscription, Claude Code go automatically request the one-hour lifetime.
• Once you don pass your plan limit and you dey use usage credits, dem go bill you for that usage, so the lifetime go drop back to five minutes.
• If you dey use API key or cloud provider, e go stay at five minutes. ENABLE_PROMPT_CACHING_1H=1 go allow the one-hour lifetime, but FORCE_PROMPT_CACHING_5M=1 go force am back down.

The advice for the rhythm na the same for any way: work in continuous stints, because if you leave gap pass the lifetime, your next turn go need to re-write the whole accumulated prefix. A detached Claude Code session in tmux no cost anything while idle, and the warm cache na wetin the idle time dey give up.

Some actions go throw the cache away even as you dey work: switching models, changing effort level, turning on fast mode, connecting or disconnecting an MCP server, enabling or disabling a plugin, denying an entire tool, compacting, and upgrading Claude Code. /model na the usual surprise, because every model get its own cache, so the next request go read the entire history without any cache hits even if the content be the same.

Editing files, editing CLAUDE.md, invoking skills and commands, running /recap, rewinding, and spawning a subagent all dey keep the cache. E dey scope to one machine and one directory, so two sessions for different directories no go see each other's cache.

To see if caching dey work, read current_usage. cache_creation_input_tokens na wetin dem write at the cache write rate; cache_read_input_tokens na wetin dem serve at roughly a tenth of the standard input rate. If the read-to-creation ratio high, e dey okay. If creation stay high turn after turn, something for your prefix dey change continuously.

Bigger context window go fix this?

Partly. Many current models support 1 million token context window, and compaction dey work same way even for large limit. The economics no change, because dem still dey re-send full prompt and dem still dey bill for every turn. Bigger window na e dey decide when you go forced to act; hygiene na e dey decide the cost. If the bill na the problem instead of the ceiling, which Claude plan fit the way you work na e go decide if you dey spend dollars or plan allowance.

Context editing and compaction for API different things

If you dey build your own agent for Messages API, no slash commands dey and you must implement am yourself. Two server-side features dey do the work, and dem no be the same thing.

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

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

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

Anthropic documentation call server-side compaction na the primary strategy for managing context for long-running conversations, and context editing na the option for finer control over wetin go commot. Check model support first. The current Opus, Sonnet and Fable models support compaction; claude-haiku-4-5 no support, and the compaction page carry the live list. Neither beta dey drive Claude Code's own /compact, wey its documentation describe as one-off summarization request wey the client dey send.

FAQ

Why Claude Code session dey slow down and cost more as e dey run long?

Because dem dey send the whole conversation again every time you talk, so one small question for session wey don open all day go carry the whole day weight with am. Prompt caching dey keep the cost low while the cache warm, at 0.1x the base input rate for a read; once one turn miss the cache, dem dey re-write the same prefix at 1.25x. Run /context to see wetin dey fill the window, and read wetin Claude Code dey bill you for for the mechanism.

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

/clear dey start new conversation with empty context. E no dey send any request, so e no dey cost anything, and na the right choice if you wan do different tasks wey no get connection. /compact dey keep the same conversation and dey replace the history with summary, so na the right choice for inside one long task. Give am focus, like as /compact keep only the plan and the diff dey do, because the instruction dey decide wetin go remain.

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

Run /context, or /context all if you want full breakdown for every item. E dey show the system prompt, tool definitions, MCP servers, memory files, and history as one colored grid, with suggestions for tools wey dey take too much context and memory bloat. For paid plan, /usage dey also show recent usage for individual skills, subagents and MCP servers.

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

Larger window dey just delay the problem, e no dey solve am. Some current models dey run 1 million token context window, Opus 4.8 and Sonnet 5 dey among dem, and compaction dey work the same way for there. Every turn still dey re-send the full prompt and still dey bill for am, so 400,000-token conversation still expensive whether e fit inside or not.

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

Context editing dey selectively clear old content, mostly tool results, and e dey leave placeholder text where each one dey so Claude go know say dem don remove am. Compaction dey generate summary and e dey replace the full history with am. Anthropic documentation dey call compaction as the primary strategy for long-running conversations, and dem dey use context editing as the fine-grained option. Both na beta with their own headers, and both dey separate from Claude Code's /compact.