DEV Community: Roshan

What actually happens when your AI coding session dies mid-refactor

Roshan — Sun, 20 Sep 2026 18:56:58 +0000

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.

How I verified that an image resizer processes files locally

Roshan — Mon, 31 Aug 2026 23:43:20 +0000

Many online image tools begin with the same instruction: upload your file.

That is convenient, but it also means trusting an unfamiliar server with profile photos, identity documents, application images, or private screenshots. When I built Shard Tools, I wanted the image-processing step to happen inside the browser instead.

I also wanted that claim to be inspectable rather than another privacy slogan.

What the resizer does

The 200×200 image resizer creates an image that is exactly 200 pixels wide and 200 pixels high.

A rectangular image cannot become square without making a choice. The tool provides two:

Crop to fill preserves the aspect ratio and removes the overflow around a centered square.
Fit with background preserves the complete image and fills the remaining space with a selected background color.

It does not stretch the width and height independently. That would technically produce a 200×200 file, but faces, logos, circles, and text would be distorted.

The width and height remain editable for forms that require a different exact size.

What happens inside the browser

After you choose a file, the browser decodes it locally and reads its visible orientation. This prevents phone photos from being processed sideways.

Crop-to-fill enlarges the image until it covers the square, then removes the overflow. Fit-with-background scales the complete image into the square and fills the remaining space. Both approaches preserve the original aspect ratio.

The browser draws the result onto a new 200×200 canvas and creates a temporary download link inside the current tab. The selected image does not need to be sent to Shard Tools for processing.

What I tested

During the latest release check, I processed a PNG and verified that the generated result reported an actual width and height of 200×200 pixels.

The interface displays dimensions read from the generated output rather than assuming that the requested size was produced. It also reports the output file size before download.

This test verifies the pixel dimensions. It does not claim that a 200×200 image meets passport or biometric-photo requirements, and it does not guarantee a particular file size in KB.

Making the privacy claim testable

I built a separate live privacy-proof page that performs a real 200×200 resize while measuring data-capable browser requests immediately before and after processing.

The measurement watches requests initiated through:

fetch
XMLHttpRequest
sendBeacon

When the difference is zero, the image-processing action added no request through those mechanisms that could carry the selected image away.

You can check this independently:

Open your browser’s developer tools.
Select the Network panel and clear its request list.
Run the built-in sample or choose an image.
Inspect any requests added during processing.
Confirm that the output uses a local blob: URL rather than an upload response.

An important limitation

The proof does not claim that the entire webpage makes zero network requests.

The page still downloads its HTML, JavaScript, CSS, fonts, advertisements, and external directory badges. Those third-party hosts are disclosed in the live page report.

The narrower claim is the useful one: selecting and processing an image should not add an upload request.

The request counter is an observable browser measurement, not a formal security proof. That is why the page explains what it measures and encourages visitors to verify the result in the Network panel.

Why this distinction matters

“Runs locally” should describe an observable boundary, not just marketing copy.

For this tool, selecting, decoding, resizing, previewing, encoding, and creating the download all happen through browser APIs. The server provides the application, but it does not need the selected image to produce the result.

Try the 200×200 image resizer, or inspect the process using the privacy-proof page.

I would especially appreciate feedback about the measurement, its limitations, and anything the disclosure should explain more clearly.

I asked 50+ developers what they do when their AI session dies mid-task. Here's what I found.

Roshan — Thu, 02 Jul 2026 22:15:58 +0000

Not a product pitch just research notes from talking to a lot of people.
I've been building in the AI coding tools space and wanted to understand one specific moment: your session hits a limit, gets deleted, or just goes stale. What do you actually do?

I posted in a bunch of developer communities and talked to people directly. A few things surprised me.

The power users aren't your best signal
Developers with sophisticated workflows custom handoff skills, AGENTS.md discipline, tmux harnesses — described the pain clearly but had already built their own fix. They're not looking for a tool. They're looking for a better version of what they made.

The people who described the pain most vividly were non-technical: a tax lawyer doing no-code projects, a school admin. No workaround, no jargon — just "I have to explain everything from scratch and it's exhausting."

Nobody trusts the transcript

Almost everyone said the same thing unprompted: the chat history isn't reliable. It carries old failed attempts, wrong assumptions, things the AI said confidently that turned out to be wrong. The people with the best workflows kept the working state outside the chat — git diff, changed files, a short note about what actually worked.

The moment that resonates

"What do you do when your AI session dies mid-task and you have to explain everything to a new tool from scratch?"

That question got strong reactions every time. Not "context management" or "handoff tooling" those got polite nods. The specific painful moment got people telling stories.