Codex Fast mode performance regression since May 23 remains unresolved #25776

Codex app version

26.527.60818 (3437)

Platform

• macOS Tahoe 26.5
• Apple Silicon MacBook Pro
• Pro plan

Selected mode

Codex model option: 5.5 Fast

Summary

I am reporting an ongoing Codex performance regression. Since around May 23, the 5.5 Fast option has been much slower than its previous normal behavior, and the slowdown is still visible in my current usage.

Representative feedback IDs for investigation:

019e6a3f-1eab-74e0-bdcb-e60ca575395b
019e6b6a-db10-77e3-a4c3-170470c88f59
019e86a4-b606-7c83-a7d3-dd71bc3774b4

Observed behavior

Simple Codex tasks that previously finished in about 10-20 minutes now often take 30 minutes to more than 1 hour. Before the slowdown, even longer tasks usually stayed under about 30 minutes.

This is a serious problem for daily development workflows because Codex is used for repeated coding, debugging, verification, and follow-up edits. When Fast mode takes this long, the product experience no longer matches the expected Fast-mode behavior.

Expected behavior

• 5.5 Fast should return to the previous normal speed profile.
• If there are capacity constraints or backend routing changes, users should receive a clear explanation.
• If the Fast mode remains significantly slower for an extended period, its usage consumption should be adjusted fairly.
• Codex should provide better visibility when a task is delayed by capacity, queueing, or throttling.

Concern

There have been many reports about the slowdown in GitHub issues and on social platforms since around May 23, but the issue still feels unresolved from the user side. Please do not treat this as resolved just because users may have become used to the slower behavior.

If extra compute is being used for training, testing, or deploying new models, I can understand that. The main request is transparency and fair usage accounting while the Fast-mode experience remains degraded.