5-hour usage limit repeatedly interrupts long-running GPT-5.6 Sol agent tasks

I have extreme problems with this 5 hour window. We have multiple seats and split seats around projects. I now lose the 100% within a strangely fast time, I cannot let agents run and continue focussing on other projects in the meantime.

A quota-aware execution planner could address this more fundamentally than simply increasing or removing the 5-hour limit.

The main issue is that Codex currently appears to treat quota exhaustion as an external hard stop, even though an agent may be in the middle of a stateful workflow: a test may be running, a development server may be open, files may be partially modified, a subagent may still be active, or cleanup may still be required.

A better model would make the remaining quota part of task planning from the beginning.

Proposed behavior

At task start, Codex could estimate the approximate execution cost of the requested work against both the remaining 5-hour allowance and weekly allowance. The estimate does not need to be exact; even a coarse risk classification would be useful.

For example:

• Task size: High
• Remaining session budget: Medium
• Estimated probability of completing safely in this window: Low

Codex could then offer or automatically choose among several strategies:

1. Proceed normally when the task is likely to fit.
2. Split the goal into resumable phases when the full task is unlikely to fit.
3. Reduce the scope for the current session while preserving the user's overall goal.
4. Defer starting an atomic operation if there is not enough budget to complete it safely.

This would be especially valuable before expensive or stateful operations such as long integration tests, builds, browser automation, dev servers, migrations, or multi-agent work. Codex should not start such an operation if the remaining budget is unlikely to cover not only the operation itself, but also result interpretation, cleanup, and checkpointing.

Rolling re-estimation

The estimate should be updated during execution. Software tasks are unpredictable: a small-looking change can reveal many failing tests or dependencies. If actual consumption is higher than expected, Codex could switch from "continue development" to "stabilize, checkpoint, and suspend" before the limit is reached.

Conceptually:

RUNNING -> DRAINING -> CHECKPOINTING -> SUSPENDED

rather than an abrupt hard stop.

Safe suspension and resume

Before exhausting the short-term quota, Codex could:

• stop starting new expensive steps;
• finish or safely terminate the current test/process;
• persist stdout/stderr and test results;
• record relevant process/PID state where applicable;
• record changed files and repository state;
• create a durable execution checkpoint;
• store the next intended action.

When the quota window resets, Codex could resume from that checkpoint rather than requiring the user to reconstruct what happened or manually restart the workflow.

The key product principle is:

A quota boundary should be a schedulable execution boundary, not an unexpected failure boundary.

This does not require granting additional weekly compute. It would make Codex aware of the compute budget it already has and allow it to plan work around that budget. For long-horizon coding agents, that seems much more compatible with the product's execution model than abruptly stopping model calls while stateful processes and partially completed work may still exist.

@IIIWhiteWolfIII I strongly agree with this framing. Treating quota exhaustion as a schedulable execution boundary is much more robust than simply making the 5-hour window larger.

The part I would emphasize most is durable suspend/resume. If Codex sees that the remaining short-term quota is approaching a danger zone, it should proactively stop starting new expensive work, stabilize the current state, create a durable checkpoint, and then automatically resume the same goal after the quota resets — without requiring the user to come back and type “continue.”

That checkpoint should preserve more than chat history. It should capture the execution state needed to continue safely: current goal, completed/pending steps, important decisions/assumptions, changed files and git state, test/build results, relevant tool outputs, subagent status, and the next intended action. On resume, Codex should first verify that the workspace and external state have not materially changed, then continue automatically if the checkpoint is still valid.

One small caveat: I would not rely too heavily on the initial cost estimate itself. Software tasks have very heavy tail risk — a change that looks like 20 minutes can turn into hours after one failing integration test or an unexpected dependency chain. So estimation is useful as an early warning, but the more important mechanism is rolling re-estimation + draining + checkpointing + automatic resume.

In other words, even if the estimate is wrong, the system should still degrade gracefully as the quota boundary approaches.

The desired behavior, to me, is roughly:

RUNNING -> DRAINING -> CHECKPOINTING -> SUSPENDED -> AUTO-RESUME

That would make long-horizon agent execution much more durable not only across quota resets, but potentially across network interruptions, app restarts, context compaction, and other execution boundaries as well.

Proposal: Make Long-Running Codex Tasks Durable Across Quota Boundaries

I think the discussion above points to a broader product principle:

Plus can have less compute than Pro without having a fundamentally broken long-running agent experience.

The 5-hour limit may be necessary for capacity management, demand smoothing, or plan differentiation. That is understandable.

The problem is not simply that the limit exists.

The problem is that today the quota boundary can become a workflow failure boundary.

For long-running autonomous tasks, this creates an awkward loop:

Give Codex a long-running goal
        ↓
Codex works autonomously
        ↓
5-hour quota is exhausted
        ↓
Execution stops
        ↓
User waits for reset
        ↓
User returns and manually inspects state
        ↓
User prompts Codex to continue
        ↓
Codex reconstructs the task
        ↓
Work resumes

This undermines one of the main benefits of increasingly capable models such as GPT-5.6 Sol: the ability to give the agent a substantial goal and let it work with less supervision.

The user should not have to supervise quota recovery.

A better model

If the 5-hour quota must remain, Codex should treat it as a lifecycle boundary:

RUNNING
   ↓
DRAINING
   ↓
CHECKPOINTING
   ↓
SUSPENDED
   ↓
QUOTA RESET
   ↓
STATE VALIDATION
   ↓
AUTO-RESUME

As the short-term quota approaches exhaustion, Codex should stop starting new expensive operations, safely finish or terminate the current atomic step, and persist a durable checkpoint.

That checkpoint should include enough execution state to continue safely:

• the active goal;
• completed and pending steps;
• important decisions and assumptions;
• changed files and Git state;
• test/build results;
• relevant tool outputs;
• subagent status;
• outstanding cleanup;
• the next intended action.

When the quota resets, Codex should automatically validate the checkpoint against the current workspace and external state.

If nothing material has changed, execution should resume automatically.

The user should not need to return several hours later, inspect what happened, type “continue,” and hope the agent reconstructs the state correctly.

If the workspace has materially changed or the checkpoint is no longer safe, then Codex can ask for user intervention.

Plus vs. Pro

This does not require giving Plus users Pro-level compute.

Plan differentiation can remain entirely intact.

For example:

| Plus | Pro |
|---|---|
| Smaller short-term quota | Larger short-term quota |
| Smaller weekly quota | Larger weekly quota |
| More frequent suspension | Less frequent suspension |
| Durable checkpoint/resume | Durable checkpoint/resume |
| Same reliable agent lifecycle | Same reliable agent lifecycle |

In other words:

Different plans can provide different capacity without providing different execution reliability.

A Plus user running a long task may hit the quota earlier than a Pro user. That is reasonable.

But hitting the quota should mean:

“Your task has been safely paused and will continue when your included usage becomes available again.”

It should not mean:

“Your autonomous workflow has been interrupted. Please come back later, reconstruct the current state, and manually tell the agent to continue.”

For users who regularly need uninterrupted execution, that experience naturally creates a reason to upgrade to Pro: more continuous compute and fewer pauses.

But Plus should still provide a coherent long-running agent experience.

The underlying product principle

The most important distinction is:

Quota should limit throughput, not break workflow continuity.

Or more concretely:

A quota boundary should pause execution, not destroy execution continuity.

This would make Codex significantly more natural for long-running development tasks while preserving the existing economic and capacity constraints of each subscription tier.

Same problem here, i hope they don't keep this like antrophic does...