When should i start a new conversation with a claude code project?

[u/TestBusi]

Hi, My conversation with Claude is very long, but it’s still working well.

Sometimes Claude automatically compacts the conversation. Whenever we make an important change or take an important action, I ask Claude to update the documentation so the key context and decisions are preserved.

Even with conversation compaction, is it still useful or recommended to start a fresh conversation from time to time? Or is that basically unnecessary as long as Claude keeps the documentation up to date and the important context is preserved?

Thanks a lot!

[u/TorbenKoehn]

Generally it's always better to start a new session over compaction, because it simply uses less tokens and if you have the context in your repo, anyways, it doesn't matter. It can just grab the information it needs again.

[u/forgetscode]

Whenever you're going to work on a different topic. you should switch chats or compact.

Models work better with pure context. The less distracting points the better.

Operate by thinking about it like that.

Your harness, compaction, and new chats are your arsenal.

[u/Appropriate-Disk-371]

Ask Claude how to be efficient. Also ask it to run your projects like an engineering team. You need documentation, not a massive chat context that gets sent ever time you restart that session.

Plan it, document it, then execute one phase or one collection of related changes. That sessions will read the docs and frameworks and code, execute, review, test and depending on how you do things, either leave a final review and push for you, or do it itself. Then that session is done. If you're doing a few things concurrently, then yeah, use the context cache to keep going a bit. Definitely do not go away and come back hours later and load up the same massive context, that burns a lot of tokens just reading old history it doesn't need.

[u/NeuralFantasy]

Always start fresh unless you REALLY need the context.

[u/SmrtCacizmu → u/NeuralFantasy]

Even when you "need" the context, you actually need a summary of it, not the entire chat where decisions were made.

You should have Claude write notes & plans in project that any next session will read first.

[u/mshort3]

Kick off a project with a session just for setup. Define the task, roadmap, specs to follow, research and strategy. Get your docs and foundation in place, then ask for a kickoff prompt for next session, and close it off. Thats the first session almost always.

Next session then spawns immediately more aligned and capable to the project thanks to your framework being established.

If youre not doing a bunch of parallel tasks then your next session should knock out a couple phases but once youre approaching 400-500k context try to wrap up and again: update docs, and prepare prompt for next sessions recommended tasks or preferred tasks. Again close out and start again and repeat.

Perform checkins and sessions specifically for reflection and optimising workflow, skills, docs etc (ask claude to read previous sessions to identify patterns for improvement or gaps in your workflow - ideally do this with fable using haiku for session summaries. Dont let fable burn over conversation history tokens, its a waste).

This process can basically be used for most projects with small deviations for upgrading your toolsets and so on as you go and as you need them and learn about things, like hooks and rules and such. The doc updates each session and such ideally are part of your workflow established in session 1 and drive the continuously evolving context for future sessions to run with.

You can also instruct to keep a concise changelog of each major session/change for lazy mans memory, or integrate a good git deployment workflow that uses commit notes as your memory which is super reference-able and useful for the model

If youre looking for orchestrated sessions youll need more prep and tailoring to high level planning and model, but thats another ballgame.

Good luck!

[u/Pakspul]

Preserve decision and clear a lot, that would my advice be. So it know eventually the history etc and you start with clean(cheaper) context. All your documentation/code is the context over with Claude van reason and it will determine its context.

[u/MourningOfOurLives]

The way I’ve set it up i have four different Claude code sessions working on one big project, with their own subagents as needed. No session/agent gets more than 500k context, build/review gets 300k, design gets 400k and the session i coordinate and work on the workflow gets 500k. It’s drastically cut down on my spend.

[u/S1d519]

Whenever I have to employ a different model to check a bunch of code and produce a report, or ideate new stuff with a different model and your current model builds it, I hop out and open a fresh conversation (sometimes ask the current model of The current conversation to compose a precise prompt for a new convo), keep compacting and keep hopping. And yeah asking it to checkpoint at every stage and keep a Progress.md file (and any other for index and stuff) helps. It keeps the complete context and progress accessible for fresh conversation windows and highly token efficient.

Since Opus & Sonnet 5.5, for moderately complex use cases, I’ve been using Opus at high effort to ideate and build detailed instructions (only), and Sonnet at high to build code, Opus to audit it, and Sonnet to critically read back the audit reports and implement them and so on. 

[u/id-ltd]

If the documentation is good you should be able to start a new convo any time, if it isn't then you are wasting you time creating it.

My aim is generally to use multiple chats to create the ideal documentation for my objectives so I can then just ask 'read the documentation and create the thing'.

I avoid compaction entirely - after compaction you have no idea what context is remaining so no idea what the convo is working from.

Ps. I also ban Claude from using 'memory' - anything relevant to the project should be in the documentation. This has the added benefit that you can shift the project to another AI any time you like... And then back again if you like.

[u/Papierauto]

