Ultra-mode Terra and Sol sessions can overcount forked context

[iam-brain]

CodexBar appears to overstate usage for gpt-5.6-terra and especially gpt-5.6-sol when they run in Ultra mode.

The pricing is correct: models.dev reports the correct input, cached-input, output, and long-context rates for these models. The inflation seems to be coming from usage accounting. Ultra sessions can fork multiple agents and replay large portions of the parent context while interleaving cumulative token snapshots.

In one local Sol session, the raw log reached roughly 268M cumulative input tokens, while CodexBar attributed 3.29B input tokens and about $4,000 of standard cost. A single forked turn contributed more than 3B tokens across hundreds of rows. The cache marked the file as having divergent totals, which is consistent with multiple cumulative-token lineages being mixed together.

Potential fixes include:

• Keep cumulative-token baselines scoped per task/turn or fork lineage.
• Detect fork/replay boundaries and avoid treating replayed parent context as new usage.
• Prefer last_token_usage deltas only when cumulative totals are unavailable or trustworthy; otherwise use cumulative deltas per lineage.
• Add a guardrail that rejects implausibly large deltas relative to the reported per-turn usage.

The goal is to preserve genuine Ultra usage while preventing replayed fork context from being counted repeatedly. This is may be related to #1062 and #1138, but appears to be a distinct current failure involving interleaved Ultra-mode task counters.

[iam-brain]

Hey @steipete your agent seems caught in a silly loop aside from the main token accounting issue.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 12, 2026, 8:17 PM ET / July 13, 2026, 00:17 UTC.

Summary
Current main contains bounded Phase 1 containment, but the repository owner explicitly reopened this canonical issue because exact cross-file fork-family provenance and smaller-lineage accounting remain unresolved.

Reproducibility: yes. at the source and fixture level: the report provides a concrete interleaved-counter failure shape, and current-main fixtures cover representative fork families and missing-parent siblings. A complete live affected-setup reproduction is still absent.

Root-cause cluster
Relationship: canonical
Canonical: #2037
Summary: This issue is the owner-designated canonical tracker for the remaining exact cross-file Ultra fork-family accounting work after Phase 1 containment.

Members:

