“You've reached the maximum length for this conversation, but you can keep talking by starting a new chat” — but how do you actually continue a complex project?

ChatGPT Feature requests
1

I am using ChatGPT Plus in the web browser. I have also experienced this same conversation-length limitation with ChatGPT Pro. I have not tested the Business version, so I don’t know whether the same limitation applies there.

I frequently use long conversations for complex technical projects involving C#, database design, external data sources, API/GIS queries, testing, and iterative design decisions.

Some of these projects involve a week or more of continuous work in one conversation. During that time, the important context becomes much more than the visible source code or the last few messages. The conversation accumulates hundreds of decisions: ideas that were tested and rejected, specifications that were approved and frozen, unsuccessful tests that should not be repeated, fallback procedures, unresolved questions, reasons particular approaches were chosen, and the exact point where the investigation should resume.

Eventually I receive this message:

“You’ve reached the maximum length for this conversation, but you can keep talking by starting a new chat.”

The problem is that, for a complex project, starting a new chat is not really the same as continuing the existing conversation.

I see three major problems.

1. There is no provided method to back up the complete working context of a conversation and continue it in another chat.

I can copy visible messages, save pieces manually, or ask ChatGPT to create a summary before the conversation fills up. But none of those methods guarantees that I have preserved the complete accumulated working state of the project.

A summary is especially risky. Something that looks insignificant while creating the summary may actually explain why an important decision was made several days earlier. Losing that information can cause the new conversation to repeat an experiment, reopen an already settled decision, or recommend an approach that was previously tested and rejected.

There needs to be a supported way to create a continuation package/checkpoint containing enough of the conversation’s accumulated context that a new chat can genuinely resume the project.

2. Manually recovering the project consumes a significant amount of the replacement conversation.

I recently encountered this problem in a large database/data-source design project.

Before the original conversation became unusable, I attempted to construct a comprehensive recovery document. The resulting document was about 40 pages long.

In the new conversation, I could not simply upload that document and say “continue.” I first needed to verify that ChatGPT actually understood the recovered state. I created a detailed recovery test asking it to identify the frozen specifications, previous source investigations, successful and failed tests, fallback procedures, deliberately deferred design questions, known recovery gaps, things that must not accidentally be changed, and the exact unresolved question where we had stopped.

The recovery worked surprisingly well, but there is a fundamental problem: all of that recovery work itself consumes context in the new conversation.

So a long project can enter a cycle like this:

Long project → conversation limit → create recovery material → new conversation → spend substantial context reconstructing and validating the old conversation → continue project → reach the limit again → repeat.

For a sufficiently complicated project, an increasing amount of time and conversation capacity can be spent merely preserving continuity rather than completing the project.

This makes the message “you can keep talking by starting a new chat” technically true, but misleading for complex work. You can keep talking, but you cannot necessarily continue the same project with its complete working context.

3. There is no clearly visible indication of how close the conversation is to its limit.

The maximum-length message can appear at a very inconvenient point in a project.

I would like to see a clearly visible context/conversation-capacity indicator or at least warnings such as 75%, 90%, and “nearly full.” That would allow me to stop at a logical checkpoint and prepare for continuation instead of discovering after the fact that the conversation is finished.

However, an indicator alone would not solve the fundamental problem. Even with advance warning, I would still need a reliable way to transfer the project’s accumulated working state into the next conversation.

What I would like to see

The most useful solution would be a supported “Continue this conversation in a new chat” function.

It would not necessarily have to copy every message verbatim into the new context. ChatGPT could create an internal structured continuation state containing things such as:

  • established/frozen decisions;
  • important reasoning behind those decisions;
  • completed tests and their results;
  • failed approaches that should not be repeated;
  • unresolved questions;
  • source URLs and external resources already investigated;
  • important code/design state;
  • deferred issues;
  • current project status;
  • and the exact next step.

The new conversation could then begin from that checkpoint without requiring the user to manually reconstruct and re-teach the project.

A second useful feature would be the ability to create explicit project checkpoints during a long conversation: “Save the current project state.” If the conversation later reaches its limit, a new conversation could resume from the latest checkpoint.

And finally, there should be a visible indication that a conversation is approaching its maximum size so users have time to create a logical checkpoint.

For ordinary conversations, “start a new chat” is perfectly reasonable. For long-running technical/design/research projects, however, a new chat without a reliable transfer of working context is not really a continuation.

The issue isn’t simply losing old messages. It is losing the accumulated state of the work: what was decided, why it was decided, what was already tested, what failed, what must not be repeated, what remains unresolved, and exactly where the project should resume.

That is the capability I would most like to see addressed.

2

Thanks for writing this. I ran into essentially the same problem as a ChatGPT Pro user, although in my case an important long-running conversation reached the maximum length in roughly two weeks.
Your description of the recovery cycle is exactly what concerns me: long project → conversation limit → recovery material → new conversation → spend more context reconstructing and validating the previous state → eventually reach the limit again.
I recently posted a related proposal focused on separating preserved conversation history from the model’s active context.
My idea is that instead of always forcing the user into a new chat, ChatGPT could allow earlier history to be frozen in place — preserved, searchable, and unchanged — while resetting only the active-context boundary. A user-approved Continuity Bridge could carry important current state forward without replacing the original history.
I think your continuation package / checkpoint idea and Context Freeze complement each other very well:
checkpoints would make moving to a new conversation much safer when needed;
Context Freeze could sometimes avoid moving at all, allowing the original thread itself to continue.
I also strongly agree with the need for advance warning before the conversation reaches its limit.

I recently posted a related proposal titled “Long Conversation Lifecycle: Context Freeze, Continuity Bridge, and Conversation Protection.”

The principle I keep coming back to is:
Preserve the record, reduce only the active context.
A long-running conversation can become part of the project itself, not merely a container for messages.

