When to Start a New Chat vs Keep Going

TL;DR: Keep going while the thread is doing one job and still honours constraints you set earlier. Start a new chat the moment it contradicts itself, repeats something you rejected, or drops a rule it followed twenty turns ago. Research finds models rarely recover once lost, so restart with a consolidated re-entry brief instead of arguing.

Should I start a new chat or keep going?

Keep going while the conversation is still about one job and the model is still obeying the rules you set. Start a new chat the moment it breaks one of those rules on its own, because that is the point where extra turns stop paying for themselves.

This is a real decision because both options cost something. Continuing a bad thread costs accuracy, and the loss compounds quietly. Restarting costs everything you established: the tone you tuned over ten messages, the constraints you added one at a time, the version you agreed was close. People choose badly because only one of those costs is visible. So make it a checklist, not a mood.

Two of those rows are options most people never use, and I will come back to both. The mechanism underneath all of this, why a model loses track of what you told it, is a separate diagnosis: why ChatGPT forgets what you told it covers it properly. This post is about the call you make once it happens.

What are the signs a ChatGPT conversation has gone bad?

There are five, and they are not equally serious. Two mean the thread is finished. The rest mean you have a turn or two left.

1. Drift. You asked about pricing tiers, and it keeps folding in the onboarding flow you discussed forty messages ago. Nothing it says is wrong, exactly. It is answering a slightly different question, and it will keep doing that, because the old topic is still in the transcript with as much claim on its attention as your latest message. Drift is the mildest signal and the easiest to miss, because the answers still look competent.

2. Contradiction. It tells you the API supports webhooks, and eleven turns earlier it told you it does not. Highest confidence signal on the list. Saying "you said the opposite earlier" does not fix it, because that just adds another turn about the contradiction. Stop here.

3. Repetition. You get back the same opening line, the same structure, or the same example you explicitly rejected two messages ago. The model is anchoring on its own earlier output rather than your correction. Repetition after an explicit rejection is the second finished-thread signal.

4. Constraint decay. You set a 300-word limit at turn five and it held for fifteen turns. Now you are getting 900 words with subheadings you never asked for. The rule is still in the transcript; it is just no longer weighted as though it matters. This is the most common trigger for a restart, and the most reversible, because it responds to being restated in the current turn. Restate it once. If it decays again, restart.

5. Post-tangent damage. The thread was excellent, you asked one unrelated question, and everything after is measurably worse. This one has its own remedy, and it is not a fresh start.

One trap. When a thread slips, the instinct is to correct harder, which lengthens the transcript and makes every remaining problem worse. The corrections become the noise.

Why does starting over usually beat pushing through?

Because a model that has taken a wrong turn tends to stay on it. That is the headline finding of a large multi-turn study, and the most useful piece of research for anyone who lives in chat interfaces.

In LLMs Get Lost In Multi-Turn Conversation (Laban et al., arXiv:2505.06120, submitted May 9, 2025), the authors simulated more than 200,000 conversations across 15 models and six generation tasks. Every model did worse when the same task was spread across turns instead of stated once, with an average drop of 39%. Aptitude fell about 16%; unreliability, the gap between a model's best and worst run on the same task, rose 112%. Their summary is blunt: "when LLMs take a wrong turn in a conversation, they get lost and do not recover."

The paper's advice to users is almost exactly the rule in this post. Under "If time allows, try again", the authors write that if a conversation "did not lead to expected outcomes, starting a new conversation that repeats the same information might yield significantly better outcomes than continuing an ongoing conversation", adding that "our experiments show that persisting in a conversation with the model is ineffective."

Then the part that matters most, headed "Consolidate before retrying": "Since LLMs are ineffective at dealing with information dispersed across multiple turns, consolidating instruction requirements into a single instruction is an effective strategy to improve the model's aptitude and reliability."

That is the whole trick. A restart alone throws away your context. A restart plus consolidation turns a scattered twenty-turn conversation into one well-specified request, which is the setting these models are good at. Position effects compound it: a rule set at turn nine sits in the middle of the context window, the worst address in the conversation.

What should I paste into the new chat?

A brief, not a transcript. This is the part people skip, and skipping it is why "just start a new chat" has a reputation for not working.

Four blocks, in this order. Keep the whole thing to one screen.

