Issue with 5-Hour Usage Limit and Subagent Bug #29996

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   on Jun 25, 2026
2. github-actions commented on Jun 25, 2026

   

   github-actionsbot

   on Jun 25, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Active turns cannot complete after 5-hour limit when Auto-review approval calls are required #29717

   Powered by Codex Action
3. 19Carlos87 commented on Aug 26, 2026

   

   19Carlos87

   on Aug 26, 2026 – with ChatGPT Codex Connector

   More actions

   I am seeing the same core problem on ChatGPT Plus with GPT-5.6 Sol at medium reasoning, and I want to add one important consequence that makes the current behavior more expensive than the limit itself.

   A long-running Codex turn can start while the 5-hour quota still has capacity, but when that quota reaches 0% the active turn is interrupted immediately. This has now happened repeatedly, not just once.

   In one clean window, the 5-hour allowance started at 100% and was exhausted in under an hour of intensive agent work while the weekly allowance still had substantial capacity remaining. The active task was cut off at the quota boundary instead of being allowed to finish or stop at a safe checkpoint.

   The main issue is not simply that new work is blocked. The abrupt interruption creates additional token/usage cost in the next window. When the task resumes, Codex cannot safely assume the partial edits are correct. It has to reconstruct the previous state by inspecting git status/diff, rereading modified files, checking which parts of the implementation completed, detecting partial/inconsistent changes, and rerunning some tests before it can continue. In a large multi-file task, this recovery work can be significant.

   So the current behavior can create a feedback loop:

   1. active turn consumes quota;
   2. quota reaches 0%;
   3. turn is terminated mid-work;
   4. next window spends additional quota reconstructing and validating the interrupted work;
   5. less of the next window is available for actual forward progress.

   This is especially problematic because the agent itself does not reliably know how much of the 5-hour allowance remains while it is working, so it cannot proactively decide to checkpoint at 10-20% remaining.

   Expected behavior would be one of these:

   • once a turn is accepted with available quota, allow that already-active turn to finish, while blocking any new turns after the quota is exhausted; or
   • when the quota boundary is reached, suspend the active turn in a durable state and allow it to resume after reset without requiring the agent to reconstruct the task from partial filesystem state; or
   • provide the active agent with a reliable remaining-quota signal early enough to stop safely, run tests, record a checkpoint, and finalize its current edits before enforcement.

   I am not asking for the 5-hour limit to be removed. The request is specifically that rate-limit enforcement should not abruptly terminate already-accepted work in a way that causes extra recovery usage and leaves the workspace partially modified.

   👍React with 👍1Reacted by Hyunjun Kim