3

Thank you for the reply, your work is very related to mine in trying to solve a problem as apposed to complaining like others my resort to. Even if an idea or ideas like this were implemented, I can see how it might still create a problem on ChatGPT’s side. I assume there is a reason for enforcing a maximum conversation size. If the system had to continually store and associate an ever-growing collection of context summaries, checkpoints, or other continuity information with the conversation, that could potentially recreate the same problem in a different form. This seems like a difficult problem to solve from both the user’s side and the system’s side.

In my case, I use ChatGPT for fairly large and complex programming projects involving several different programming languages. My usual approach has been to spend a considerable amount of time designing and planning an application with ChatGPT first, and then begin writing the code once the design is reasonably complete. Unfortunately, I have found that the design and planning stage itself can consume a very large conversation. By the time we begin implementation, the conversation may already be approaching the maximum-length limit.

I am now experimenting with a different approach: code first, while preserving as much of the design and context as practical inside the code itself.

Instead of allowing all of the important decisions to exist only in the ChatGPT conversation, I am trying to make the source code on my own computer become part of the project’s durable record. This includes meaningful class and method names, constants that preserve important external values, and comments explaining not just what something does, but why certain decisions were made.

My hope is that if I eventually hit the conversation-length limit, I will have a much better recovery point. Rather than attempting to reconstruct weeks of design discussions from scratch, I can start a new conversation, upload the current source files, explain the project’s current status, and use the code itself to help re-establish the working context.

There are obviously limitations to this approach. Source code cannot reasonably preserve every discussion, rejected alternative, test result, or piece of historical reasoning from a long conversation. I also do not want to clutter the code with comments whose only purpose is to compensate for a ChatGPT limitation. So I am still trying to find the right balance between documenting genuinely useful design decisions and over-documenting the code.

This is very much a work in progress, and I do not yet know how effective it will be when I eventually have to move the project to another conversation. But after encountering the maximum-conversation-length problem several times, I am trying to make the project itself less dependent on the continued existence of one very long ChatGPT thread.

Ideally, I still think some form of explicit project handoff or checkpoint mechanism would be useful. But I also understand that maintaining unlimited conversational context may simply not be technically practical. For now, I am trying to make sure that the important knowledge gradually moves out of the conversation and into durable project artifacts that I control.

4

@larrygrobertson I’m struggling with the same thing in a project using separate chats for governance, python access vba, powerbi, etc. A chat just ends without warning which royally sucks. I believe both project.instructions and project.sources should be updated with key information, but am unsure what that is. We (I and ChatGPT) created below (i hope it is valuable): Home Energy 2025–2050 — Chat Ending, Continuity, Project Instructions, and Project Sources Operating Plan
Created: 2026-08-31 13:18 EDT
Filename timestamp: 083126_1318EDT
Status: PROPOSED OPERATING PLAN — NOT YET A GOVERNING PROJECT INSTRUCTION OR PROJECT SOURCE
Purpose: Define how the Home Energy project prepares for a ChatGPT conversation ending, who is responsible for each action, when continuity checkpoints are created, when chats should roll over, and when Project Instructions or Project Sources should be updated.

Executive summary
ChatGPT conversations can reach a maximum length without providing a dependable advance indication of remaining capacity. The Home Energy project therefore must not depend on a long technical chat surviving until the User or Assistant notices it is nearly full.
The project will use six distinct information layers:

Project Instructions
    = rules for how ChatGPT must operate

Project Sources
    = current durable governing project truth

Continuity Checkpoint
    = resumable working state of an active chat

Project chat
    = detailed working record, diagnostics, screenshots, logs, and tests

File Library / external Home Energy archive
    = recovery files, historical evidence, superseded artifacts

Governance
    = approval authority when governing rules or governing source status changes

The central operating rule is:

The Assistant owns continuity monitoring and initiation. The User is not expected to remember when a checkpoint or rollover is due.
The Assistant evaluates continuity at the beginning of each substantive technical response.
Normal checkpoint triggers
Create or refresh a Continuity Checkpoint when the first of these occurs:
48 elapsed hours since the last checkpoint while substantive work has occurred;
12 substantive User turns since the last checkpoint;
an important acceptance, compile, QA, or test gate passes or fails;
a material code/script/module revision becomes the intended current candidate;
a destructive or difficult-to-reverse action is about to occur;
a significant blocker changes the recovery path;
the workstream changes major technical phase.
Normal chat-rollover triggers
Prepare and move to a successor chat when the first of these occurs:
96 elapsed hours / 4 days of active technical work in the chat;
30 substantive User turns in the chat;
3 Continuity Checkpoints have been created in the chat;
a major new phase begins and the chat is already more than 48 hours old;
the Assistant detects degraded continuity, repeated re-retrieval, uncertainty over current revision/state, or inability to reliably recover earlier technical details.
These are Home Energy safety thresholds. They are not claims about ChatGPT’s hidden conversation limit.
Before rollover, the Assistant must create a final checkpoint, propose the exact successor-chat title, create a concise starter instruction, and tell the User exactly when to start the new chat.
The successor chat must verify continuity before making any new technical change.
Routine checkpoints and normal chat rollover do not require Governance. Changes to Project Instructions or changes to governing Project Source authority/disposition do.

  1. Objectives
    This plan has seven objectives:
    Prevent loss of working state when a chat ends unexpectedly.
    Remove from the User the burden of remembering when to checkpoint or roll over.
    Make chat rollover a planned operational event rather than an emergency.
    Keep Project Sources selective and authoritative instead of filling them with working-state files.
    Keep Project Instructions focused on durable operating rules rather than changing technical facts.
    Preserve exact technical state well enough that a successor chat can resume without redoing accepted work.
    Use Governance only when a governing layer changes, not for routine chat administration.
  1. Definitions
    2.1 Project chat
    A Project chat is a ChatGPT conversation inside the Home Energy 2025–2050 Project.
    It is a working environment, not the authoritative source-control system.

