Custom GPT does not reuse an Action response on the next user turn — reproducible after GPT-5.6 rollout

[enpasos]

After the GPT-5.6 rollout, our production Custom GPT workflow stopped working across user turns. We built a minimal public reproducer that excludes authentication, databases, learner data, RAG and production-specific logic.

Reproduce

1. Open RegressionGPT:
   ChatGPT - RegressionGPT
2. In a new chat, send RUN_RETAIN. The GPT successfully calls the Action and replies RETAIN_READY.
3. Immediately send RECALL_RETAIN in the same chat.

Expected: The GPT returns the exact token received from the previous Action without calling another Action.

Observed: RETAIN_MISSING

Passed controls

• RUN_SINGLE successfully reads fresh fields from the Action response.
• RUN_CHAIN successfully passes the complete response into a second Action within the same assistant turn; the backend verifies proof_valid=true.
• A direct HTTP probe/verify control passes against the same public API.

This shows that same-turn processing works, while data from the successful Action is not reused after the immediately following user message. It does not establish which internal component causes the behavior.

Our production learning coach needs ordinary backend responses—including session references, learner state, navigation results and workflow instructions—across later user turns. The observed behavior is sufficient to break that workflow.

Questions for OpenAI:

1. Are successful JSON Action responses expected to remain available after the next user message?
2. Can context selection, summarization or compaction omit them even in a fresh two-turn conversation, and can a GPT builder control this?
3. If cross-turn availability is unsupported, what architecture does OpenAI recommend for multi-turn Custom GPT Actions?

Technical reproducer, exact instructions and OpenAPI schema:

Custom GPT Action cross-turn reproduction · SkillPilot

Direct OpenAPI schema:

https://skillpilot.com/api/action-regression/openapi.yaml

The timing is a correlation with the GPT-5.6 rollout, not a claim that GPT-5.6 is the proven cause.

[enpasos]

I ran another test series with the reproducer on July 15, 2026, systematically changing the Recommended model configured for the Custom GPT.

The issue reproduced with every available configuration except one:

Recommended model	Result
GPT-5.6 Thinking	Failed
GPT-5.5 Thinking	Failed
GPT-5.5 Instant	Failed
GPT-5.5	Failed
GPT-5.4 Thinking	Failed
GPT-5.3 Instant	Passed
No recommended model / no preselection	Failed
o3	Failed

When GPT-5.3 Instant is selected, the reproducer passes and the Action response remains usable on the following user turn. Interestingly, the model indicator in the resulting conversation shows “Legacy 5.4, Instant” rather than GPT-5.3 Instant.

To the best of my recollection, before the GPT-5.6 rollout this workflow generally worked regardless of the configured recommended model.

This means that, at least for now, there is a workaround for this specific issue: setting the recommended model to GPT-5.3 Instant. However, this also means that I can no longer configure the model I would actually recommend for my GPT merely to preserve a previously working multi-turn Action flow.

For my application, SkillPilot, the failing behavior is a showstopper because subsequent user turns depend on information returned by the previous Action call.

I have therefore also started evaluating alternative platforms in parallel. In an equivalent multi-turn tool-use test on Anthropic’s Claude platform, I have not observed this specific failure mode. This does not identify the root cause, but it suggests that losing access to the previous tool response is not an unavoidable or generally expected behavior of tool-based assistants.

Based on these results, this appears to be a regression that should be corrected rather than treated as expected behavior.

[iyvljtjqleyj]

Is this the same like my bug?

Custom GPT can’t memorize anything from the fetched data, after one turn.

It get’s it data (successfully) form my server, using a very basic action (“connect to the server, ask for data”). It does get the data, but after the first question it doesn’t remember it.

Introduced during the update to 5.6, but also present in 5.x

Since then it has to re-require the data for every single question you ask about it.

On instant, is 100% faulty, on ‘thinking’ it sometimes does work (but can also be hallucinating).

Custom GPT's can't memorize retrieved data

