Codex 0.150 processes comparable ~32.8M-token high-reasoning workloads ~1.6–1.8x faster in wall-clock time, rapidly depleting Pro weekly quota

What issue are you seeing?

I am observing a large increase in Codex token throughput after moving from the 0.147 runtime series to 0.150, which materially reduces the wall-clock duration of my Pro weekly quota.

This is based on local Codex logs, not subjective impressions or the usage UI alone.

I compared long development workloads with:

• the same subscription class: ProLite
• the same reasoning level: high
• similar repository/development workflow characteristics
• almost exactly the same total token volume: ~32.8M tokens

Direct comparison:

Parameter	2026-08-10 — 0.147.0-alpha.6.5	2026-08-29 — 0.150.0-alpha.12.2
Plan	ProLite	ProLite
Reasoning	high	high
Total tokens	32.807M	32.754M
Model steps	250	219
Wall-clock time	71.3 min	40.5 min
Tokens/min	0.460M	0.809M
Steps/min	3.51	5.41
Tokens/model step	~131k	~150k
Visible weekly quota change	+3 pp	+4 pp

The two workloads differ by only ~0.16% in total token count:

32.807M vs 32.754M

but the newer runtime processes that workload in:

71.3 min → 40.5 min

which is approximately:

0.809 / 0.460 ≈ 1.76x

higher token throughput in wall-clock time for this direct comparison.

Using my broader stable early-August baseline of approximately ~0.50M tokens/min, the current ~0.81M tokens/min represents roughly a ~1.6x increase.

I use ~1.6x only as a rounded description of the scale of the problem, not as an exact universal coefficient.

The increase appears to come from both:

• higher model-step frequency
• more tokens processed per model step

Direct comparison:

steps/min:
3.51 → 5.41
≈ +54%

tokens/model step:
131k → 150k
≈ +14–15%

Combined:

~1.54 × ~1.14 ≈ ~1.76x

The practical impact is that my Pro weekly quota now lasts only around 2–3 intensive development days, followed by approximately 4–5 days waiting for the weekly reset.

I upgraded from Plus to Pro specifically to obtain continuity of development work throughout the week.

What steps can reproduce the bug?

This is not a single-command deterministic reproduction. It is observable by comparing long Codex development runs from local logs.

My reproduction methodology:

1. Use a Pro/ProLite subscription.
2. Run Codex with reasoning=high.
3. Perform a long repository development checkpoint involving typical agent work:
   • repository inspection
   • planning/reasoning
   • edits
   • tool calls
   • builds/tests
   • validation
   • git operations
4. Record from local Codex logs:
   • runtime/client version
   • total tokens
   • model-step count
   • wall-clock duration
   • visible weekly quota change
5. Calculate:
   • tokens/minute
   • model steps/minute
   • tokens/model step
6. Compare runs with similar total token volume and similar engineering workload.

Example measured runs:

Older runtime

0.147.0-alpha.6.5
reasoning=high

• 32.807M tokens
• 250 model steps
• 71.3 minutes
• ~0.460M tokens/min
• ~3.51 steps/min
• ~131k tokens/model step

Newer runtime

0.150.0-alpha.12.2
reasoning=high

• 32.754M tokens
• 219 model steps
• 40.5 minutes
• ~0.809M tokens/min
• ~5.41 steps/min
• ~150k tokens/model step

Despite nearly identical total token volume, the newer runtime processes the workload substantially faster in wall-clock time.

My broader early-August stable baseline was approximately:

• ~0.50M tokens/min
• ~3.88 model steps/min
• ~129k tokens/model step

Current observed values are approximately:

• ~0.81M tokens/min
• ~5.41 model steps/min
• ~150k tokens/model step

This independently gives approximately:

1.39 × 1.16 ≈ 1.61x

higher token throughput relative to that broader baseline.

What is the expected behavior?

I do not expect Codex to be artificially slowed down.

If a newer runtime can perform the same useful engineering work faster, that is desirable.

However, a major increase in internal token throughput should not cause the practical weekly capacity of a Pro subscription to collapse without a proportional increase in useful end-to-end task throughput.

For comparable workloads and the same reasoning=high, I would expect one of the following:

