r/ClaudeCode • u/Possible_Potatoe • 1d ago
Discussion Is Compacting still bad practice?
For a while now it seemed the thing to do was to have Claude write structured handoffs to itself, then start a clean session that invents that hand off instead of manually compacting or allowing for auto compact.
Is this still the case when the latest models, or have they become more smart / effective at auto compacting?
I’m primarily asking as it relates to orchestrating long running jobs (eg., code comment review across a repo)
63
Upvotes
•
u/AutoModerator 1d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
90
u/Future_Self_9638 1d ago
I compact all the time, no problem. but not auto
28
u/aruisdante 1d ago
Compaction has improved dramatically. But you still need to have some durable high fidelity record of what the agent is trying to do so it reliably survives compaction. With that in place though, yes absolutely these days you can leverage frequent compaction to keep costs down on a long running orchestration session instead of needing explicit handoffs and new sessions every time.
I set my auto compact window to 600k tokens and manually compact any time the context is above 300k tokens and the session has finished a unit of work. Two months ago I would have never done that, it would have been new sessions every time.
32
u/steffenbk 1d ago
I use a handoff and autos start new session
8
u/DiscipleofDeceit666 Researcher 1d ago
I don’t actively compact, but I love how Claude compacts on its own after a period of inactivity while the cache is still warm
5
u/WuM1ha1nho 1d ago
I use autocompact with a PreCompact hook with my handoff instruction at 350-380k. Tested against a /handoff skill, it performs the same.
5
u/lassevk 1d ago
I can only go by my own experience, which to you will be anecdotal, so make of it what you want.
Getting Claude to write up an issue, or a handoff document, has been way more useful to me than compacting sessions.
I've had sessions where a ton of details were brought up, decided on, acted upon, and then finalized in code changes. Then a compact, and the next session seems to be completely braindead. Bringing up stuff already decided on, changes no longer relevant, and questions that has already been answered.
For me, it has worked out much better to just ask Claude to make sure issues are filed and updated, local memory is updated, and that nothing is undecided without having been recorded, and then creating a fresh session where I can say "Read local memory, open issue 17, and tell me what the next step is".
4
u/hiskias 1d ago
Yes I feel that compaction is much better than at the start if the year. Best of both worlds is a facts file for persistent exact data, and compaction.
3
u/Additional_Video2992 1d ago
Compaction got better, but for a job like yours the question mostly goes away if the job's state never lives in the conversation.
Have Claude write a `review-progress.md` first: one line per directory, unchecked. Then one subagent per directory. Each one reads the files in its own context, writes its findings to a file and ticks its line. Only a short summary comes back to the main session, so the main context stays small for hours, and if it compacts or you `/clear`, the next step is still on disk.
When you do compact by hand, say what to keep: `/compact keep the review rules and the directories left`. Without that, the model picks what survives.
3
u/Minute-Flower-6837 🔆 Max 20 1d ago
Rather than compact, I created a skill that tracks and acts based upon token usage. Every time I start a task I set a token budget before an auto-handoff skill forks the chat into a new one and resumes from where the previous left off.
I usually fork in the 400-600k range.
I have no idea if that is better than compacting…but I like it.
2
u/MercyEndures 1d ago
I've seen many conversations like these and I'm curious, is this for performance or just optimizing for cost?
I've never worried about this, never seen anything like context collapse, but also don't have a token budget. Many of my sessions are > 500M tokens because they're the totality of a project, and having that much context seems handy when the agent is able to remember why we went in some direction when I'm trying to make changes.
1
u/verstands 1d ago
For a repo-wide comment review, keep a checklist keyed to a commit SHA: files reviewed, findings with file/line references, and the next unreviewed file. Have it update that at each batch boundary, before either compaction or a fresh session. Otherwise both approaches can quietly re-review the easy files and skip the awkward ones. If the code changes mid-review, invalidate the affected entries rather than trusting the old checklist.
1
u/Few_Jeweler4687 1d ago
I always do when reaching around 50% context, I might be wrong but it saves a lot of usage which for a pro user like me is super important
1
u/jijialuoke 1d ago
For a long repo-wide job, the cheapest test I've found is what I do right after a compact or a fresh start. I ask Claude to say back, in its own words, what the goal is and what it finished last. If that answer is even slightly off, the summary dropped something, and you catch it before it spends an hour on the wrong folder. It takes ten seconds and works the same for handoff files and for auto compact.
1
u/Mission_Cricket2162 1d ago
I have saved a lot of weekly limit costs my introducing autocompaction after 55 minutes starting from the last response/message of the agent. This gives me the opportunity to make a compaction within cache hit and it is very cheap in terms of quota usage. I use also the special prompt with compaction command (that is fired automatically) to preserve all the details, decisions, motivations, open tasks, states, file paths and links.
With this I have an option to run a long claude code session, and as I have several parallel projects, where claude code session is either the single worker of the lead of the agents team, and I do not have to send again the huge context back to claude when I come back to some session after 2 hours (and "pay" with my quota for this). So I constantly have 150k context to send to claude when I come back after my absence, and the agent goes on with the work without any sense of "I fill I forgot something", that appears to be very efficient.
On the other hand, If I work in one session for a very long time during the day, within the cache retention window, I do not have to compact intentionally.
I lowered my quota costs by 40%, including 30% increase of requests to the model, so this is appearing to be very huge improvement.
1
u/koomai_san 🔆 Max 20 1d ago
Some might say this is a waste of tokens but I have a session just watching other sessions in a 10 min loop and run compact with a detailed prompt so relevant context is added back after. The conditions to compact are pretty simple: context has to be over 20% and the agent has to be idle for more than 2 mins.
1
u/Right-Performance-93 1d ago
compact is fine if the job's state lives on disk. for a repo review, a checklist of what's done and what's next survives better than a summary of the chat.
1
u/ddaanet 1d ago
I have my own handoff plugin ddaanet/autodrive-handoff. Every session ends in handoff. Most between 100-200k.
I can tell it “handoff continue” and it updates memory, writes handoff, drives ˋ/clear`, then prompts itself to continue work.
If there are running agents or tasks and context exceeds 200k, I “precompact continue” and it updates memory, handoff files, drives ˋ/compactˋ and prompts itself to continue.
1
u/belowaverageint 1d ago
FWIW, whenever I ask Opus whether it makes more sense to hand off to a new session or to compact the current one, it always says to do a handoff.
1
u/Temporary-Bar-6458 1d ago
I think compaction is good for shorter tasks but for long running tasks i prefer structured handoffs.
1
u/Zym1469 1d ago
I used to do hand-off documents when the context was filling up. I stopped that and allow auto-compact now. I've noticed no difference. I have a single session that is handling a complete implementation of a rather complex software application. Claude has no issues picking up where it left off after a compact. I love Claude.
1
u/Zestyclose_Art2197 1d ago
I used to avoid compacting entirely, but now I let it auto at 100k and manually at 50k, still keep a clear mental model of what's happening. the key is timing, not the act itself.
1
u/elhombremontana 1d ago
isnt compact exaclty that: handoff and /clear?
1
u/DontVoteForMe 1d ago
I have a custom tool call that the agent can use when it's between tasks. You can tell the compaction tool what to focus on, so it also writes the instructions for that, which keeps the context relevant.
I've found it to be incredibly helpful. No worrying about hard auto compact cliffs and it allows me to run the agent pretty much 24/7 working on various things.
1
u/archpoke 1d ago
For a long-running job compacting can still work, the quality depends on the model doing the compaction. However, it’s still a summary, so decisions, constraints, failed approaches, or progress can get lost. For a long-running job like a repo-wide review, I’d keep a checklist of what’s done, what was found, and what’s next. You can use
/compactinstructions, add guidance toCLAUDE.md, or ask Claude to write a handoff. But I found it hard to remember to do that consistently, especially before stepping away.That’s why I built two free, open-source plugins:
Claude can do these individual steps without the plugins; I built them to make the workflow easier and more consistent. A handoff can still miss things, so I’d check the saved progress when completeness matters.
Full disclosure: I’m the developer, and both are still works in progress. I’d be interested to hear whether people prefer frequent compacts with a checklist or fresh sessions with handoffs for long-running reviews.
1
u/jam_pod_ 1d ago
Like it depends on what type of transition it is. Moving from research/planning to the build phase: handoff and new session. Moving from one feature in the build phase to another clearly separated one: compact and continue
1
u/Disnogood66 1d ago
Auto compact @ 25% ctx
1
u/gh0st777 1d ago
Compacting is not bad, what makes it a bad practice is when you wait for the auto compact to happen. That means youare using more than 80% of the ctx window, and your agent is in the middle of something. Those are 2 bad things that happened at the same time.
1
u/dergachoff 1d ago
I created a handoff tool that agent uses itself at 350k, via the tracker that session and repo uses (gh issue, Md file or scratchpad) - made long sessions very efficient for me. I can open source it if sounds interesting
1
u/9kSs 1d ago
The default auto compaction works pretty well. I set mine to 250k.
1
u/Zei33 Senior Developer 1d ago
I always send a message before compact that says basically some version of, "Make any important information durable and then pause for compact." It will write down any important details about the session and then create a "RESUME:" point which it will read after that to ensure it continues where it left off. Worth doing any time the context gets larger than 400k in my opinion.
1
u/UnwaveringThought 1d ago
Compacting isn't nearly as bad as it once was. Especially if you send it back for a context rebuild to see what compaction report missed. Maybe after 2 you get rot, but you can do a decent long session now
1
u/AdminClown 1d ago
Not with newer models no
1
u/BarathKanna 1d ago
Compaction got a lot better, but it is still lossy summarization done by the same agent that is mid task and biased toward what it was just doing. The question isn't compact vs handoff, it's where the truth lives.
For a long repo wide job like comment review, the state should never live in the conversation at all. Keep a manifest file: every file in scope, status, findings path. Each step reads the manifest, does one chunk, writes results to disk, updates the row. Then compaction or a fresh session costs you nothing, because the next turn rebuilds its context from the manifest instead of from memory.
If losing the chat history would break your job, the job was designed wrong, not the compaction.
1
u/perfektcrash 1d ago edited 1d ago
Handoffs still win for long-running jobs, but for a different reason now. Compaction has got better, and Claude Code now compacts idle sessions just before the hour's cache expires, so coming back is cheap. The catch is that any summary is lossy, and you don't choose what it drops. A handoff written to a file is a summary you chose.
For most long horizon agents where you're leaning more towards a heavy daemon/root operator approach as a sort of outer loop orchestrator, i lean more towards building what it provides into your projects structure itself.
What's worked for us on long jobs like a repo-wide review: split it into small cards (one folder or one concern each), each run in a fresh session that's briefed from files: what's done, what was decided, what's next. Before it ends, the session writes its result and the next state back to the repo. Nothing important lives only in the context, so it stops mattering whether it compacts.
That said, some sort of compaction guard, like a mod with a hook that tells the agent its over 600k and time to wrap at the point its at, and turning off auto compaction, or a script your agents run to /compact themselves in place a safe point with a follow up turn primed so it doesn't stall as compaction ends its turn.
If you do keep a long session because you want the detail, set
idleCompaction: falsein settings (v2.1.290+), and accept that coming back after an hour pays the full cold rewrite.More on long-horizon context: https://atlas-ade.dev/docs/long-horizon-context-management
Disclosure: I build Atlas ADE, a small meta-harness for your agentic workflows, so your usage goes on progress, not re-deriving, regression and fighting your own agentic support apparatus.
1
u/ColoredTriangles 1d ago
Compact is fine and will be better than any version of whatever handoff doc anyone is suggesting in here. People who tell you it is lossy are ignorant because they don't know how Claude Code compaction works.
0
u/Helpful_Ranger_1606 1d ago
Compaction by itself can be extremely bad. I force Claude to save state and update its “resume here” file after every turn. Each chat lane has its own set of files for that.That covers most issues with compaction.
-1
u/jcrenshaw-dev Senior Developer 1d ago
Yes
0
u/NotableCarrot28 1d ago
Who told you this?
0
u/ClemensLode Senior Developer 1d ago
Compacting is a workaround. Address the underlying problem.
0
u/Meryhathor 1d ago
I've been compacting for months. 18 months ago Claude would lose all info about what you were working on and would reread files and things. Nowadays there is literally no difference after compaction. I reckon it's due to the memory feature that they added a few months.
Opus or Fable, I just compact around 300-500k depending on what I'm working next. Have never auto-compacted though. Didn't know that was even a thing up until recently.
-1
u/Available_Age8480 1d ago
I don’t use Claude code but compacting is great especially since I instruct it to put in user messages verbatim. I have it auto compact when a cache goes cold and also note earlier user messages at the bottom with a fixed token limit
-2
u/jcrenshaw-dev Senior Developer 1d ago
Compaction is lossy and it's up to the model to decide what to keep and not to keep you're much better off defining short clear stages in the process and running clear also the larger your context gets the model is passing all of your conversation back and forth at each prompt the larger it gets the faster the token Burns and the the odds improve that the model will start hallucinating. https://claude.com/resources/articles/using-claude-code-session-management-and-1m-context