I have some GPT’s with custom instructions for years now. Made 1.000’s of calls using them. They fetch the needed data from my server, using a \_POST / _GET command. As a custom action, using the web-interface. Since 2027 07 10 it can only remember the fetched data when set to ‘thinking’. With ‘instant’ it just hallucinates nonsense data. But even with ‘thinking’ it can’t memorize it longer then one answer. Every time I ask another question, it has to ping the external server, ask for the …

-edit- I did fill in a bugreport, but OpenAI is just ignoring it with bot-answers;

Is AI support handled by real humans or AI?

I have encountered a (I think) serious bug in custom GPT’s. When loaded with some custom data from an external server, it can’t remember anything of that particular data after the 1st message: it has to connect to the external server (where the data is stored) every single time. Ask a question? Needs to connect. Another question? Needs to connect. Etc… This bug was introduced after the web-update (same day when 5.6 / SOL was rolled out). But since then it also happens in 5.4 / 5.5 / etc… so…

[enpasos]

@iyvljtjqleyj — yes, based on your description, it looks like we are experiencing the same problem. I opened this issue and created the minimal reproducer precisely to turn the question “Is this the same bug?” into a concrete, measurable failure case. We cannot determine the internal root cause from the outside, but the behavior you describe appears to match the one documented here.

One additional observation may be relevant to the timeline. All times below are Berlin local time.

On the morning of July 15, 2026, the Recommended model dropdown in the Custom GPT configuration still showed version-specific entries, including GPT-5.3 Instant, GPT-5.4 Thinking, GPT-5.5, GPT-5.5 Instant, GPT-5.5 Thinking, and GPT-5.6 Thinking.

I used those labels for the test series reported above, in which GPT-5.3 Instant was the only passing configuration.

By the evening of July 15, the version numbers had disappeared. This remained unchanged on July 16: the dropdown showed three entries labeled only “Instant”, three labeled only “Thinking”, plus o3.

After selecting an entry and running the GPT, the actual model is still shown, so it can still be identified afterward. At selection time, however, the individual versions are no longer distinguishable in the configuration panel.

This visible UI change does not establish a causal connection to the Action-response issue. It does show that the model-selection area changed during the same test window, and it may have coincided with related changes being deployed in the background. Given the model-dependent test result, I think this is worth recording as part of the issue timeline.

Screenshots attached.

---

[iyvljtjqleyj]

@enpasos

This visible UI change does not establish a causal connection to the Action-response issue.

In my case (and maybe “our” case) I think the UI change does have something to do with the bug.

At the same moment both GPT 5.6 SOL was introduced AND the interface (web) was changed.

The Android app, which I also use, didn’t fetch that UI-update and there my custom GPT was still working.

But on the web, with both UI and GPT model change, the bug was introduced.

---

Also, before the bug, the GPT did fetch my data from my server telling me something like “connecting to the app”.

Where “the app” was my server and it was connecting with the custom action, set in it’s instruction.

This text was not part of the message, but the UI-interface: one was able to click on it (it was a dropdown) and there I could see all fetched data. 100% complete, raw data, line by line, word by word.

And the GPT was able to reference that data, because it was visible (though initially hidden) in the chatsession.

But after the UI-update, this whole “connection to app” is gone. And so is the data when you ask for it after the 1st message.

Sometime I need to write an article with that data, served on my own server. And when I ask the GPT 10 questions about the exact same data, it has to fetch it 10 single times from my server.

It’s a waste of time and also introducing an extra vector for hallucinated answers (sometimes it doesn’t even connect to my server and makes things up, because it can’t read the data itself: it just plain forgot it).

---

-edit- When switched to thinking, it’s a bit better - but GPT still can’t remember any data at all. It does fetch it, but can’t access it after the 1st message. This happens in 5.4, 5.5 and 5.6 (web only).

[enpasos]

@iyvljtjqleyj — thanks, this is a useful additional observation.

I think we are describing two different visible UI changes at different points in the timeline.

Your observation appears to relate more closely to the onset of the problem: around the time the cross-turn behavior changed, the expandable Action call/result panel also disappeared from the web conversation. That timing may be relevant.