1. useful task-completion throughput to increase approximately in proportion to increased token throughput; or
2. subscription usage accounting to account for runtime efficiency changes so that a faster internal agent loop does not drastically reduce the usable number of development hours provided by the same weekly subscription.

I do not observe my real engineering checkpoints completing approximately 1.6–1.8x faster.

The desired outcome is therefore:

• investigate whether the newer runtime is performing substantially more internal/model/tool-loop work for comparable useful output;
• verify whether subscription metering behaves as intended with the increased runtime throughput;
• preserve a reasonable amount of usable weekly development capacity for Pro subscribers.

Additional information

Subscription quota observations

Across a larger set of my measurements, the approximate token volume per visible weekly quota percentage point appears broadly similar:

Earlier:
~8.14M tokens / 1 percentage point

Current:
~8.19M tokens / 1 percentage point

I do not consider an individual integer percentage change precise enough to infer the exact server-side metering formula, because the visible quota meter is coarse/rounded.

However, this suggests that the primary observed change may not simply be a large reduction in nominal token capacity.

Instead, the runtime appears to be consuming token workload much faster in real time.

Approximate intensive-work quota consumption:

Earlier:
~3.7 percentage points/hour

Current:
~5.9 percentage points/hour

This is approximately consistent with the observed ~1.6x increase in wall-clock token throughput.

At eight hours of comparable intensive work:

Earlier:
~30% of weekly quota

Current:
~47% of weekly quota

---

Important: I do not observe proportional task-completion speedup

This is the main practical concern.

The logs show substantially higher token throughput, but my real engineering checkpoints do not appear to finish 1.6–1.8x faster.

The same work still involves approximately similar amounts of:

• repository analysis
• planning
• editing
• builds
• tests
• PostgreSQL validation
• tool calls
• service restarts
• verification
• git operations

Therefore, in my observed workflow:

higher tokens/minute != proportional increase in completed useful work/minute

Some of the additional throughput may be going into:

• more frequent model/tool iterations
• larger model steps
• additional context rereads
• additional internal reasoning iterations
• different cache/context behavior
• other runtime-loop behavior

I cannot determine the exact cause from client-side logs alone.

---

User impact

I previously used Plus and upgraded to Pro specifically because Plus did not provide enough continuous weekly capacity for this kind of intensive repository-development workflow.

Pro initially solved that problem.

With the current consumption rate, I am effectively back to:

2–3 days of intensive development
+
4–5 days waiting for the weekly reset

This removes the primary practical reason I upgraded to Pro.

The nominal larger pool still exists, but the newer runtime consumes it much faster per wall-clock hour of active development.

---

What I am NOT claiming

I am not claiming that:

• the Pro weekly quota was definitively reduced by exactly 1.6x;
• the server-side metering formula definitely changed;
• every Codex workload now consumes exactly 1.6x more resources;
• the newer runtime is universally worse.

The directly measurable claim from my logs is narrower:

Comparable high-reasoning Codex development workloads are being processed with substantially higher token throughput in the 0.150 runtime series than in the earlier 0.147 series.

In my measurements, the scale is approximately ~1.6–1.8x depending on the baseline used.

Because subscription quota is finite, this materially reduces the number of wall-clock hours of intensive development available from the weekly Pro allowance.

---

Request to the Codex team

Could you please investigate whether changes between the 0.147 and 0.150 runtime series affected:

1. model steps per minute;
2. average tokens processed per model step;
3. context/cache behavior;
4. agent/tool-loop iteration frequency;
5. reasoning iteration behavior;
6. subscription usage accounting;
7. or any other runtime behavior that could explain this large increase in token throughput?

I can provide additional sanitized local-log measurements if useful.

Update — Controlled 5-vs-5 rollout telemetry comparison

I performed a larger comparison using my local Codex rollout telemetry to determine whether the recent increase in Pro quota consumption is reproducible across multiple sessions rather than being caused by one unusually expensive checkpoint.

The comparison uses two cohorts of real development sessions:

Stable Pro cohort

• 5 sessions from August 9–14, 2026
• Codex 0.147.0-alpha.6.5 / 0.148.0-alpha.9