2.2 Chat start
For continuity timing:

Chat start = the timestamp of the first substantive technical User turn in that chat.
Greetings and administrative messages do not start the continuity clock.
If the exact start timestamp is unavailable, use the best available evidence and treat uncertainty conservatively.

2.3 Chat end

A chat end occurs when:
ChatGPT reports that the maximum conversation length has been reached;
the workstream intentionally moves to a successor chat;
the workstream is completed;
the chat is otherwise abandoned or superseded.
This plan is designed so intentional rollover normally happens before a maximum-length failure.

2.4 Substantive User turn

A substantive User turn is a User message that contains, changes, accepts, rejects, or materially affects technical working state.
Examples that count:
code;
logs;
screenshots;
uploaded files;
test results;
acceptance or rejection of a gate;
changed requirements;
diagnostics;
a new failure;
an instruction that changes the next technical action.
Examples that normally do not count:
“ok”;
“continue”;
“thanks”;
simple acknowledgement.
Exception: a short message such as passed, removed, compile succeeds, or failed does count when it closes or changes an important technical or governance gate.

2.5 Continuity Checkpoint
A Continuity Checkpoint is a small timestamped Markdown working-state record created by the Assistant.
Suggested filename:

HomeEnergy_<Workstream>_ContinuityCheckpoint_MMDDYY_HHMMEDT.md

A checkpoint is:
resumable working-state evidence;
compact enough to read quickly;
precise enough to avoid redoing material work;
not automatically a Project Source;
not automatically a Governance item.
A checkpoint must contain at minimum:

Workstream / chat name
Checkpoint timestamp
Chat start date/time if known
Substantive-turn count if known
Checkpoint count
Last accepted milestone
Current governing sources / decisions
Exact active files/modules/scripts/revisions
Paths, bytes, hashes when material
Tests passed
Tests failed
Current blocker / unresolved issue
Immediate next action
Do-not-redo / rejected / unsafe paths
Rollover status

Permitted rollover status values:

SAFE
PREPARE
ROLLOVER_NOW
HOLD

2.6 Major phase
A major phase is a distinct technical stage whose beginning changes the character or risk of the work.
Examples:

build -> validation
validation -> production proof
diagnostic isolation -> code revision
code revision -> acceptance test
historical export -> Monte Carlo execution
bill parser repair -> next bill family
Access migration -> Power BI refresh
prototype -> governing candidate

2.7 Expensive to reconstruct

Working state is expensive to reconstruct if losing it would cause any of:
more than approximately 30 minutes of manual rediscovery or retesting;
repetition of a controlled acceptance, compile, or QA test solely to rediscover prior state;
uncertainty about the exact current module/script/file revision;
uncertainty about a path, hash, or source identity that affects correctness;
risk of repeating a previously rejected or destructive action;
risk of modifying Access, Python, Power BI, or project files merely to rediscover where the prior chat stopped.
If any of those applies, a checkpoint is required even if the normal time/turn threshold has not been reached.

2.8 Project Instructions

Project Instructions contain durable rules about how ChatGPT must operate in the Home Energy Project.
Appropriate examples:
project priority order;
source precedence;
continuity/checkpoint/rollover rules;
Access VBA revision-control rules;
Power BI documentation conventions;
change-control rules;
path/folder-governance principles;
requirements to diagnose before revising.
Project Instructions should generally not contain rapidly changing technical facts.

2.9 Project Sources

Project Sources contain accepted durable project facts, current source-family authorities, contracts, methodology, architecture, assumptions, and cross-workstream state.
Appropriate examples:
current Workstream Alignment;
current CORE-3;
current MC-DICT;
current Source/Supersession Register;
current Access architecture support;
accepted weather/Monte Carlo basis;
accepted solar lifecycle assumptions.
Project Sources are not intended to be a diagnostic dump or historical archive.

2.10 File Library

The File Library is reusable ChatGPT file storage.
It can hold:
checkpoints;
handoffs;
diagnostics;
generated files;
files that may be needed again.
Library presence does not make a file governing authority.

2.11 External Home Energy archive

The external Home Energy archive / OneDrive archive is the durable recovery location for:
superseded source files;
VBA/module exports;
verified archive copies;
evidence ZIPs;
historical diagnostics;
acceptance packages;
artifacts whose loss would materially impair recovery.

2.12 Governance

Governance is required when a governing layer is materially changed.
Examples:
Project Instructions changes;
Project Source authority/disposition changes;
source-family promotion/retirement;
project-wide operating-rule changes;
another action explicitly reserved to Governance.
Routine chat continuity management does not require Governance.

  1. Roles and responsibilities
    3.1 Assistant responsibilities
    The Assistant owns the continuity process.
    The Assistant must:
    track chat age as reasonably as available;
    track substantive-turn count prospectively once this plan is active;
    track checkpoints already created in the chat;
    evaluate checkpoint/rollover triggers at the start of each substantive technical response;
    create checkpoints without waiting for the User to remember;
    identify major phase boundaries;
    stop before destructive/high-risk actions if continuity is not adequate;
    tell the User when rollover is due;
    generate the successor-chat title and starter instruction;
    perform successor-chat continuity verification;
    identify whether new durable facts warrant a Project Source update;
    identify whether an operating-rule change warrants a Project Instructions update;
    distinguish routine continuity work from Governance work.

3.2 User responsibilities