My observation occurred later. All dates and times I have mentioned are Berlin local time. On the morning of July 15, 2026, the version-specific entries were still available in the Recommended model dropdown. I used those entries to run the model-specific test series and posted the resulting matrix above.

As far as I can reconstruct the sequence, only afterward—by the evening of July 15—did the version-specific labels change to the generic labels “Instant” and “Thinking.” They were still displayed that way on July 16.

I would therefore not assume that these observations refer to the same UI update or deployment. Your observation may help locate when the regression first appeared, while mine documents a later change in the model-selection interface, after the reproducible and model-dependent test result had already been captured.

I would also interpret the visible Action panel as an indicator rather than as the mechanism that made the data available to the GPT. The GPT would not retain the Action response merely because it was displayed in the UI. However, the panel may have been the visible representation of an Action response being retained as part of the conversation state. Its disappearance and the loss of cross-turn access could therefore be two externally visible effects of the same underlying change.

The difference you observed between the web client and Android is also useful. It suggests that client-specific behavior or a staged rollout may be involved in addition to the selected model.

My later dropdown observation does not establish that related backend changes occurred. However, because the test result was strongly dependent on the configured recommended model, I still think the subsequent change in the model-selection interface is worth recording as part of the timeline.

[iyvljtjqleyj]

@enpasos

Your observation appears to relate more closely to the onset of the problem: around the time the cross-turn behavior changed, the expandable Action call/result panel also disappeared from the web conversation. That timing may be relevant.

That’s exactly what I meant.

That panel did contain all data, which the GPT used (I think) for further messages / answers in the same tread.

Now that that data is gone, it’s memory is gone.

[enpasos]

OpenAI team: is this intended behavior or a regression?

At this point, the most useful clarification would be how OpenAI classifies the behavior documented in this thread.

From my perspective, this is a bug: a Custom GPT can use an Action response within the assistant turn in which it is returned, but after the next user message it no longer reliably has access to that response. To the best of my knowledge, this multi-turn flow worked before the GPT-5.6 rollout.

However, the decisive question for application developers is whether the current behavior is expected to remain or is considered an unintended regression that will be corrected.

For SkillPilot, and for other applications that depend on Action results remaining available across user turns, the current state is a showstopper. The classification directly determines the available options:

• If this is intended behavior, I need to redesign the architecture or migrate to another platform.

• If this is a regression that is expected to be corrected, I can use temporary mitigations while avoiding a potentially unnecessary redesign or migration.

The model-specific result documented above does currently provide a workaround: one recommended-model configuration still passes the reproducer. However, if the loss of cross-turn Action responses is now intended behavior, this passing configuration cannot be regarded as a supported or dependable solution. It may simply be an incidental exception and could disappear with a future model, routing, or configuration change.

Building around that exception could therefore consume valuable engineering time without providing a viable long-term path. An early classification from OpenAI would help me avoid investing in a workaround that may not be intended to remain available.

I am not asking for a firm ETA at this stage. Even a preliminary statement from the OpenAI team—“expected behavior” or “tracked regression”—would already provide the clarity needed to make responsible product and architecture decisions.

[iyvljtjqleyj]

I have made a bug report, screen recordings, step by step walk through, shared demo-chats, etc…

They’re not interested.

Custom GPT’s are broken, and they don’t care.

Maybe nobody but us uses them?

[iyvljtjqleyj]

Check this error message I got, my storage quota was exceeded (and I don’t save any document / image at all: after generating them, I delete them at once).

And so my GPT couldn’t save it’s memory, and so my GPT couldn’t access it’s memory, and so my GPT couldn’t answer my questions about any fetched data, since it didn’t have access to it…

More details in the thread below.

Custom GPT's can't memorize retrieved data

Interesting enough, I am sending a HAR-file to the OpenAI support (which is by the way 100% a bot you are mailing with, no human seen there). But while re-creating the bug, I saw the message below in my developer console. > QuotaExceededError: Failed to execute ‘setItem’ on ‘Storage’: Setting the value of ‘cache/user-xxx-8974-4b46-9ced-xxx/system-connectors’ exceeded the quota @ https://chatgpt.com/cdn/assets/2340486e-i4b839otgjgqarcp.js So ‘there is something wrong with my storage and the re…