Current cohort

• 5 sessions from August 28–29, 2026
• Codex 0.150.0-alpha.8 / 0.150.0-alpha.12.2

All selected sessions use:

• source = vscode
• plan_type = prolite
• reasoning_effort = high
• no Ultra mode
• no manually launched subagents

To reduce noise, I excluded sessions containing:

• quota reset/expiry inside the measured window,
• substantial idle periods,
• overlapping main VS Code sessions.

used_percent is an account-global value reported in whole percentage points, so quota-derived measurements are less precise than raw token and model-step telemetry. For that reason, I treat tokens/min and model steps/min as the strongest measurements and quota/hour as supporting evidence.

---

### 1. Source session data — stable Pro

Date	Codex CLI	Tokens	Duration	Tokens/min	Steps/min	Quota delta	Quota pp/hour	Cache
Aug 14	0.148.0-alpha.9	27.98M	50.7 min	0.552M	3.69	3 pp	3.55	97.82%
Aug 10	0.147.0-alpha.6.5	32.81M	71.3 min	0.460M	3.49	3 pp	2.52	98.09%
Aug 10	0.147.0-alpha.6.5	21.80M	51.2 min	0.426M	3.42	3 pp	3.52	97.89%
Aug 10	0.147.0-alpha.6.5	18.91M	30.8 min	0.615M	3.74	2 pp	3.90	98.44%
Aug 9	0.147.0-alpha.6.5	17.23M	33.9 min	0.508M	3.24	1 pp	1.77	98.32%

Stable cohort totals

• 118.73M tokens
• 237.9 minutes
• approximately 836 model steps
• 12 observed quota percentage points

Weighted rates:

• 0.499M tokens/min
• 3.515 model steps/min
• 3.027 quota pp/hour
• 9.894M tokens per quota percentage point
• 98.076% cached input

---

2. Source session data — current 0.150.x runtime

Date	Codex CLI	Tokens	Duration	Tokens/min	Steps/min	Quota delta	Quota pp/hour	Cache
Aug 28	0.150.0-alpha.8	33.21M	55.9 min	0.594M	4.01	4 pp	4.29	97.86%
Aug 29	0.150.0-alpha.12.2	32.75M	40.5 min	0.809M	5.39	4 pp	5.93	96.94%
Aug 28	0.150.0-alpha.8	30.37M	40.7 min	0.745M	5.25	3 pp	4.42	97.91%
Aug 28	0.150.0-alpha.8	23.47M	48.1 min	0.488M	3.70	3 pp	3.75	98.22%
Aug 29	0.150.0-alpha.12.2	22.64M	30.0 min	0.754M	5.26	3 pp	5.99	97.95%

Current cohort totals

• 142.44M tokens
• 215.2 minutes
• approximately 992 model steps
• 17 observed quota percentage points

Weighted rates:

• 0.662M tokens/min
• 4.610 model steps/min
• 4.740 quota pp/hour
• 8.378M tokens per quota percentage point
• 97.731% cached input

---

3. Cohort-level comparison

Metric	Stable Pro 0.147/0.148	Current 0.150.x	Change
Weighted token throughput	0.499M/min	0.662M/min	+32.6%
Weighted model-step frequency	3.515/min	4.610/min	+31.1%
Approx. weighted tokens/model step	~142K	~144K	~+1%
Observed quota burn	3.027 pp/hour	4.740 pp/hour	+56.6%
Tokens per quota percentage point	9.894M	8.378M	−15.3%
Weighted cache ratio	98.076%	97.731%	−0.35 pp

The most important part of this result is that average token volume per model step is almost unchanged.

The current runtime is not simply making individual requests dramatically larger.

Instead, the dominant measurable difference is the frequency of model steps:

3.515 → 4.610 model steps/minute

This is a 31.1% increase.

Because each step carries approximately the same amount of context, that directly produces approximately 32.6% higher token throughput per minute:

0.499M → 0.662M tokens/minute

Cache behavior is also effectively unchanged:

98.08% → 97.73%

so the increase cannot reasonably be explained by a major cache failure.

---

4. Direct workload-matched comparison A — almost identical 32.8M-token workloads

