[Windows Desktop][GPT-6.1 Sol High] Severe long-context slowdown around ~270K / 500K; manual compaction substantially restores responsiveness #54026

Summary

I am reporting a severe performance/usability regression in long Codex Desktop conversations using GPT-6.1 Sol (High reasoning) with a reported 500K-token context window. In my repeated practical use, responsiveness deteriorates sharply once a conversation grows to roughly 270K tokens, long before reaching the nominal maximum. Manually compacting the context within the same conversation produces a substantial immediate speed improvement.

The ~270K point is an approximate observed range, not a rigorously established hard threshold. This report is about execution latency and long pauses, not a demonstrated drop in model answer quality.

Environment

• Client: Codex Desktop on Windows; exact app build not captured.
• Model: GPT-6.1 Sol, reasoning effort High (not Max).
• Context: reported 500K-token window; substantial slowdown observed at ~270K and above.
• Observed around October 14–15, 2026 (UTC+8).
• Normal software-development workflow with repeated file reads, code edits, shell commands and validation.
• No visible "reconnecting" / "retrying connection" messages in the affected screenshots.
• The same account, system and network respond much faster in a fresh Codex conversation. Network latency at the user's proxy is typically ~68–100ms, but this alone cannot rule out every network issue.
• Account throttling, backend queue delays and local UI causes have not been independently ruled out.

Actual behavior

1. In the existing long thread, progress appears to stall on "Thinking", "Ran command", or "Edited file" between actions for ~30–120 seconds or more, repeatedly.
2. A development task that would ordinarily take around half an hour may instead take more than an hour, occasionally becoming practically unusable.
3. Some pauses end in a batch of code edits (e.g. >300 lines), so not every quiet interval is necessarily a hung command; the concern is the repeated dramatic difference versus a compacted/fresh session.
4. Manual context compaction in the affected thread noticeably restores continuous tool/action progress, without changing model, reasoning effort, project or network.
5. Once the compacted context grew again (around 110K tokens), occasional pauses reappeared, although overall performance remained better than before compaction. This suggests a strong context-related component, not a conclusively proven 270K-only cutoff.

Reproduction / diagnostic comparison

1. Use Codex Desktop on Windows with GPT-6.1 Sol, High reasoning.
2. Keep working in a tool-heavy engineering conversation as the context grows toward/above ~270K of the 500K window.
3. Observe repeated long delays between visible tool completions and subsequent actions / outputs.
4. Manually compact the existing conversation context.
5. Continue comparable work in the same project, same model, same account and compare responsiveness immediately after compaction.
6. Separately, a fresh conversation with the same model/project is significantly faster than the long-running conversation.

These are in-the-field observations, not a controlled benchmark with server timestamps. There is no confirmed measurement of model inference TPS, prefill time, or backend queue time.

Expected behavior

• The usable performance of a model advertised with a 500K context should not collapse well below that limit without clear warning or mitigation.
• Tool calls and post-tool continuation should remain reasonably responsive for long agentic tasks.
• The app should clearly distinguish active reasoning or editing from a genuine wait/stall, where possible.

Request for Codex engineering

Please investigate:

• Request queue time, time to first token, context prefill / cache behavior and streamed token throughput as context size grows.
• Whether long-context replay or tool outputs increase per-step latency disproportionately.
• Tool-completion -> next-action latency and any desktop UI/app-server buffering.
• Why manual compaction produces such a large improvement, and whether proactive compaction or clearer performance guidance is warranted.

Privacy: No account IDs, project source files, local paths, secrets or raw session logs are published here. The affected Windows desktop screenshots contain private project paths and can be supplied in a redacted form if needed.

Submitted on the affected user's explicit request.