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

[FlapPearLabs]

Summary

The 5-hour usage window is increasingly incompatible with the kind of long-running autonomous work GPT-5.6 Sol is now capable of doing.

This is not just a complaint that the Plus allowance is too small. The problem is that a short rolling window can interrupt an already-running, multi-hour agent task in the middle of execution, even when the user intentionally gave Codex a long-horizon goal and expected it to continue autonomously.

I currently have one long-running task that has already been interrupted twice by the 5-hour limit.

That creates a product-level contradiction:

The model is capable of sustained autonomous work, but the quota system is structured in a way that repeatedly breaks sustained autonomous work.

Why this matters more with GPT-5.6 Sol

GPT-5.6 Sol is capable enough to take a substantial goal, plan multiple steps, use tools, inspect intermediate results, and continue working for a long time with relatively little supervision.

That makes long-running tasks one of the most valuable use cases for Codex / ChatGPT Work.

A typical workflow is now:

Give Codex a substantial goal
        ↓
Let the agent plan and execute autonomously
        ↓
Inspect files / run tests / use tools / iterate
        ↓
Continue for hours
        ↓
5-hour limit is reached
        ↓
Task stops in the middle
        ↓
Wait for reset
        ↓
Resume the same task
        ↓
5-hour limit interrupts it again

At that point the user is no longer supervising the work; the user is supervising the quota window.

That defeats much of the value of long-horizon agent execution.

Actual impact

In my current case, the same long-running task has been stopped by the 5-hour limit twice.

The cost is larger than simply waiting for the quota to reset:

• autonomous execution loses continuity;
• the user has to return and restart/resume the task;
• intermediate context and momentum become more fragile;
• long experiments, refactors, investigations, and multi-step builds are artificially split into quota-sized chunks;
• the user cannot confidently start a substantial goal and leave the agent to work;
• the product feels much more synchronous and supervised than the model itself requires.

This becomes especially frustrating when meaningful weekly quota is still available. The weekly allowance already limits total included compute; the 5-hour window additionally limits when that compute can be used and can terminate work at arbitrary execution boundaries.

This is distinct from simply asking for more quota

I am not asking for unlimited Codex or a larger weekly allowance.

The issue is execution semantics for long-running tasks.

A system designed around autonomous agents should have a reasonable way to handle an in-flight task when the short-term quota is reached.

Possible solutions

Any of the following would substantially improve the long-task experience:

1. Graceful completion for already-running tasks

If a task was started while quota was available, allow the current long-running task to reach a safe completion/checkpoint before enforcing the 5-hour limit.

New tasks could still be blocked once the limit is reached.

2. Automatic pause and resume

Persist the execution state and automatically resume the same task when the 5-hour window resets, without requiring the user to manually return and prompt it again.

3. Opt-in flexible usage

Allow Plus users to consume more of their remaining weekly quota during a long task, with an explicit warning that this may exhaust the weekly allowance earlier.

4. Long-task / goal-aware quota handling

When Codex is explicitly running a persistent goal or other long-horizon workflow, use quota boundaries as checkpoints rather than hard user-visible task failures.

Expected behavior

A user should be able to give GPT-5.6 Sol a legitimate multi-hour task and trust that Codex will either:

• finish it;
• reach a durable checkpoint and resume automatically; or
• clearly pause in a recoverable state without requiring repeated manual babysitting.

A rolling quota boundary should not repeatedly terminate the same goal as though the agent unexpectedly failed.

Related

This is related to #40524, which proposes giving Plus users more control over how their weekly quota is consumed.

The narrower point here is that the current 5-hour policy directly conflicts with long-running autonomous agent execution, regardless of the broader quota-allocation policy.

#34035 is also related to the broader request to remove the short-window restriction.

I think this should be evaluated using not only aggregate compute consumption, but also metrics such as:

• percentage of long-running tasks interrupted by quota boundaries;
• number of manual resumes required per goal;
• task completion rate before/after a quota interruption;
• time-to-completion for persistent goals;
• user abandonment after quota-triggered interruptions.

The model has become much better at long-horizon work. The quota system should not make that capability artificially unreliable.

[pfarrergraf]

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.