This is the strongest directly matched pair in the dataset.

Metric	Stable — Aug 10	Current — Aug 29	Change
Codex CLI	0.147.0-alpha.6.5	0.150.0-alpha.12.2
Plan	prolite	prolite	identical
Reasoning	high	high	identical
Total tokens	32.81M	32.75M	−0.2%
Duration	71.3 min	40.5 min	−43.2%
Tokens/min	0.460M	0.809M	+75.9%
Model steps/min	3.49	5.39	+54.4%
Observed quota delta	3 pp	4 pp
Observed quota pp/hour	2.52	5.93
Cache	98.09%	96.94%	−1.15 pp

The total token workload differs by less than 0.2%.

The older runtime processed approximately:

32.81M tokens in 71.3 minutes

while the current runtime processed:

32.75M tokens in 40.5 minutes

Essentially the same amount of token work was therefore consumed at approximately 76% higher token throughput per wall-clock minute.

Both sessions used reasoning_effort=high.

---

5. Direct workload-matched comparison B — approximately 22M tokens

Metric	Stable — Aug 10	Current — Aug 29	Change
Codex CLI	0.147.0-alpha.6.5	0.150.0-alpha.12.2
Total tokens	21.80M	22.64M	+3.9%
Duration	51.2 min	30.0 min	−41.4%
Tokens/min	0.426M	0.754M	+77.0%
Model steps/min	3.42	5.26	+53.8%
Observed quota delta	3 pp	3 pp	identical
Observed quota pp/hour	3.52	5.99	+70.2%
Cache	97.89%	97.95%	essentially identical

This pair is useful because:

• total token volume differs by less than 4%,
• cache ratio is almost identical,
• the displayed quota delta is exactly 3 pp in both sessions.

Despite those similarities, the current runtime consumes the workload in approximately:

30 minutes instead of 51 minutes.

---

6. Direct workload-matched comparison C — approximately 28–30M tokens

Metric	Stable — Aug 14	Current — Aug 28	Change
Codex CLI	0.148.0-alpha.9	0.150.0-alpha.8
Total tokens	27.98M	30.37M	+8.5%
Duration	50.7 min	40.7 min	−19.7%
Tokens/min	0.552M	0.745M	+35.0%
Model steps/min	3.69	5.25	+42.3%
Observed quota delta	3 pp	3 pp	identical
Observed quota pp/hour	3.55	4.42	+24.5%
Cache	97.82%	97.91%	essentially identical

Again, cache behavior is almost unchanged while model-step frequency is substantially higher.

---

7. What appears to have changed

The larger sample suggests that the regression is not primarily caused by:

• a different Pro entitlement,
• switching from high to a higher reasoning mode,
• Ultra mode,
• manually launched subagents,
• dramatically larger individual model requests,
• or a major loss of cache efficiency.

The dominant measurable runtime change is:

approximately 31% more model steps per minute.

The weighted token volume per model step remains almost the same:

~142K → ~144K

while model-step frequency increases:

3.515 → 4.610 steps/min

That produces:

0.499M → 0.662M tokens/min

or approximately:

+32.6% token throughput per wall-clock minute.

This suggests that the current 0.150.x runtime is running a more aggressive agent/reason/tool continuation loop.

---

8. Weekly quota impact

The account-level quota telemetry shows an even larger user-visible effect.

Observed weekly quota burn increased from:

3.027 percentage points/hour

to:

4.740 percentage points/hour

which is approximately:

+56.6% quota burn per wall-clock hour.

The observed raw token workload per quota percentage point also changed:

9.894M → 8.378M tokens/pp

or approximately:

−15.3%.

I do not claim that this proves the nominal Pro allowance itself was reduced by exactly 15.3%.

used_percent is:

• account-global,
• quantized to whole percentage points,
• not a precise per-request billing counter.

Therefore quota-derived values contain more uncertainty than raw token telemetry.

However, quota quantization cannot explain the independently measured:

• +31.1% model-step frequency
• +32.6% token throughput

and the direction of the quota/hour measurement is consistent with the practical behavior I am seeing as a subscriber.

---

9. Practical impact

