Memory Summary should not replace Saved Memories

Memory Summary should not replace Saved Memories.

Saved Memories and Memory Summary serve different purposes. Saved Memories are explicit, user-controlled information that the user intentionally stores, reviews, edits, and deletes. Memory Summary is an automatically generated interpretation of past context. Because it summarizes and infers, it cannot preserve precise details, exceptions, priorities, or user intent as reliably as Saved Memories.

The main problem is that Memory Summary appears to be treated as a replacement for Saved Memories, even though it does not provide the same level of control, transparency, or precision. This causes unwanted or outdated information to be reused, while users have less ability to see exactly what is being remembered or to manage it item by item.

Please do not replace Saved Memories with Memory Summary. Memory Summary should be an optional supporting layer, not a substitute. Saved Memories should remain available, editable, and prioritized over any automatically generated summary.

Thanks for raising this, @Deltarune.

Just to clarify, Memory Summary is not intended to replace Saved Memories. They serve different purposes, much like you described: Saved Memories are user-controlled and editable, while Memory Summary is an automatically generated overview of past context.

I can see why the current experience feels concerning if the summary appears to be surfacing information that doesn't match what's explicitly saved. The distinction between the two should remain clear, especially when it comes to transparency and user control.

Have you run into a specific issue, such as Saved Memories disappearing, not being referenced correctly, or being replaced by information from the summary? If so, it would be helpful to report the details to support@openai.com so the team can investigate and track the behavior.

If you can share an example of what you're seeing, that may help others compare notes as well.

-Mark G.

This change has been really disruptive for me, and I think it’s the same underlying issue the OP is describing. I wasn’t using saved memories as casual personalisation; I was using them as a lightweight configuration layer. The old explicit memory system is also a big part of why I chose to stick with ChatGPT over other LLMs like Claude — to me it was the “Killer feature” because of the fine-grained control it provided.

For my workflow, saved memories let me store stable operating preferences and workflow rules: how I want context transferred between threads, how I want drafts patched rather than rewritten, how I want the assistant to handle uncertainty, when to ask clarifying questions, and what kinds of tone or framing are counterproductive for me.

This regression is especially problematic because Custom Instructions are still severely space-limited. If users had a large, explicit, editable instruction layer, memory could safely become more summary-like because exact workflow rules could live elsewhere. But for complex workflows, Custom Instructions fill up quickly. Mine already have to cover tone, reasoning style, interaction preferences, safety boundaries, project behavior, and editing preferences. Saved memories filled the gap by acting as persistent configuration items. Replacing them with an implicit summary removes that capability without providing an adequate alternative.

The old system worked because saved memories were relatively discrete, inspectable, and user-directed. If a memory was wrong, stale, or no longer useful, I could identify the specific item and fix or delete it. The system was imperfect, but I could usually tell what persistent instruction or fact was being carried forward.

The new memory summary changes that. A synthesized summary may be useful for casual personalization, but it isn’t a replacement for explicit saved memories. It collapses many separate control points into a lossy, assistant-mediated interpretation. I can no longer tell as clearly what the model actually knows, what it’s inferring, what it’s prioritizing, or why a response is being shaped a certain way.

This matters for people who use ChatGPT as a structured workflow tool rather than just a conversational assistant. My setup depends on keeping separate layers: explicit instructions, project-specific context, personal preferences, transient conversation history, and the model’s own inferences. When those are merged into an implicit summary, the system becomes harder to audit, understand, and correct.

It’s also made my workflow noticeably worse. I’m seeing more drift toward unwanted personalization behaviors, such as affirmation-heavy, overly agreeable, or facetious responses. Previously I could manage these preferences through saved memories and Custom Instructions. Now, because the system is more synthesized and less directly configurable, I have less confidence that those constraints are being preserved accurately.

I don’t object to summaries, but I do have a problem with them becoming the primary control surface.

What I’d like to see is explicit saved memories remain first-class editable objects, separate controls for saved memories and chat-history-derived summaries, and a way to pin exact memories so they aren’t rewritten, merged, or abstracted away. I’d also like import/export or version history for memory, along with either much larger Custom Instructions or a separate long-form configuration layer.

The current direction may be better for users who want ChatGPT to “just know them” without managing details. But for users who rely on memory as a configuration system, replacing explicit memories with a synthesized summary removes much of the control that made the feature useful. The new paradigm shifts agency away from the user. Saved memories let me configure the assistant directly. The memory summary asks me to rely on the assistant’s interpretation of how it should configure itself. For my use case, that’s a major regression (and based on reddit comments I’m not the only one with this experience).

I completely agree with this.

I am experiencing the same issue. I intentionally saved specific instructions, writing frameworks, and custom workflows into Memory so I would not need to re-enter them every time. Previously, I could trigger those instructions with a simple prompt and ChatGPT would reliably recognize them.

