Document the July 29 “18% longer” Sol usage metric and provide reproducible quota attribution

Summary

On July 29, 2026, OpenAI publicly acknowledged that GPT-5.6 Sol had been consuming Codex limits faster than expected for some users. The update said that several improvements should make usage last around 18% longer during typical Sol use, while also stating that some users should see significantly larger improvements and that the long tail had been underestimated.

This issue is a source-backed synthesis and a request for a reproducible definition of that 18% metric. It does not claim that subscription allowances were silently reduced, that one bug caused exactly 18% extra token consumption, or that any community benchmark represents OpenAI's private billing ledger.

Primary official sources:

• Tibo's July 29 usage update
• OpenAI engineering post: How GPT-5.6 fuses frontier intelligence with frontier efficiency

What OpenAI officially confirmed

The July 29 update states that:

1. OpenAI had not reduced usage on any subscription plan.
2. Several improvements had landed, with an expected result of approximately 18% longer usage during typical Sol use.
3. Some users should already see significantly larger improvements.
4. Sol is more willing to work for longer, make more tool calls, and coordinate workflows across tools and subagents.
5. The same named reasoning effort is not directly comparable across generations: Sol High can use more tokens than GPT-5.5 High.
6. Programmatic Tool Calling / Code Mode had produced more responses per turn, more cached input tokens, and higher usage than expected.
7. The problem was particularly visible while waiting for tools and while running many web searches; OpenAI said both cases had been improved.
8. The distribution was uneven: the median user was relatively token-efficient, while power users running harder tasks could drain usage much faster. OpenAI explicitly said it had focused too much on averages and medians and missed the long tail.

That official wording matters: 18% is a typical-use estimate, not a maximum, and not a universal per-task token reduction.

What “18% longer” means mathematically

Assuming equal completed work, fixed allowance, and approximately linear consumption:

new duration = old duration × 1.18
new burn rate = old burn rate ÷ 1.18 ≈ old burn rate × 0.8475

Therefore:

• measured from the old burn rate, the reduction is approximately 15.25%;
• measured from the improved burn rate, the old burn rate is 18% higher.

Without OpenAI's benchmark definition, “18% longer” should not be rewritten as “18% fewer tokens,” “18% lower billing weight,” or “a single bug caused 18% overhead.”

Why repeated agent steps can amplify usage

The following is a conceptual diagram derived from the official explanation and the public Code Mode reports. It is not a claim about the exact private production architecture.

flowchart LR
    A[One user request] --> B[Model response]
    B --> C[Code Mode or tool call]
    C --> D{Work complete?}
    D -- No: wait, poll, search, or inspect --> E[Return control to model]
    E --> F[Reprocess conversation and cached prefix]
    F --> B
    D -- Yes --> G[Final response]

If independent operations are serialized, or if waiting repeatedly returns control to the model, one logical user turn can create many model requests. Even with a high prompt-cache ratio, each extra request can contribute cached-input usage and quota-weighted cost.

This mechanism is consistent with OpenAI's engineering post, which says that one user turn can contain many model/tool iterations and that costs inside the repeated region are multiplied.

Three different efficiency metrics should not be conflated

OpenAI's engineering post reports multiple improvements, but does not equate them:

| Published metric | Layer | What it measures | What it does not establish |
|---|---|---|---|
| Around 18% longer typical Sol usage | Codex product usage | Expected allowance duration after several improvements | Per-task token reduction or one bug's contribution |
| More than 15% token-generation efficiency | Speculative decoding / inference | More generation from expensive primary-model passes | Subscription quota reduction |
| 20% lower end-to-end serving cost | Kernels and inference stack | OpenAI's cost to serve models | User token accounting or quota weighting |

The engineering post also describes deferred tool discovery, a default 10,000-token tool-output cap, append-only model-visible history, deterministic tool ordering, and prompt caching. It describes these as compounding stack improvements, not as a changelog for one July 29 incident.

Public source-code evidence

1. Responses Lite disables top-level parallel tool calls

At the source snapshot referenced by #32503, the public request path contains:

parallel_tool_calls: prompt.parallel_tool_calls && !model_info.use_responses_lite,

Source: codex-rs/core/src/client.rs

Code Mode can still run nested tools concurrently through model-authored JavaScript such as Promise.all, but #32503 reports that the tested Sol trace used that mechanism in only 5 of 739 exec cells.

This proves the public tool paths differ. It does not by itself prove how much subscription usage the difference causes.

2. Buffered Code Mode yields

PR #34441 / commit 99efeef added an experimental code_mode_buffered_exec feature that changes the default Code Mode exec yield from 10 seconds to 30 seconds.

At merge time, the public feature default was disabled. The commit therefore proves the implementation exists, but does not prove when or for whom it was enabled in production.

3. Longer agent waits to avoid busy polling

PR #35594 / commit 8a1c941, merged July 27, changed the model-visible wait_agent schema to say:

Prefer longer waits (minutes) to avoid busy polling.

This is directly related to the waiting mechanism acknowledged in the official update. However, no public commit, PR, or issue currently identifies it as the complete source of the 18% estimate.

4. Prompt-cache and deferred-tool work

Other public changes align with the engineering post but should be treated as background infrastructure rather than confirmed July 29 fixes:

• Use session IDs for prompt-cache keys, #33035
• Token-based tool deferral, #18097
• Deferred tool exposure, #22489
• Deterministic MCP tool ordering, #2611

The latter changes predate the July 29 announcement, in some cases by many months.

Community measurements

These are useful public measurements, but they are not official OpenAI billing data.

Code Mode batching: #32503 and #35050

#32503 reports an observational long-session comparison in which Sol used nested Promise.all in approximately 0.7% of exec cells. The report explicitly notes context-window and reasoning-effort confounders.

