Claude Code stuck on "Compacting conversation"? Here's why (and what it costs)

Claude Code stuck showing "Compacting conversation..." for minutes with no progress, or bouncing straight back into it right after finishing, is a documented failure with two distinct shapes on Anthropic's own issue tracker - not ordinary compaction just taking a while. One shape is an infinite loop: Claude Code re-reads the same files and re-attempts compaction without ever finishing the task. The other is a hard hang: the process freezes outright, Ctrl+C stops responding, and the fix is force-killing an orphaned process. Neither clears itself, and both keep billing tokens the entire time they're stuck.

What happens when Claude Code says "Compacting conversation"?

Compaction is a real API request, not a local operation. Per Anthropic's own compaction documentation, once the conversation's input tokens reach a configured trigger (150,000 by default, and Claude Code's own auto-compact fires on the same principle as your context approaches its configured window), the next request carries your full history plus a summarization instruction. The response comes back wrapped in a compaction content block, and every subsequent request drops everything before that block, continuing from the summary instead. That's the whole mechanism working normally - it's also, per the docs, an extra sampling iteration billed on top of your ordinary turn, which is why a compaction that succeeds still shows up as its own line in what a session costs.

None of that explains a compaction that never finishes. Compaction and prompt caching, explained simply covers why context fills and triggers this in the first place, and /compact vs /clear covers what a normal compaction costs you when it works. This guide is about the two documented cases where it doesn't.

Why does compaction stall or loop instead of finishing?

The loop (issue #6004, filed against v1.0.83): the reporter's session got stuck reading the same five test files, attempting compaction, then reading the same five files again - indefinitely, with the todo list stuck showing the task as "in_progress" despite having every piece of information it needed after the first read. Typing "please continue" once the loop was interrupted just resumed the same pattern, because the thing that triggered it - an oversized context sitting right at the compaction threshold - was still there.

The hang (issue #19567, filed against v2.1.12): a 23.6 MB session, already compacted once before, froze completely on its next compaction attempt. Ctrl+C had no effect, the terminal went unresponsive, and the reporter had to close the window entirely. The claude process didn't exit with it - it kept running as an orphan (PPID=1) and, per the reporter's own diagnostics, was still consuming 277% CPU and 11.8 GB of RAM more than 26 hours later, until it was manually found and killed.

Neither issue's own comment thread lands on a root cause Anthropic confirmed. The closest either gets is the loop reporter's own theory - that compaction loses task state, so Claude re-reads files to "recover" it, which re-triggers compaction, which loses the state again.

What does a stuck compaction cost you in tokens?

The two failure modes cost you in different ways, and neither is a single clean number - so here's what can honestly be said about each, labeled for what it is.

The hang is mostly not a token story. The process is waiting on one in-flight request; it isn't re-billing per second. The real cost the reporter documented is local: CPU and RAM held by an orphaned process for over a day, plus whatever unsaved session state is gone the moment you close the terminal on it.

The loop is a token story, and it's the one that's honestly modelable. Anthropic's own compaction docs ship a worked example of what one compaction iteration bills: 180,000 input tokens, 3,500 output tokens. I ran that exact pair back through Sonnet 5's current published rates ($2/M input, $10/M output, $0.20/M cache read) to see what one cycle of the loop actually costs, cache-warm and cache-cold:

This is a modeled estimate from Anthropic's own documented example, not a number pulled from a live repro of the bug - nobody can force this loop on demand to measure it directly. What it shows honestly: a loop that gets caught and interrupted after one or two cycles is a rounding error. A loop like #6004's, left running for ten cycles before anyone notices, is real money spent producing nothing - and unlike a normal compaction, none of it buys you the smaller context compaction is supposed to leave behind, because the loop never actually finishes one.

How to recover without losing your session

1. Try Esc or Ctrl+C first. The loop case is usually interruptible - you get back to a working prompt. The hang case usually isn't; give it no more than a minute before assuming it won't respond.
2. If you got control back, don't just say "continue." Per #6004, resuming from exactly where you left off walks straight back into the same loop, because the oversized context that triggered it hasn't gone anywhere. Run /compact yourself with a narrow instruction (/compact keep the last file I edited, drop the rest), or /clear if you don't need the history, before you carry on.
3. If nothing responds, find and kill the orphan. Close the terminal, then run ps aux | grep claude in a fresh one and kill -9 <pid> on anything still running - the process can outlive the window that spawned it, exactly as #19567 documented.
4. Once you're back, check what you were carrying. Both reported cases were large sessions sitting right at the edge of the compaction threshold - the hang's was 23.6 MB. The context window calculator estimates how close a session is to that edge before you get there again.
5. If you just want the state back, not a summary of it, /rewind truncates to an earlier turn instead - and because that turn is content the cache already has, the next request reads it back cheap instead of paying to rebuild.

| | The loop (#6004) | The hang (#19567) | | --- | --- | --- | | What happens | Re-reads files, re-attempts compaction, repeats | One compaction attempt freezes entirely | | Does Ctrl+C work | Usually, yes | Reported: no | | Process survives it | Only as the same stuck session | Yes, as an orphan (PPID=1) | | Real cost | Token cost, per repeated cycle | Local CPU/RAM, held until killed | | Fix | Interrupt, then /compact narrowly or /clear - don't just resume | Close terminal, find and kill -9 the orphan |

Are the known bugs fixed, or just closed?

Both #6004 and #19567 show as closed on GitHub. Reading only the badge is exactly how the scattered blog posts and forum threads covering this topic get it wrong: I pulled state_reason from the GitHub API directly for both, and it's not_planned on each - Anthropic's own tracker classifies that as distinct from completed, which is the label a confirmed fix gets. Both were closed by the repository's stale-issue bot after weeks of inactivity, not by a maintainer confirming a resolution. One commenter on #6004 flagged the bot closing it "incorrectly despite recent human comments" and pointed to a separate, also-closed meta-issue (#16497) about the same bot over-closing active reports. Closed here means the tracker stopped waiting for a response, not that the loop or the hang stopped happening.

When it's slow, not stuck

Not every long "Compacting conversation..." is this bug. A genuinely large session has a genuinely large history to summarize, and that takes real time - the 38 real sessions measured for /compact vs /clear topped out at 226,867 tokens of accumulated context, and a compaction on a session that size is doing real, billable work, not spinning. The signal that separates "slow" from "stuck" is progress, not time: if it resolves within a couple of minutes, or you can see it's still working, that's compaction doing its job on a big input. Force-killing a process ten seconds into a large, legitimate compaction just throws away the summary it was about to hand back.

FAQ

• Is a stuck compaction the same thing as auto-compact firing too often? No. Firing often is a symptom of carrying too much context into every turn - see how to reduce Claude Code's context window usage. This guide covers compaction that starts and then never finishes, which is a separate bug, not a frequency problem.
• Does Ctrl+C always get me out of it? No - that's the actual difference between the two documented failure modes. The loop (#6004) is usually interruptible. The hang (#19567) reportedly isn't; you have to close the terminal and kill the orphaned process instead.
• Are #6004 and #19567 fixed in the current version? Not confirmed. Both are closed with state_reason: not_planned on the GitHub API - a stale-inactivity closure, not a maintainer marking it resolved. Neither issue's thread contains a fix confirmation.
• Does killing the process lose my work? It loses the in-memory conversation, not your files. Anything Claude already wrote to disk during the session stays written; only the unsaved session history and context go with the killed process.
• What version was this checked against? The mechanism section is sourced from Anthropic's current compaction documentation; the issue states were pulled from the GitHub API on 2026-08-27, and Claude Code's own version was 2.1.222 at the time of writing.

None of this requires guessing whether your own session is close to this edge - the free scan reads your real Claude Code session history and shows exactly how much context you're carrying before compaction ever has a reason to hang. The compaction cost calculator turns your own session pattern into an estimate of how often you're triggering it and what each one costs, stuck or not.

Made by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.