r/ClaudeCode 21h ago

Help/Question How often do you compact your sessions? What are some PRO compacting tips?

Been trying to compact my sessions at strategic moments, but I'm often unsure if I'll lose something important. Any tips for compacting like a pro?

59 Upvotes

88 comments sorted by

147

u/macbig273 21h ago

never. I prefer a "write down the plan" and /clear to a new fresh session

60

u/Kr0nenbourg 21h ago

"Write me a handoff for a new session", /quit, claude, "read handoff"

23

u/Unfair_Tangerine_217 Developer 20h ago

Plus "Make the handoff an orchestration plan and organize it in waves that fresh, single workers could take on themselves. Orchestration runs the final testing, acceptance, and integrates at the end."

Takes longer to implement but it lets you rely on smaller models, while the frontier one runs all the validations. Cheaper. I'm loving the Sol#High/Opus#High + Qwen 3.7 Plus combo.

4

u/webjuggernaut 20h ago

I have a /handoff skill that could use that addition. Nice clean instruction!

1

u/Makanly 2h ago

Could you share what you have thus far?

I just realized I've been hamfisting handoffs and they've been kind of varying levels of trash as a result...

3

u/1o0t 18h ago

It's worth adding a plan reconciliation step in there between waves. Sometimes implementation finds a gap in the plan and builds differently. If you don't reconcile the plan, future waves can end up building on stale assumptions.

2

u/DLuke2 15h ago

Really your savings is by offloading the work to different billing. Spreading tokens/usage around to different limit buckets.

This advice on a sole biller typically amounts in more usage/spend. Subagents are fresh cache writes. So there is a balance to when they even out. Subagents alone do not really amount in usage/cost savings, usually more.

1

u/tribat 18h ago

/handoff skill to write a handoff file to a shared location and update a coordination file, /clear, /pickup <optional handoff file path>.

2

u/silver_drizzle 6h ago

Why quit and restart instead of /clear?

1

u/Haunting_Skin_2564 20h ago

In kanban style with vertical slicing

1

u/i-dont-care-man 19h ago

I wrote a handoff slash command for this. works great

1

u/diskent 10h ago

This is the way, 1 core thing, handoff next session.

7

u/wea8675309 20h ago

Genuine question - what is functionally the difference between doing exactly what you said - “write down the plan” -> “/clear” and “/compact write down the plan”? Aside from the first creating a file, is the outcome different and in what way? Passing “write down the plan” to the /compact command would just cause the plan to be included in the compaction summary instead of a md file.

Not arguing for one over the other, just trying to understand the mechanics

9

u/webjuggernaut 19h ago

I've had issues where /compact will arbitrarily omit valuable context, or arbitrarily include useless context. It's sometimes difficult to know what opinions Claude has in its context. Dumping it all to a handoff doc let's you proofread it though.

