Feature Request: Conversation Context Capacity Indicator and Seamless Handoff to a New Chat

I frequently use ChatGPT for long-running technical and creative projects where a single conversation may accumulate architecture decisions, source files, audit results, code changes, research, test results, project rules, and hundreds of important details over time.

The current problem is simple but significant:

Users have no clear indication that a conversation is approaching its effective working-context limit.

A long conversation can continue normally, while the user has no way to understand how much active context remains or when it would be wise to prepare for migration to a new chat.

By the time continuity problems become noticeable, reconstructing the project state may already be difficult.

I believe ChatGPT would benefit greatly from a visible Conversation Context Capacity indicator.

For example:

“Conversation context: 72% used”

“Conversation context: 90% used — consider preparing a handoff”

“Conversation context: 97% used — starting a new conversation is recommended”

Or alternatively:

“Context remaining: ~28%”

The indicator does not need to expose exact internal token counts or implementation details.

An approximate percentage, capacity bar, or several clearly defined levels would already solve the main problem.

Importantly, I would not recommend showing something like “5 messages remaining,” because messages can differ enormously in size. A short sentence and a large source-code archive, log, or technical analysis may consume completely different amounts of context.

The useful metric for the user is therefore not the number of remaining messages, but the approximate amount of usable conversation context remaining.

A simple visual system could work well:

75% used — normal

90% used — “Consider preparing a checkpoint”

97% used — “Conversation context nearly full”

At this point ChatGPT could also offer a button such as:

“Prepare handoff to a new chat”

This could turn the warning into a complete continuity workflow.

ChatGPT could automatically create a structured project checkpoint containing:

  • the current project state;
  • important decisions already made;
  • architecture and technical constraints;
  • files, archives, documents, and artifacts being used;
  • completed work;
  • current test or audit status;
  • unresolved issues;
  • important instructions and conventions;
  • decisions that must not be accidentally reversed;
  • the exact next task;
  • any additional context required to continue safely in a new conversation.

The user could review and edit this checkpoint before opening the new conversation.

There could then be an action such as:

“Continue in a new chat”

The new conversation would start with the approved handoff package already available as its initial working context.

The workflow could look like this:

Conversation reaches ~75% capacity
→ user can see that the project is becoming large

Conversation reaches ~90%
→ ChatGPT suggests creating a checkpoint

Conversation reaches ~97%
→ a stronger warning appears

User selects “Prepare handoff”
→ ChatGPT creates a structured continuation package

User reviews it
→ selects “Continue in new chat”

→ work continues with minimal loss of continuity.

This would be extremely useful for software development, large coding projects, research, long-term writing projects, document and repository audits, product development, design projects, debugging sessions, multi-stage analysis, projects involving many uploaded files, and any workflow that spans hundreds of messages.

The key benefit is predictability and user control.

A user investing many hours into a ChatGPT conversation should not have to guess when the conversation is becoming too large.

ChatGPT itself is in the best position to provide an approximate warning before continuity becomes a problem.

This would also reduce the need for users to manually maintain huge “master prompts” whose main purpose is transferring project state from one conversation to another.

Those manual handoff prompts work, but ChatGPT could make this process much more reliable, structured, and accessible to ordinary users.

In my experience, long-running ChatGPT conversations increasingly behave less like simple chats and more like persistent project workspaces.

Giving users visibility into remaining working context — together with a native handoff mechanism — would make that mode of working considerably more reliable.

A small context indicator may look like a minor interface feature, but for users who rely on ChatGPT for serious long-term work, it could solve a very real usability problem.

Thank you for considering the idea.

Respectfully,

Vladimir & ChatGPT
working together on long-running technical and creative projects

I strongly agree with the idea of making context capacity visible and preparing a structured, user-reviewable checkpoint before continuity begins to degrade.
I proposed a closely related lifecycle model in an earlier topic, “Long Conversation Lifecycle: Context Freeze, Continuity Bridge, and Conversation Protection.”
One additional possibility may be worth considering:
“Continue in a new chat” should not necessarily have to be the only destination of the handoff.
If the complete conversation record can remain preserved while only the active context is reduced or refreshed, the user could potentially continue in the same visible conversation.
A lifecycle might therefore look like:
Capacity indicator → early warning → editable continuity checkpoint → Context Freeze → refreshed active context → continue the same conversation
Older portions of the conversation would remain intact and readable, but would no longer need to occupy the active context continuously. If an older decision, artifact, or discussion becomes relevant again, the system could selectively retrieve it from the preserved history.
A new-chat handoff would still be valuable — especially when the user intentionally wants a clean workspace — but it could become one option rather than a mandatory consequence of reaching the context boundary.
This distinction matters for long-running projects because transferring information is not always the same as preserving conversational continuity.
The principle I keep coming back to is:
Preserve the record. Reduce only the active context.
Your capacity indicator would be an excellent way to make that lifecycle visible and predictable to the user.