›_ Codex Issues
Codex Issues / #35463

Codex subagents drain full week quota overnight - usage counting broken

Open 💬 14 comments Opened Jul 26, 2026 by grapexy
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.145.0

What subscription do you have?

Pro 20x

Which model were you using?

gpt-5.6-sol

What platform is your computer?

MacOS 26.3.1 (Darwin 25.3.0, arm64)

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

My entire Pro plan usage quota was drained to 0% overnight on 2026-07-26, correlated specifically with heavy use of the MultiAgent V2 subagent feature (multi_agent_version: "v2"). This does not happen on days when I don't use subagents.

This happened across two independent projects/workspaces on the same machine that day. In both cases I instructed the top-level orchestrator agent to delegate work to subagents for actual task execution. I was using reasoning_effort: xhigh, not any higher/"ultra"-tier workflow preset. Despite that, both workspaces independently produced fork trees up to 4 levels deep (a subagent's subagent's subagent's subagent), which was not something I asked for. As detailed in problem N3 below, this turns out not to be a configuration oversight on my part — there is currently no way to bound nesting depth under MultiAgent V2 at all.

I audited my local ~/.codex/sessions rollout logs for that day in detail and found three distinct, compounding problems:

1. Every subagent fork replays its entire ancestor lineage's bookkeeping into its own log file, verbatim

When a subagent forks, its rollout JSONL is seeded with a burst of thousands of token_count events — a byte-for-byte copy of everything every ancestor in its fork chain had already logged — all written within 1-2 seconds and re-timestamped to the fork's own creation time.

Concretely, on 2026-07-26 I had 129 sessions (root thread originally created 2026-07-17, recursively forking subagents up to 4 levels deep). Representative examples from a single fork chain (root → A → B, C, D...):

  • Parent session: 23,743 total logged token_count events, of which 22,919 (96.5%) were themselves an inherited burst from its parent, leaving only 824 genuinely new events across its real ~4.7 hour working span.
  • Two children forked from that same parent: 23,135 total events (23,108 replayed / 27 real) and 23,468 total events (23,388 replayed / 80 real) respectively.

I compared the replayed burst in a child session against the parent's own historical records index-by-index: 100% of the (input_tokens, cached_input_tokens, output_tokens) triplets matched exactly, in the same order — the only difference was the timestamp. This is unambiguously a local copy/replay of already-recorded bookkeeping, not new model calls (23,000+ in ~2 seconds is not a plausible real request rate).

This inflates every downstream reporting tool that sums token_count events (e.g. ccusage — see ccusage/ccusage#950) by up to ~90x. My own reconstruction of "real" (non-replayed) usage for the day came to roughly 1.5% of what naive summation reports.

I want to be explicit that I cannot confirm from local logs alone whether this replayed data is inert with respect to my actual billed/metered usage, or whether it's also the direct cause of the real quota drain described below. If whatever system computes my account's real usage quota draws on this same per-session token telemetry — rather than exclusively on independently-verified real API request records — then this bug would not just be inflating third-party tools like ccusage, it would be inflating my actual billed usage too, once per fork in the tree. I'd like this checked directly rather than assumed away.

2. The real backend usage quota was actually drained

Regardless of how problem N1 is ultimately explained, my account's real weekly usage quota was fully consumed overnight. This is a genuine backend-side accounting problem tied to subagent spawning, not something I can attribute to a local display/logging bug alone.

From reading codex-rs/core/src/client.rs: a fresh subagent fork has no established websocket connection and no previous_response_id to chain from (prepare_websocket_request returns (None, false) when get_last_response() is empty), so every fork must open a brand-new connection and send a non-incremental first request. With a deep/wide fork tree (dozens of forks within a single hour, several clustered within the same minute), this produces a burst of new-connection establishment that looks structurally identical to the pattern that originally tripped the anti-abuse/rate-limiter bug in openai/codex#9748 (which was reported fixed server-side in February 2026, but scoped to MultiAgent V1's concurrent-spawn trigger — I could not find confirmation that the fix covers V2's tree-forking spawn pattern).

This may also be connected to the broader, still-open quota-accounting regression described in openai/codex#31668, where OpenAI's own team acknowledged anti-abuse/fraud-prevention systems overflagging ordinary usage — though that issue includes reports with no subagents involved at all, so it may be a distinct or overlapping cause rather than the same one.

3. MultiAgent V2 has no enforced nesting-depth limit at all

There is an existing config field intended to cap subagent nesting depth, agents.max_depth (agent_max_depth internally, in codex-rs/core/src/config/mod.rs). Its own doc comment says exactly why it didn't help me:

/// Maximum nesting depth for V1 agent threads. Ignored by V2.
pub agent_max_depth: i32,

I confirmed this is accurate — not just a stale comment — by reading both spawn handlers directly:

  • codex-rs/core/src/tools/handlers/multi_agents/spawn.rs (V1): computes child_depth via next_thread_spawn_depth(&session_source), reads turn.config.agent_max_depth, and calls exceeds_thread_spawn_depth_limit(child_depth, max_depth) — rejecting the spawn with "Agent depth limit reached. Solve the task yourself." if it's exceeded.
  • codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs (V2 — not something I opted into; see note below): computes child_depth via the exact same next_thread_spawn_depth call (line 60), but never calls exceeds_thread_spawn_depth_limit, or any other depth check, anywhere in the file.

Worth noting this isn't a niche configuration choice on my part: openai/codex#31097 documents that GPT-5.5 forces MultiAgentV2 even when it's explicitly disabled in config.toml and via command-line overrides. I was on gpt-5.6-sol, the same model line, and never selected V2 myself — so whatever is broken here isn't limited to users who deliberately opted into V2, it applies to anyone using this model family with subagents at all.

So there is currently no configuration that bounds fork-tree depth under MultiAgent V2 — not "the default is too permissive," but the enforcement path that exists for V1 has no V2 equivalent. Combined with problems N1 and N2 above, this is close to a worst case: unlimited recursion depth, where every level replays its full ancestor history into its own log (N1) and every level opens a new, non-incremental, potentially quota-draining connection (N2).

What steps can reproduce the bug?

  1. Start a long-lived Codex session on gpt-5.6-sol with reasoning_effort: xhigh (MultiAgent V2 does not need to be deliberately selected — per openai/codex#31097, this model line forces V2 regardless of config). Note that agents.max_depth has no effect under V2 regardless of whether it's set (see problem N3), and fork_turns defaults to "all" / full-history fork if left unset (per openai/codex#34061).
  2. Instruct the orchestrator agent to delegate pieces of work to subagents (a single level of delegation, as normally expected). Do not request or configure recursive/nested spawning.
  3. Observe that subagents themselves spawn further subagents unprompted, several levels deep, with no depth limit enforced and full ancestor history replayed at every level.
  4. Let this run for several hours, accumulating dozens of forks across the resulting tree, several minutes apart or clustered within the same minute.
  5. Observe: (a) local rollout logs balloon with replayed bookkeeping (confirmable by diffing a child's early token_count sequence against its parent's), and (b) the account's real weekly usage quota drains to 100% far faster than the actual new work performed would justify.

What is the expected behavior?

  • Forking a subagent should not replay/duplicate the parent's entire historical token_count/bookkeeping records into the child's own log — at minimum this should be a reference to the parent session rather than a duplicated copy, so downstream tools don't double/N-count it.
  • Real backend usage quota consumption should scale with actual new inference performed, not with the number and depth of forks in a session tree. Establishing a new fork's connection is a one-time, filtered-history event (per the #34061 investigation) and shouldn't be able to single-handedly exhaust a subscription's full usage window.
  • Subagents should not spawn further nested subagents unless that is explicitly configured/requested. A single requested level of delegation should not silently become a multi-level recursive fork tree. Concretely: agents.max_depth should be enforced by MultiAgent V2's spawn handler the same way it already is for V1, not silently ignored.
  • If a rate-limiter/anti-abuse system is what's actually draining the quota (as in #9748 and #31668), it should not be triggered by ordinary, sequential subagent spawning under MultiAgent V2, and should never zero out the visible/billed usage quota as a side effect of being tripped.

Additional information

  • Related issues that this report ties together: #9748, #22779, #31097, #34061, #33447, #31668, ccusage/ccusage#950.
  • I have local rollout JSONL evidence (fork chains, byte-for-byte replay comparison, timing analysis) available if useful for debugging — happy to share sanitized excerpts privately rather than post full logs here.

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34268

Powered by Codex Action

Sachinart · 1 month ago

It burnt my quota within 4 hours (SOL ULTRA Standard 100% to 0%). I don't know why and how.

There are some issues with the limits and usage probably!
Thanks & Regards

trevorlasn · 1 month ago

complete scam

SunFoxx · 21 days ago

Independent reproduction on 2026-08-06 (America/Montevideo).

Environment:

  • Codex Desktop on macOS, Pro plan
  • GPT-5.6 SOL and Terra subagents, mostly xhigh
  • One long-running parent goal lasting about 53 hours
  • 60 direct subagents

I observed the same inherited token_count replay described in this issue.

For the local day of 2026-08-06:

  • Raw token total obtained by summing child rollout events: 8,268,236,296
  • Token events written in replay bursts within two seconds of child creation: 5,833,581,676
  • Estimated fresh post-fork traffic after excluding those bursts: 2,434,654,620
  • Approximate inherited/replayed share of the raw total: 70.5%
  • 81 session files were touched that day
  • The active session directory was approximately 33 GB

A representative child recorded 3,721 token_count events during the same second immediately after creation. Its cumulative total jumped to 450,646,393 tokens in that burst, then reached only 453,340,154 after its actual work. The rate-limit snapshots also moved backwards during the replay burst, from a copied 64% snapshot to a copied 41% snapshot with a different reset state. This supports the conclusion that stale historical telemetry is being replayed, rather than those events representing real requests.

The account’s real weekly Codex meter nevertheless reached 80%, so this was not only a third-party reporting concern. Fresh work was genuinely expensive too: about 68% of the estimated post-replay traffic came from subagents, and approximately 97% of input tokens were cached.

The exposed spawn_agent contract defaults fork_turns to "all" when omitted. For a large parent, this creates a dangerous combination:

  1. Children inherit more context than their bounded task needs.
  2. Historical bookkeeping is duplicated into child rollouts.
  3. Local usage totals become unreliable.
  4. Cached but still chargeable context is repeatedly processed.
  5. Wide or recursive delegation can consume quota unexpectedly.

Suggested fixes:

  • Make fork_turns: "none" the default and require explicit opt-in for full-history inheritance.
  • Do not copy telemetry events such as token_count into child rollouts.
  • Store inherited history by reference or mark inherited events so usage tools can exclude them.
  • Display post-fork token deltas separately from inherited cumulative totals.
  • Enforce nesting-depth and active-child limits in MultiAgent V2.
  • Warn before spawning from a very large parent context.

I have retained the local session evidence and can provide redacted metadata or aggregation output if maintainers need it. I will not publish complete rollout files because they contain private conversation and tool data.

MamZer-b · 19 days ago

Independent reproduction on Windows Codex App.

Environment:

  • Codex App: 26.803.5235.0
  • Platform: Microsoft Windows NT 10.0.26200.0 x64
  • Root model: gpt-5.6-sol, ultra
  • max_concurrent_threads_per_session = 100
  • Feedback ID: 019f9b70-5b46-79b3-be43-cb885c22bf61

Observed:

  • The root initially spawned only 3 explorer agents.
  • Delegation then expanded recursively to 345 recorded subagents.
  • Maximum observed nesting depth: 22.
  • Approximately 50% of my Codex quota was consumed.
  • The Desktop panel displayed 339 agents running and 6 completed.
  • Local rollout inspection found:
  • 245 task_complete
  • 91 turn_aborted
  • 9 non-terminal/orphaned entries
  • All 345 persisted spawn edges were still marked open.
  • Live agent lookup generally reported only the root agent.
  • One supposedly absent agent later reappeared as pending_init.
  • No descendant activity was observed after the cascade stopped.

This independently reproduces the recursive quota-consumption issue at a much greater nesting depth. The stale Desktop lifecycle/UI state also matches #37426.

helloworldJL · 17 days ago

Independent macOS Desktop reproduction with a single causal chain connecting unbounded MultiAgent V2 recursion, system-wide OOM, and real backend weekly-usage depletion.

Environment

  • ChatGPT/Codex Desktop: 26.803.41515
  • Bundled Codex CLI: 0.147.0-alpha.6.5
  • macOS: 26.5.2 (25F84), Apple Silicon
  • Physical RAM: 48 GiB
  • Incident: 2026-08-11, Asia/Shanghai

Trigger and agent fan-out

The root task was ordinary local work and did not request recursive delegation. It directly spawned a bounded audit worker, but descendants recursively delegated again.

Read-only reconstruction from session metadata and app-server logs found:

  • approximately 483 descendant sessions
  • maximum agent-path depth: 14
  • 547 spawn_agent tool calls
  • 316 successful spawn sends to distinct receiver threads
  • at least 341 overlapping inter-agent threads at 17:31:22
  • 468 distinct spawn paths entering per-thread MCP initialization
  • 2,811 per-thread MCP service-init records

The Desktop log also recorded 397 unique browser-use sessions and 406 unique local socket listeners during the burst. Only 181 of those sessions had a disposal record before the app was forcibly terminated.

Direct macOS memory evidence

The 17:38 Jetsam report recorded the Codex resource coalition with:

  • 5,185 active process entries
  • 143.261 GiB aggregate physicalPages.internal
  • 155.523 GiB summed resident pages
  • main Codex process: 17.257 GiB internal
  • 4,315 Node + 428 Python + 428 node_repl children: 123.971 GiB internal combined
  • system free memory: 0.525 GiB
  • compressor: 18.582 GiB
  • vm-compressor-space-shortage

The entire Mac became unresponsive and required forcing applications to quit. After relaunch, the old coalition was gone, which argues against unrelated persistent orphan daemons as the primary cause.

Backend usage evidence

Service-side limit_id=codex weekly telemetry moved from used_percent=2 at 17:12:11 to used_percent=25 at 17:35:09. Every integer step was present in the accident window, so at least 23 percentage points of real weekly usage were consumed during the fan-out.

After globally deduplicating inherited/replayed telemetry by turn and token-usage payload, the accident window still contained:

  • 4,158 unique model responses across 448 turns
  • 385,820,350 raw processed tokens
  • 384,823,754 input tokens, of which 375,723,776 were cached
  • 996,596 output tokens
  • 10,096,574 minimum non-cached-input-plus-output tokens

The raw processed-token total is not presented as a billing equivalent; the direct quota evidence is the backend used_percent sequence.

Recovery/rehydration risk

After the force-quit, the affected root task was automatically restored and resumed writing. A later snapshot again showed about 22 repeated MCP/plugin helper generations and approximately 19.4 GiB RSS across the ChatGPT/Codex tree. Relaunch alone therefore does not reliably contain the abnormal agent tree.

Why this appears to be the same core defect

The current V2 spawn path computes child_depth but still does not perform the depth-limit rejection present in the V1 handler:

Current documentation exposes agents.max_concurrent_threads_per_session, but a hard tree-wide recursion-depth circuit breaker is not documented. A per-parent or per-session limit is insufficient if every descendant can open another independent allocation.

This reproduction connects the quota failure here with the macOS OOM and task-restoration families reported in #23749, #35994, #32942, and #33700.

Requested safeguards

  1. Enforce a hard V2 nesting-depth limit.
  2. Enforce one tree-wide live-descendant cap shared by the root and every descendant.
  3. Add spawn-rate, process-count, memory-pressure, and usage-anomaly circuit breakers.
  4. Interrupt the whole descendant tree when the root is stopped or an abnormal fan-out is detected.
  5. Do not automatically resume an abnormal tree after a crash/relaunch without explicit user confirmation.
  6. Provide a private diagnostic-upload path and review anomalous quota depletion caused by confirmed fan-out.

I retained the affected session ID, redacted Jetsam aggregates, process-tree snapshots, and sanitized log findings. I am not posting raw rollouts or full logs publicly because they contain local paths and conversation content, but they can be provided privately to OpenAI engineers.

helloworldJL · 17 days ago

Additional context from the postmortem: this installation had features.multi_agent_v2.max_concurrent_threads_per_session = 1000 in the user config. That value was introduced by a third-party LazyCodex/OMO migration guard, so it substantially amplified the incident compared with Codex's current source defaults. The same third-party guard preserves an existing explicit V2 cap, so I have now reduced it locally to 6 and installed a higher-precedence managed config with agents.max_concurrent_threads_per_session = 6, agents.max_depth = 1, and a no-recursive-delegation instruction for V2 subagents.

This local factor is important for reproduction and attribution, but the upstream safety gap remains: one root task was still able to recursively fan out to depth 14, hundreds of concurrent descendants, and large quota/resource consumption without a built-in hard depth/cost/circuit-breaker stop. A defensive product cap should prevent a plugin or user config from turning one mistaken delegation loop into a system-wide failure.

justanotherhuman · 12 days ago

Independent reproduction on macOS with GPT-5.6 Sol xhigh and real weekly quota exhaustion.

Environment / observed account impact:

  • ChatGPT Pro
  • macOS 26.5.2 arm64
  • Codex CLI 0.147.0
  • Model: GPT-5.6 Sol, reasoning xhigh
  • Weekly Codex allowance reached 0% after roughly 3 days of use, substantially faster than my historical Codex usage pattern.

Local rollout evidence from ~/.codex/sessions:

  • 111 active rollout JSONL files
  • 224.86 GiB total
  • codex doctor reported 63 subagent:thread_spawn rows
  • 48 session files were modified across Aug 13-15 (20 / 12 / 16 by day), the same period in which the weekly quota was exhausted
  • 19 of the 20 largest rollout files are from Aug 13-15; those 19 alone total roughly 111 GiB

The Aug 15 large rollouts are strikingly similar in size and historical structure, consistent with children/forks inheriting a very large ancestor history. Examples:

| Size | token_count occurrences | "type":"compacted" occurrences | inline image occurrences | task_complete occurrences | turn_aborted occurrences |
|---:|---:|---:|---:|---:|---:|
| 6.17 GiB | 18,684 | 238 | 5,801 | 439 | 48 |
| 6.14 GiB | 18,799 | 237 | 5,776 | 438 | 48 |
| 6.08 GiB | 18,639 | 235 | 5,726 | 438 | 48 |
| 6.08 GiB | 18,584 | 235 | 5,726 | 438 | 48 |
| 6.02 GiB | 18,433 | 233 | 5,676 | 438 | 48 |
| 6.02 GiB | 18,432 | 233 | 5,676 | 438 | 48 |
| 5.99 GiB | 18,423 | 232 | 5,651 | 438 | 48 |
| 5.99 GiB | 18,399 | 232 | 5,651 | 438 | 48 |
| 5.99 GiB | 18,308 | 232 | 5,651 | 437 | 48 |

One additional clue: in those files there are ~232-238 textual occurrences of "type":"compacted", but only 10 top-level compacted JSONL records in each when parsing records directly. That suggests most of those historical compaction markers live inside inherited/replayed payloads rather than representing fresh compactions in each child. The same files also contain ~5.6k-5.8k inline image occurrences and ~438 historical task_complete occurrences each.

I attempted a privacy-safe token-history prefix comparison, but my first parser did not match the current token_count payload shape and returned zero parsed records, so I am not claiming a measured common-prefix percentage yet.

Evidence boundary:

  • The local duplication/inherited-history pattern is directly observable.
  • I am not claiming that duplicated local telemetry records themselves were billed.
  • The real server-side weekly quota depletion is independently observed.
  • The likely concern is that large inherited contexts and repeated subagent/fork work may cause substantial real inference/cache usage, but OpenAI would need to correlate these session IDs with backend metering to establish causality.

Representative affected session IDs:

  • 01a007b0-47a9-7113-852c-178f5de17d4a
  • 01a007c6-d93a-7f51-94de-a5f59e72b4aa
  • 01a007aa-ae99-7e23-8be1-6d53f1accb1c
  • 01a007b4-6738-7480-801a-d23b1f90490f
  • 01a0077e-8f65-7cb3-9c6c-70d5efdf7dc2
  • 01a0078b-c0e5-72b3-baf7-9762855fc186

This looks closely related to the inherited-history / recursive subagent behavior described in this issue. I can provide additional privacy-safe structural statistics from the local rollouts if maintainers want a specific comparison.

shleder · 11 days ago

The recursively forked subagent/session tree in this report is useful for a different part of codex-rescue field validation: session discovery and conservative diagnosis across large inherited histories. It won’t fix quota accounting or MultiAgent V2 recursion; I’m specifically testing persisted-state handling without mutating the original rollouts.

If you still have the affected session tree locally, could you run:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

I’d like to know whether discovery remains sane with the deep fork tree and whether doctor avoids treating copied bookkeeping as evidence that an action executed. If diagnosis finds a genuinely unfinished action and recovery is needed, the optional path is salvage --latest --fork followed by verify <rescue-id>.

Please share only sanitized output, versions and exit codes; no raw rollout/SQLite files, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

zoomerland · 11 days ago

I can provide an additional privacy-safe data point for this issue.

Environment:

  • ChatGPT Pro 20x
  • Windows Codex Desktop 26.810.52044
  • The desktop app had updated within roughly the previous 1-2 days; I do not have the exact prior build number.
  • Work and Excel usage were negligible.
  • GPT-5.3-Codex-Spark was not used (its separate weekly limit remained at 100%).

Observed account impact:

  • Codex Usage showed 3% of the general weekly limit remaining.
  • Reset time: 2026-08-20 06:32 Europe/Moscow.
  • From the inferred start at 2026-08-13 06:32 through an observation around 2026-08-17 04:12, about 97% of the weekly allowance was consumed in roughly 3 days 22 hours.

Privacy-safe local structural findings for that same window:

  • 82 local thread records were updated; 65 were created in the window.
  • Of the 65 created records: 59 leaves, 1 intermediate, 1 root, and 4 standalone.
  • 8 parent-child edges were internal to the window; 52 children had a parent created before the window.
  • Maximum observed ancestry depth was 2.

This is not the same deep recursive tree reported in the issue: I did not observe depth 4+ or evidence sufficient to claim unbounded fan-out. It is nevertheless a similarly severe weekly-quota depletion with shallow observed topology.

The local metadata included Sol/high, Sol/max, Sol/xhigh, and a small number of Sol/ultra-labelled child records. I did not intentionally select Ultra for those child runs; two had a Sol/max parent. I am not claiming that the local tokens_used field equals billed usage, because both parent and child counters can be nonzero and naïve summation is unsafe.

I can provide further sanitized structural statistics if OpenAI engineers specify the exact fields needed. I will not post raw rollout files, prompts, local paths, session IDs, or credentials publicly.

zoomerland · 11 days ago

Additional workload context: on Friday, August 14, I was away for most of the day and did very little direct Codex work until the evening. The severe weekly-quota depletion therefore occurred during materially lower hands-on activity than my normal work pattern. This does not by itself prove background usage; it is a workload-control observation.

roncampos · 11 days ago

Independent reproduction on macOS Desktop with the stale-active-state symptom and possible quota concern.

Environment:

  • ChatGPT/Codex Desktop bundled Codex CLI: 0.148.0-alpha.9
  • macOS 15.6, Apple Silicon
  • root model: GPT-5.6 Sol
  • one long-lived local task

Observed:

  • The Subagents panel showed 415 Active while the live orchestration registry exposed only the root task plus completed agents.
  • Asking the parent to stop four visible long-running children returned not_found for each child ID.
  • A local process check did not show hundreds of corresponding worker processes.
  • I then set:

``toml
[agents]
enabled = false
max_concurrent_threads_per_session = 1
``

  • After fully quitting and reopening the desktop app, the panel got worse: 525 working / 7 done.
  • The current task is no longer spawning subagents, but the persisted activity panel is still restoring/increasing the stale working count.

This appears to overlap the recursive quota problem reported here and the stale lifecycle/UI state in #37426. The especially concerning part is that a full restart with agents disabled did not clear the active tree.

Expected:

  • Disabling agents and restarting should not restore completed/orphaned descendants as Working.
  • A stop request should close the entire descendant tree.
  • The panel should reconcile to the live orchestration registry instead of preserving hundreds of open edges.

I have screenshots showing 415 before restart and 525 after restart, plus sanitized app logs, if maintainers want them through a private diagnostic channel.

nos1609 · 6 days ago

Additional Linux reproduction with a flat, depth-1 V1 agent topology.

Environment:

  • Rocky Linux 10.2, x86_64
  • VS Code Web with the OpenAI extension 26.818.32112
  • Live Codex executable: 0.149.0
  • All affected children were direct children. No recursive agent tree was involved.

I found seven direct children created with fork_context: true. Each child rollout received a dense copied prefix immediately after creation:

  • one child copied 5,563 token records in 295 ms;
  • four children copied 8,138 token records in 314-523 ms;
  • one child copied 8,171 token records in 346 ms;
  • one child copied 8,236 token records in 297 ms.

For every affected child, I compared the copied prefix with the parent history index by index. The (input_tokens, cached_input_tokens, output_tokens) tuples matched the parent sequence exactly: 100% match, in the same order.

The copied cumulative baselines were between 850,391,164 and 1,260,303,143 tokens. As a result, the child rows in the state database reported about 861M-1.273B tokens_used each. After removing the copied prefix and unchanged cumulative snapshots, the actual new work was only 20-86 token events and approximately 1.38M-12.68M tokens per child.

Across the seven children, naive local accounting therefore included 8.334B tokens of inherited cumulative baselines. The cloned rollouts also copied historical task, compaction, and session metadata, so counts of those records are inflated for the same reason.

One metadata caveat may help diagnosis: the live executable reported 0.149.0, while affected child metadata reported 0.148.0. The child metadata is part of the cloned state and is not a reliable runtime-version source in this case.

The visible server-side weekly meter also increased by 39 percentage points in the same 24-hour observation window. However, local evidence cannot prove that the copied 8.334B records were billed. After replay correction, genuine processing across the five observed task families was approximately 1.915B tokens. I am reporting the copied history as a confirmed persistence/telemetry defect, while keeping its billing effect explicitly unproven.

Expected behavior:

  • A full-history fork must not inherit the parent's cumulative tokens_used as child usage.
  • Copied history should be referenced or explicitly marked as inherited.
  • Child-local usage must start from zero, or expose separate inherited and new-work counters.
  • Session and compaction metrics must not treat cloned historical records as new child activity.

No prompts, task identifiers, repository names, local paths, account data, or credentials are included.

shleder · 1 day ago

Before deleting anything to reclaim disk/quota: vetto rescue --json scan inventories actual per-session rollout bytes read-only, so you can see which sessions genuinely ballooned versus what the UI misreports. It never writes inside ~/.codex, so the inventory step cannot make things worse.