CONTEXT RESET. This message is the full brief. Do not ask me to re-explain any of it.

GOAL
[One sentence. What finished looks like, not what the topic is.]

CONSTRAINTS (non-negotiable)
- [Format and length]
- [Audience and reading level]
- [Anything forbidden: words, claims, structures, tools]
- [Anything required: a schema, a house style, a citation rule]

DECIDED ALREADY (do not reopen)
- [Decision] because [one-line reason]
- [Decision] because [one-line reason]

LAST ACCEPTED OUTPUT
"""
[Paste only the most recent version I approved. If none, write NONE.]
"""

TASK NOW
[The single next thing you want.]

If anything above conflicts with what you infer from memory or from files,
the text above wins. If a constraint is unclear, ask one question, then proceed.

The "DECIDED ALREADY" block saves the most time. Half the pain of restarting is relitigating settled questions, and a decision with its reason attached is much harder to quietly overturn than a decision on its own.

You do not have to write the brief from scratch. Ask the dying thread to write it, then edit it, which takes about a minute:

Before I close this conversation, write me a handoff brief for a fresh chat.

Include only:
1. The goal, in one sentence.
2. Every constraint I set that still applies, as a bulleted list. Quote my wording.
3. Every decision we made and the reason we made it.
4. The most recent version I said was good, verbatim.

Rules:
- Do not summarise the discussion. I want the state, not the story.
- Do not include anything I rejected or reversed.
- If you are unsure whether a constraint still applies, list it under UNCERTAIN
  instead of guessing.
- Maximum 250 words plus the verbatim output.

Read it before you paste it anywhere. The UNCERTAIN section does real work: it surfaces the constraints the thread had already started losing. Two things not to carry over: the old transcript, because you would reimport the noise that broke it, and any output you rejected without saying why, since an unexplained bad example is still an example.

Does a long chat cost more money and make replies slower?

It costs real money if you pay per token, and far less latency than people assume. The "long chats are expensive" folk wisdom is broadly right. The "long chats are slow" one is mostly wrong.

Start with the mechanism. OpenAI's conversation state guide states that "each text generation request is independent and stateless". The model does not remember turn thirty-nine when you send turn forty. Your client re-sends the whole transcript, every time. A conversation is not an object growing on a server. It is a payload that gets bigger and is paid for again every turn.

On cost, that compounds visibly. OpenAI's published rate for GPT-5.6 Terra is $2.00 per 1M short-context input tokens, or $0.20 per 1M cached, checked on the API pricing page August 26, 2026. If a transcript has reached roughly 100,000 tokens and you send twenty more turns, that is about 2M input tokens re-sent. Arithmetic from those rates puts it between roughly $0.40 fully cached and $4.00 uncached, for twenty turns of a conversation you already had. Real threads land in between, because caching covers only the stable prefix, and a cached prefix has a 30 minute default lifetime from its last use.

One threshold is worth memorising. The GPT-5.6 Terra model page states: "Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request." Not 2x on the excess. On the whole request.

Latency is where common advice runs backwards. OpenAI's latency optimization guide is direct: "cutting 50% of your prompt may only result in a 1-5% latency improvement", and it says to spend your effort elsewhere unless your contexts are genuinely massive. The heuristic that does move the needle: "cutting 50% of your output tokens may cut ~50% of your latency." If a reply feels slow, the length of the answer is the lever, not the length of the history.

Restarting carries one counterintuitive cost. The caching guide warns that "summarization, compaction, or context truncation can change the prefix and reset cache reuse". A fresh chat discards a cached prefix you were already getting a discount on, so in a metered agent loop, restarting purely to save money can cost more than staying put. Restart for quality; treat cost as a tiebreaker.

When should a fact live in a Project or a saved instruction instead of a chat?

The moment you need it in a second conversation. A chat transcript is working memory, and treating it as storage is the root cause of most restart pain.

Four durable homes sit above the transcript, and they behave differently. All of the following was checked on OpenAI's help centre on August 26, 2026.

Custom Instructions are the global layer. OpenAI states they are "available on all plans" and "applied immediately to all chats", including existing conversations. There is a hard budget: 1,500 characters on Free and Go, 5,000 on Plus, Pro, Enterprise, Business, and Education. That limit is the real design constraint. Standing rules only, no project detail.

