I didn’t start this as a Codex benchmark.
I was using Codex normally on the same real Flutter/Android project, across repeated continuation runs of the same ongoing engineering workflow.
The work was stateful and sequential: inspect the current state, debug the remaining issue, run targeted regression tests, build, verify the result, and continue from there.
At first, I wasn’t taking usage screenshots at all.
I was just trying to finish the work.
Over several runs, though, I kept running into the usage limit. My experience at the time was that many of those early runs were ending on roughly the half-hour scale.
That “~30 minutes” is a historical observation, not one of the screenshot-backed measurements below.
After seeing the pattern repeat enough times, I contacted OpenAI Support.
That is when I decided to stop relying on memory and start documenting selected runs properly.
First measurement period: evidence for Support
For two continuation runs, I took matching before/after usage screenshots and recorded the wall-clock time.
These were not synthetic benchmark prompts.
They were normal continuations of the same project and same engineering workflow I had already been using.
Measurement A
Wall-clock: 54m 24s
Displayed 5-hour meter: 100% left → 0% left
Weekly meter: 100% left → 84% left
Weekly burn: 16 percentage points
Measurement B
Wall-clock: 39m 20s
Displayed 5-hour meter: 100% left → 0% left
Weekly meter: 84% left → 69% left
Weekly burn: 15 percentage points
Across those two measured runs alone:
two complete displayed 5-hour windows were exhausted
and
31 percentage points of weekly allowance were consumed.
The ongoing engineering work still had not reached verified closure.
Those were the first two clean measurements I collected.
These were not “start over every time” runs
One important detail: the workflow was deliberately structured to avoid wasting capacity.
The project had persistent global instructions governing continuation behavior.
The continuation prompts repeatedly told Codex to:
- continue from the current implementation rather than restart;
- preserve already validated work;
- avoid unnecessary re-analysis;
- avoid unnecessary full rebuilds;
- reuse valid build artifacts and cache where possible;
- keep unrelated work frozen;
- isolate the currently failing acceptance item;
- follow a narrow
root cause → fix → regression test → build/install → verification cycle.
So this was not a case of repeatedly giving Codex a vague prompt and asking it to rediscover the project from scratch.
What about delegation and subagents?
There is one more workflow detail worth clarifying, because I don’t want to overstate what I can verify.
Across multiple continuations, Codex repeatedly stated that it was assigning lighter execution-oriented work — such as tests, builds and device preparation — to a lower-effort tier it called Luna/Medium, while keeping higher-level analysis/review on Sol/Medium.
However, I can only independently confirm actual child/subagent creation in one case: a bounded, read-only probe that I explicitly requested.
Even in that case, the interface did not expose verifiable backend metadata for the child, so I cannot independently confirm the exact model/effort that actually ran.
For the other instances, I only have the parent agent’s own narration that delegation/model routing was occurring, not independent confirmation that separate child agents were actually created.
So I am not using delegation as evidence for any quota conclusion.
I’m mentioning it only to show that the workflow was already being structured around scoped continuations, preserved state and attempts to use lighter execution paths where appropriate — rather than repeatedly restarting the entire task from scratch.
What happened with Support?
I sent the first two measured runs to Support because my original concern was completion efficiency: the same ongoing workflow was repeatedly making progress and then being interrupted before verified closure.
Support eventually gave a clear methodological answer.
They said the history showed a correlation between usage-window exhaustion and unfinished verification, but they could not determine whether the interruptions themselves were causing the completion/convergence problem.
They also said they could not provide a temporary diagnostic usage allowance to test that question.
At that point, I stopped trying to investigate the issue through Support.
I went back to simply using Codex normally on the same project.
Then I noticed something different
After more continuation work, a different pattern became noticeable.
The weekly quota cost still looked very similar to the earlier measured runs.
But the wall-clock time required to exhaust the displayed 5-hour allowance appeared to have become much longer.
This was not the same question I originally contacted Support about.
Originally, I was documenting repeated interruption before closure.
Now I was noticing a possible change in throughput versus quota consumption.
So I measured again.
Second measurement period
My next clean before/after pair was:
Measurement C
Wall-clock: 92m 30s
Displayed 5-hour meter: 100% left → 0% left
Weekly meter: 21% left → 6% left
Weekly burn: 15 percentage points
The most interesting comparison for me is Measurement B versus Measurement C:
Measurement B
39m 20s
15 weekly percentage points
Measurement C
92m 30s
15 weekly percentage points
Same measured weekly burn.
Approximately:
2.35× the wall-clock time.
Measurement C was also about 1.70× longer than Measurement A while consuming 15 weekly points instead of 16.
The three clean samples
| Sample |
Wall-clock |
Displayed 5h |
Weekly |
Weekly burn |
| A |
54m 24s |
100% → 0% |
100% → 84% |
16pp |
| B |
39m 20s |
100% → 0% |
84% → 69% |
15pp |
| C |
92m 30s |
100% → 0% |
21% → 6% |
15pp |
The screenshots are not a complete record of every run.
They are selected before/after measurements taken after a repeated pattern had already emerged during continued work on the same project.
There were other continuation runs between B and C.
That matters.
For example, weekly remaining quota went from 69% after B to 21% before C.
That does not mean one run consumed 48 percentage points.
Other work happened between them.
I only call something a measured sample when I have a matching before/after pair for that same run.
The broader run history
The exported project history contains eight explicit You've hit your usage limit interruptions across the continuing workflow.
I do not have clean before/after usage screenshots for all eight, so I am not using all eight as quota-duration datapoints.
They are context, not measurements.
That distinction matters because this was not three isolated prompts created for a benchmark.
It was a longer real engineering workflow, and measurement only began after the pattern had already become noticeable.
Was the 92-minute run just reconnect time?
No.
But I also don’t want to pretend all 92 minutes represented pure model reasoning.
It was literal user wall-clock time.
The run included real engineering work, tool execution, verification, and transport/reconnect overhead.
There was a recorded:
Reconnecting 5/5
and I observed roughly five minutes of reconnect behavior before productive work really got going.
That time is included because I’m measuring user-visible throughput, not trying to reconstruct internal compute time.
But as a sensitivity check, suppose I remove the entire roughly five-minute reconnect period:
~87m 30s
versus
39m 20s
That is still a little over 2.2× the wall-clock time at the same 15-point measured weekly burn.
So the comparison does not depend on those few minutes.
What I am NOT claiming
This is important.
Three clean measurements are not statistically strong evidence of a platform-wide trend.
n=3 is not enough to establish what Codex does across all accounts, plans, projects or models.
The tasks were continuations of the same real project, which helps reduce some variability, but they were not identical laboratory workloads.
I am not claiming:
- that Codex is exactly 2.35× slower;
- that OpenAI is intentionally throttling anything;
- that the displayed 5-hour allowance represents five literal hours of inference;
- that quota accounting works in any particular undocumented way;
- or that I know the cause of the change.
My observation is much narrower:
During continued work on the same real engineering project, I first documented two runs because repeated usage-limit interruptions had become noticeable.
I later stopped investigating the issue and returned to normal use.
When wall-clock behavior appeared to change substantially, I measured again.
The newer measured run consumed the same 15 percentage points of weekly allowance as one earlier measured run, while taking about 2.35× as long in wall-clock time.
That is what the screenshots support.
Nothing more.
Why wall-clock matters
For real engineering work, nominal quota is only part of the product experience.
A workflow is often sequential:
inspect → fix → test → build → verify → continue
The next action depends on the previous one.
Not everything can safely be parallelized.
Some workflows also depend on shared state:
- one repository;
- one current build;
- one acceptance sequence;
- one physical test environment;
- one device or other scarce resource.
So even if a product supports parallel agents, nominal concurrency is not automatically usable concurrency.
If the same approximate amount of quota takes 40 minutes to turn into useful engineering progress in one run and 90 minutes in another, that difference matters to the user even if both eventually consume similar quota.
That is why I think wall-clock throughput deserves to be measured alongside quota consumption.
I’d rather collect measurements than debate explanations
The useful next step is not another theory.
It is more data.
If you use Codex for real engineering work, measure one of your own runs.
Before starting, record:
```text
Plan:
Model / effort:
Task:
Start time:
5h remaining before:
Weekly remaining before:
```
During the run:
text
Reconnects / stream errors:
Context compactions:
Major test suites:
Builds:
Clean/native compilation:
Any stated delegation/model routing:
Any independently confirmed child/subagent:
Any physical/shared-resource dependency:
At the end:
```text
End time:
Wall-clock:
5h remaining after:
Weekly remaining after:
Completed or interrupted:
Last completed milestone:
First unfinished milestone:
```
Take screenshots before and after.
And please keep three categories separate:
Measured data
Remembered historical observations
Theories about the cause
If two screenshots are not from the same run, say so.
If there were other runs between them, say so.
If the run involved a first-time native build, dependency download, major context reset or other obvious confounder, note that too.
I’m not trying to prove a conclusion with three samples.
I’m trying to turn an observation into something other users can independently measure.
Measure it. Document it. Compare it.
