I use ChatGPT heavily for long-running projects, game playthroughs, campaign management, design work, and other conversations that can continue for months. One of the most frustrating parts of that workflow is eventually having to create successor chats even though I am not actually changing tasks.
I would like to propose an optional Persistent / Continuous Chat mode that keeps one visible conversation while ChatGPT automatically manages fresh internal context segments, structured checkpoints, archived conversation retrieval, and rollover behind the scenes.
Users who prefer manually creating successor chats could continue using Regular Chat exactly as they do today.
So here is my proposal as chatGPT describes it
Summary
Please consider adding an optional Persistent Chat or Continuous Chat mode for users who want one conversation to remain usable indefinitely even after the model’s active context needs to refresh.
The idea is not to remove the current behavior or force automatic rollover on everyone.
Instead, ChatGPT could offer different conversation types for different needs:
-
Regular Chat — current behavior, with normal context handling and manual successor chats when necessary.
-
Work mode — for delegated work, browser/computer use, larger workflows, artifacts, and similar tasks.
-
Persistent / Continuous Chat — an opt-in mode where ChatGPT automatically manages context rollover behind the scenes while preserving one continuous visible conversation.
This would let users choose whether they prefer maximum manual control or automatic continuity.
The Problem
Long-running ChatGPT conversations eventually encounter practical context limitations.
When that happens, users working on an ongoing project, campaign, game, research task, design project, or other continuous activity often have to manually create a new chat even though they are not actually starting a new subject.
The successor chat may be doing exactly the same job as the previous chat.
That creates unnecessary administrative work for the user:
-
creating “Part 2,” “Part 3,” and additional successor chats;
-
explaining that the new chat continues the previous one;
-
preparing and transferring handoffs;
-
checking whether important information survived;
-
locating old conversations when something needs to be recovered;
-
maintaining many separate chat entries for what is conceptually one continuous activity.
The model having a finite active context is understandable.
The user having to manually manage that limitation does not necessarily need to be.
Why Make It Optional?
Automatic rollover carries a tradeoff.
Some users may prefer to manually create a new chat because they want full control over what gets transferred and do not want to risk an automatic checkpoint missing something important.
That preference should remain available.
Other users would gladly accept a small continuity risk in exchange for not having to manually maintain successor conversations.
Persistent Chat mode would let the user make that choice.
Selecting it would effectively mean:
I understand that ChatGPT may need to periodically rebuild its active context using checkpoints and retrieval. I prefer ChatGPT to manage that automatically rather than requiring me to create successor chats manually.
Regular Chat would remain available for users who prefer today’s behavior.
Proposed Persistent Chat Behavior
A Persistent Chat would remain one visible conversation to the user.
Behind the scenes, ChatGPT could divide it into internal context segments.
For example:
Visible conversation:
My Campaign
Internal implementation:
Segment 1 → Segment 2 → Segment 3 → Segment 4 → ...
When the current active context approaches a practical limit, ChatGPT would automatically:
-
Create a durable structured checkpoint of the current conversation state.
-
Preserve the completed conversation segment as a searchable archive.
-
Start a fresh internal active context.
-
Load the structured checkpoint and the most relevant recent context.
-
Continue responding in the exact same visible conversation.
-
Retrieve older archived exchanges whenever exact historical information becomes relevant.
From the user’s perspective, nothing interrupts the conversation.
They simply continue talking.
What the Checkpoint Should Preserve
The rollover should not rely on a short generic summary.
The checkpoint should preserve structured information such as:
-
current objective;
-
current task and exact stopping point;
-
accepted decisions;
-
unresolved decisions;
-
important user preferences;
-
active constraints;
-
authoritative sources;
-
source ownership and provenance;
-
important files and documents;
-
tool state that can safely be preserved;
-
current project or campaign state;
-
active characters, resources, statistics, or counters where applicable;
-
pending actions;
-
recent corrections;
-
assumptions that remain unresolved;
-
known conflicts or uncertainties;
-
information that must be retrieved verbatim rather than summarized.
Different kinds of chats could maintain different checkpoint structures.
A game campaign may need a current save state.
A software project may need repository state, requirements, and unresolved bugs.
A research project may need sources, findings, and open questions.
A design project may need accepted decisions and dependencies.
Archived Conversation Retrieval
Old segments should not simply disappear after rollover.
They should remain searchable.
When something from an older segment becomes relevant, ChatGPT should retrieve the original exchange rather than relying solely on the checkpoint.
The ideal architecture would therefore be:
**Active Context
-
Structured Checkpoint
-
Searchable Archived Segments
-
Memory
-
On-Demand Retrieval**
The checkpoint provides fast continuity.
The archived conversation provides exact evidence when needed.
Important Accuracy Rule
Automatic checkpointing should not silently turn uncertain information into fact.
If ChatGPT cannot confidently determine what happened earlier, it should retrieve the relevant archived exchange.
If a checkpoint conflicts with the original conversation, the original authoritative exchange should win unless later information explicitly superseded it.
The system should preserve provenance where important so it knows whether information came from:
-
the user;
-
an assistant proposal;
-
an accepted decision;
-
a source document;
-
a tool result;
-
an inferred conclusion;
-
an unresolved idea.
This would reduce the risk of automatic summaries gradually changing the meaning of a long-running project.
Optional Rollover Controls
Persistent Chat could offer a few user preferences.
Automatic Rollover
ChatGPT handles rollover automatically without interrupting the conversation.
This would likely be the preferred setting for users who specifically choose Persistent Chat.
Ask Before Rollover
ChatGPT warns the user before refreshing the internal active context.
For example:
This Persistent Chat is approaching an internal context rollover. Would you like me to checkpoint and continue automatically?
The user could then choose:
-
Continue automatically;
-
Review checkpoint first;
-
Start a manual successor chat instead;
-
Always roll over automatically in this conversation.
Checkpoint Review
Users who want extra control could optionally inspect the state ChatGPT intends to carry forward before the rollover occurs.
This should be optional rather than mandatory so Persistent Chat does not create a new form of repetitive administrative work.
User Interface
A Persistent Chat could have a small indicator such as:
Persistent Chat
or optionally:
Persistent Chat · Segment 14
The segment number would simply indicate that ChatGPT has internally refreshed its active context several times.
The user would not need to interact with it.
The entire history would still appear as one continuous conversation.
Starting a Persistent Chat
Persistent Chat could be selectable in the same general way users choose other conversation experiences.
For example:
New Chat
-
Regular
-
Persistent
-
Work
Alternatively, users could convert an existing chat:
Make this a Persistent Chat
Once enabled, ChatGPT would handle future internal rollover automatically.
Why This Is Different from Memory
Memory and Persistent Chat would solve different problems.
Memory helps ChatGPT remember useful information across conversations.
Persistent Chat would preserve the identity and continuity of one specific ongoing conversation or workstream.
A user should not have to convert every important project detail into general account memory just to keep a single long-running chat functional.
Likewise, general memory may intentionally compress or generalize information that a project requires precisely.
Persistent Chat should maintain project-specific continuity while still being able to use normal Memory where appropriate.
Why This Is Different from Projects
Projects are useful containers for related chats, files, and context.
But a Project can still contain many separate conversations.
Persistent Chat would address a different issue:
What if the user does not actually want many chats?
A user might have a Project called:
Evelyn Campaign
but still want one conversation called:
Campaign
that they continue using for a year.
The underlying system may internally roll that conversation over dozens of times, but the user should not have to manage dozens of successor chats unless they want to.
Projects and Persistent Chat could complement each other.
Why This Is Different from Work Mode
Work mode is useful when the user wants ChatGPT to carry out substantial tasks using a broader execution environment.
Persistent Chat solves continuity rather than autonomy.
A user may want a conversation that lasts for months or years while still interacting normally turn by turn.
Persistent Chat should therefore be its own concept rather than requiring users to enter Work mode simply because their conversation is long.
Example Use Cases
Long-Running Game Campaign
A user runs a tabletop campaign with ChatGPT for two years.
The visible conversation remains:
Evelyn Campaign
Internally, ChatGPT may eventually be operating on Segment 37.
Current characters, world state, campaign time, relationships, unresolved plots, and authoritative sources are kept in the checkpoint.
If the user asks:
What exactly did Mara say when we first arrived in Calder?
ChatGPT retrieves the relevant archived exchange from Segment 4 rather than guessing from a summary.
Video Game Playthrough
A user keeps one chat for an entire heavily modded game playthrough.
The conversation tracks:
-
mods;
-
character build;
-
equipment;
-
current location;
-
progression goals;
-
prior troubleshooting;
-
screenshots;
-
decisions.
Instead of creating ten separate chats as the playthrough continues, Persistent Chat quietly rolls its active context forward.
Long-Term Design Project
A user designs a board game over many months.
Accepted mechanics, rejected alternatives, balance decisions, unresolved systems, source documents, and playtest results remain part of the persistent state.
The user does not have to continually explain which new chat is the successor to which old one.
Research or Writing Project
A user spends months researching and writing a large project.
Persistent Chat maintains:
-
current thesis;
-
sources;
-
findings;
-
unresolved research questions;
-
document state;
-
accepted revisions;
-
planned sections.
Older discussions remain retrievable if exact reasoning or source history becomes important.
Benefits
Persistent Chat would:
-
reduce unnecessary chat fragmentation;
-
make ChatGPT more useful for long-running relationships with projects;
-
reduce manual handoff work;
-
reduce repeated explanations;
-
make context-window limitations less visible to users;
-
allow technically fresh model contexts without visibly abandoning the conversation;
-
preserve old conversation evidence for later retrieval;
-
allow users to choose between convenience and manual control;
-
make months- or years-long ChatGPT workflows feel genuinely continuous.
Core Product Principle
A finite model context is an implementation constraint.
It does not necessarily need to become a user workflow constraint.
If ChatGPT can checkpoint, archive, retrieve, and rebuild context safely enough, then a user’s conversation should be able to continue even when the model’s active context cannot.
Users who prefer manual successor chats should retain that option.
Users who prefer automatic continuity should be able to select Persistent Chat and let ChatGPT handle the rollover itself.
Requested Feature
Please consider adding an opt-in Persistent Chat / Continuous Chat mode that automatically manages internal context rollover while preserving one continuous visible conversation.
The key design should be:
Optional rather than mandatory.
One visible chat rather than many successor chats.
Structured checkpointing rather than simple summarization.
Archived original conversation rather than deletion.
On-demand retrieval rather than trusting compressed memory alone.
User choice between automatic rollover, reviewed rollover, and today’s manual behavior.
This would allow long-running ChatGPT conversations to function more like persistent workspaces while still preserving Regular Chat and Work mode for users whose needs are different.
Personal use-case / why this would matter to me
For my own workflow, the rollover system would not need to preserve every detail of every previous conversation perfectly.
I already use external sources as my durable record. I regularly have ChatGPT update documents in Google Drive and files on my desktop through connected tools, so important project information does not need to exist only inside the conversation.
What I am primarily trying to eliminate is the repeated administrative work caused by a chat eventually reaching its practical limit.
Right now, I repeatedly have to create a successor chat and then tell the new AI things like:
-
read my Framework again;
-
read the relevant project documents again;
-
reconnect to the authoritative state;
-
understand where the previous chat stopped;
-
then continue doing exactly what the previous chat was already doing.
That is the part that becomes frustrating.
With a Persistent / Continuous Chat, an internal rollover could simply become a checkpoint. At that checkpoint, I could have instructions telling the AI to re-read my Framework, re-read whichever authoritative documents are important to that project, rebuild its working context from those external sources, and then continue.
In other words, I personally do not need Continuous Chat to act as perfect permanent memory. I need it to preserve the continuity of the workspace while allowing the AI to periodically refresh itself from authoritative external sources.
Even a system where the model periodically starts with a mostly fresh context would be a major quality-of-life improvement for me if that refresh happened invisibly inside the same conversation instead of requiring me to manually create and initialize another chat every time.
For users like me, external files and connected sources can hold the durable truth. Persistent Chat mainly needs to remove the repetitive successor-chat setup.