How to Continue a Long Claude Chat in a New Conversation

A Claude conversation that has run for hours eventually stops being useful. Replies get slower, earlier decisions quietly stop being honoured, and you find yourself repeating a constraint you already agreed on three times. The instinct at that point is to keep pushing, because the whole history is right there on screen and starting again feels like throwing it away. It is not throwing it away, and pushing on is the more expensive option. The work is in deciding what travels to the next conversation and writing it down deliberately, rather than hoping the next chat inherits something.

This is a mechanical problem with a mechanical answer. What follows is the sequence: why the old chat cannot be rescued, what actually needs to move, how to write the handover, where to put it, and how to confirm the new chat received it.

Why the Old Chat Cannot Be Rescued

Every turn in a conversation re-sends the whole conversation. The model has no running state between your messages — the transcript so far is assembled and submitted each time you press enter, and the amount that fits is finite. Once a conversation outgrows that budget, something has to give, and whatever gives is gone from the model's view even though it is still visible to you in the scrollback.

That mismatch is the signature. If you can read a decision on your own screen and the assistant behaves as though it was never made, the problem is capacity rather than comprehension, and no amount of rephrasing fixes it. Asking the model to re-read the conversation does not work either, because it cannot read anything that was not sent to it. The full version of this distinction is in Context Window vs Memory.

A second effect compounds it. Even material that still fits is not attended to evenly. Content at the start and end of a long context is used more reliably than content buried in the middle, so a conversation can degrade well before it hits any hard wall. The practical consequence is that a very long chat is already lossy by the time you notice, and the question is not whether to restart but how cleanly.

The one thing a restart genuinely costs you is the implicit context: the dozen small clarifications, the tone you settled into, the examples you worked through. Most of that is reconstructible in a paragraph. Almost none of it is worth the degradation you are absorbing to keep it.

What Actually Needs to Travel

The temptation is to carry everything. Resist it, because carrying everything recreates the problem you are escaping — a new chat that starts three quarters full is a new chat that degrades in an afternoon.

Four categories are worth moving, and they are smaller than they look:

1. Decisions that are settled. What you are building, which approach you chose, what the output has to look like. These are usually five or six lines and they do most of the work.
2. Constraints that must hold. The things that, if violated, make an answer useless — a library you cannot use, a tone you must keep, a length limit, an audience. Constraints are the material most often lost first and most expensive to lose, because a violated constraint produces confident, plausible, wrong output.
3. Rejected options and why. This is the category people skip and then regret. Without it the new chat will cheerfully re-propose the approach you spent an hour ruling out, and you will spend that hour again.
4. The current state. Where the work actually stands right now, as opposed to where it started. One paragraph, present tense.

What does not need to travel: the full transcript, your exploratory questions, the model's long explanations, anything already captured in a file you can attach, and the narrative of how you got here. If a detail does not change what the next answer should be, it is history rather than context.

The Handover Document

Write it yourself, or write it with the model's help and then edit it — but do not paste an unreviewed summary forward. A summary the model produces is a compression of what it currently sees, which in a degraded chat is already missing things. Reviewing it is how you catch that.

A shape that works, in plain prose rather than any special format:

• Goal. One or two sentences on what the work is for.
• Decided. A short list of settled choices, each a single line.
• Constraints. A short list of hard requirements, each a single line.
• Ruled out. Each rejected option with a half-line reason.
• Current state. Where things stand and what the immediate next step is.
• Open questions. Anything genuinely undecided, so the new chat does not invent an answer and treat it as given.

Three hundred words is usually plenty and five hundred is generous. If yours runs past a page, you are carrying history rather than context, and the first thing to cut is anything describing how you arrived at a decision rather than what the decision is.

One habit makes this much cheaper: write it before you need it. Spending two minutes at the end of a working session on a decisions-and-constraints paragraph means the handover already exists when a chat finally degrades, rather than having to be reconstructed from a conversation that is by then unreliable.

Where to Put It: Project Instructions or a Paste

If the work lives in a Claude Project, you have two places to put the handover, and they behave differently.

Project instructions are supplied to every chat in the Project, unconditionally. That is what makes them reliable. Anything that must always apply — the constraints, the settled decisions, the tone — belongs here, and putting it here means you never paste it again. The cost is that it occupies space in every conversation whether relevant or not, which is a reason to keep it tight.

Attached documents are drawn on selectively. They are stored with the Project and relevant parts are pulled in when a question appears to call for them. When the selection is good this is indistinguishable from memory; when it is not, you get an answer that contradicts a file you can see sitting in the sidebar. That makes attachments right for reference material you consult occasionally and wrong for the rules that must hold on every reply.

A paste into the first message of the new chat is the fallback when there is no Project, and it is perfectly adequate. It is explicit, it is visible, and it sits at the start of the context where it is attended to reliably.

What does not happen, in any of these cases, is a conversation leaving something behind for the next one. A Project shares its instructions and its documents; it does not accumulate what its chats concluded. An hour of reasoning in one chat leaves the Project exactly as it found it unless you promote the conclusions yourself. That mechanism, and a two-minute test you can run on your own account to confirm it, is covered in Does Claude Remember Other Chats in the Same Project.

