Don't stop here
Hand-picked guides our readers explore right after this one.
You are deep into a task, the context indicator creeps toward full, and then Claude Code refuses to continue with 'Conversation too long'. You run /compact to summarize and keep going, and compaction itself fails with the same error. That is the deadlock users have reported repeatedly: you cannot continue, you cannot compact, and the only escape offered is /clear, which throws away everything the session knew. It is worth understanding why this happens, because the fix is mostly preventative. Compaction works by sending the conversation off to be summarized, which is itself a request that needs room. If you wait until the window is genuinely full, there is no room left to perform the operation that would create room. The practical answer is to compact early and deliberately at task boundaries rather than treating it as an emergency brake, and to keep bulky material (large file dumps, verbose tool output, chatty MCP servers) out of the context in the first place. This page covers both the escape route when you are already stuck and the habits that stop it recurring.
The CLI refuses new messages with 'Conversation too long'
/compact returns the same 'Conversation too long' error instead of compacting
Auto-compaction does not trigger even as the context indicator approaches full
Claude forgets decisions made earlier in the same session
It re-reads files it already read, or re-asks questions you already answered
Responses slow noticeably and answers get shallower as the session grows
The default window is 200K tokens, with 1M available on newer Opus and Sonnet models. Long sessions that read many files, run many commands, and capture verbose output fill it faster than people expect, and tool results are usually the largest contributor rather than the conversation itself.
Compaction summarizes the conversation, which is itself a model call over the whole history. At the moment the window is full there is nothing left to work with, so the operation that would rescue you fails for the same reason you needed it. This is why compacting late is unreliable and compacting early is not.
A portion of the window is reserved so that compaction can run. Users have measured this reserve at a substantial fraction of the total, which means your usable working space is meaningfully smaller than the headline number.
The system prompt, your CLAUDE.md, and connected MCP servers all load into every session. A single verbose MCP server plus a large project memory file can consume tens of thousands of tokens before your first prompt, and that cost is paid on every message.
Reading a big file, dumping a whole test log, or catting a lockfile puts the entire result into context permanently. A handful of these outweigh hundreds of conversational turns.
When to try: First, the moment you see the warning
If Claude can still respond at all, ask it to write a handoff note: the goal, decisions made, files changed, what is done, what is next, and known gotchas. Save it as NOTES.md in the repo. This turns a forced /clear from a total loss into a two minute restart, and it is the single most valuable thing to do while you still can.
When to try: Before resorting to /clear
Run /compact with a short instruction about what to preserve, for example: /compact keep the architecture decisions and the list of changed files, drop all file contents and command output. A narrower target sometimes succeeds where a general compaction fails, and the result is more useful either way.
When to try: When /compact keeps failing
If compaction will not run, use /clear, then point Claude at your handoff note and the specific files involved. With a good note this costs a couple of minutes. Do not try to resume by pasting the old conversation back in, which recreates the problem immediately.
When to try: At the start of the next session, to prevent a recurrence
The /context command breaks down consumption: system prompt, CLAUDE.md, MCP servers, tool results, and conversation. It usually reveals one dominant consumer, and that is where the fix belongs. People guess it is the conversation and are usually wrong.
When to try: As a standing habit
Make /compact a routine move when you finish a subtask, roughly around the point where you are past halfway through the window rather than near the end. Compaction has room to work then, the summary is cleaner because the task just ended, and you never reach the deadlock at all.
When to try: When /context shows MCP tools as a top consumer
Each connected MCP server loads its tool definitions into every session. Removing servers that are not relevant to the current project can return a large block of context immediately. Check the /context breakdown to see which ones are costing the most.
When to try: When configuration dominates the context breakdown
A project memory file that has grown to hundreds of lines is paid for on every single message. Keep commands, conventions, and constraints. Move background, history, and rationale into a separate document that Claude can read on demand instead of always.
When to try: For any task involving many files or large output
Delegate wide searches and bulk reading to a subagent so only the conclusion returns to your main context, and have long output written to a file rather than printed. Redirect verbose commands to a file and ask for the relevant lines. This keeps the expensive material out of the window entirely.
Write a handoff note to a file at every natural checkpoint, not just when you are in trouble
Compact deliberately at task boundaries instead of waiting for the limit
Run /context early in a session so you know your real working budget
Redirect large command output to files rather than into the conversation
Report it on the Claude Code GitHub issue tracker if /compact fails while the context indicator shows substantial free space, if auto-compaction never triggers as the window fills, or if the failure reproduces on a fresh session with minimal configuration. There are existing public issues covering compaction failing at the limit, so check for a matching one and add your details rather than opening a duplicate. Include the Claude Code version, the model in use, the /context output, and the percentage shown when the failure occurred.
Compaction is itself a model call that has to process the whole conversation to summarize it. When the window is already full there is no room to run it, so the rescue operation fails for exactly the reason you needed it. This is why compacting at task boundaries, well before the limit, is reliable and compacting in an emergency is not.
/compact summarizes the conversation into a condensed form and continues the same task with that summary in place of the full history. /clear discards everything and starts fresh. Use /compact when you want to keep going on the same work, and /clear when you are switching to something unrelated, which is also cheaper and produces better results than carrying irrelevant history.
Before clearing, ask Claude to write a handoff note to a file covering the goal, decisions taken, files changed, what remains, and any gotchas. Then clear and point the new session at that note. Doing this at every checkpoint rather than only in emergencies means a forced restart is never expensive.
Usually not the conversation. Tool results (file reads, command output, test logs) dominate, followed by fixed overhead from the system prompt, CLAUDE.md, and connected MCP servers, which is paid on every message. Run /context to see your actual breakdown rather than guessing, because the answer differs a lot between setups.
It postpones it rather than removing it. A larger window means longer sessions before the limit, but the same deadlock applies at the top, and quality tends to degrade well before the window is technically full. Good context hygiene (compact early, keep bulk output in files, delegate wide reads) matters at every window size.
Product behavior and limits can change. These primary sources were used to verify this guide.