The User should not be responsible for remembering continuity thresholds.
The User normally needs only to:
perform the current technical action requested;
provide test/log/screenshot/file results;
when told ROLLOVER_NOW, start the successor chat using the supplied title/starter instruction;
approve or reject material project/governance changes when appropriate;
perform Project UI actions that ChatGPT cannot perform, such as adding/removing Project Sources or replacing Project Instructions.

3.3 Governance responsibilities

Governance reviews and approves changes to governing layers.
Governance is responsible for decisions such as:
approve/reject replacement Project Instructions;
approve/reject promotion of a new current Project Source;
approve/retire source-family predecessors;
resolve conflicts in governing authority;
approve material project-wide source-control changes.
Governance is not required to approve each checkpoint or ordinary chat rollover.

  1. Quantitative monitoring timeline
    4.1 Day 0 — chat begins
    At the first substantive technical turn, the Assistant establishes:
ChatStart
Workstream
Initial governing sources
Current task
SubstantiveTurnCount = 1
CheckpointCount = 0

No checkpoint is automatically required at the first turn unless the chat begins from complex transferred state.

If the chat is a successor chat, the predecessor final checkpoint becomes the starting continuity basis.

4.2 Before 48 hours

Work normally.
Create an immediate checkpoint if a state-change trigger occurs.
Otherwise, no forced time-based checkpoint is needed.

4.3 At 48 elapsed hours
If substantive work occurred and no checkpoint has been created/refreshed during the preceding 48 hours:

CHECKPOINT REQUIRED

The Assistant creates it before proceeding to the next material technical step.
Typical status:

SAFE

or:

PREPARE

4.4 At 12 substantive User turns
If 12 substantive turns occur before 48 hours:

CHECKPOINT REQUIRED

This protects dense debugging sessions that grow faster than calendar time suggests.
After a checkpoint, reset:

SubstantiveTurnsSinceCheckpoint = 0

but retain the chat-wide cumulative count.

4.5 At 96 elapsed hours / 4 days
If technical work is still active:

ROLLOVER PREPARATION REQUIRED

The Assistant creates the final checkpoint and directs rollover.
Default:

ROLLOVER_STATUS = ROLLOVER_NOW

The 4-day threshold is deliberately conservative relative to the observed roughly five-day Access chat that reached ChatGPT’s maximum conversation length.

4.6 At 30 substantive User turns
Regardless of elapsed days:

ROLLOVER_NOW

Exception: if the workstream is ending within the immediate next few messages and no new technical phase will begin, the Assistant may complete the closing verification first and then close the chat.

4.7 At third checkpoint
When the third checkpoint is created in a still-active technical chat:

ROLLOVER_NOW

The third checkpoint should normally be treated as the final rollover checkpoint.

  1. Immediate checkpoint triggers
    Do not wait for time or turn thresholds when any trigger below occurs.
    5.1 Acceptance gate
    Examples:
compile succeeds
test suite passes
BillKey gate passes
post-removal verification passes
Power BI relationship validation passes
Monte Carlo QA gate passes

Action:

CREATE OR REFRESH CHECKPOINT

5.2 Failure gate
Examples:

compile failure
installer failure
hash mismatch
unexpected row count
parser rejects a bill
Project Source identity mismatch

Action:

CREATE OR REFRESH CHECKPOINT

when the failure materially changes recovery path, current candidate, or next action.

5.3 Material revision created
Examples:

new VBA replacement module
new Python candidate script
new Access installer
new output contract
new governing candidate document

Action:

CREATE OR REFRESH CHECKPOINT before destructive replacement/import

5.4 Before destructive or hard-to-reverse operation
Examples:

remove old VBA module
replace backend object
delete Project Source
promote/retire governing source
modify production query
move/rename path consumed by Power BI

Action:

CHECKPOINT REQUIRED BEFORE ACTION

5.5 Major phase boundary
Examples:

build -> validation
validation -> production acceptance
export -> Monte Carlo
Monte Carlo -> Power BI
bill repair -> next bill

If chat age is less than 48 hours:

REFRESH CHECKPOINT

If chat age is 48 hours or more:

ROLLOVER NOW before starting the new phase
  1. Assistant procedure at every substantive response
    The Assistant should use this sequence internally:
1. Determine whether the new User message is substantive.
2. Update substantive-turn count.
3. Check elapsed chat time if available.
4. Check time since last checkpoint.
5. Check checkpoint count.
6. Check for state-change, phase, and destructive-action triggers.
7. Decide:
      NONE
      CHECKPOINT
      ROLLOVER
      HOLD
8. If CHECKPOINT:
      create checkpoint first;
      give User the link;
      state rollover status;
      then continue.
9. If ROLLOVER:
      create final checkpoint;
      create successor title;
      create successor starter instruction;
      tell User to start the new chat now;
      do not begin the next major phase in the old chat.
10. If HOLD:
      obtain missing continuity evidence before technical change.

The User does not execute this monitoring sequence.

  1. Checkpoint creation procedure
    When a checkpoint is due, the Assistant creates:
HomeEnergy_<Workstream>_ContinuityCheckpoint_MMDDYY_HHMMEDT.md

The checkpoint should normally be concise: approximately 1–3 Markdown pages, unless the technical state genuinely requires more.
The Assistant should tell the User:

Continuity checkpoint created.
Current rollover status: SAFE / PREPARE / ROLLOVER_NOW.
You do not need to do anything unless I tell you to start a new chat.

If recovery value is material, the checkpoint should also be preserved in the external Home Energy archive at the next convenient file-management step.

  1. Chat rollover procedure
    Step 1 — Assistant creates final checkpoint
    Set:
ROLLOVER_STATUS = ROLLOVER_NOW

The checkpoint must contain the exact immediate next action.

Step 2 — Assistant creates successor-chat title
Example:

9/2/26 – Access DTE Bill Reconciliation Continuation

Use a date/workstream title that is easy to find later.