• partial_overlap: Contain Codex interleaved overcount and add fork provenance fixtures (#2037) #2082 - Merged Phase 1 contains intra-file inflation and adds provenance fixtures and design, but explicitly leaves exact cross-file accounting open.
• superseded: Contain Ultra interleaved token overcounting (#2037) #2066 - Its file-local containment work was incorporated into the broader merged Phase 1 pull request.
• partial_overlap: fix: revert unsafe Pi cumulative reconciliation #2059 - The merged revert removed an unsafe attempted reconciliation and preserved this issue as the canonical redesign tracker.
• superseded: fix: limit Pi cumulative Ultra token overcount #2043 - Its merged per-file lineage reconciliation was reverted because it did not solve cross-file duplication and introduced undercount paths.
• partial_overlap: Codex cost estimate overcounts when forked parent session logs are missing #1138 - It covers missing-parent fork overcounting, one important family shape now represented in provenance fixtures, but not the complete interleaved Ultra problem.
• 1 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
The bug is valid, but the owner-defined remainder is a scan-wide provenance and cache redesign with collision and pricing constraints, so it is not a safe autonomous one-PR repair candidate.

Review details

Best possible solution:

Implement a scan-wide fork-family provenance ledger with copy-stable event identity, cross-window family closure, collision-safe ownership and cache migration, while preserving distinct events and nonlinear pricing, then validate it against the sanitized corpus and redacted initial and cached repeat scans from an affected setup.

Do we have a high-confidence way to reproduce the issue?

Yes at the source and fixture level: the report provides a concrete interleaved-counter failure shape, and current-main fixtures cover representative fork families and missing-parent siblings. A complete live affected-setup reproduction is still absent.

Is this the best way to solve the issue?

Yes, the documented Phase 2 direction is the safest durable approach; another per-file or token-value heuristic would leave cross-file duplication or introduce undercounting. The implementation must include cache and nonlinear-pricing compatibility plus real-corpus proof.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A token-value-based or overly broad lineage identity can silently collapse distinct billable events that happen to have equal counters.
• The landed containment can intentionally omit smaller-lineage usage and cannot remove copied ancestor events across files, so affected Ultra totals remain estimates rather than exact accounting.
• The remaining design lacks redacted initial-scan and cached repeat-scan output from the reporter-shaped real setup, leaving cache migration and repeat-scan behavior unproven.

Codex review notes: model internal, reasoning high; reviewed against c852c135e10c.

Label changes

Label justifications:

• P2: The bug can substantially inflate local token and cost estimates, but current main contains the runaway intra-file multiplication and provider billing or core availability is unaffected.
• impact:other: Affected users can see materially incorrect local token and dollar estimates, which is meaningful usage-accounting impact outside the more specific owned impact classes.

Evidence reviewed

What I checked:

• Owner-confirmed remaining scope: The repository owner states that merged Phase 1 does not complete exact cross-file fork-family provenance or exact smaller-lineage accounting and reopened this issue for that Phase 2 work. (c852c135e10c)
• Phase 1 containment: Merged Contain Codex interleaved overcount and add fork provenance fixtures (#2037) #2082 adds file-local watermark/min-cap containment and sanitized fork-family fixtures while explicitly deferring the cross-file ledger and affected-setup repeat-scan proof. (Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner.swift, c852c135e10c)
• Unsafe narrow fix was reverted: The owner-authored revert explains that per-file reconciliation leaves copied ancestor events duplicated across forked files and can collapse distinct events or misprice nonlinear usage. (Sources/CodexBarCore/PiSessionCostScanner.swift, 2ebd59d4f736)
• Source-level reproduction: The report describes approximately 268M cumulative input tokens becoming 3.29B attributed tokens when forked lineages interleave, and Phase 1 added representative fork-family and missing-parent fixtures. (Tests/CodexBarTests/CostUsageScannerBreakdownTests.swift, c852c135e10c)
• Release boundary: Latest release v0.42.1 points to 3e05988 and predates the July 13, 2026 Phase 1 merge, so the bounded containment is current-main-only at this review point. (3e05988f5c5f)

Likely related people:

• Zihao-Qi: Authored the merged containment and provenance-fixture work that defines the boundary between landed Phase 1 and remaining Phase 2. (role: Phase 1 implementer and recent area contributor; confidence: high; commits: 1e3c3686cf6b, df637ecb1cf7, c852c135e10c; files: Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner.swift, Tests/CodexBarTests/CostUsageScannerBreakdownTests.swift, Tests/CodexBarTests/CostUsageCacheTests.swift)
• steipete: Authored the safety revert, documented why per-file reconciliation was insufficient, and explicitly reopened the issue with the remaining Phase 2 boundary. (role: repository owner and recent scanner decision owner; confidence: high; commits: 2ebd59d4f736, 41541c857c7e, ce461e168643; files: Sources/CodexBarCore/PiSessionCostScanner.swift, Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner.swift, docs/issue-2037-ultra-fork-overcount-spec.md)
• kiranmagic7: Authored the earlier lineage-based adjustment whose merge and subsequent revert exposed the cross-file duplication, distinct-event, and nonlinear-pricing constraints. (role: earlier reconciliation implementer; confidence: medium; commits: db93fc92abca; files: Sources/CodexBarCore/PiSessionCostScanner.swift, Tests/CodexBarTests/PiSessionCostScannerTests.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

#2037 remains unresolved after #2059 reverted the attempted fix. The reverted implementation reconciled rows within each session file, so copied ancestor events across forked files remained duplicated; it also introduced distinct-event and nonlinear-pricing undercounts. The known released baseline is restored, but a replacement still needs cross-file fork-family/event provenance and proof against a sanitized real fork corpus.