-edit- the regular storage is not full

-edit2- I know this is local storage vs. remote storage.

But even after clearing all the local storage, OpenAi is sending a sh*tload to my browser, exceeding the 50mb quota on my browser’s side. So something is wrong with their app-connector.

[enpasos]

Update: correlated browser and backend evidence (July 21)

I have now correlated one failing run at both the ChatGPT browser boundary and the SkillPilot application-server boundary.

The captured run used ChatGPT web with gpt-5-6-thinking, reasoning effort standard, and automatic model switching disabled.

What is now directly established

• RUN_RETAIN started at 04:38:07 UTC (06:38:07 CEST).
• During that turn, ChatGPT invoked createRegressionProbe exactly once.
• At 04:38:15.277 UTC, the SkillPilot handler generated a fresh schema-valid tuple and committed an HTTP 200 JSON response:
  • 128 response bytes
  • response_committed=true
  • independently verified response-byte count and SHA-256
• ChatGPT completed the first turn with RETAIN_READY approximately 3.857 seconds later.
• RECALL_RETAIN was then sent in the same conversation. Its parent_message_id exactly matches the final RETAIN_READY Assistant message from the preceding turn, so this was not a new or incorrectly branched conversation.
• The Recall turn invoked no tool. Backend request-sequence continuity independently confirms that no probe or verifier handler ran during Recall.
• ChatGPT completed the second turn with RETAIN_MISSING.

This closes an important evidence gap: the first Action did not merely appear to run in the UI. The application handler actually produced and committed a successful, tiny JSON response during the captured turn.

The remaining boundary is inside OpenAI. From outside, I still cannot determine whether the response was fully received and parsed, how the Action result was represented after the first turn, or whether its fields were included in the next-turn model context. The browser-visible stream contains the Action-call node but no conventional serialized Action-result node or actual probe fields. That is a useful structural observation, not proof that OpenAI never received or stored the response.

Separate system-connectors / localStorage finding

First, thank you, @iyvljtjqleyj, for sharing the QuotaExceededError observation and screenshots. That was a valuable lead and prompted a much deeper inspection of the Connector request, its initiator stack, and the exact ChatGPT JavaScript bundles delivered in the HAR.

The Action/JIT message renderer triggers a second Connector request without skip_directory=true:

• initial request: 33 connectors, about 77 KB;
• JIT message request: 2,345 connectors, about 9.85 MB;
• the client then attempts to persist an approximately 10.45-million-character system-connectors value in localStorage.

This very strongly explains the observed QuotaExceededError and appears to be a real Web-client inefficiency/bug.

However, the code path stores Connector-catalog metadata, not the Action response. It populates the in-memory cache before attempting the persistent write, catches the storage exception, and does not rethrow it. In this run, the large Connector response—and therefore the earliest possible storage write—also completed only after ChatGPT had already produced RETAIN_READY.

I therefore would not currently treat the quota error as the demonstrated cause of RETAIN_MISSING. The best evidence-bounded interpretation is that these are probably two separate Action/JIT-related issues:

1. an oversized full-directory Connector fetch and failing persistent cache write in the Web client;
2. failure to reuse an earlier Action result after the next user-message boundary.

A patched/unpatched repeated browser test can still determine whether the quota exception is necessary for the second symptom, but the inspected dataflow provides no direct deletion mechanism.

Public reproducer

The public, stateless, credential-free reproducer remains available here:

Custom GPT Action cross-turn reproduction · SkillPilot

It links RegressionGPT, the live OpenAPI schema, exact instructions, source, and test protocol. No authentication, production sessions, learner data, or database state are involved.

I have opened a ticket with OpenAI Support. The private conversation IDs, internal trace IDs, exact synthetic tuple, sanitized HAR analysis, and correlated server audit have been supplied there for internal trace inspection. I am not publishing those private identifiers, the support case number, or the raw HAR here.

I will update this thread if Support or the relevant engineering team classifies the behavior as intended, unsupported, or a tracked regression.