Verifying the New Chat Took It

Do not assume the handover landed. Verification costs one message.

Open the new chat and ask it to restate, in its own words, the constraints and what has been ruled out. Three things can come back. It restates them correctly, in which case you are running. It restates them vaguely — right shape, wrong specifics — which usually means your handover described a decision without stating it, and the fix is in your text rather than in the tool. Or it has no idea, which means the instructions are not where you think they are, the chat was started outside the Project, or you are in a different workspace than you assumed.

That last case is the most common and the easiest to miss. A chat started from the sidebar or the home screen looks identical to one started from inside a Project and does not inherit any of its materials. If a new chat behaves as though the Project does not exist, check where you started it before checking anything else.

A second check is worth running once, not every time: ask a question whose correct answer depends on a ruled-out option staying ruled out. If the model re-proposes it, your handover recorded the decision but not the reason, and reasons are what stop a suggestion coming back.

Three Ways This Goes Wrong

Pasting the whole transcript. It is the obvious move and it is the worst one. You spend most of a fresh context window on material that was already too long to be used properly, including every abandoned direction, and you reproduce the degradation immediately. The transcript is the thing you are escaping.

Trusting an unreviewed summary. Ask for a summary by all means — it is faster than writing from scratch. Then read it against what you know, because it was produced by a model that has already lost part of the conversation, and a confident summary with a missing constraint is worse than no summary at all. Correct it before it becomes the foundation of the next session.

Assuming the Project remembers. Shared instructions and attached documents cross between chats. Conclusions do not. This is the single most common disappointment with Project-based work, and the fix is a habit rather than a setting: at the end of a session, promote what was decided into the instructions. The broader version of the question — what Claude carries between conversations at all — is in Does Claude Remember Previous Conversations.

When to Start the New Chat

Earlier than feels natural. The useful threshold is not a token count you cannot see; it is the point at which re-establishing context costs less than the errors you are absorbing.

Concrete signals, any two of which are enough: you have restated the same constraint twice, the model has contradicted a decision you can still read in the scrollback, replies have become noticeably slower, or you have started prefacing messages with reminders. Those are all the same underlying symptom.

Starting fresh at that point is cheap, because you write the handover from a conversation you still trust. Waiting until the chat is visibly broken means writing the handover from a conversation that has already dropped things, and you will not know which things.

There is also a planning version of this. If a piece of work is obviously multi-session — anything spanning days — set it up as a Project at the start with the constraints already in the instructions, and treat each chat as disposable from the beginning. Then there is no handover to write, because the durable part was never inside a conversation.

Keeping the Handover After the Chat Ends

The handover you write is more valuable than the conversation it came from, and it is the thing most people throw away.

Keep it outside the assistant. A conversation is a transcript that nobody wants to re-read; a decisions-and-constraints document is a page you will reuse for weeks. Kept as plain text you own, it also pastes into whichever assistant you open next, which matters more than it sounds — the material transfers even though no memory feature does. Working across two assistants deliberately is covered in Using ChatGPT and Claude Together.

The accumulated version of these handovers is a genuinely useful artefact. After a month of a project you have a short, current statement of what is true, what was tried, and what is still open — which is exactly what you would want to hand a colleague, and exactly what you want to hand a fresh chat.

Where MindLock Sits

To be precise about the category: MindLock does not extend a Claude conversation and no tool can, because the limit is a property of the model rather than of the interface around it. What it addresses is the part after the chat ends.

You save a conversation worth keeping with Ctrl or Cmd plus S in Claude, ChatGPT, Gemini or Perplexity, or with the one-click button from the Chrome extension, which is loaded unpacked in developer mode rather than installed from a store. You upload the saved page, and distillation turns your saved conversations into memory documents — a profile memory plus topic memories — which are plain text you can open, read and correct rather than an opaque store. Semantic search with Ctrl or Cmd plus K finds the relevant one without you remembering which chat it came from. Then you select what matters, generate a context block, and paste it into the new conversation. What those documents look like is in Memory Documents.

Two caveats, stated plainly. Nothing is captured automatically: saving is a keystroke you press, and memory documents update when you re-run distillation rather than continuously, so a document is only as current as your last distil. And local distillation runs on your own GPU through WebGPU, using Llama 3.2 3B by default, so hardware without WebGPU support cannot run it and would need the cloud option on the paid tier. The split between the two is on the pricing page.

The Short Version

A long Claude chat cannot be extended, only replaced, because the whole transcript is re-sent every turn and the budget is finite. The signature is material you can read on screen that the model behaves as though it never saw.

Carry four things into the new conversation: settled decisions, hard constraints, options you ruled out and why, and the current state. Leave the transcript behind. Put anything that must always apply into Project instructions rather than a paste, and verify by asking the new chat to restate the constraints before you rely on it.

Start the new chat earlier than feels comfortable — at the first repeated reminder rather than at visible breakdown — and keep the handover afterwards as plain text you own. The conversation was disposable. The page you wrote about it is not.