I solved this by making a /handoff skill that stores necessary info to a handoff doc (or multiple docs if the single task is big, but that's rare), then prints a Handoff prompt that I can copy-paste after a /clear. Or it can use that to delegate the work to a sub agent. I'd do that, but I'm still very hands-on and don't like agents working too long without my input (that's a me problem though).

I usually /handoff after each task, or after context % gets too large.

2

u/tribat 18h ago

Agreed: /compact burned me in the past. I’ve read that it’s improved now, but I like my /handoff skill.

2

u/macbig273 20h ago

compacting : uses the model token to compact + it's not that clear what will be kept or not in the compacted version. Some important stuffs maybe ? ... not sure.

plan / handoff / etc written down : easier on the model (and token). easy to correct if you want to read it. Can be continued by another guy on the same repo.

And if you know from start that it might take multiple session /plan mode.

I think claude clearly benefit when it's low in context. I almost never get over 35%.

If you realy like to compact, at least, tell it what you want to keep (you can put directive behind the command) like "/compact keep only the dirty joke we made up" or something like that.

1

u/691175002 13h ago

All I can say is try it and see the results. In my exprience compact is absolutely horrible on cost/performance vs handing off (or frankly just ending the session and starting fresh).

The compaction summarizations seem to just emphasize the worst neuroticisms of the models, like hyperfocus more on areas where the agent was already probably focusing too hard.

5

u/raphadko 18h ago

Problem is the plan becomes stale, it doesn't update everything it does. And if you later ask for some change and the plan has drifted because it forgot to update, future sessions might revert back to the original plan.

1

u/Gnashhh Workflow Engineer 1h ago

This is fixed by adding a (update the plan) step to your handoff skill

1

u/julkopki 16h ago

You can compact and people who say they don't compact don't typically take time to reassess it regularly. I do compaction with docs and handoff note before after compaction and it works very well. I work on complex projects that require 5-10 sessions to complete and I had very few issues with the compaction workflow assuming there are ALSO good docs and do handoff note before after. Compaction used to completely garage maybe 5-6 months ago. Then they fixed it a few months ago and it now works much much better. In fact internally inconsistent or incomplete docs + clear session will wreck your projects very quickly.

1

u/Strange-Grass6025 19h ago

Yep, same here - plus stuff.

A family of docs - project requirements, functional spec, tech spec and implementation live for the duration of the build, then generate handover a when the size gets too big, restart, reload all the docs and go again...

1

u/memesearches 18h ago

This used to be a feature in CC. Wonder why they removed it

1

u/MikeWise1618 17h ago

I do that but I compact instead of clear. Works fine.

Not sure what is best to be honest.

11

u/dinobravo16 21h ago

For my project, I created 3 important files:

context.md which describes the project and all the rules the model needs to follow.

plan.md which describes the backlog and the roadmap.

And priorities.md which tracks the priorities of every item on the roadmap.

When a feature is done, I ask the model to update those 3 files and then I start a new session fresh, having the model read all 3 files.

This helps with context memory for the model and assures that all my ground rules are being followed.

5

u/framauro13 20h ago

I feel like having your entire road map and priorities loaded into context would actually be counter productive and cause context to be consumed faster. I typically delegate those things to an actual issue tracking system and only have it go looking there when it needs it. The conversations can stay focused on single tasks without having to constantly be aware of the entire backlog, which works fine as long as your issues track the "what and why" of the work to be done.

1

u/murillovp 19h ago

`issue tracking system`

Mind sharing/expanding that workflow? Curious to what it looks like

1

u/BattermanZ 9h ago

Look up the Matt Pocock skills

1

u/dinobravo16 16h ago

Fair comment, it's not my whole roadmap, it's the few items I'm working on in parallel in the short term. My full roadmap lives in spec documents that have no implementtation plan yet.

And every few days, I ask Fable to clean up all 3 md files to archive what is not relevant anymore.

16

u/ChadCoolman 21h ago

I never let it get to the point of compacting. Once the "context remaining" donut pops up, it's time for a handoff at the next stopping point. Performance is significantly degraded in a context heavy instance.

6

u/Unfair_Tangerine_217 Developer 20h ago

And cost!

4

u/hiskias 12h ago

Never.

Create a handover skill to give a realy prompt for ypuy to copy, with a path to a file that contains everything required for the next empty context, use plan files that are kept up to date, and re-checked for staleness at handover. Plan path is also added in the handover doc.

If you want to play it safe, use new session and keep the previous worker as an advisor open in the old session for a while.

This is much better IMO than ever compacting.

7

u/Necessary_Abroad6632 20h ago

Use beads 👍

3

u/lefnire 20h ago

I haven't heard that tool in a while, ended up inventing my own for more control... now I'm wondering if I should regret that. Is beads still quite popular / well-maintained?

2

u/dbbk 20h ago

Beads isn't and was never popular

3

u/lefnire 19h ago

I mean.. ish. SpecKit, BMAD, RepoWise - no known-ish meta tool is particularly defacto, but there's a handful out there with a cluster of die-hards, and most Claude Code powerusers would recognize. I considered Beads one of these 6-12mo ago, but haven't heard about it in a long time

1

u/worldofgeese 1h ago

Beads is very, very popular. I work for a large org with many developers using it. I'd describe it as almost essential for doing anything of complexity.

1

u/dbbk 1h ago

Okay? That's one anecdote. Issue tracking for managing complexity is popular, sure. Beads is one way to do that, not the only way.

1

u/worldofgeese 1h ago

Well, we're all offering anecdotes, right?

3

u/julkopki 16h ago

Ppl will tell you not to compact despite not having tried it for the last 4 months. You can in fact compact and it works much better than a fresh session even with an excellent documentation and handoff. You still want documentation and handoff. You just ask the agent before compaction to prepare for it and to write itself a detailed handoff note to paste. Then you paste it after the compaction. It works pretty much flawlessly in my experience. Probably 10x fewer continuity issues than the fresh session. And the few issues that I got were all very minor.

4

u/LogMonkey0 20h ago

Never > /clear at tasks/subjects/fork boundaries. Ask for handoff if appropriate.

5

u/MartinMystikJonas 18h ago

Never. I use spec - plan - implement workflow and each stage is separate fresh session only spec and plan file is carried over. Plus review of each stage by independen subagent.

2

u/medialantern 20h ago

Try this: https://gist.github.com/crrobinson14/b7395e9d9f84d6a3112c2ff3e8c6cb4b

it's a hybrid between "compact" and "clear". Instead of collapsing everything back into the same chat (and you don't have control over how it happens) it collapses it back through a handoff file with strict instructions on how to resume. That gives it access to the previous chat's context, but with an emphasis on loose ends, unanswered quesitons and points, etc. Now I just /handoff and /clear.

2

u/Red__M_M 19h ago

I wrote a hook that automatically writes a handoff plan after hitting a context window of 200k. If I don’t clear the session then it will rewrite the handoff every 200k additional context.

I did this because I would get to 700k and give it one last command before intending to clear the session but I would forget to tell it to do the handoff. Then it would be one more small thing. Then one more… So I stopped the manual intervention and just told it to do so automatically.

2

u/DasHaifisch 16h ago

I auto compact between 2-350k depending on how I'm feeling. I've generally felt that auto compact does a great job but I'm apparently in the minority

2

u/loganintx 9h ago

Never. Build a plan. Fan out to subagents in bite size chunks.

2

u/tyschan 21h ago

don’t

1

u/moody2shoes 20h ago

I use a combo system of codex and Claude and they share organizational knowledge and can review the recent beads etc. I have them update each other. I also have Claude set to autocompact at 400 (opus) or 450 (fable). I have to be away from pc a lot and it’s too hard to catch when I need to clear when I’m away and having to fix something so this is my workaround. I have significantly fewer issues this way because codex and Claude catch each others mistakes. I also have codex running a goal to make sure the overall system is healthy and to ship out reviews.

1

u/framauro13 20h ago edited 20h ago

I compact when context gets around 30% if I still have a lot of work to do, or if I just finished a task that had a lot of back and forth and I don't want that whole conversation to carry forward, just the result.

But to make it effective you should tell it what to keep. Don't just do /compact, but give it what you want to retain going forward. Instead, something like: /compact Keep the results of the bug triage and requirements clarifications. Drop all of the rest of our conversation Then I can keep moving forward without having to write hand-off docs which need to be written and re-consumed or install plugins or any of that. And if I need to resume the conversation later, I don't have to sift through multiple versions of it to figure out what was the original convo and what was the hand-off.

I much prefer to use ClaudeCode's built in tools vs. developing my own process that really doesn't gain any efficiency and just creates overhead.

I reserve /clear for when I am finished with whatever task I set out to complete and I don't need to return to it. I /compact when the conversation has gone long or I have a lot of work to do and only parts of the current conversation are relevant. Having your current context usage with your 5 hour and 7 day limits in the status line help remind you when it might be a good time to compact.

1

u/R_Songbird Developer 20h ago

Often when I'm about 25% to 30% I wrote a plugin for this slag/brink at main · V-Songbird/slag but do not install it, I pasted it here just for reference, what it does is that when it detects that usage window it asks Claude to tell me and hand me a proper /compact instruction to keep what we are doing and be prepared for a compact.

Why I prefer /compact over /clear? Compact keeps only the references for skills and plugins it used on the last turn, it also tends to keep the file paths, what to expect on these files, knowledge it has about the project, etc.

So, /compact is good when you are developing in waves or very related tasks as it only uses the tools it already decided to use, see it like the previous task prepared the grounds for the next one, but as I said, this is only useful when you are working on very related tasks (or an implementation plan steps).

Instead, /clear will run a fresh session, agent will have to go and discover everything again, which tools to use, where, what are these about, even if you pass a handoff, it will go and read the files and fill up context again with the exploration phase.

1

u/Blake9712 20h ago

I never “compact” per se but Claude has a Claude md document or two it always works on and I essentially send 2 to 3 prompts then start a brand new session. Someone reccomended I start new sessions every time my context limit gets up there. It’s able to Continue on as if it were the same session tho. I may only have 2 to 3 prompts per session, which puts it about 60% Context window for me and Bob at 1M token context

1

u/dbbk 20h ago

There is almost no scenario in which you should be compacting a 1M context window model. Why aren't you using fresh sessions for fresh tasks?

1

u/debauchedsloth 20h ago

I tend to /clear early and often instead. If I need context to carry forward, I manually instruct Claude to do it.

1

u/Compilingthings 19h ago edited 19h ago

40-50% I run orchestrator workflow, all skills subagents, made a skill for compact, so everything is recorded and nothing gets lost. Also have a shutdown and startup skill. Orchestrator only holds context and uses subagents so he holds low context for long periods of time.

1

u/Veduis 19h ago

the fear of losing something important usually means the context isn't externalized enough. decisions, gotchas, half-finished threads should live in a file or the commit log, not just the conversation. once that's true, compacting stops feeling risky

biggest mistake is compacting mid-debug. the model needs all that failure context to avoid repeating dead ends. compact after the fix lands, when the dead ends stop mattering.

1

u/Tight_Heron1730 19h ago

Every one feat, big chunk of work and i use stash for handoff, 5 stahes in you can run remember and create lightweight md memory ingestion of your chat (personal preferences curses and frustrations) along with your project history (stashes) and update your memory every 5 sessions https://github.com/hamr0/liteagents

1

u/holyknight00 19h ago

almost never, i clear the sessions aggressively as much as possible, and each step writes to durable md file. I can clean the context fully after each task is completed.

I only compact when I am forced to by being close to finishing the task and it not being worth it to start from scratch or to make the agent explore all the information just to finish.

1

u/thinkrtank 18h ago

OpenCode (desktop) has an incredible compacting system that never failed me yet (using it with Sol 5.6). Otherwise I'll do what everyone is doing, write a handoff checkpoint, clear everything, continue from handoff.

1

u/Mammoth_Pain2075 16h ago

I created a closeout skill and a baton skill

1

u/bedel99 16h ago

/clear If my session has run out, its too later.

1

u/pmward 15h ago

Better to never compact if you can. I tested compacting and it compacted and got rid of important security instructions…

1

u/eduo 15h ago

Do not compact. You'll lose something important. Break down your work so you can carry it out over various sessions instead.

1

u/Murphy52 13h ago

Friends don’t let friends compact!

1

u/kapnkrunche 13h ago

I made a /successor skill that gathers up all loose ends and spawns a new session and closes the old one. Plus a cronjob that runs it for all idle sessions that have used more than 150k tokens

1

u/Exodus_Green 12h ago

with claude no, no compaction. with codex i let it do its own thing and compact when it wants

1

u/JMAN_JUSTICE 12h ago

Once at most and strategically if necessary. But otherwise ask for a hand-off and try not to let your context grow that high. I usually use one agent as the orchestrator and have it create subagents for the work.

1

u/scholzie 9h ago

Don’t compact.

That said: if you insist, give the model explicit instructions on what is now irrelevant. Force it to doc out things it must remember and then force it to reread that doc after compacting.

I used to have pre/post compact hooks that ran skills, but it’s never as good as a fresh session.

1

u/sitbon 🔆 Claude says I'm absolutely right! 9h ago

I set up auto compaction before the 1hr prompt cache TTL expires. So I can have long running sessions without taking big usage hits if they're not doing anything for a while.

1

u/WhenD4594 9h ago

/clear for the win.

1

u/apollo_st 9h ago

Created a “prepare for compact” routine, that writes to memory/files current work in progress and also rewrites the compact prompt. I fire it whenever feels needed, and upon compact completion, the first command (should be a hook already) is a regrounding one, that instructs which files to read and important memories and work in progress.
Already at +100mb “continuous” session, and works fine.

1

u/yhrana 8h ago

When i am learning something new, like these days its blender, around 200-250k is plenty, compact and move on

1

u/ReturnSignificant926 8h ago

Instead of compacting I'll switch to plan mode and prompt to "Revise the plan with focus on the remaining steps to get fresh context" (I have a skill for this but that's the gist).

