On Saturday, August 29, Tibo Sottiaux of the Codex team said OpenAI had reset usage for paid Codex and ChatGPT Work users after fixing eight sources of unintended consumption. The post attached unusually specific numbers: usage dropped about 10% for heavy image users, one memory thread checked whether it could stop 15,000 times, goal failures consumed as much as 70% of a weekly allowance, and old Computer History behavior could take one fifth.
Those are two different kinds of statement. A source diff can prove that an image was missing from a budget or that a child inherited the wrong service tier. It cannot, by itself, prove how many accounts encountered the bug, what the billing system charged, or whether every user received a reset. We treated the announcement as twelve checkable claims—the eight fixes plus the reset, the 10–50% overall estimate, regression paging and a promised usage view—and looked for the closest public artifact for each.
The result is more substantial than a trust-us changelog and less complete than a public incident report. Five fixes leave close code fingerprints. Three point into components absent from the open repository. The four surrounding promises remain backend or future-product claims. Here is the proof, the limit and the most useful question for every one.
1. Compaction: the missing image budget is in the diff
Verdict: mechanism verified; impact private. The closest match is almost word for word. Codex commit “Budget retained images during remote compaction” says the retained-message budget counted text but not images, allowing an image-heavy history to retain more context than the budget represented. The new history builder passes an image budget into retained-message truncation; the loop then charges image content and refuses to backfill older messages when a boundary image does not fit.
The regression is better than its title: it uses an eight-image fixture—seven images initially and an eighth between cycles—and runs the history through two compaction cycles, comparing enabled, disabled and then-current default behavior. A later commit enabled the image budget by default, and the change appeared in the 0.150.1 hotfix. An unconfirmed user report of 224 compactions and 92 retained images supplies a plausible field symptom.
What the repository does not contain is the reported roughly 10% reduction for heavy image users. The test manually requests compaction; it does not prove that a short follow-up cannot cross the automatic threshold again. The constructive question: what cohort, usage unit and before/after distribution produced 10%, and can the automatic-compaction suite assert enough post-compaction headroom for a short next turn?
2. Memory: the inherited Stop-hook loop is visible before and after
Verdict: mechanism verified; incidence and 15,000-check example private. Before the fix, the Stop dispatcher gave subagents special handling but let a memory-consolidation session fall through to the ordinary Stop target. When that Stop was blocked, the turn path could continue the model loop. That is unusually close corroboration of a background worker inheriting a hook that would not let it finish.
Commit “Scope stop hooks for memory consolidation” adds a memory-specific Stop target. Its selector excludes user, project, session and plugin lifecycle hooks while preserving managed policy and executor cleanup; a blocking or stopping managed-hook outcome becomes a terminal error instead of another unattended turn. The startup integration test installs a blocking user Stop hook and asserts that memory consolidation neither invokes it nor sends the ordinary notification.
The public code does not define “affected fewer than 1%” or reveal what was counted 15,000 times. The constructive question: were those hook invocations, stop attempts or model turns, over what window? A privacy-safe counter at the memory worker's Stop evaluation could page at a team-defined bound; a focused regression can assert one terminal outcome for a blocking managed hook and bound request and hook counts, not only the final state.
3. Goals: execution-host loops now have a guard; the completed-goal path is not publicly reproduced
Verdict: strong proof for execution-host failures and terminal turn errors; partial for arbitrary broken tools and post-completion continuation. The newest fix is explicit: “Block goals after repeated execution host failures”. Accounting now counts default-namespace exec failures only when the handler ran, resets on any successful tool and trips after three qualifying failure turns. It does not count every failed script, pre-handler failure, blocked call, MCP call or other tool. The app-server test points Codex at an unavailable execution host, observes three failure turns and three follow-up responses, then asserts a blocked goal and exactly six model requests. At the audited snapshot this commit was merged to main but was not contained in a public release tag.
This sits on top of an earlier change that made goals stop auto-continuing after terminal turn failures, including permanent HTTP errors. Together, the source supports two likely loop classes—unavailable exec hosts and terminal turn errors—but not a general retry ceiling for failing scripts, MCP calls or other tools. Current main clears current-turn accounting after a complete update, and the idle continuation path re-reads persisted state and returns unless the goal is active. That shows the intended guard, but we found no public historical fix or reproduction for a persisted Complete goal that nevertheless scheduled a later automatic turn. Nor is the stated 15–70% weekly-allowance loss public.
The constructive question: did “finish” mean persisted Complete, a model's prose claim, a verifier result or another stop condition? The missing end-to-end case should mark the goal complete, allow its final answer, wait for idle and assert zero later goal-triggered turns or tools.
4. Automations: the deployed custom-schedule fix is not in public main
Verdict: no merged artifact tied to the production fix; related prototype code identifies the likely controls. OpenAI's automation documentation says advanced custom schedules can be expressed as RFC 5545 recurrence rules and that tasks run in the background. The only schedule-shaped API we found at public main commit 63d2138 is remote plugin scheduled-task template metadata with hourly, daily, weekday and weekly labels. That snapshot has no automation-runtime RRULE occurrence, lease or next-run implementation.
A public but unmerged prototype commit, “Add heartbeat cooldown defer,” parses a limited recurrence subset, computes next runs and defers a heartbeat from the later of its last run or thread activity; its test prevents immediate second-worker reclaim. It predates the announcement, is not an ancestor of main and does not prove the deployed custom-schedule fix. Public issues show adjacent trouble—a local schedule whose next run appeared in UTC, for example—but not the reported over-frequency repair. The missing evidence must come from the closed scheduling layer that owned the affected task type; public evidence does not identify whether that was web, desktop-local or shared backend.
The constructive question: which scheduling layer and recurrence shapes were affected—INTERVAL, multiple BY* fields, daylight-saving transitions, retry overlap or expired leases? For time-based RRULE tasks, a proposed durable invariant is one successful claim per (task_id, scheduled_occurrence_at), with an alert when actual executions exceed expected occurrences in a window; event-triggered tasks need their own coalescing rule.
5. Subagents: two commits map to the two halves of the claim
Verdict: direct public fixes, with one enforcement caveat. Commit “Require explicit requests for spawn model overrides” changes the exposed subagent contract from permitting a “clear task-specific reason” to allowing a different model only when the user explicitly asks. That closely matches smaller orchestrators selecting more capable helpers without permission.
The Fast-mode half has a harder runtime fix. Commit “Make subagents follow the root service tier” gives the agent tree root-owned tier state, copies that tier on spawn and tests live changes, reloads and remote compaction. The public test matrix covers supported and unsupported child models rather than merely changing instructions.
The caveat is important: explicit model choice is enforced in the tool description, while the handler still accepts a model argument. The commit does not name Luna or publish frequency and cost data. The constructive question: is there also a managed runtime check that an override came from explicit user intent? An evaluation matrix should run under the smaller model and require every child model to equal its parent unless the fixture contains override language; telemetry can record parent model, child model and an authorization reason without recording the prompt.
6. Computer History: public architecture, private deduplication
Verdict: related architecture and field evidence; no public fix or one-fifth measurement. OpenAI's official Computer History documentation says the rebuilt system periodically starts ephemeral Codex sessions to summarize an event stream, stores the result under its Skysight memory extension and uses tokens. Public Codex exposes a default-off Chronicle sidecar flag and downstream memory compatibility—not the production window scheduler or summarizer.
A user investigation in issue #37983 reported 11,848 ten-minute summary starts over fourteen days and quoted a legacy rolling window refreshed every minute. That makes overlapping source windows plausible, but it does not prove duplicate billing or linkage to OpenAI's incident. Another report, #40386, identifies the present boundary as Skysight event segments, a bundled codex_chronicle helper and generated memory resources.
If the defect was duplicate scheduling, its likely ownership boundary is a durable event cursor or idempotent window claim in the Skysight/Computer History scheduler, plus dedupe in the summary writer. The constructive question: what cursor or window policy prevents the same activity interval from producing more billable summary work than intended, and can OpenAI publish a redacted regression with window bounds, source hashes, prior watermark, dedupe result and token count? None of that requires raw activity. Only anonymized production before/after telemetry can substantiate the reported one-fifth maximum.
7. Rolling task summaries: the closest public feature may be the wrong one
Verdict: exact worker and disablement not public; roughly 1% remains internal telemetry. Issue #41130 is the closest field report: its reporter says they traced hidden Luna sessions to a prompt that fills a compact, search-oriented thread description. That resembles a rolling summary worker, but it is user evidence, not source or fix proof.
There is also a separate public feature that must not be quietly substituted for the missing one. Commit “Generate automatic and manual conversation recaps” sets a three-turn and three-minute eligibility threshold, then schedules a temporary structured model thread; its one-request regression is public. At audit time, that commit was on main and 0.151 alpha tags rather than the 0.150.1 stable hotfix. It may be entirely different from the disabled worker in the announcement.
The constructive question: does “rolling task summaries” mean the desktop retrieval-description worker, TUI recaps or a separate backend service—and where is its production kill switch? The missing regression should complete ordinary turns under production defaults and assert zero requests categorized as rolling-task summaries or retrieval descriptions, while allowing separately eligible recap work; background usage should be labeled by trigger rather than mixed into the parent task.
8. MCP: the double encoding is direct; truncation-to-refetch is a chain
Verdict: direct proof for encoded-twice output and truncated instructions; related proof for cache loss and unnecessary server startup. Commit “Preserve MCP tool output as content items” replaces an unstructured result serialized as a JSON array inside text with typed content items. The conversion now distinguishes typed unstructured blocks from deliberately serialized structured content, and a wire-level test rejects the escaped array form. That is a precise public match for “some tool results could be encoded twice.”
The instruction half has its own receipts. One patch raised a 1,000-byte namespace-description ceiling; the next raised a 4 KiB aggregate tool-search ceiling to 512 KiB because metadata could be truncated before reaching the model. Later commits preserved namespace descriptions in the cache and prevented cache rereads from omitting tools or causing unnecessary server startup.
No single public trace proves that truncated instructions themselves caused repeated fetches. The constructive question: did “fetched again” mean another MCP tools/list, another tool search or another lazy server startup, and which cache patch closed that causal path? An end-to-end test should combine more than 4 KiB of multibyte instructions, a near-expiry catalog and repeated model steps, then assert a stable spec hash and one discovery fetch per catalog generation.
9. The paid-user reset: individual redemption is public; the bulk operation is not
Verdict: public account-scoped reset path; first-party bulk-reset claim. The app server authenticates the account, creates a backend client and fetches rate limits and reset-credit data. It also exposes an account-scoped reset-credit consume method whose backend response distinguishes reset, nothing to reset, no credit and already redeemed. That code can request and observe one account's redemption. It contains neither the announced bulk grant/reset operation nor a snapshot of the eligible-account ledger, so it cannot independently verify “all.”
The constructive question: how many accounts were eligible, how many reset mutations succeeded, when did propagation finish, and were any plan, region or account-state exceptions retried? A one-line completion record with aggregate counts and no identifiers would turn “all” into an auditable operational statement.
10. The 10–50% improvement: no denominator, no reproducible range
Verdict: internal analysis only. The commits make lower waste plausible, and several changes plainly reduce redundant context or requests. But no public dataset defines “go further.” It could mean completed tasks, model input tokens, weekly credits, wall time or a weighted quota unit. Nor does the announcement publish the cohort, date window, model mix, task mix or distribution behind the lower and upper bounds.
The constructive question: is 10–50% observed or modeled, which metric is in the denominator, and what are the median and tails after holding model and Fast-mode mix constant? A sanitized before/after chart per fix—with cohort size, p10, median, p90 and attribution method—would let users map the range to their own workload.
11. Regression prevention and paging: tests are public; paging configuration is not
Verdict: partially supported. The compaction, memory, goal, subagent and MCP changes all add targeted regressions, and some are genuine end-to-end tests. That is concrete architecture against recurrence. But the stronger promise—that teams will be paged regardless—depends on production counters, alert thresholds, routing and ownership that are not in the repository.
The constructive question: what invariant pages for each class? Useful examples are compaction-again-on-next-turn rate, Stop evaluations per memory worker, continuation admitted for a non-active goal, child/root tier mismatch, executions per scheduled occurrence, duplicate history-window claims and MCP wire bytes divided by logical bytes. Publishing names and thresholds, not internal dashboards or user data, would make the assurance testable.
12. Showing where usage goes: a thread estimate exists; richer attribution is unverified
Verdict: partial public implementation; promised attribution and rollout unverified. The account processor already maps backend thread-usage estimates, and commit “Show estimated thread usage in /status” renders a TUI view for eligible Business and Enterprise plans with estimated credits or dollars plus model, reasoning, speed and token groups. That is already a user-facing usage surface. It does not yet prove which other clients or plans receive the promised view, whether background work will be separated, which categories it will use, or when a broader rollout will land.
The constructive question: will the view distinguish foreground model work, compaction, memory, goals, automations, Computer History, summaries, subagents and MCP overhead—and reconcile those categories to the quota ledger? A usage view that omits the background categories named in this incident would answer the wrong question.
The useful standard is a small incident matrix
Public code gives this announcement real weight. It lets readers verify the shape of five fixes and trace the other three to adjacent public interfaces while showing why their production implementations cannot be audited from openai/codex. It also prevents a category error: a good regression proves intended behavior, not the claimed population effect.
OpenAI could close nearly every remaining gap with one privacy-safe table: component, first affected build, fixed build or server flag, affected-account denominator, before/after usage distribution, regression link, production invariant and alert threshold. For closed components, name the owning boundary and describe the test. For the numbers, define the unit. For the reset, publish aggregate completion. That would turn a detailed and constructive engineering update into a source-grounded incident record—and give users the clarification they actually need.