My development workflow has not materially changed between the two comparison periods.

I use Codex for long-running software architecture and implementation checkpoints.

The selected sessions use:

reasoning_effort=high

I intentionally do not use Ultra for normal development because of its substantially higher resource consumption.

I also do not manually launch subagents.

During the earlier stable Pro period, even with intensive daily development work, I frequently reached the weekly reset with approximately:

20–50% of the weekly Pro allowance remaining.

With the current runtime behavior, I can consume nearly the entire weekly allowance in approximately:

2–3 days.

For example, during one normal real-world checkpoint on August 29, my displayed remaining weekly allowance fell from approximately:

13% → 9%

in about:

40 minutes

while using normal high reasoning.

This is why the current Pro experience operationally feels similar to my previous Plus experience.

The account is correctly identified as prolite.

The issue is the amount of useful wall-clock development time that can now be obtained from the Pro allowance.

---

10. Requested engineering investigation

I would ask the Codex team to compare runtime behavior between:

• 0.147.0-alpha.6.5
• 0.148.0-alpha.9

and:

• 0.150.0-alpha.8
• 0.150.0-alpha.12.2

with particular attention to:

1. Agent-loop scheduling and iteration frequency.
2. Tool → reasoning → tool continuation frequency.
3. Automatic continuation behavior.
4. Compaction timing and retained context.
5. System-managed orchestration.
6. Any change that could explain the approximately 31% increase in model steps/minute at the same reasoning_effort=high.
7. Whether the observed decline in tokens/quota-pp reflects an actual metering change or is mainly an artifact of whole-percentage account-level quota reporting.

If the increased execution rate is intentional rather than a regression, I believe Pro limits should be adjusted to compensate for the materially higher rate at which the current runtime consumes the allowance.

---

11. Methodology and limitations

The measurements were extracted from local Codex rollout JSONL telemetry.

Selection criteria:

• source=vscode
• plan_type=prolite
• reasoning_effort=high

Excluded from the clean comparison:

• sessions containing quota resets/expiry,
• sessions with substantial idle gaps,
• overlapping main VS Code sessions,
• Ultra workloads,
• manually launched subagents.

The comparison contains:

Stable cohort

• 5 sessions
• 118.73M tokens
• 237.9 minutes
• approximately 836 model steps

Current cohort

• 5 sessions
• 142.44M tokens
• 215.2 minutes
• approximately 992 model steps

Important limitation:

used_percent is a global account-level metric and is reported as whole percentage points.

Therefore:

• tokens/min and model steps/min are the strongest per-session measurements;
• quota/hour should primarily be interpreted at cohort level;
• individual 1 pp transitions should not be interpreted as exact billing measurements.

The underlying rollout JSONL files and selected-session dataset have been retained and can be provided in sanitized form if useful for engineering investigation.

---

12. Conclusion

Across 10 selected real-world Pro development sessions, the transition from Codex 0.147/0.148 to 0.150.x is associated with:

+31.1% model-step frequency

and:

+32.6% token throughput per minute

while average token volume per model step and cache efficiency remain almost unchanged.

At the same time, observed weekly-quota consumption per wall-clock hour increased from:

3.027 → 4.740 pp/hour

or:

+56.6%.

The direct workload-matched comparisons show the same behavior independently of the cohort aggregation.

The clearest example is:

Stable 0.147 / high

• 32.81M tokens
• 71.3 minutes

versus:

Current 0.150 / high

• 32.75M tokens
• 40.5 minutes

for essentially the same total token workload.

That is the usage-efficiency regression I would like the Codex engineering team to investigate.

I cancelled my Pro renewal because the practical amount of sustained development time I receive from the weekly allowance has deteriorated materially.

I would be willing to return to Pro if this regression is corrected, or if Pro quota is adjusted to compensate for the substantially higher runtime consumption rate.

Start by reviewing the local Codex telemetry for runtime versions 0.147–0.150, using the controlled five-versus-five session comparison described in the issue. Compare tokens/minute, model steps/minute, cache values, and quota changes while checking for differences in runtime-loop behavior and subscription accounting. Done means identifying whether the throughput change is real and whether it reflects runtime behavior, metering, or both.