Regression in v0.48.0: Standard/Fast cost split re-inflates deduplicated fork usage

[1328189205]

Summary

CodexBar 0.48.0 can preserve the correct canonical Codex token total for a day/model while the new Standard/Fast cost split re-inflates the same usage by summing physical per-file pricing rows, including copied fork/subagent prefixes.

This appears to be a report-layer regression related to, but distinct from, #2037 and #2108: canonical token ownership is already deduplicated, but the mode-split cost path bypasses that ownership when building the final report.

Environment

• CodexBar 0.48.0 (build 112)
• Codex CLI 0.147.0-alpha.1.2
• macOS 27.0
• Apple Silicon
• High-fanout Codex workload with forks/subagents
• Full 90-day catch-up completed:
  • historyCoverageIsEstablished = true
  • codexScanCatchUpPending = false
  • 2,590 / 2,590 files
  • about 10.5 GB scanned

Verified invariant violation

For one day/model (2026-08-06, gpt-5.6-sol):

canonical totalTokens:       461,400,373
cached standardTokens:    11,311,061,683
cached priorityTokens:        30,472,681
split token total:        11,341,534,364
split / canonical ratio:             24.6x

For a single day/model, standardTokens + priorityTokens should not exceed canonical totalTokens.

Observed cost before applying a local guardrail:

2026-08-06: $7,972.81
90-day total: $29,048.93

After constraining the split to the canonical owned total:

2026-08-06: $369.33
90-day total: $9,199.41

The corrected 90-day result also independently cross-checks against the canonical aggregate input/cached-input/output totals and published model rates (within about 0.06%).

These values are API-equivalent estimates, not a claim about an actual subscription bill.

Source-level cause

In CostUsageScanner+CacheHelpers.swift:

1. Canonical report tokens come from reportCache.days[day][model].
2. codexNanosByDayModel and codexIntByDayModel independently sum the cached mode-split maps across every physical cache.files.values entry.
3. Those per-file maps are derived from codexRows, which can retain copied parent rows for pricing/audit.
4. When a split is present, buildCodexReportFromCache prefers:

splitTotalCost = standardCost + priorityCost

over cachedBaseCost and canonical-token fallback pricing, without checking that the split token count is consistent with totalTokens.

As a result, the main token totals can be correct while the displayed Standard/Fast costs are multiplied by copied fork rows.

Relevant current-main file:

Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner+CacheHelpers.swift

Reproduction outline

1. Use Codex with a high-fanout parent task and multiple forks/subagents.
2. Complete a full native Codex history refresh:

codexbar cost --provider codex --days 90 --refresh --format json

3. In codex-v11.json, compare each canonical days[day][model] token total with the sum of per-file codexStandardTokens and codexPriorityTokens for the same day/model.
4. Build the report and compare the resulting Standard/Fast cost with the canonical day/model total.

No prompt text, responses, account identifiers, session IDs, filenames, or local paths are needed to reproduce the invariant failure.

Expected behavior

• Mode-split tokens and costs should use the same fork-family ownership/deduplication as canonical totals.
• For every day/model:

standardTokens + priorityTokens <= totalTokens

• If split ownership is inconsistent or ambiguous, the report should either:
  • fall back to canonical model pricing,
  • normalize the split to the canonical owned token total, or
  • mark the split estimate incomplete instead of displaying a precise inflated value.

Local guardrail tested

A local guardrail normalizes the Standard/Fast split only when its token sum exceeds canonical totalTokens, preserving the relative Standard/Fast pricing mix while scaling it back to canonical ownership.

Validation completed locally:

• make check passed
• 19 focused CostUsageScannerPriorityTests passed
• full 90-day cache rebuilt successfully
• repeated cached reads remained stable

I can provide the small patch and regression tests if that direction is useful.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 8, 2026, 9:44 PM ET / August 9, 2026, 01:44 UTC.

Summary
Keep open: current main still prices Standard/Fast splits from physical cached rows before the canonical day/model fallback, and the maintainer-owned repair PR explicitly targeting this issue remains open.

Reproducibility: yes. — the report path is source-reproducible: create a fork family whose physical pricing rows exceed the canonical day/model total, then compare the row-derived split against the report total. The supplied CLI refresh procedure provides a real-history confirmation path, though it was not run in this read-only review.

Regression provenance
Possible regression — suspected (reviewed change). No predecessor PR is attributed.

Next step
Do not queue another repair while the explicitly linked maintainer-owned implementation PR remains open.

Review details

Best possible solution:

Land a focused report-boundary guard that withholds an inconsistent Standard/Fast split and prices from canonical usage, with a fork fixture proving both valid and over-counted splits.

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

Yes — the report path is source-reproducible: create a fork family whose physical pricing rows exceed the canonical day/model total, then compare the row-derived split against the report total. The supplied CLI refresh procedure provides a real-history confirmation path, though it was not run in this read-only review.

Is this the best way to solve the issue?

Yes — rejecting an unreconciled row-derived split and falling back to canonical pricing is narrower and safer than trying to infer fork ownership again at report time; the open repair follows that boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Until a repair lands, high-fanout fork histories can show inflated Standard/Fast and total cost estimates even when the displayed canonical token total is correct.

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

Label changes

Label justifications:

• P2: The defect affects cost-estimate accuracy for fork-heavy Codex histories but does not impair core application availability or data integrity.
• impact:other: The concrete impact is materially inflated usage-cost reporting, which is not covered by the more specific owned impact categories.

Evidence reviewed

What I checked:

• Current report path remains vulnerable: Current main groups read-time pricing rows from every cached file, then prefers the resulting row cost over the canonical or authoritative fallback without reconciling row tokens to the canonical day/model total. (Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner+CacheHelpers.swift:1377, 6e4a753340bd)
• Canonical total is distinct from row-derived cost: The report obtains input, cached-input, and output from canonical daily model data, while the row-derived cost is selected first and the split fields are published from that same row breakdown. (Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner+CacheHelpers.swift:1398, 6e4a753340bd)
• Regression provenance: The affected read-time pricing path appears to date to the current-main commit titled “Fix Codex cost pricing race”, which changed this helper as part of pricing persisted usage at report-read time. (Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner+CacheHelpers.swift:1374, 0aafe2b80563)
• Focused coverage does not exercise this fork reconciliation: Existing priority-rate coverage verifies ordinary Standard/Fast pricing, but its fixture has no copied fork rows whose row-token sum exceeds the report’s canonical total. (Tests/CodexBarTests/CostUsageScannerPriorityTests.swift:8, 6e4a753340bd)
• Open implementation candidate: The provided issue timeline and PR context show that Fix inflated Codex Standard/Fast cost splits #2782 is an open, maintainer-authored repair that explicitly targets this issue and adds a fork fixture plus canonical-total validation.
• Release check: No local tag contains the current-main pricing-race commit; the latest release commit predates it, so neither the regression nor its proposed repair is established as shipped in a release. (0aafe2b80563)

Likely related people:

• Peter Steinberger: Authored the current-main read-time pricing change that touches the affected report helper and the maintainer-owned open repair. (role: recent area contributor; confidence: high; commits: 0aafe2b80563; files: Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner+CacheHelpers.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.