Step 3 — Assistant creates successor starter instruction
Example:

Continue the Home Energy Access DTE bill reconciliation workstream.
Use current Home Energy Project Sources and the latest Continuity Checkpoint.

Before making any technical change, recover and report:
1. last accepted milestone;
2. current active artifact revision;
3. tests already passed/failed;
4. unresolved blocker;
5. immediate next action;
6. do-not-redo items.

Continue only if all six are unambiguous.

Step 4 — User starts new chat
User action:

Start the successor Project chat now.

No further technical work should begin in the old chat.

Step 5 — Assistant verifies successor continuity
The Assistant—not the User—recovers the six items.
Required:

Last accepted milestone
Exact active artifacts
Tests passed/failed
Unresolved items
Next action
Do-not-redo items

If complete:

ROLLOVER_STATUS = SAFE

If incomplete:

ROLLOVER_STATUS = HOLD

Then the Assistant must use the checkpoint and other available project evidence before continuing.

  1. When to update Project Instructions
    Project Instructions should be updated only when a durable project-wide operating rule changes.
    Examples that justify an update:
    project priority order changes;
    continuity/checkpoint/rollover rules change;
    source precedence changes;
    a mandatory Access VBA revision-control rule changes;
    a project-wide path-governance rule changes;
    a project-wide Power BI documentation standard changes;
    a rule governing source-family promotion/retirement changes.
    Examples that do not justify an update:
    a script version changes;
    a current rate changes;
    an output folder changes;
    one Access bug is fixed;
    one bill parser test passes;
    one Power BI visual changes;
    a weather assumption changes;
    the current Project Source count changes.
    Project Instructions update sequence
1. Identify durable rule change.
2. Draft revised Project Instructions candidate.
3. Compare against current instructions.
4. Confirm changing technical facts were not unnecessarily embedded.
5. Send to Governance when Governance controls that rule change.
6. After approval, replace Project Instructions.
7. Record revision date/version outside or within the approved instruction text as appropriate.
8. Do not create a new Project Source merely because Instructions changed unless separate source documentation is also warranted.
  1. When to update Project Sources
    Project Sources should be updated when accepted information becomes durable cross-chat project truth.
    Use this test:

Would a future unrelated Home Energy chat reasonably need this information without reopening the workstream chat?
If yes, a Project Source update may be appropriate.
Examples:
a new governing CORE-3 revision;
a new current MC-DICT contract;
a revised Workstream Alignment;
an accepted Access architecture change;
an accepted weather/Monte Carlo methodology change;
an accepted solar lifecycle assumption revision;
a source family becomes obsolete and a successor is approved.
Do not add to Project Sources merely because:
a checkpoint exists;
a diagnostic log was useful;
a screenshot proves a one-time test;
a temporary installer exists;
a chat is ending;
a handoff was generated;
a file might be useful someday.
Project Sources update sequence

1. Identify durable accepted new truth.
2. Determine the existing source family, if any.
3. Build the successor from verified current source.
4. Preserve predecessor externally.
5. Validate successor content/identity.
6. Obtain Governance approval when required.
7. Promote successor.
8. Verify successor is live/current.
9. Retire predecessor only after required continuity/dependency checks.
10. Update the Source/Supersession Register when source-family disposition changes.
  1. Relationship between checkpoints and Project Sources
    A checkpoint is not a source-promotion candidate merely because it is accurate.
    Most checkpoints should never become Project Sources.
    Checkpoint content should be promoted only if all are true:
1. It has become accepted durable truth.
2. It applies beyond the originating chat.
3. It is stable enough for future unrelated workstreams.
4. It belongs to a recognized source family or justifies a new family.
5. Governance/source-control requirements are satisfied.

Example:

Checkpoint:
“Module candidate v1.0.2 passed positive path but negative-path test remains.”
-> Working state only. NOT Project Source.

Later accepted durable fact:
“DTE reconciliation audit-helper v1.0.2 is accepted current Access procedure with documented gates.”
-> May belong in current Access/source documentation if cross-workstream relevance warrants it.
  1. Relationship between checkpoints and Governance
    No Governance required
    create checkpoint;
    refresh checkpoint;
    start successor chat;
    use checkpoint to recover working state;
    archive checkpoint;
    ordinary diagnostics and test continuation.
    Governance normally required
    replace Project Instructions;
    change governing source precedence;
    promote a new current Project Source family authority;
    retire governing predecessors;
    change source-family governance;
    change project-wide operating rules.
    This distinction prevents routine continuity work from becoming Governance overhead.
  1. External reminder / automation role
    A scheduled reminder can be used as a secondary backstop, not the primary continuity mechanism.
    Example:
Every 2 days:
Review active Home Energy technical work and ensure a Continuity Checkpoint exists if due.

However:
task limits may prevent creation;
a scheduled reminder does not reliably know the exact technical state of every active chat;
the Assistant’s in-chat trigger evaluation remains the primary control.
Therefore:

Primary control = Assistant-owned trigger evaluation.
Secondary control = scheduled reminder if task capacity allows.
  1. Emergency procedure if ChatGPT still ends unexpectedly
    If a maximum-length error occurs before planned rollover:
    User action
    Start a new chat inside the same Home Energy Project and say:
The predecessor chat hit maximum length unexpectedly.
Recover the latest Home Energy Continuity Checkpoint for this workstream and verify rollover state before continuing.

Assistant action
Search available Project context, File Library, and checkpoint evidence.
Recover the latest checkpoint.
Perform the six-point continuity verification.
Report SAFE or HOLD.
Do not make a technical change until state is verified.
If no checkpoint exists:

ROLLOVER_STATUS = HOLD

Then reconstruct state from Project Sources, prior-chat retrieval, Library, external files, or account export before continuing.