Project instructions are the scoped layer, and they come with a warning most people meet by accident. OpenAI's Projects article states that project instructions "only apply inside the respective project and will override your global custom instructions". Anything you truly need everywhere belongs in both places. Duplication is correct here, not a smell.

Project files are the reference layer, for material you would otherwise paste into every thread. Limits by plan: 5 files on Free, 25 on Plus and Go, 40 on Pro. Uploading a spec once beats pasting it into six conversations, and it does not eat your instruction budget.

Memory is the accumulating layer, and the least deterministic. OpenAI draws the line itself: "For explicit information or instructions, you can add it to your Custom Instructions. For information shared via conversations, ChatGPT can remember relevant details for you." Rules go in instructions. Context accrues in memory.

That last row is worth arguing about. Every layer above it belongs to a vendor and can be capped, overridden, resynthesised, or changed in a product update you did not read. Keeping persistent product context in every AI chat works through the storage side, and building a personal AI prompt library covers reusable instructions. For whether a rule belongs in an instruction layer or in the message itself, system prompt versus user prompt has the trade-off.

This is the gap Prompt Architects was built for. Standing context lives in a Context Library and reusable instructions live in a Prompt Library, both outside any single conversation, and Global Variables let one brief carry the client name, audience, and constraints without retyping. The enhancer turns a rough re-entry brief into a structured one before you paste it.

What we do not do: read your chats, replace ChatGPT's memory, or enlarge your context window. No browser extension can do that last one; the number is set by your plan and your model. What we change is whether the useful half of your context lives only inside a transcript that is about to fall out of range.

What is a Temporary Chat for?

For questions you want answered without them shaping anything else. OpenAI's Temporary Chat FAQ states that ChatGPT "won't access or create memories for personalization" there, but "will still follow your custom instructions if they're enabled", checked August 26, 2026. Temporary Chats also do not appear in your history and are not used to improve models, though a copy may be kept up to 30 days for safety. You start one by opening a new chat and clicking the pill-shaped "Temporary" button at the top right.

That combination is useful and confusing in equal measure. A Temporary Chat knows your standing rules perfectly and nothing about your history. Use it for a one-off question, for anything you do not want influencing future personalisation, and to test whether a bad answer comes from your memory rather than your prompt. If the same prompt behaves correctly in a Temporary Chat, the problem was something stored about you.

Do not use it for ongoing work. Nothing you establish inside one survives.

Branch instead of restarting

This is the option most people do not know exists, and it is the right answer for post-tangent damage. ChatGPT's release notes for September 4, 2025 describe it: "Hover over a message, click More actions (⋯), and select Branch in new chat to start a separate conversation from that point." The note says it was available that day for all logged-in users on web.

A branch keeps everything before the branch point and drops everything after it. That is the surgery you want when a thread was excellent for thirty turns, you asked one unrelated question, and quality collapsed. No re-entry brief needed, because the context you care about is already in the branch. Inside a project, OpenAI describes branching as a way to "explore a new idea without losing the original thread".

Branching does not fix a thread that was confused from the start. If you cannot point to the message where things went wrong, restart instead.

The rule, in one line

Keep going while the thread does one job and obeys its rules. Restart the moment it breaks one on its own, and never restart empty-handed.

Three habits make it automatic. Start a new chat slightly earlier than feels necessary, roughly whenever a conversation stops being about one thing. Keep a re-entry brief template somewhere you can reach in five seconds, because a template you have to rewrite is one you will skip. And when you catch yourself explaining something for the third time, move it up a layer into instructions or a project file.

For a health check before you decide, paste this into the thread:

Pause the task. Answer these four questions about this conversation only:

1. In one sentence, what task do you believe we are working on right now?
2. List every constraint I have set that you are currently applying.
3. Name any constraint I set earlier that you are no longer sure applies.
4. Name anything you have told me in this thread that contradicts
   something else you told me in this thread.

Answer only these four. Do not resume the task.

An honest answer to question three or four is your restart signal, and it costs one turn. A model that says it lost your word count is one you can fix in a line; a model that quietly guesses costs you a rewrite. Thresholds differ by tool: ChatGPT vs Claude for prompts covers where the two diverge on long instructions.