[IIIWhiteWolfIII]

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.

[FlapPearLabs]

@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.

[FlapPearLabs]

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.

[zzvictoor]

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

[gapview01]

I am building Toreva, and this is the exact missing-turn failure we are testing against.

To be precise: Toreva cannot change Codex quotas or automatically relaunch Codex after a reset. What is live now is an OAuth Streamable HTTP MCP goal store, so a restarted Codex run can re-read the durable goal, plan, and checkpoint instead of reconstructing them from chat. Codex supports this remote MCP connection in its CLI, IDE, and app.

Setup: https://toreva.com/connect-codex?utm_source=github&utm_medium=community&utm_campaign=first_real_goal&utm_content=openai_codex_40905

If you are willing, I would like to run your already-interrupted goal through it and compare manual resume turns and continuity. If it does not reduce the babysitting, that is a failed test—not proof.

[FlapPearLabs]

@gapview01 Thanks for the detailed reply. I took a closer look at Toreva, and I think the core idea is genuinely strong. Separating the durable goal/plan/checkpoint from the lifetime of a single Codex run is exactly the right direction for long-running agents, and MCP is a sensible way to expose that state across CLI/IDE/app sessions.

That said, I think there are two important gaps to solve before this becomes a really robust continuity layer.

First, goal + plan + checkpoint may not be enough for a reliable cold resume. For coding work, I would want the durable state to include things like the repo/commit SHA, dirty-tree state and changed files, completed/pending steps, important decisions, test/build results, relevant tool outputs/evidence, active process or subagent state where possible, blockers, cleanup obligations, and the exact next intended action. Ideally there should also be some notion of idempotency/safety so a restarted agent does not accidentally repeat a destructive step.

The benchmark I would care about most is something like a cold-resume success rate: start a completely fresh Codex session with no prior chat context, give it only the Toreva state, and measure whether it can correctly and safely continue the task. If that works consistently, Toreva becomes much more than persistent memory — it starts to look like an agent checkpoint / continuity layer.

Second, privacy and security are a real concern for a remote MCP store. A coding checkpoint can easily contain private repository names, file paths, diffs, internal URLs, product logic, test output, tool output, or even accidentally captured secrets. I would want very clear answers around exactly what is stored, encryption in transit/at rest, retention and deletion, tenant isolation, auditability/version history, OAuth scopes, and whether read/write permissions can be separated or tightly allowlisted. A local/self-hosted mode or client-side encryption option would also make this much easier to trust for sensitive projects.

I also understand and appreciate that you are not claiming Toreva can change Codex quotas or automatically relaunch Codex after reset. Even without that, solving the continuity/reconstruction problem is useful. The remaining gap for the full workflow is still the scheduler/trigger side: RUNNING -> CHECKPOINTING -> SUSPENDED -> RESET -> AUTO-RESUME.

Overall, I like the project and the direction a lot. My main question is: how much execution state does Toreva persist today beyond semantic goal/plan/checkpoint text, and have you tested true cold resume with a fresh agent and zero chat history?

[mralect]

I'm seeing the same issue consistently in the VS Code Codex extension on ChatGPT Plus.

My workload is a fairly complex existing codebase, and I use GPT-5.6 Sol with Medium reasoning for long-running implementation tasks.

My current Plus 5-hour allowance is often exhausted after only about 15–20 minutes of continuous Sol Medium agent work.

The main problem, however, is not just the size of the allowance.

Every time the 5-hour limit is reached during an active long-running task, the task is immediately interrupted in the middle of execution. Codex does not finish the current turn or reach a safe checkpoint. This can leave an implementation only partially completed and requires me to wait for the reset and manually resume the task.

This happens consistently, not occasionally.

This also appears to contradict the current OpenAI documentation, which says:

“If you reach your usage limits during an active turn, the agent will be able to continue working on that turn, subject to fair use limits.”

In my case, the active turn does not continue.

For long-running Sol tasks, I think at minimum an already-running turn should either:

• be allowed to reach a safe completion/checkpoint, or
• automatically pause and resume after the reset.

Hard-stopping an active implementation at an arbitrary quota boundary makes long-running agent workflows unreliable, even when substantial weekly quota is still available.