[Regression] Active long-running turn now stops when usage limit is reached instead of finishing the current task

What issue are you seeing?

Codex appears to have regressed in how it handles a usage limit that is reached during an already-running turn.

Previously, if I submitted one long task and the usage allowance was exhausted while Codex was already executing that task, the active turn could continue working and finish the task. I could not start another turn afterward, which was reasonable, but the task already in progress was not abruptly abandoned.

Now, long-running tasks are being interrupted as soon as the usage limit is reached, even though they were started while usage was still available. The result is that a single command/task can consume the remaining allowance and then stop halfway through the requested work.

This is especially disruptive for agentic software-development tasks that involve repository inspection, edits, tests, browser checks, and multiple tool calls within one user request.

The practical regression is:

Previous behavior:
start task with quota available
-> task keeps working
-> quota reaches limit during the active turn
-> active turn can still finish
-> no new turn can start until reset

Current behavior:
start task with quota available
-> task keeps working
-> quota reaches limit during the active turn
-> active turn is interrupted immediately
-> requested task remains incomplete

This is not a request for unlimited usage and not a request to start new work after the limit is reached. The request is to preserve the previous behavior for the already-authorized active turn, subject to reasonable-use safeguards.

OpenAI's current Help Center documentation for Codex says that when a usage limit is reached during an active turn, Codex may continue working on that turn subject to reasonable-use limits. The currently observed behavior makes long single-turn tasks unreliable because they can be terminated solely because the quota boundary is crossed mid-execution.

Help Center reference:
https://help.openai.com/en/articles/11369540

Why this matters

For a long task, the user cannot reliably know in advance whether the remaining allowance is enough for Codex to finish. If the active turn is killed at the exact usage boundary:

• partially completed implementation work may be left behind;
• tests and validation may never run;
• the next allowance window must be spent reconstructing state and determining what remains;
• users are incentivized to split every task into many small prompts, which is the opposite of the intended agentic workflow;
• one large but otherwise valid command becomes much less dependable than it was previously.

This also compounds the recovery-cost problem described in #45383: once the turn is interrupted, the next session may spend additional quota reconstructing context instead of simply finishing the original task.

Steps to reproduce

1. Start a Codex task while there is still usage allowance available.
2. Make the task substantial enough to require an extended sequence of model/tool calls within the same user turn.
3. Let the task continue until the account reaches its usage limit during that active turn.
4. Observe that the active task is interrupted before completing the requested work.
5. Compare with the previous behavior where an already-running turn could continue beyond the point at which the usage meter reached its limit, while subsequent turns remained blocked.

Exact client build/model were not captured for this report. The important behavior being reported is the change at the account usage boundary during an already-running turn.

Expected behavior

If a turn was accepted while usage was available, Codex should normally be allowed to complete that active turn even if the usage boundary is crossed during execution, subject to documented reasonable-use limits.

At minimum, the product should distinguish between:

• starting a new turn after the limit has been reached (block it), and
• completing the currently active turn that began before the limit was reached (allow it to finish within a bounded grace policy).

If OpenAI intentionally changed this policy, the client and documentation should state that clearly before a long task begins, because it materially changes the reliability of long-running Codex workflows.

Related issues

• #45383 — interrupted sessions waste quota rebuilding state after usage-limit interruptions.
• #21073 — request to auto-resume a CLI session after the usage limit resets; related but different because this report concerns finishing the already-active turn before the reset.
• #45411 — long implementation task repeatedly exhausts 5-hour windows before completion.
• #41220 — meta tracker for abnormal quota/usage behavior.

This report is intentionally focused on the active-turn cutoff regression, not general quota size or unusually high token consumption.

No files, tests, or entry points are named. Start by locating the usage-limit enforcement and active-turn lifecycle, then compare the handling of a new turn with a turn already in progress. Done means an accepted active turn can finish within a bounded policy while later turns remain blocked, with regression coverage for the quota boundary.