gpt-5.4 generates response to earlier messages not the last user message

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #13823
• #11897

Powered by Codex Action

I think this is model behavior, not something that's under control of the Codex harness. If you see this again, please use /feedback to upload your session details and post the thread ID here. That will allow us to determine for sure.

GPT-5.4 xhigh seems more biased toward the overall thread and previous tool call context than the user’s most recent message. My workaround is to start a new thread whenever I switch to a task that is not directly related to the current goal. It is a very strong coding model, but it struggles to distinguish between what I’m asking now and what I asked earlier in the thread and what it read in the repo files that don't directly affect what we are working on now. It made me swear at it when it started refactoring non-related parts of codebase, so I won't share the thread 😆 but it's definitely something what was much less present in 5.3 xhigh. I still prefer 5.4 over 5.3 for coding, but it keeps you on your toes.

Just had this happen again and submitted a feedback report (019cb7c8-ffb6-7583-9608-66aadce3ebe1):

---

Model reverts to earlier instruction during reasoning phase instead of responding to latest user message

I’m observing a recurring behavior where the model begins a reasoning phase for a new instruction but ends up responding to an earlier message in the conversation instead of the latest user message.

In the session where this occurred, I previously asked the model to check the parity between Korean and English documentation. The model completed that task and we continued the conversation afterward.

Later in the session, I gave a handoff-style message asking the model to begin implementation. This should have triggered a longer reasoning phase because the task is non-trivial.

However, the model only reasoned briefly (around ~16 seconds) and then produced a response addressing the earlier instruction about checking parity between the Korean and English docs — even though that task had already been completed earlier in the conversation.

This pattern appears to repeat:

1. The user provides a handoff-style message expecting the model to start a longer task (e.g., implementation).
2. The model starts reasoning.
3. The reasoning phase stops unexpectedly after a short period.
4. The model generates a response addressing an earlier instruction instead of the latest user message.

Notably:

• The earlier instruction had already been completed.
• The response looks like the model is reattempting or falling back to that earlier task.
• This occurs even though the latest message clearly initiates a new task.

I’ve observed this behavior on gpt-5.4 with:

• reasoning=high
• reasoning=xhigh
• /fast both enabled and disabled

The issue therefore does not appear to depend on reasoning depth or fast mode.

The more I use it, the more this looks like a pattern: after a thread accumulates a fair share of complexity, the model starts choosing the easiest thing it can address right away instead of the most important thing to do next. In coding tasks, that is visible when progress falls from substantial multi-file implementation to tiny, low-value edits in a full turn, or just repeated summaries of previous messages. I cannot prove the cause, but my suspicion is that it is too influenced by general training signals that encourage minimal-effort responses (potentially not intended consequence of I assume merged training data for coding + the rest of GPT training data). Workaround is starting new threads and keeping implementation docs updates per every turn, but this burns so many more tokens, every new thread start becomes half an hour investigation of how everything works so it's not only counterproductive and time wasting, but it's unnecessary load of infrastructure.

Another note: this issue seems to become more prominent when a new run goes through auto-compaction. It almost feels as though auto-compaction is nudging the model away from the current user message, or at least not prioritizing it strongly enough. If that is the reason, then the bug may be simpler than core model behavior.

I'm getting this repeatedly too on long running threads, compaction also seems to be a trigger. Raised feedback, latest one is 019cd18a-12b6-7c21-a8d4-fca2d315cb43.

same. this behavior happens a lot more often on long threads, which has been compacted multiple times. much less on new threads. maybe this is tradeoff that comes with gpt-5.4 being great at understanding / summarizing full context of long threads.

I'm seeing this a lot since switching to GPT-5.4 and enabling the 1 million token context window. Not sure if the context window is related. It just happened to me multiple times in a single thread around the 75% context remaining mark, which should be comparable to the old limit. This happened in a thread that had not experienced any compaction. Basically the thread is busted and I need to start over. It does not feel like a model behavior. It feels like some sort of context injection / memory issue. I tried "/feedback" and it just said:

Noted. The failure mode you’re describing is: the assistant latches onto an older turn and answers that instead of the latest user message, and you’ve seen it repeatedly since
  moving to 5.4 with 1M context enabled.

  I can’t file product feedback directly from here, but that’s a crisp bug report as written.

Also, the model is still able to access the correct user message somehow, but its memory seems all kinds of messed-up.

*Okay, back to the task at hand. What's the last task I gave you?*
Your last task was to fix the drag interaction bug where a failed drag, like trying to drag a folder into itself, could leave drag effectively broken until the app was restarted.
*No, that's not it*
The last concrete task you gave me was to change the checkbox text to Completed.
*After that*
The last bigger task you gave me after the drag work got sidetracked was:
Add a substring search bar to the list, using the pattern from the sibling app.
*Yess there you go*
I’m picking that back up now.
...

UPDATE: Here's a good example. Note how Codex acks the user request and then there's a solid line and it snaps back to a previous request about a merge conflict.

In this case: gpt-5.4 high fast · 68% left · 65.3M in (1 mil context enabled).

<img width="875" height="363" alt="Image" src="https://github.com/user-attachments/assets/71a91745-7922-4c4b-aaa4-48ecd4171bc2" />

If these responses are inherent to the model’s characteristics, should we wait for GPT-5.5?😭😇🥹😂🤬🫠😵

Encountering this a fair few times recently, threadid: 019ce89f-a1a4-7e11-b2c8-c6c5d1e4487d

Interestingly this was before compaction with context at 14% left after the wrong response was finished.

Happening with me as well. It usually occurs when the context becomes very large—around 300k tokens or so. Is OpenAI looking into this?

Happening with me as well. It usually occurs when the context becomes very large—around 300k tokens or so. Is OpenAI looking into this?

Agreed. I've started always manually compacting by around 300k, and I don't think I've seen the issue since. Basically using the 1mil context window to eek out a little buffer compared to the default 250k window.

Same thing happenings Using 1M Context.