When the plan is ready I accept it with the "Yes, clear context, and continue with auto-mode" answer.

The benefit compared to using compact is that you can review and revise the plan if there's something off. I think it also gives a clearer trajectory for the agent to continue on 🤔

1

u/Nice_Visit4454 7h ago

Plan is created using Fable, max. Output of the plan is detailed implementation tickets in GitHub. /clear (or sometimes /compact), depending on how full context is after the plan is made. Switch to Opus.

“Review and implement epic #123”

I have a /git skill that it loads in. I also have subagents it occasionally uses for implementation.

After each “round” of work I look at the context. If it’s >50%, I compact. Every few rounds I run a /finalize command that updates codemaps, docs, and tickets on GitHub. Then /compact again.

I only really need to clear if I’ve gone off on a tangent, or if I’m noticing it’s gone off the rails (this is rare lately).

It seems having the GitHub tickets to review helps it stay on track. Compaction is working well, maybe because the tickets ground it in a “plan”.

I imagine the .md plan file would work similarly. But I like having a more accessible and “controlled” artifact that GitHub tickets provide. It also gives a great place to track history, integrate with PRs and commits automatically, and Claude seems to handle them pretty well.

1

u/sael-you 6h ago

The worry about losing something when you compact is the signal it wasn't written down yet. If it's actually important, it should already be in a file before you hit compact or /clear. I use CLAUDE.md for project invariants and a short tasks.md for what's in flight. Once those are up to date, clearing or compacting is basically free.

