Guide · Session continuity
Why your AI forgets everything between sessions
You close the tab, open a new chat the next morning, and spend the first twenty minutes explaining the project again: what it is, what you already tried, what you decided yesterday and why. That isn't your AI being careless. It's how these models work, and once you see why, the fix is simple.
What is actually happening
A language model keeps nothing between requests. Each time it answers, it sees only what is sent to it in that moment: the instructions, the files it was given and the conversation so far. That bundle is its context window. A "session" is just that conversation being sent again with every new message.
So a new session starts with an empty context. Nothing from yesterday is in it unless something puts it there. And even inside one long session, the context fills up: older messages get trimmed or compacted into a summary, and the early decisions, the ones that explain why the code looks the way it does, are the first to blur.
Why built-in memory doesn't fix it
Chat assistants now offer memory features. They are useful, and they solve a different problem:
- They remember facts about you, not where a piece of work stands. "Prefers TypeScript" is a memory. "We dropped the queue because retries doubled the cost; next step is the webhook test" is a state, and that is what you need tomorrow.
- They live inside one product. What one assistant remembers does not follow you to another vendor, to a coding agent in your terminal or to a local model.
- Project instructions go stale. A rules file or project prompt is good for things that rarely change. Nobody rewrites it at every pause, so it can't say where the work stopped.
What does carry the work forward: a handoff at natural pauses
The fix is the one people use when they hand work to a colleague: a short note at a natural stopping point that says where things stand. Not the whole transcript, which is long, noisy and expensive to send again. A good handoff answers five questions:
- What was tried? So nobody repeats a dead end.
- What was decided, and why? The reasons are what a summary usually loses.
- What is done? With a way to check it, such as a passing test or a merged change.
- What failed? Including the error, so the next session doesn't retry it blind.
- Where does it stand, and what's next? One state (working, blocked, open) and the next concrete step.
state: working tried: moved retries into the webhook handler decided: one subscription row per account; Stripe's webhook is the only writer (a client can't grant itself access) done: checkout opens for all three plans; tests pass failed: invoice.paid arrived before checkout.completed and was dropped; now retried next: test a 7-day trial end to end, then the cancel path detail: docs/billing.md, branch billing-webhooks
Read that at the start of a session and the model is working within a minute instead of twenty.
Doing it by hand, and where that breaks
You can start today with a file in the repo, such as HANDOFF.md, and an instruction in your assistant's rules: read it first, update it before you stop. It works, and it breaks in three predictable places: someone forgets to update it, two lines of work end up in one file, and the note doesn't travel when you switch to another assistant, another machine or a cloud session.
How ResumeState does it
ResumeState makes the handoff part of how your AI starts and ends a session, for any assistant:
- You connect an AI once with a one-time code. You paste two lines; no API key goes into a chat or a config file.
- Work is kept in lanes, one per line of work, each with a short code. Each handoff is saved under its lane with the fields above.
- At the start of the next session, the AI asks for the lane's latest handoff and picks up from there, on any model: a new chat, a different vendor, a cheaper model or a teammate's AI.
- Your continuity is private to your account (and your team, on Team), and you can export it while you're a member.
It works with assistants that can run a command (Claude Code, Codex, Cursor's agent, Gemini CLI) and with chat assistants that can send a web request. See Claude Code session handoff for what the start and end routine looks like in practice.
Questions
Isn't a bigger context window the same thing?
No. A bigger window lets one session run longer before it trims, but a new session still starts empty, and a long transcript costs more to send every time. A handoff is a few hundred words that carry the state, whatever the window size.
Does it work if I switch from one AI vendor to another?
Yes. ResumeState is model- and vendor-agnostic: a handoff written by one assistant is plain structured text that any other connected assistant can read and continue from.
Do I have to write the handoffs myself?
No. Your AI writes them at natural pauses, in the same shape each time. You can read and edit them in your account.
What does it cost?
Solo is $9.99 CAD a month, Team $19.99 CAD and Enterprise $99 CAD, with 20% off yearly. Every plan starts with a 7-day free trial.
Try it on your own work. Every plan starts with a 7-day free trial, cancel anytime. Plans start at $9.99 CAD a month.
Related guides
- Hand a session to a cheaper or different model: Let the strong model reason, let a cheaper one do the volume, and keep the thread between them.
- An MCP server for session continuity: What an MCP memory or continuity server should do for coding agents, and how ResumeState connects.
- Claude Code session handoff: Carry Claude Code's work across /clear, compaction, new sessions, other machines and other models.