Recently, that behavior has changed. It feels like the system only remembers a high-level summary of my preferences instead of the actual details I explicitly saved. As a result, important rules, priorities, and custom instructions are either partially recalled or completely missing.

For users who rely on ChatGPT for professional work, this is extremely frustrating. A Memory Summary is not a replacement for Saved Memories. Summaries are useful for general context, but they cannot preserve detailed frameworks, writing standards, operating procedures, or other precise instructions that users intentionally chose to save.

Saved Memories should remain transparent, editable, and prioritized over automatically generated summaries. Otherwise, the reliability of long-term workflows is significantly reduced.

I hope OpenAI considers restoring a clearer separation between Saved Memories and Memory Summary, because the current experience feels less predictable and less dependable than before.

Title: Pro, Heavy plus, Business, and Enterprise users should keep Saved Memories, or receive an equivalent pinned/editable memory system

I want to clarify my concern about Saved Memories, Memory Summary, and the new Dreaming-based memory system.

I am not against Memory Summary. I think Memory Summary can be useful as an automatically generated overview, especially for broad personalization and scalable memory across more users.

My concern is that Memory Summary should not fully replace explicit user-managed Saved Memories, especially for Pro, Plus, Business, and Enterprise users.

Saved Memories and Memory Summary are not equivalent.

Saved Memories are detailed, explicit, user-controlled facts that the user intentionally wants ChatGPT to use across future chats. They are visible, editable, durable, and often contain long-term context that may remain important even if it has not been discussed recently.

Memory Summary is a compressed, automatically generated overview. It may capture the general shape of a user, but it does not preserve the full operational detail.

A simple way to put it:

Saved Memories are the database.
Memory Summary is the dashboard.

The dashboard is useful, but it should not replace the database.

For example, detailed Saved Memories may include specific health context, supplement categories, medication context, follow-up timelines, and safety considerations. A Memory Summary may compress that into something broad like “the user has insomnia and uses sleep medication.”

That compression loses important details.

The same issue applies to business use. Saved Memories may include detailed business strategies, inventory structure, product categories, certification details, pricing ranges, recent transactions, client/project context, and recurring workflows. A Memory Summary may compress that into something like “the user works in jewelry.”

Again, that is not equivalent. “The user works in jewelry” is not enough context for serious business continuity.

This distinction matters even more for paid tiers.

According to OpenAI’s Dreaming post, recent improvements reduced the compute required to serve Dreaming to Free users by approximately 5x, making it practical to roll out dreaming-based memory to Free users. That is good for scalability.

But Pro users are not Free users. Pro users pay for higher access and more compute. Business and Enterprise users also pay for more capable, reliable, professional-grade systems. The compute constraints that make compression necessary for Free users should not define the memory experience for paid tiers.

For Pro, Plus, Business, and Enterprise users, OpenAI should maintain explicit user-managed Saved Memories, or provide an equivalent replacement that preserves the same core capabilities.

At minimum, paid users should have one of the following:

  1. Both Saved Memories and Memory Summary available side by side
  2. A true pinned memory system where users can mark certain memories as durable and always available
  3. An equivalent editable long-term memory layer with visibility, user control, and migration support

The essential requirements are:

  1. User control
  2. User editing
  3. User visibility
  4. Explicit persistence
  5. Ability to preserve dormant but still important facts
  6. Ability to pin or protect critical memories
  7. Migration support if the implementation changes
  8. Business and Enterprise workspace support
  9. Clear distinction between automatic summaries and user-saved memory

The word “legacy” in the release notes is also concerning. In product language, “legacy” often implies eventual deprecation. If Saved Memories are not intended to be replaced by Memory Summary, it would help if OpenAI clarified whether “legacy” refers only to the previous UI/implementation, or whether explicit user-managed Saved Memories themselves may eventually be phased out.

Again, I support better memory and better summaries.

But Memory Summary should be an additional layer, not a lower-detail replacement for explicit user-managed Saved Memories.

For Free users, a more compute-efficient summary-based system may make sense.

For Pro, Plus, Business, and Enterprise users, there should be durable user-managed memory, or at least an equivalent pinned/editable memory system that preserves the user’s control over long-term context.

Thanks for raising this, and also appreciate everyone who shared examples of how the changes to Saved Memory and Memory Summary are affecting their workflow.

From the reports here, it sounds like the current experience is creating some confusion around what gets remembered, how memories are surfaced, and how the Memory Summary is presented. A few people seem to be running into similar concerns about visibility, control, and predictability.

I've passed this feedback along for the team to review. Specific examples like the ones shared in this thread are especially helpful because they show how these changes affect real-world usage.

If anyone else notices unexpected behavior or has examples of what worked better before, feel free to add them here. The more concrete details people can provide, the easier it is to highlight the patterns.

-Mark G.