Long Codex conversations become progressively much slower, especially after image use #30375

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

1. Use Codex in one conversation window for several hours, around 5-10 hours.
2. Include image-related interactions at some point in that conversation.
3. Continue normal back-and-forth work in the same window.
4. Observe step latency growing over time.
5. Open a new Codex window/conversation with similar work.
6. 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.