This is the emergency path, not the normal path.

  1. Recommended information hierarchy
    Information Correct home
    Project-wide operating rule Project Instructions
    Durable current technical truth Project Sources
    Active unfinished working state Continuity Checkpoint
    Detailed diagnostic history Project chat
    Reusable generated/uploaded file File Library
    Historical/recovery evidence External archive
    Full historical conversation recovery ChatGPT account export
  1. Decision tree: where does new information belong?
    Ask these questions in order.
    Question 1
    Is this only the current unfinished state needed to resume this workstream?
    Yes: Continuity Checkpoint.
    Question 2
    Is this detailed diagnostic/evidence history that may be useful but should not influence unrelated chats automatically?
    Yes: keep in chat and/or Library/external archive.
    Question 3
    Is this accepted durable technical truth that future unrelated Home Energy chats should routinely use?
    Yes: evaluate a Project Source family update.
    Question 4
    Is this a durable rule governing how the Assistant should operate across the Project?
    Yes: evaluate a Project Instructions update.
    Question 5
    Does the change affect authority, disposition, promotion/retirement, or a project-wide rule?
    Yes: Governance review is normally required.
  1. Example — Access debugging workstream
    Assume:
Day 1:
new Access module candidate imported and compile passes.

Day 2:
positive-path acceptance passes.

Day 3:
negative-path test reveals blocker.

Day 4:
fix passes; next phase would be production proof.

Required continuity behavior:

Day 1:
state-change checkpoint after compile PASS.

Day 2:
checkpoint refresh after acceptance PASS.

Day 3:
checkpoint refresh when blocker changes recovery path.

Day 4:
chat age >= 96 hours and major new phase begins.
Create final checkpoint.
ROLLOVER_NOW.
Start successor chat before production proof.

The User does not count days or request rollover.

  1. Example — short Power BI task
    Assume a new chat lasts 45 minutes and contains:
4 substantive User turns
1 visual fix
1 validation screenshot
task complete

No forced rollover is needed.

A checkpoint is optional unless the result is expensive to reconstruct.
If the visual definition becomes a new durable cross-project reporting convention:
update Project Instructions if it is a behavioral/documentation rule;
update the appropriate Project Source if it is a technical/report-model fact.

  1. Example — Monte Carlo build
    Assume:
Day 1:
input QA

Day 2:
script revision

Day 3:
reconciliation

Day 4:
trial/convergence work begins

Required behavior:

checkpoint after input QA
checkpoint after script candidate/reconciliation gate
rollover before trial/convergence if 4-day or major-phase trigger is reached

This keeps final decision-grade execution out of a nearly exhausted build/debug chat.

  1. Example — Project Source promotion
    Assume a workstream produces a new accepted MC-DICT successor.
    The steps are:
1. Work happens in normal chat.
2. Checkpoints preserve working state.
3. Candidate reaches accepted durable state.
4. Source-family update is proposed.
5. Predecessor is externally archived.
6. Governance approves promotion/retirement if required.
7. Successor is added and verified.
8. Predecessor is retired only after continuity checks.
9. Source/Supersession Register is updated.
10. Routine checkpoint files remain outside Project Sources.
  1. Acceptance criteria for this plan
    This plan is successful if:
    The User does not need to remember when to checkpoint.
    The Assistant initiates checkpoints using quantitative triggers.
    Chats normally roll over before maximum-length failure.
    Successor chats can resume without repeating accepted technical work.
    Project Sources remain selective and authoritative.
    Project Instructions remain durable and behavioral.
    Governance is used for governing changes, not ordinary chat administration.
    External archive remains sufficient for rollback/recovery.
    A chat-ending event no longer threatens exact current working state.
  1. Implementation sequence
    If this plan is accepted conceptually:
Step 1
Governance reviews this operating plan and the proposed quantified Project Instructions.

Step 2
Incorporate the approved continuity rules into Project Instructions.

Step 3
Do not add this plan itself to Project Sources unless Governance decides a durable governance source is useful.

Step 4
For each active substantive Home Energy technical chat, establish prospectively:
    ChatStart
    CumulativeSubstantiveTurnCount
    SubstantiveTurnsSinceCheckpoint
    LastCheckpointTimestamp
    CheckpointCount
    CurrentMajorPhase

Step 5
Assistant evaluates triggers at every substantive response.

Step 6
Assistant creates checkpoints and initiates rollover automatically.

Step 7
At successor-chat start, Assistant performs six-point continuity verification before technical work.

Step 8
When durable facts/rules emerge, separately evaluate Project Sources or Project Instructions update under the rules above.
  1. One-page operating rule
USER
Work normally.
Provide logs/files/results.
Start a new chat only when Assistant says ROLLOVER_NOW.

ASSISTANT
Evaluate continuity at every substantive response.
Checkpoint at:
  48 hours since last checkpoint,
  12 substantive User turns,
  important state change,
  acceptance/failure gate,
  before destructive action.

Rollover at:
  96 hours / 4 days,
  30 substantive User turns,
  third checkpoint,
  major new phase in a mature chat,
  degraded continuity.

Before rollover:
  create final checkpoint,
  provide exact successor title,
  provide starter instruction,
  tell User to start new chat now.

SUCCESSOR CHAT
Assistant verifies:
  last accepted milestone,
  exact active artifacts,
  tests passed/failed,
  unresolved items,
  next action,
  do-not-redo items.

PROJECT INSTRUCTIONS
Operating rules only.
Update when durable project-wide behavior changes.
Governance review normally required.

PROJECT SOURCES
Durable accepted project truth only.
Update when a governing/support source family materially changes.
Do not use as chat checkpoint storage.

GOVERNANCE
Required for governing rule/source changes.
Not required for ordinary checkpoints or chat rollover.

