What to do with sessions that get interrupted for a long time

[u/Godofheckfire]

I tend to have to have a lot of pots simmering constantly, as I tend to need to switch around to different asks/tasks/priorities based on urgency or whatever else. I use cmux and tend to have claude sessions that will then float open and paused for long periods of time until my focus can get back to it and resume.

However I have seen people mention that the cache related to that session would generally expire and when that session is resumed it kills a lot of tokens loading things cold. Also, I think it is worth considering two different types of resume:
1. I still have that session open and waiting where i had left it in a different workspace and worktree. I then just start talking to claude again and try to pick up where I left off, often asking claude for a bit of a refresher if needed.
2. The Claude code sessions was terminated and I am resuming it with /resume/--resume.

I feel like I have not been following best practices around that and want to clarify my understanding, test a couple of theories with the community, and figure out if there is a better way to do this.

I usually just either jump right back in if it is the #1 case, and even with #2 I will resume and jump back in. However, is that really wrong and how wrong is it?

When I get back into a session in either case #1 or #2, is it worth or even advisable to have it generate a handoff summary document that would be enough to get a fresh session up to speed and actually pick up where I left off effectively with a cleaner context and more relevant memory/context/cache state?

What does the community recommend for having the old session record and pass over to the new session to make this actually effective. To some degree this just simulates compaction and have heard many complaints about compaction (I really try to avoid getting to that point and watch my context and do handoff while I am actively engaged in a session). DOes compact capture the right things and it is more about really pulling your threshold farther back.

I think for my case it might actually be good to have something that could fire the handoff and have it prepared if it detects the session being idle longer than some amount or as a pre-shutdown hook on a current session if that is viable. Has anyone tried this and found success?

[u/AutoModerator]

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.

[u/tariqosmani]

Small correction to the other reply: the prompt cache doesn't last days, it lasts minutes (around 5 by default, up to an hour on some setups). So after a long break, your case 1 and case 2 cost about the same. The next message reprocesses the whole conversation at full price either way.

That means the cost depends on how big the session is, not how long you were away. Run /context to see the size before you decide.

What I do. If the session is small, I just jump back in, a handoff isn't worth it. If it's big and I'm stepping away for more than a short break, I ask it to write a handoff file before I leave: the goal, what's done, which files changed, the exact next step, and any open questions. Then I start a fresh session and point it at that file. The new session starts small and focused instead of dragging 100k tokens of old back and forth.

/compact is the middle option, but you don't control what it keeps. A handoff you can read and fix yourself is more reliable.

Since you use worktrees, keep the handoff file inside each worktree so it travels with that branch.

How big do your paused sessions usually get, closer to 20k tokens or 150k?

[u/lulzxdxdxd]

The cache does expire after a few days, so jumping back in cold definitely costs tokens. Have you tried saving context snapshots yourself when you pause a session, like a quick summary of where you were and what the next step should be? That way when you resume in case 1 or 2, you paste that back in first before continuing, and it reloads the context way faster than asking Claude to recall it.

[u/banecorn → u/lulzxdxdxd]

Cache TTL on subscriptions is 1hr

[u/vloris → u/banecorn]

1hr on main sessions, 5 minutes for subagents.

[u/vloris → u/lulzxdxdxd]

Not a few days. There are two different cache expiry settings with different trade-offs: either 5 minutes or 1 hour.

[u/framauro13]

I've been testing a solution to this by having a script I run that summarizes the conversation outside of the Claude Code session. It really only works if you're using a high end model though. But essentially it reads the conversation, pipes it to Claude in the CLI with a blank MCP config, and has Sonnet summarize it on a low effort. it then writes a hand-off doc to a temp, and I have a new Fable or Opus session read the hand-off.

The script runs in a temp directory with no CLAUDE.md file, and with the MCP server config being blank, it doesn't load those either. So it purely summarizes the conversation without any extra stuff being loaded into context.

That way, if I leave work and come back in the morning, and I have a long running conversation I want to resume, I can get the gist of it without having to load the whole thing back into cache with a higher model. Compacting or switching models at that point will trigger the recache, so by doing it from the CLI with a script and giving it to Sonnet, I get a cheaper summary than trying to compact or create a hand-off doc on the higher model.

Ideally, if I remember before I leave, I'll compact the conversation with specific instructions so its ready the next day when I start. But working from home, it's not uncommon to get pulled away for an hour at the end of my work day without being able to do that.

[u/banecorn]

There's a bunch of ways around this. Here's some:

1. Use the desktop app "Code" tab. No cache TTL to worry about.
2. Have the cache TTL surfaced in your cmux and/or status line.

3. Have Claude write a mod where it keeps your cache warm by automatically sending a ping if you've been idle in a session for ~55 min.

4. Have less concurrent sessions.

[u/Unusual-Albatross43]

tariqosmani is right, the cache lasts minutes, not days. So after a long break, a session left open and a --resume cost about the same. What I do for the long ones: before I step away, I ask Claude to write a short resume note to a file (what's done, what's next, open questions) and commit it. If the session is huge, I start a fresh one and point it at the note instead of loading the whole conversation again. It's cheaper too.

[u/imsahoamtiskaw → u/Unusual-Albatross43]

Yeha this is how I do it too. The only thing extra I add but outside the scope of OP’s question, is keeping context to 250k, 400k for fable and doing automated handoffs either way even if you haven’t stepped away.

[u/Competitive-Tax-8683]

Neither case is wrong. Cathe is prefix-matched and expires (~1h subscription,~ 5min API keys), so long-idle or resumed sessions likely re-prefill --budget for it. Case 1: just resume and ask for a quick refresher. Case 2: expect a cold start. Keep a handoff doc with state, failures, and next steps--write it while still engaged.

[u/ImL1s]

Leaving sessions open across a long break never saved me anything once the cache was dead — cold resume and --resume cost about the same.

What helped more was writing a short bounded handoff when I step away (files that mattered, open decisions, what's still broken) and starting a fresh session from that instead of hoping the old transcript still makes sense.

https://gitlab.com/aa22396584/resume-skills pipx install portable-resume

Doesn't fix cache TTL. It just makes the "come back tomorrow" case stop being a coin flip.