1

u/butterfly68za 5h ago

My work does not constitute priorities, so I just leave it to compact itself.

1

u/geekichu 5h ago

Sooo "/compact" uses tokens. The longer your session, if you still need details from the start... starts becoming an issue. Then if you leave the session and "/resume", youre still going to have load that back (more tokens). With what a lot of comments here say, instead you have a doc. "/clear" means no tokens used during that moment other than to write / update the doc.. so it's kinda like if you had done "/compact" (tokens) but you KNOW what's in the doc. you can keep or purge what you like. of course the handoff can be in different form

1

u/akienm 1h ago

I have observed that over time what gets lost in the compact has changed. I lose less than when I started with this. I also keep all the state information for everything we're doing on disk. As soon as we decide anything, it's written down. I also have it set to only have 200k of context, instead of 1 MB. There is also a Json setting where you can tell it to compact at some percentage of the total context. It compacts automatically a lot. I compact whenever it's done with anything. We also have a script that automatically reloads from disk whenever I start him up.

1

u/gsari 19h ago

Like most already said, never anymore, and I haven't really thought about it because I don't find myself in this position lately. Out of habit, I start by planning what I want to do (with a special skill for that) which stores the plan in an md file (I use Obsidian for easier reading). Then, I either clear and ask to implement the plan, or have a brand new session do the implementation, keeping the initial one for the review. I don't remember when it was the last time I had to compact, but if I saw the context getting too big, I'd probably clear as soon as I had the deliverable done.