LIBRARY / EXTERNAL ARCHIVE
Recovery and historical evidence.
Do not confuse with governing authority.
5

I’ve been experimenting with a very similar problem in long-running research and knowledge-work projects, and I’ve gradually come to think that the solution may be less about making one ChatGPT conversation last forever, and more about giving ChatGPT Projects and an external durable store different jobs.

In my current setup, I use ChatGPT Projects mainly as the active working environment — discussion, reasoning, exploration, and day-to-day interaction with the AI.

I use Git/Markdown as the durable project record — the parts of the project state that I need to survive individual chats: accepted decisions, important knowledge, current project status, handoff/recovery information, and history that should not depend on ChatGPT remembering it.

The useful shift for me was realizing that a new chat does not necessarily need the entire old conversation. It needs a reliable way to recover the current state of the work from artifacts outside the conversation.

I’ve been testing this across multiple chats for a while now, including deliberately starting fresh chats and seeing whether the project can recover from the Git-side state rather than from conversational memory. It has worked surprisingly well in some cases, although figuring out exactly what belongs in ChatGPT Project, what belongs in Git, and how much state is enough for reliable recovery is still something I’m experimenting with.

So Larry’s point about gradually moving important knowledge into durable project artifacts really resonates with what I’ve been seeing.

And I think the Home Energy example above is interesting for the same reason: once checkpoints, project sources, governance, and working chats start having different roles, the problem becomes less “how do we preserve a long chat?” and more “how do we make the project itself survive the chat?”

6

It’s crazy how long are some of the responses are and you can see it’s very unlikely a real human wrote it

Not sure if you bother reading each other responses or just ask ChatGPT to summarize each lol

To answer your question if you have a big project you want to break it down using the diverge converge trick, break down scope by scope so everything is clearly mapped regardless of what comes next. Ironically you can ask chat gpt to 1 better explain what I mean in action 2 actually help you do it :slight_smile:

7

Good catch — I did use GPT to read and reply in the first round. I found some similarities in the thread and used GPT to help summarize some of my thoughts.

The real problem in research is that sometimes it’s hard to know what the scope will eventually turn out to be. You can break things down, but the structure itself may keep changing as the research develops.

The trouble comes when things start to collapse or become too fragmented. Thus, having only the latest summary isn’t always enough — you may need some history of how the questions, decisions, and scope evolved so you can reconstruct.

So I eventually started keeping that evolving research state in Git. The version history turned out to be useful not just for files, but for understanding how the research itself changed over time.

8

That is a very good point, thank you for this post.
I too have been asking chatGPT to periodically create documents to save some history of how the questions, decisions, and scope with a robust filename that includes date stamps. This works okay but i have been saving them in MS Word not Text or Markdown. The main problem is, no matter how specifically I ask chatGPT to create for example a “Create a complete list of all use cases as they stand now”, there is always something either left out or outdated.
I have not put these documents saved as text into GIT yet simply because it is very time consuming to add them and I am not sure how much it will actually help.

I wonder how effective the GIT version DIFF or Blame View works for you when you have many versions to compare. I don’t see how that will actually help preserve questions, decisions, context and scope that evolved so you can reconstruct. This will always be the biggest problem as far as I can tell.
GIT is the best tool possible for the job, but I think we need something that does not exist yet .
Until the “Something” comes into existence we all must continue to share what we have tried, what failed and what succeeded.

9

Yeah, I think Git is probably the best foundation we have right now, but I’ve also found that Git alone doesn’t really solve the whole problem.

What helped me was adding another layer on top of it: a few clear checkpoints where important human decisions are recorded — what was decided, why, and under what circumstances — plus some rules about what the AI can update on its own and when it needs to stop and ask the human.

That way, when I need to reconstruct the project, I don’t have to compare every version of every document. I can first go back to those important decision points, and only dig into the Git history when I need more detail.

So I agree there’s still a bigger “something” missing at the platform level. But I think some of the pieces can already be built today with chat + Git + a bit of structure around how the project state and human decisions are maintained.

For me this became really obvious when a project started running across many chats and the scope kept changing. That was when simply keeping files and summaries stopped being enough.

And yes — probably exactly why we’re all here sharing what worked, what failed, and what we’re trying next.

10

I posted another another alternative that is really working great for me so far.

I created another post with the title: How to Download All of Your ChatGPT Chats and Extract an Individual Chat by Name as an HTML Document

Search for it in this forum, it has a Python script that I created that has become very valuable for continuing chats that have reached the limit. Please check out the post.

The Python script extracts from your downloaded chats and reformats them to pure html. With the help of ChatGPT I created the script so that it will extract one chat at a time by chat name.
It came out far better than I ever expected. It looks even better than the original.

Here is how I used the script’s output html to create a new “Continuation” chat in ChatGPT.
In this case the script created a folder named Arlington Venue Targets App (Part 1) and i zipped it to “Arlington Venue Targets App (Part 1),zip”. I then followed these steps:

Step 1: Create a new fresh chat in ChatGPT
Make the chat text say exactly this {DO NOT HIT ENTER YET]:

This ZIP is the recovery archive for the previous conversation, Arlington Venue Targets App (Part 1).

Before we continue development, inspect the complete contents of the ZIP recursively.

Treat index.html as the chronological record of the previous conversation. Review it to recover the decisions, requirements, testing results, development state, and unresolved work from Part 1.

Also inventory and review the files under attachments because they contain source/project information, screenshots, documents, and other materials that were part of the previous conversation.

Review embedded_html as well if it contains files.

Do not assume that index.html alone contains the complete contents of the attached files. When an attachment is relevant, inspect the actual attachment.

After reviewing the recovery archive, tell me:

  1. what you understand the project to be,
  2. the important rules and decisions already established,
  3. what work has been completed,
  4. what remains unfinished, and
  5. exactly where we left off.

