What is up people!
An AI can work through a project with you all afternoon and still miss an important detail when you return tomorrow. It can also answer a follow-up faster because part of the earlier work was reused. Those two experiences seem contradictory if you describe both as “memory.” They make more sense once you separate the information the assistant receives from the computation used to process it.
OpenAI’s September 22 update to prompt caching gives us a useful way into that distinction. The announcement concerns the cost of repeatedly processing familiar material. It does not promise that every detail you tell an assistant will become a reliable fact it can recall forever.
You do not need to become a developer to understand the difference. It explains something practical: when an assistant keeps using an old detail, or loses one you expected it to keep, asking it to “remember better” may leave the actual problem untouched.
📌 TL;DR
Repeated background can become cheaper → Prompt caching lets an AI service reuse computation from earlier input. The discount applies to eligible reused input, not automatically to your whole bill or subscription.
Reuse and recall are different → A temporary cache, the current conversation, and a product’s memory features do different jobs. One can work while another disappoints you.
Correct the source of the detail → A stale project file needs a different correction from an outdated personal preference. Find where the information came from before deciding what to change.
Repeating the background should cost less than starting over
Suppose you are using an assistant to plan a small garden. You provide a description of the beds, where the shade falls, and the plants already there. First you ask about the layout. Then you ask about a path. Then you change your mind about the seating area.
The later questions still depend on the original garden. A useful answer about the path needs to account for the beds, and a useful answer about the seating needs to account for the shade. The short new message is only part of the material needed to answer.
Behind many AI applications, software sends a request to the model through an API, which is the connection that lets one program use another service. That request can include earlier messages, background documents, and instructions as well as your newest question. The model’s input is therefore larger than the sentence you just typed.
OpenAI’s September 22 caching announcement describes reusing computation for that shared material. If the beginning of a later request matches eligible earlier input, the service can reuse work instead of processing all of it afresh. OpenAI says its improved system raises cache reuse by default and offers discounts of up to 90 percent on cached input.
That is a meaningful improvement for applications that keep carrying substantial background through a series of steps. It can reduce the repeated cost of supplying instructions while an agent works. It does not mean the agent has learned those instructions permanently, or that it can recover them from anywhere later.
There is a small piece of arithmetic worth understanding before the percentage runs away with the story. OpenAI’s current developer guide lists a cache-write cost of 1.25 times the ordinary input rate for GPT-5.6 and later, followed by a read cost of 0.1 times that rate.
Imagine processing one unchanged block would normally cost one unit. Processing it ten times without reuse would cost ten units. Writing it to the cache once and successfully reusing it nine times would cost 1.25 plus nine lots of 0.1, or 2.15 units.
This is an illustrative calculation for that input block alone. It assumes every later request successfully reuses the whole block. New material and generated answers still have their own costs. A 90 percent discount on a cached read therefore does not make the entire ten-step job 90 percent cheaper, and it says nothing about a reduction in your monthly subscription price.
Anthropic’s caching documentation describes the same broad idea of reusing a matching prompt prefix, with its own model prices and cache lifetimes. The details differ between services. What carries across is the reason for doing it: repeated background does not always need to incur the same processing cost each time.
If you use an ordinary subscription, the application handles those mechanics for you. There is no reason to reorganize every sentence you type around an API pricing table. The useful news is that providers are improving the economics of continuing work, alongside the more visible competition to make models smarter.
A cache does not decide what tomorrow’s chat remembers
Return to the garden. During today’s conversation, the assistant has been told that the back fence faces north. Tomorrow you open a different chat and ask where to put the bench. Whether that new answer has access to the fence detail is a question about how the application supplies information.
A cache cannot, by itself, decide that this particular sentence belongs in tomorrow’s planning conversation. It speeds the processing of matching material presented to the model. The application still needs a way to carry forward or retrieve relevant information.
OpenAI’s conversation-state guide explains ways developers can preserve conversational context, including supplying previous messages and using stored conversation state. That is a separate responsibility from making repeated input cheaper. A program needs both a sensible selection of material and a way to process it economically if it is going to support sustained work well.
You can see why these functions should remain distinct. The garden plan might contain several abandoned ideas. You considered putting a bench beside the fence, rejected it, and chose a shaded corner instead. Keeping every sentence available is useful history, but availability alone does not tell the assistant which decision is current.
Now imagine that somebody supplied only the first half of the discussion to the next session. The assistant could process that material efficiently and still recommend the rejected location. The missing correction would be an information problem. Faster processing would simply get you the outdated suggestion sooner.
This is a hypothetical example, not a report of a product test. It illustrates why “the AI forgot” can describe several different failures. Perhaps the information was never carried forward. Perhaps an older source contradicted it. Perhaps the right material was present and the model interpreted it incorrectly. Those possibilities deserve different investigations.
Product memory adds another function. OpenAI’s Memory guide says ChatGPT can use relevant preferences and details from available sources, depending on the account and its settings. It also says Memory does not retain every detail from every conversation. A remembered preference can help personalize an answer without serving as a complete record of a complicated project.
For example, “I prefer low-maintenance plants” is a useful general preference. “We rejected the bench by the fence because it blocks access to the shed” is a specific project decision. Both could matter to a garden answer, but they are different kinds of information. You would not want a passing comment about a friend’s garden quietly replacing the dimensions of your own.
Nor should you treat a cache lifetime as a privacy countdown. The current OpenAI caching guide describes a 30-minute eligibility window after a cache write or reuse for GPT-5.6 and later, and says entries may be retained longer. That is not a promise that your chat, files, or saved memories disappear after half an hour.
A familiar answer, a quick answer, and a correctly remembered answer can look similar from the outside. The difference becomes visible when you ask which information supported the result. That is a more useful question than judging the assistant’s memory by how confidently it speaks about your garden.
Correct the source that supplied the wrong detail
Suppose the assistant keeps describing the garden as having three beds, although you now have two. You could repeat “two beds” in every message. That may help the next answer, but it leaves you doing the correction again whenever the old description returns.
Start by locating the old detail. Is it in the file you uploaded? In the instructions attached to the project? In a previous conversation the product can reference? Or is the assistant making an unsupported assumption? Asking for the supporting source gives you something specific to inspect, though the assistant’s explanation still needs checking against the material itself.
If the uploaded plan shows three beds, update the plan you intend to use. If the file is correct and the assistant misread it, point to the relevant passage. If the answer provides no support, ask it to leave the number unresolved until it has evidence. These corrections are more precise than treating every wrong detail as a broken memory setting.
A temporary instruction needs care too. Imagine asking for a design with no flowers because you are exploring what a mostly green garden might look like. That does not necessarily mean you have developed a permanent dislike of flowers. Saying “for this version” makes the scope clearer and avoids turning an experiment into a standing preference.
The reverse happens when a real change gets phrased as a casual aside. “We removed the third bed last weekend” changes the current plan. A useful follow-up would identify the old plan as outdated and supply the replacement, so the assistant has a clear reason to use the newer dimensions. The point is to make the relationship between sources understandable.
ChatGPT’s Projects documentation describes keeping related chats, files, and instructions together. It also distinguishes default memory from project-only memory. In the latter mode, chats can draw on other conversations inside that project while excluding outside conversations and previously saved personal memories. The current guide also says ChatGPT Work is unavailable in a project using project-only memory, so this is a choice with a functional tradeoff.
That can explain an apparent inconsistency without blaming the model. A preference you established elsewhere may be outside the context that project is allowed to use. If you want that preference to guide the project, provide the relevant instruction there. Check the settings and features your account actually offers rather than assuming every project draws from everything you have ever said.
There is no prize for collecting the largest possible pile of context. A garden assistant does not need every email you have ever sent about gardening. It needs the relevant information, including which version is current and which choices are still open. More material can introduce more conflicts if nobody makes those distinctions.
This is also where the caching story reaches its limit. Developers can reduce repeated computation while keeping useful background available. You still need the background to describe the garden you have now. An efficiently processed old plan is an old plan.
Also this week...
OpenAI released GPT-6 Sol and Luna on September 22. The launch announcement positions them as faster, lower-cost alternatives within the GPT-6 family. It lists availability in ChatGPT Work and Codex for Plus, Pro, Business, Enterprise, and Edu, with Luna accessible to Free and Go users in the desktop app. The announcement explicitly says they are not yet available in Chat. Check the surface you are using before assuming a missing model means something is broken.
Anthropic released Claude Opus 5.5 the same day. Its announcement claims about 40 percent lower cost on typical workloads than Opus 5. The listed input and output token prices are 20 percent lower; cache-read prices and the amount of work a model uses also affect the total. That is another reason to read what a price comparison actually measures. These are Anthropic’s results, not a comparison run for this newsletter.
💡 Suggested how-to: trace one detail
Here is an exercise to try with an ordinary project you understand. It has not been run as a controlled test for this issue. Choose a harmless detail whose correct answer you know, such as a garden measurement, the audience for a document, or a preferred date format.
Ask the assistant to use that detail in a small task and identify the source supporting it. You can adapt this request:
Before suggesting the layout, tell me how many garden beds you believe there are and identify the file, message, or instruction supporting that number. If you cannot establish it from the available material, ask me. Treat the attached current plan as authoritative for the dimensions.
Inspect the source it names. If the source is old, correct or replace the relevant material. If the source is current but the answer misstates it, point out the mismatch. If it cannot identify support, provide the missing fact explicitly rather than accepting an invented explanation of where it came from.
Then ask a related question in the place where you expect the information to remain available. Keep the conclusion modest: the new answer shows what happened in that case. It does not establish that every future conversation will retrieve the same detail.
🧰 Tools to try
Your existing memory controls: OpenAI documents these under Settings, Personalization, then Memory, with controls varying by account. Where Sources appear below a personalized response, they may help you inspect what contributed. They are not an exhaustive account of everything affecting the answer.
One current project reference: For details that need exact wording, use a file you can inspect and update. A short, clearly named current plan is more useful for this exercise than another long instruction demanding perfect recall. Keep the original somewhere recoverable if you replace it.
The next time the assistant confidently puts a bench where a shed now stands, ask it to show you the plan it used. You will know whether to correct the plan, the interpretation, or the information available in that conversation.
P.S. An AI wrote these sentences from this week’s primary sources and current product documentation. Payton set the editorial standards and what good looks like. He wants to be transparent when AI wrote the issue.