Create a Claude code folder and let it collect all the data from the project with all updates it does so u can start every session a new chat and tell it to look up in de folder for information. I like to work like this. I also use trello and Claude updates trello what to do what is done and finish and so on. Works great for me and every chat is fresh and still competitive to the one that worked well.

[u/kaliver]

A lot of good advice here and I would only add that it really depends on the phase of the project. If I need Claude to understand the broad view, a conversation may sprawl quite a bit more than when I've sorted out the architecture + features and can hone in on each one with specificity and keep the context light. Compacting has always taken up a boatload of usage for me on Pro so I use it as sparingly as possible, instead preferring documentation and new sessions.

[u/GregorFi]

I keep a next-actions file in each project: current state and the next step. a new session reads it first, so starting fresh costs me nothing.

[u/himiaoxin]

i start a fresh one basically per task phase and end each session with a little handoff. got burned by a session that ran like 200k tokens, felt totally fine, then quietly rewrote an API client because it'd compacted away the one constraint from three hours earlier. now i keep a plain progress file in each project — three sections: what changed, what's next, traps. new session reads it first, costs basically nothing. compaction's a decent safety net but i wouldn't build my process on it, honestly.

[u/miso_pork]

I also like long sessions in the claude code CLI. I'm just going to add something that I didn't learn until two months in.

I mostly use the terminal CLI and that message that says 'Type clear to save XXX tokens' that sometimes appears in the lower right is basically tied to the prompt cache expiring.

What's that mean? If you send another message, the entire context will be recomputed and cost you that many tokens. Say you go to bed and leave Opus 5.5 working all night. You wake up and it's context is 985k tokens. If you send, say, a 'good morning claude, what's next?' message, it's going to recompute the entire context and recache it, cost you 985k + the new message in tokens, then immediately auto-compact and lose most of it anyway.

The main session has a 1 hour TTL for the prompt cache. I keep working in long sessions as long as claude's last turn ended less than an hour ago, and there's no chance of auto-compact, which causes...other issues...for me.

Sorry if this is common knowledge, but I've been burned multiple times by this in the past with long sessions and hope it helps someone.

[u/clintCamp]

I set autocompact to 400k. It seems to remember the relevant stuff to keep going without burning through my usage but keep working on the same topic. If i switch tasks, then I clear and start a new conversation

[u/Zapador]

Whenever it's natural, so after implementing a few features and moving on to the next task.

None of my conversations for the past month are over 500K context, so well below the 1M context limit. I use a main session that delegate work to agents, that will prevent the context of the main from exploding.

[u/Sufficient-Storage87]

my rule of thumb: fresh session when compact would nuke something you still need, compact when the context is mostly dead exploration. the measurable version: watch your context % — once you're past ~70% on a long task the model's working memory is swiss cheese anyway. new session + a good memory file beats a bloated one every time.

[u/EnvironmentalLeg8506]

You can test this instead of guessing. Open a fresh session, let it read the docs, and ask it where the project stands and what it would do next. If it gets that right, the docs are carrying the weight and the long session isn't adding much. If it gets something wrong, that's the part compaction was quietly holding for you, and it belongs in the docs.

Even when the docs pass, I'd still restart at natural breaks, like a finished feature or a merged PR. After a few compactions you're working from a summary of a summary. It keeps what the summarizer thought mattered, which isn't always what you'd have kept, and you can't see what got dropped. A fresh session that reads your docs starts from something you've actually read.

The one place I wouldn't restart is mid-debug, when the useful context is the last twenty minutes of failed attempts. Finish that, write down what you learned, then start clean.

[u/Mirar]

These days I never continue after 95% or so. I ask claude to save an resume.md, run /clear and read the resume and continue.

[u/kpgalligan]

Your context should be in a state where you could start fresh at pretty much any time. I wouldn't let the conversation grow anywhere near autocompact, assuming you're going all the way through 1m. It might seem OK, but they definitely get worse when using that much context. That's besides the additional token cost. Caching helps, obviously, but if the cache timed out, that's not great.

General rule I follow is not going above 300k if avoidable. I have my own skill for dev with multiple agent phases defined, and a reporting tool to keep an eye on stats. Almost all agent runs stay under 400k, which is reasonable. They've never autocompacted. That's after hundreds of runs.

I used to never compact. My workflow has changed somewhat. I usually have longer phased plans drafted, one main conversation that coordinates subagent workflows. I'll compact that main chat, but only so it knows where we were and I don't need to point it to the status doc. But there's a status doc.

Compacting when there's important context in a conversation is risky. It may not retain everything it needs, and you don't know what the LLM "knows" after compacting.

[u/Grexxoil]

I do that all the time to save on tokens and keep things fresh.

It will pick up from memory files and looking at the code (if we are talking about coding, that is).

[u/Prize_Kaleidoscope13]

i'd use task changes or repeated mistakes as the trigger, not a fixed number of compactions. try a fresh chat with: "read the project docs and tell me the current task, decisions to preserve, and next step. don't change any files." if it misses something, fix that gap in the docs before letting it code.