When an agent stops mid-task, I preserve its transcript and working tree before deciding how to continue. Resuming can retain the working context; it is not a promise of free processing or a warm prompt cache.
An agent stopping mid-task is not the same event as an agent failing at the task, and for a long time I treated the two identically. A session hits a weekly usage limit, or the pane it was running in gets closed, or a subagent gets killed by something upstream, and the instinct is to start over: launch a fresh session, hand it the same brief, let it work from a clean slate. That instinct throws away the single most valuable thing the dead session produced, which is not its output but its transcript.
I treat a saved transcript as working context, not as a complete copy of the model’s mind. It can preserve the messages, tool results and decisions the session recorded, which gives the next invocation something concrete to continue from. It does not guarantee that every earlier detail will fit into the active context, or that a file mentioned earlier still contains the same code. My first check after resuming is therefore the working tree and the last recorded result. I want continuity without mistaking an old observation for the current state, because an accurate transcript can still describe a repository that another process has changed since.
The economic question is separate from the continuity question. I do not assume that replaying a saved conversation is free, or that the existence of a transcript proves the provider still has a reusable prompt cache. Avoiding repeated investigation can save work, but reading the retained context can still consume tokens. The amount charged depends on the actual request and service, so I check usage instead of deriving a saving from the word resume. The transcript is my working cache in the ordinary sense of a record worth keeping; it is not a receipt proving what the next invocation will cost.
The mechanics differ by what actually died. A CLI with saved-session support may offer a resume command keyed by session id; I check that the intended conversation was restored before continuing. A subagent stopped by its parent, or a workflow run interrupted partway, needs the resume path specific to that tool, pointing back at the same run or transcript rather than issuing a new invocation with the same prompt, because a new invocation with an unchanged prompt is not a resume, it is a second attempt that happens to look similar from the outside.
I also keep a distinction between resuming a conversation and reusing a cached request or workflow result. Changing a model or configuration can affect cache reuse without erasing the saved conversation. Adding a new instruction can be part of continuing that conversation rather than starting over. For a workflow whose replay rules require unchanged inputs, I preserve those inputs and check its own record of what was reused. For a CLI conversation, I check the restored session and its supported options. Treating all of those mechanisms as one cache gives me a neat rule that can be wrong for the tool actually in front of me.
The other half of this is protecting whatever partial work exists outside the transcript itself, an open working tree, staged but uncommitted files, a half-finished diff. That state does not disappear when a session dies, but it is only useful if the resumed session checkpoints it immediately rather than assuming it is still exactly where it was left. The first thing a resumed worker should do is commit or stash what is already there, so a second interruption does not compound the first.
Quota running out, a connection dropping, a pane closing, none of that is the same as the work being lost. The work is sitting in the transcript and the working tree exactly where the dead session left it. Starting fresh without carrying that record forward discards useful context. My default is to preserve it, inspect it and resume where the tool supports it, with the next step grounded in the work that actually survived.