This evidence still does not prove GPT-5.6 causation; the rollout remains timing context. It does make the externally observable failure much narrower: a successful Action response is committed during a correctly linked two-turn conversation, yet its value is not used on the immediately following turn.

[enpasos]

Current production impact and workaround

As long as OpenAI does not confirm that reliable cross-turn reuse of Custom GPT Action responses will be restored—or provide a supported replacement—I currently see only one viable path for SkillPilot on the Custom GPT platform: redesign the integration so that it no longer depends on this capability.

Viewed as a user interface, a Custom GPT would normally allow standard key/label semantics: the user sees a human-readable label, while an opaque technical key is retained and passed to the backend. With the current behavior, such a key cannot reliably survive into a later user turn unless it is also written into the visible conversation.

In practice, this means either:

• replacing key/label interactions with label-only flows; or

• exposing technical keys to the user and carrying them forward as visible text.

This workaround is technically feasible, and I am currently implementing it for SkillPilot, but it comes at a real cost: reduced usability, more implementation details in the conversation, and a more fragile interface contract. It is not an equivalent replacement for retaining Action responses across turns.

In parallel, I am introducing a Claude-based coaching interface which, in our testing, does not have this limitation.

I would still prefer to keep the Custom GPT integration and return to the cleaner architecture if OpenAI restores this behavior. A clear statement on whether the regression will be fixed—or which supported mechanism should replace cross-turn Action-response reuse—would be very valuable for production users.

[enpasos]

Update: cross-turn retention succeeds through a UI-less ChatGPT MCP app

Following my previous update, I tested whether the same limitation also affects the newer ChatGPT App/MCP path, or whether it is specific to Custom GPT Actions.

For this test, I built a minimal developer-mode ChatGPT app exposing exactly two stateless MCP tools:

1. The first tool creates a fresh synthetic tuple {probe_id, token, proof}.
2. The second tool receives that tuple and cryptographically verifies the proof.

The test deliberately excluded alternative state channels:

• no embedded UI or widget;
• no widget state;
• no result _meta;
• no authentication state;
• no server-side session store or value lookup;
• no tuple values in the visible assistant response;
• no tuple values in the second user message.

The decisive two-turn sequence was:

• Turn 1: the creation tool returned the tuple only as MCP structuredContent; the assistant displayed only MCP_RETAIN_READY.
• Turn 2: the user sent only MCP_VERIFY_RETAIN, without copying any identifiers or values.
• ChatGPT then called the verification tool with the complete tuple from the preceding tool result.
• The server confirmed that the probe ID was unchanged and the cryptographic proof was valid. No new creation call occurred during the second turn.

A separate raw-recall test also succeeded: on the following user turn, ChatGPT reproduced values that had never appeared in the visible conversation.

Therefore, under these short-dialog test conditions, the Custom GPT Action regression documented in this thread did not reproduce through the MCP app path. Because the test had no widget, the successful retention cannot be attributed to embedded UI state. It came through the MCP tool-result/conversation path itself.

This result is consistent with OpenAI’s description of MCP conversation awareness, according to which structured tool results can remain available for references in later turns: Apps SDK – Conversation awareness.

Important limitations remain: this was a developer-mode smoke test across one immediate user-turn boundary. Long conversations, context compaction, conversation reloads, authentication, different models, and repeated production usage still need testing. It is also not evidence that the Custom GPT Action regression has been fixed.

However, this changes my current architectural direction for SkillPilot. After testing the visible key/value workaround described in my previous comment, I no longer consider it viable for production. Requiring users to see and carry technical identifiers through the conversation creates too much friction and makes the interface unnecessarily fragile.

The more promising path is now to migrate the existing SkillPilot coach from Custom GPT Actions to a data-only MCP app first, while retaining the option to add embedded UI components later. This is an alternative integration path—not a resolution of the Custom GPT Actions regression.

I would still appreciate clarification from OpenAI on whether reliable cross-turn reuse of Custom GPT Action responses will be restored. The original reproducible Action failure remains documented here: Custom GPT Action cross-turn reproduction.