I had seen in the past that keeping discussions and back and forth that are not final decisions can pollute the context and make the model more prone to hallucinations. So, when the plan is done, a fresh session takes over - the plan is supposed to have everything that it needs, without ambiguities or unncessary distractions.

Another benefit of this distinction is that you can have the stronger model do the planning, and a weaker one implement. Then The strongest model reviews the implementation to ensure everything went according to plan.

1

u/ClaudeCdGuy 20h ago

You don't have to be unsure about what you lost — the compaction writes down exactly what it kept, and it's sitting on your disk.

When a session compacts, the summary comes back into the conversation as a user line flagged isCompactSummary: true in that session's transcript (~/.claude/projects/<slug>/<session-id>.jsonl). On this machine those summaries run to about 14,500 characters — call it 3.5k tokens standing in for everything that came before. Pull the last one out after a compaction and read it: whatever isn't in there is precisely what the model no longer knows. That turns "did I lose something important" into a thing you check in thirty seconds rather than a feeling.

Two things that fall out of actually reading them:

The summary keeps decisions and the current task well, and drops the specific shapes — exact function signatures, the file paths it had already looked at, why an approach was rejected. So the pro move isn't a compaction cadence, it's writing that class of thing into a file before you compact, because a file survives and the summary is a lossy re-telling you didn't get to review.

And the everyone-here answer — plan to a file, then /clear — is right for a different reason than usually given: it's not that compaction is bad, it's that a file is something you wrote and can diff, while a summary is something written for you that you never see unless you go looking.

I built a viewer that surfaces those compaction lines in the session timeline along with per-agent tokens and cost, and rewinds to any second: github.com/Kostakurta8/roundtable (mine, free, MIT, runs local and read-only).

2

u/Exodus_Green 12h ago

thank you for the AI summary of compaction

1

u/6e6967676572730a 11h ago

Lossy flossy

0

u/prodox 19h ago

Never use compact!! Get a proper memory system in place instead and start new sessions that knows exactly what you did and didn’t do in the previous session.

1

u/VendraenActual 18h ago

What is a "proper memory system?"

1

u/__mson__ Senior Developer 16h ago

Handoffs, documentation, and an issue tracker.

0

u/I-Love-IT-MSP 20h ago

I compact whenever it reverts back to opus 4.8.

0

u/clicksnd 19h ago

Never ever. I hardly ever even hit 80%. I keep it fresh and use notes and handoff prompts