Long Codex conversations become progressively much slower, especially after image use
Summary
Codex conversation windows appear to become progressively slower over very long sessions. The slowdown feels non-linear or exponential: a fresh conversation is responsive again immediately, but an older long-running conversation can take minutes for a single step.
Observed behavior
- Common after using the same Codex conversation window for roughly 5-10 hours.
- The issue seems more likely or more severe when the conversation has included image usage.
- As the conversation continues, each subsequent interaction becomes slower.
- In a roughly 10-hour window, a single Codex step can take 1-3 minutes.
- In severe cases, the user may wait around 5 minutes while Codex is still "thinking".
- Opening a new conversation/window immediately restores normal speed, suggesting the slowdown is tied to the accumulated conversation/window state rather than the machine or network alone.
Expected behavior
Long-running Codex conversations should degrade gracefully, or old context/image artifacts should be compacted/pruned in a way that does not make each step dramatically slower. A new window should not be required to restore normal responsiveness.
Actual behavior
The same workflow becomes progressively slower in the old window, while a newly opened Codex window responds at normal speed.
Reproduction pattern
- Use Codex in one conversation window for several hours, around 5-10 hours.
- Include image-related interactions at some point in that conversation.
- Continue normal back-and-forth work in the same window.
- Observe step latency growing over time.
- Open a new Codex window/conversation with similar work.
- Observe that responsiveness returns to normal.
Impact
This makes long, high-context work sessions hard to continue. The user has to abandon the old window and start a fresh one even when the existing thread still contains useful project context.
Notes
I am not attaching private conversation contents or logs in this public issue. If maintainers need session IDs, logs, or diagnostics, a private support/feedback path would be better for that data.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