#35050 adds small controlled A/B comparisons that held repository state, task, model, reasoning effort, and permissions constant while changing only explicit Code Mode batching guidance.

The issue author reported:

| Dataset | Model cycles | Raw tokens | Estimated weighted usage | Estimated same-credit capacity |
|---|---:|---:|---:|---:|
| Large repository | 52.1% fewer | 63.1% lower | 45.0% lower | 81.8% more |
| Personal project, High/XHigh | 54.7% fewer | 52.6% lower | 27.0% lower | 37.0% more |
| Personal project, Max, one pair | 80.4% fewer | 79.5% lower | 47.4% lower | 90.2% more |

Most of the reported raw-token reduction came from cached input rather than output, which is consistent with fewer outer model round trips.

Important limitations from the issue itself:

• the samples are small;
• the tasks are primarily read-heavy investigations;
• the Max result is one pair;
• tool-output truncation affected some runs and led to follow-up corrections;
• “weighted usage” is an API-equivalent estimate, not the private subscription ledger;
• the issue remains open, unassigned, and has no linked official PR as of July 30.

After the July 29 announcement, the author posted an eight-run follow-up. Within that author's A/B framework, the default condition without explicit batching guidance was reported as averaging:

• 23.32% more API-equivalent usage;
• 38.62% more total tokens;
• 41.00% more cached input;
• 32.31% more response steps.

This is evidence that the tested workload still had a greater-than-18% batching gap. It is not a before/after measurement of OpenAI's complete rollout and therefore cannot directly validate or falsify the “typical use” estimate.

Wait/status polling: #35259

#35259 reports replay-corrected local telemetry from one weekly-reset-to-49%-usage window. The author attributed 19.8% of raw local token volume to turns whose only actions were wait_agent, list_agents, write_stdin, or generic wait calls.

pie showData
    title One community-reported raw-token window (#35259)
    "Wait/status-only turns" : 19.8
    "Other model turns" : 80.2

The issue carefully states that local raw tokens are not the same as subscription usage and that its credit number is a public-rate-card estimate, not OpenAI's billing ledger.

Evidence boundaries

The following remain unknown from public sources:

• the cohort, task mix, sample size, and observation window behind 18%;
• the definition of “typical use”;
• whether the metric is quota burn, API-equivalent cost, raw tokens, or an internal proxy;
• p50, p90, and p99 results;
• the separate contribution of waiting, web search, extra tool calls, subagents, cache behavior, and reasoning effort;
• which fixes were model changes, server-side prompts, harness changes, quota-weight changes, or client commits;
• the exact deployment time, rollout population, and minimum Codex App/CLI version;
• the mapping between public issues and OpenAI's internal incidents;
• production kernel, speculator, web-search, and orchestration diffs that are not in the public repository.

The July 29 global usage reset also means absolute quota percentages immediately before and after the announcement are not a valid before/after benchmark unless per-session deltas are isolated.

Requested outcome

Please make the 18% claim independently interpretable and future usage regressions diagnosable:

1. Define the metric

• What exactly does “usage lasts 18% longer” measure?
• What model, effort levels, surfaces, and task mix define “typical use”?
• Is the denominator raw tokens, API-equivalent cost, internal quota units, completed work, or wall-clock duration?

1. Publish distributional results

• Include at least p50, p90, and p99 or equivalent workload buckets.
• This is especially important because the official update says the long tail was missed.

1. Identify the effective rollout

• Provide the deployment date/time, minimum client version where applicable, and whether changes were server-side.
• Clarify which improvements applied to waiting, web search, Code Mode response count, and cache usage.

1. Expose reproducible quota attribution

• Per model request: model, effort, cached input, uncached input, output/reasoning, and charged quota units.
• Per user turn/session: number of model responses, tool/wait-only responses, compactions, subagent work, and quota delta.
• Account-wide attribution across clients, as requested in #28985.

1. Add regression coverage for repeated work

• Independent Code Mode calls should be batched or the model should receive explicit concurrency guidance.
• Waiting on tools, processes, and subagents should avoid repeated full model sampling when no meaningful state changed.
• Web-search-heavy tasks should be included in the same efficiency suite.

Suggested reproducible benchmark

A public or internal validation can control:

• frozen repository commit;
• identical task prompt and expected coverage;
• fresh sessions with equal initial context;
• same model, effort, permissions, MCP/plugin set, and client version;
• alternating run order;
• several task classes: read-heavy investigation, implementation, long process wait, subagent coordination, and web-search-heavy research.

Report separately:

• outer model-response count;
• nested tool-call count and concurrency;
• cached input, uncached input, output, and reasoning tokens;
• wait/status-only responses;
• compactions and subagent sessions;
• completed-task quality;
• actual quota delta, if OpenAI can expose it.

For local JSONL analysis, copied parent-history prefixes in child rollouts and unchanged cumulative token snapshots must be excluded. Otherwise totals can be overstated.

Related issues

• #32503 — Sol rarely parallelizes Programmatic Tool Calling
• #35050 — controlled batching comparisons
• #35259 — repeated wait/status model turns
• #32309 — high-frequency Code Mode polling
• #35108 — nested wait_agent polling boundaries
• #34971 — repeated cached-context processing in long sessions
• #35226 — auto-compaction loop and usage impact
• #28985 — account-wide usage attribution

Closing

The official update and the community reports are not necessarily contradictory. An approximately 18% typical-use improvement can coexist with much larger long-tail improvements or regressions. The current problem is that the public metric is not reproducible: users cannot determine which workload bucket they are in, which changes reached them, or how local token events map to subscription quota.

Publishing the methodology and exposing quota-weighted per-turn attribution would turn future usage discussions from anecdotes into testable engineering reports.