Issue with 5-Hour Usage Limit and Subagent Bug
The main agent was started while the 5-hour usage quota was still available. However, when the quota was close to being exhausted, the main agent launched a subagent, which then encountered an error.
<img width="756" height="648" alt="Image" src="https://github.com/user-attachments/assets/97d95077-5156-4fa0-aee9-edde99bedfcb" />
The subagent displayed a usage quota exhausted message and was forced to interrupt its task. However, the UI continued to show “subagent is working,” which made it look as if the subagent was still running.
<img width="500" height="181" alt="Image" src="https://github.com/user-attachments/assets/cc48ecbe-dfc2-4a54-aabb-54a87c47e8e6" />
The main agent did not properly terminate or close the subagent. Instead, it directly marked the current task as completed/finalized.
I think subagents should be allowed to complete their current work even after the 5-hour usage quota is exhausted, similar to the main agent. Once the subagent finishes, the main agent should properly terminate the subagent and then finalize the task.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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:
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:
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.