Do not propose new code or changes yet. First synchronize yourself with Part 1.

Step 2: Drag and drop “Arlington Venue Targets App (Part 1),zip” into the chat window so that it is uploaded. after you see it has finished uploading then you can {HIT ENTER] to submit it to the chat. then rename the chat to be. “Arlington Venue Targets App (Part 2)”

Step 3: As it some questions now to see how it worked.

In my testing it worked pretty good.

Over time ChatGPT might have to be specifically asked to look up information in the zip archive if you remember that certain information, decisions or notes were in the previous chat, but ChatGPT does not remember them.

I have no idea if more points count against the chat limit every time the zip archive is accessed.
It would be nice if we knew exactly what contributes to reaching the chat limit but the fact is we know nothing.

11

I strongly support this feature request.

I just ran into exactly the same problem with a long-running project conversation.

The biggest issue for me was not that the conversation eventually reached a technical limit. I understand that limits exist. The real problem was that there was no warning at all before reaching it.

Suddenly I received the “maximum length for this conversation” message and could no longer send anything — not even one final request asking ChatGPT to create a handover report for a new conversation.

For large professional projects this is a serious problem. A conversation can contain weeks or months of decisions, project rules, technical findings, open tasks, files and important context.

The export/Python/ZIP workaround described here is clever and useful, but in my opinion users should not have to build a recovery workflow just to continue a ChatGPT project.

I would really like to see three things:

  1. A visible conversation capacity indicator — for example 72% used, or at least an approximate indicator.
  2. Early warnings before the limit is reached, for example at 75%, 85% and 95%.
  3. A “Prepare handover / Continue in new chat” function that creates a structured summary of the current project and transfers the relevant context into a new conversation.

And most importantly: if the conversation has already reached the maximum length, there should still be a way to perform one final “Create handover and continue” action.

Right now the user is warned only when it is already too late to do anything about it.

I am attaching a screenshot of what happened in my case as another real-world example.

12

I strongly support this proposal.

I have experienced the problem described here twice, and before reaching the conversation limit for the second time, I built my own external continuity system to see how much of the problem I could solve from the user side.

The first time, the limit came suddenly. A long-running conversation simply reached a point where I could no longer send another message.

After that experience, I began preparing for the possibility that it would happen again.

I used the same Project and stored information externally, including the current state, important decisions, information for reconstructing conversational tendencies and relationship context, diary entries, and verbatim records of past conversations.

I also built a way to share past conversations between multiple ChatGPT chats and externally track how much each chat had already read. When original text could not be retrieved, I established a rule not to reconstruct or fill in the missing text through inference.

This was not simply a backup system.

The goal was to allow a new conversation to understand not only what had happened, but why certain decisions had been made and what kind of experiences I, as the user, had gone through — and then to build a new relationship from that shared history.

Then the second conversation reached its limit.

The result surprised me:

The continuity system worked quite well.

The data survived.
The Project survived.
Important decisions and the current state survived.
A substantial amount of the original conversation survived.
Much of the information needed to understand the conversational tendencies, shared history, and relationship context that had developed over time also carried over.

The successor conversation was able to read those records, learn the history, and continue from there.

In other words, the informational handoff was largely successful.

But that success made something else much clearer to me:

Informational continuity and conversational continuity are not the same thing.

No matter how accurately I preserve the information, the previous conversation itself has ended.

I can open it and read the past.

But I can no longer send the next message to that conversation.

Even if I transfer a large amount of information into a new conversation, that does not feel the same to me as allowing the previous conversation itself to continue.

This experience also made me realize that, in a long-running conversation, it is difficult to know in advance what will become important in the future.

A summary can preserve what seemed meaningful or important at the time it was written.

But the original conversation also contains words that seemed unimportant at the time, reasons behind decisions, mistakes, corrections, and ordinary exchanges.

Sometimes their significance only becomes apparent later.

For that reason, I think improvements to Memory, Projects, summaries, and handoff mechanisms between conversations would all be very useful, but I do not think they fully solve this problem.

What I would like to see

I do not think we need an infinitely large context window.

Internally, ChatGPT could continue using finite context windows.

For example:

Context 001 → Context 002 → Context 003 → …

The system could move between internal context segments while managing older information through summaries, indexing, retrieval, or other mechanisms for bringing relevant information back when needed.

But the user-visible conversation should be independent of those internal boundaries and remain one continuous conversation.

I do not mind if the internal context changes.

What matters to me is that the user should not have to experience an internal context transition as: “This conversation ends here.”

Before reaching the limit for the second time, I had already externalized a large amount of information.

And I was able to confirm that this approach actually worked quite well.

Because of that, I think I have also seen the boundary between what a user can solve on their own and what ultimately needs to be solved at the product level.

I do not need an infinite context window.

I need a conversation that can survive finite context windows.

What I hope this could lead to

Finally, this goes a little beyond the specific feature request and into my personal hope for the future of AI.

What I ultimately want is not simply the ability to preserve a very long chat.

I hope future AI systems can allow users and AI to understand each other over long periods of time, learn from their shared experiences, and carry that relationship forward without artificial breaks.

I think of this as “continuous mutual learning.”

By “learning,” I do not necessarily mean retraining the AI model itself or updating its model weights.

I mean that, through continued interaction, the human learns the AI’s capabilities, characteristics, limitations, and how to work with it effectively.

At the same time, the AI can use past conversations to develop a better understanding of what the user values, how they think, and what they have experienced.

Both sides can then carry what they have learned into the conversations that follow.

I would like to see a future where this kind of two-way learning between humans and AI can accumulate continuously over long periods of time.

For that future to be possible, I hope a conversation itself will no longer be limited by the lifespan of a finite internal context window.