3:47pm. Mid-refactor. "Rate limit reached."
If you've used Claude Code, Cursor, or any AI coding tool for more than a
few weeks, you've hit this. The model was two files deep into a change,
you had a plan in your head that never made it into a comment or a commit,
and now the session is just... gone. You open a new one, and it knows
nothing.
I got tired of this happening to me, so I spent a while looking at what
actually survives a dead AI session and what doesn't — and building a tool
around the answer. This post is about the "what doesn't survive" part,
because I think it's more interesting than the tool itself.
What's actually lost when a session dies
Three different things get conflated under "context," and they behave
completely differently when a session ends:
1. What's on disk. Your git diff, the files you touched, your commit
history. This survives everything — a crash, a rate limit, an accidental
window close. It's also the least useful part on its own, because a diff
tells you what changed, not why.
2. What was in the model's context window. Prior turns, tool calls,
files it read. This is gone the instant the session ends, full stop.
There's no API that hands you back a dead session's context.
3. What was in your head. The plan, the constraint you were working
around, the two approaches you already tried and rejected. This is the
part that actually matters for picking up where you left off — and it's
the part that was never written down anywhere, in disk or in the model's
memory.
Most "session recovery" approaches focus on #1 because it's the only one
that's technically easy — read the git diff, dump it into the next
session's context, done. But a diff without the "why" behind it is why
handoffs between AI tools (or between you and a fresh session of the same
tool) feel so lossy: the new session can see what changed, but has to
re-derive why, which is exactly the part that took the most thinking the
first time.
What's actually recoverable, and how
The disk-scan part is straightforward: diff, changed files, a dependency
graph so the next session knows what's risky to touch (impact radius, not
just "these files changed").
The harder part is #3 — and the only way to get it back is if something
was actually watching the conversation, not just the disk, before the
session died. That's the piece most tooling skips, because it means
hooking into each tool's session/transcript format individually rather
than just reading files.
I ended up building this as ShardStitch — the name is literal: it shards
a session into its parts (diff, files, dependency graph, and the intent
behind them) and stitches those back into a formatted handoff for
whatever tool picks up next. It keeps a local, always-on vault of session
transcripts too (so a rate-limit or crash doesn't also delete the
conversation, which some tools do), and on handoff distills that into
intent, decisions made, and things already tried and rejected — not just
"here's the diff." It's local-only, 23 target tools, free CLI scan for
anyone who just wants the git-diff-plus-dependency-graph part without the
transcript layer.
Repo's here if you want to see how the disk-scan side works:
https://github.com/shardstitch/shardstitch — and the tool itself is at
https://shardstitch.com if the transcript-recovery part is useful to you.
The actual question worth asking
If you're building anything AI-agent-adjacent: what's your session losing
right now that isn't on disk? For most setups the honest answer is "the
reasoning," and that's usually the expensive part to reconstruct. Curious
what other people have done here — CLAUDE.md/AGENTS.md conventions,
custom hooks, anything else that's worked for you.
Top comments (2)
The failure mode we hit most often with session-death handoffs isn't just lost intent, but negative knowledge. Specifically, the three failed hypotheses the first session burned through before finding the working path.
If the incoming session only gets the current working tree and a high-level goal, its very first instinct is usually to try failed hypothesis #1 all over again because that's the most canonical pattern in the pretraining data. We started writing append-only scratchpads for active runs where the agent explicitly records rejected paths and why they broke. That small negative index saves more tokens on resumption than dumping the whole prior transcript.
The three-category breakdown is the right frame. Disk state (durable, survives everything), model context window (gone on session end, no recovery API), and head state (the plan, the two rejected approaches, the constraint) — these behave completely differently and most tooling only addresses the first one because it's the only one that's technically easy.
The 'diff without the why' problem is the real cost of session loss. A new session can see what changed but has to re-derive why, and the re-derivation is exactly what took the most thinking the first time. This is also why CLAUDE.md conventions help — they're a way of externalizing some of the intent layer to disk before the session ends.
The dependency graph / impact radius piece is the most useful addition beyond a plain git diff. 'These files changed' is different from 'these files changed and here's what they touch.' The second version lets the next session know where the blast radius is without having to re-read the codebase.
What I've found useful: writing a brief 'state of play' comment in code or a scratch file at natural stopping points — not for future humans but specifically as a handoff note to the next AI session. Something like 'we're mid-refactor of X, tried approach A (rejected because of Y), currently on approach B, next step is Z.' It's manual but it addresses the head-state problem directly without needing tooling.