[Codex cost] Completed scan shows Spend unavailable with grouping-dependent totals

[Atopoz]

Summary

After a completed 30-day Codex history scan, Usage & Spend shows Spend unavailable for Codex even though token coverage is established and the CLI can still calculate non-null (but grouping-dependent) cost totals.

Restarting CodexBar does not recover the spend display. This appears to be a cost aggregation/completeness regression rather than an incomplete scan.

Environment

• CodexBar 0.49.6 (120)
• macOS 26.6.1 (25G76)
• Apple Silicon (arm64)
• Usage & Spend window: 30d
• Codex history size: 820 JSONL files, approximately 21.4 GB parsed

Reproduction

1. Enable local estimated Codex usage history.
2. Let the 30-day history refresh complete.
3. Confirm that the dashboard reports Coverage: 30 / 30.
4. Quit and reopen CodexBar.
5. Open Settings > Usage & Spend and select 30d.

Observed behavior

• The dashboard shows:
  • Tracked tokens: 11B
  • Codex: Spend unavailable
  • Model breakdown unavailable
• The state persists after restart and manual refresh.
• The SQLite scan index is complete: 820 / 820 file rows have scan_complete = 1.
• The ungrouped CLI result reports established history coverage and 28 daily rows, but 7 token-bearing daily rows have totalCost: null.
• Cost output changes depending on grouping, while token totals remain identical:

Query	Tokens	Cost
Ungrouped 30-day result	11,021,656,248	$4,770.22
--group-by project top-level result	11,021,656,248	$6,434.50
Sum of project rows	11,021,656,248	$7,001.18

The project-grouped result contains 116 project/day rows; only 3 have a null cost, while the ungrouped result has 7 null daily costs.

Expected behavior

• Cost availability and totals should not change solely because a grouping option is requested.
• When history coverage is established and request-level pricing evidence is available through one aggregation path, the ungrouped path should preserve the same authoritative cost evidence.
• If some rows genuinely cannot be priced safely, the UI should expose the incomplete/partial state without making the entire provider spend unavailable while another grouping path returns a total.

CLI evidence

Ungrouped:

$ CodexBarCLI cost --provider codex --days 30 --json-only
historyCoverageIsEstablished: true
last30DaysTokens: 11021656248
last30DaysCostUSD: 4770.2201546
daily rows: 28
token-bearing daily rows with totalCost == null: 7

Grouped:

$ CodexBarCLI cost --provider codex --days 30 --group-by project --json-only
historyCoverageIsEstablished: true
last30DaysTokens: 11021656248
last30DaysCostUSD: 6434.4966916
sum(project.totalTokens): 11021656248
sum(project.totalCost): 7001.1821246

Hypothesis

This may be an interaction between the request-level long-context tier preservation added after #2858 and the all-daily-rows-must-have-cost completeness policy added in 0.49.4. The project grouping path appears to retain pricing evidence that the ungrouped daily/model aggregation loses.

I have not attached the raw database or logs because they contain local paths, project names, and session identifiers. I can provide a minimized/redacted fixture or run a diagnostic build if useful.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 15, 2026, 2:32 AM ET / 06:32 UTC.

Summary
Current source confirms the dashboard intentionally withholds spend when any covered daily cost is missing, but it does not support the claimed grouping-dependent top-level calculation. Keep this open for a maintainer decision on whether a clearly labeled partial estimate should become a supported UI contract.

Reproducibility: no. high-confidence reproduction of the claimed grouping-dependent top-level total: current CLI source does not feed grouping into the fetch path. The unavailable dashboard state is source-reproducible whenever an in-window daily cost is nil.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should Usage & Spend retain verified-only totals when any daily cost is unpriced, or expose a clearly labeled partial Codex estimate?	Retain verified-only spend: Keep Spend unavailable for incomplete daily pricing and request a redacted fixture if the same snapshot produces differing global and project totals.

Why: Current tests encode verified-only display as deliberate behavior, while the report requests a different user-facing cost-completeness contract rather than a mechanical correction.

Next step
Maintainer direction is needed because the current verified-only dashboard behavior is intentional and the claimed grouping-dependent total is not reproduced by the CLI path.

Review details

Best possible solution:

Keep one authoritative pricing path; only add a prominently labeled partial estimate if maintainers intentionally define its semantics, completeness indicator, and reconciliation tests for global and project views.

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

No high-confidence reproduction of the claimed grouping-dependent top-level total: current CLI source does not feed grouping into the fetch path. The unavailable dashboard state is source-reproducible whenever an in-window daily cost is nil.

Is this the best way to solve the issue?

Unclear: a partial estimate is a viable UX direction, but it changes the current verified-only cost contract and needs maintainer approval plus a redacted fixture for any aggregation defect.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Without a minimized redacted cache fixture, the cause of the reported unpriced daily rows cannot be separated from the intentional verified-only presentation policy.
• Displaying the known-cost subtotal as a normal spend total could make an incomplete API-equivalent estimate appear complete.

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

Label changes

Label changes:

• add P3: This is a bounded cost-presentation policy request; current source does not establish an active incorrect grouping calculation.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a bounded cost-presentation policy request; current source does not establish an active incorrect grouping calculation.

Evidence reviewed

What I checked:

• CLI grouping boundary: For Codex, the parsed project grouping selects presentation after the same token snapshot has been loaded; it is not passed into the cost fetch or aggregation path, so it cannot change that command's top-level total. (Sources/CodexBarCLI/CLICostCommand.swift:49, 5a518372a69e)
• Verified-only dashboard contract: The dashboard rejects the provider total if any in-coverage daily entry has no valid cost or the daily sum differs from the aggregate; the current test explicitly expects full coverage with unpriced rows to remain unavailable. (Sources/CodexBar/SpendDashboardModel.swift:385, 5a518372a69e)
• Request-scoped pricing parity: Current regression coverage verifies that two short requests whose aggregate crosses the long-context threshold retain their request-level price, and that project and session totals equal the primary report. (Tests/CodexBarTests/CostUsageScannerForkSplitTests.swift:63, 5a518372a69e)
• Release-to-main comparison: The reported v0.49.6 release is an ancestor of current main, and the relevant CLI, dashboard, scanner, project-rollup, and regression-test files have no diff after that release; this is not already fixed on main. (Sources/CodexBarCLI/CLICostCommand.swift:49, 5a518372a69e)
• Feature-history routing: Available blame reaches the shallow v0.49.6 boundary and attributes the current CLI grouping and dashboard-completeness lines to steipete; deeper per-file history is unavailable locally. (Sources/CodexBar/SpendDashboardModel.swift:385, 62b5b5efa936)
• Maturity helper unavailable: The required shortlist helper could not locate qa/maturity-scores.yaml in this repository; no stable-maturity label is selected, independently supported by this being a requested policy feature.

Likely related people:

• steipete: Current CLI grouping and dashboard-completeness lines blame to the v0.49.6 shallow-history boundary authored by steipete. (role: source-history boundary author; confidence: medium; commits: 62b5b5efa936; files: Sources/CodexBarCLI/CLICostCommand.swift, Sources/CodexBar/SpendDashboardModel.swift, Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner+Projects.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.

[Atopoz]

Additional diagnosis

I reproduced two cache consistency failures behind the unavailable spend:

1. Late Codex priority-trace metadata can reclassify an already-cached request from standard to priority, but the in-window ownership maps are merged with the existing maps. Existing standard keys therefore survive instead of being replaced. buildCodexReportFromCache also skips this migration once the file already has otherwise-complete pricing metadata. The result is a modeOwnershipMismatchGroups failure and a nil daily cost.
2. Two completed, non-fork session files had persisted request rows whose token vectors no longer reconciled with their file-day aggregates. This left three additional days fail-closed even after repairing priority ownership.

Verified local recovery

On a private build based on the v0.49.6 tag, I:

• rebuilt standard/priority ownership from canonical in-window pricing rows;
• detected cached ownership mismatches even when the trace-key set itself had not changed;
• migrated those files before building the report;
• evicted only the two irreconcilable cache entries and reparsed their unchanged source JSONL files.

After the repair, the installed v0.49.6 (120) CLI independently reports:

• exact history coverage: 782 / 782 files;
• 0 daily rows with totalCost == nil;
• a non-null 30-day total;
• source bytes equal to parsed bytes for all 821 retained cache files;
• no SQLite foreign-key violations.

The number of unavailable days changed from 7 to 3 after the priority-ownership repair, then from 3 to 0 after selectively reparsing the two inconsistent files.

Proposed fix

For the priority path, replace in-window mode ownership rather than filling only missing keys, using canonical reconciled rows as the source of truth. Also schedule a metadata refresh when cached ownership disagrees with current trace evidence, even if the trace-key set did not change during that refresh.

For completed non-fork files, consider detecting a persisted request-row/day-aggregate reconciliation failure and scheduling a one-time full reparse of that file instead of leaving the affected days permanently unavailable.

[urda]

Independent confirmation on a second machine, plus a commit attribution that I do not see in the thread yet.

Same failure, different account

macOS, CodexBar built from f15f142a7 (0.50.1 development). Settings > Usage & Spend, 30d, USD group. Codex shows Spend unavailable, the model panel shows Model breakdown unavailable with no GPT rows, and the daily chart renders Claude only. Coverage reads 30 / 30.

The local scan is complete. All 211 rows in files have scan_complete = 1, and day_aggregates runs through the previous day.

The second cause that @Atopoz reports also occurs here. Three day/model groups fail per-file reconciliation between usage_rows and file_day_aggregates. All three are gpt-5.6-sol. Each comes from one completed non-fork session file, with no saw_divergent or saw_interleaved flag:

Day	canonical in / cached / out	row sum in / cached / out
2026-07-17	27,889,945 / 26,504,960 / 80,405	34,732,637 / 32,815,104 / 101,163
2026-07-23	11,063,790 / 10,220,032 / 88,509	13,387,965 / 12,468,224 / 108,312
2026-07-25	7,165,497 / 6,952,960 / 48,989	9,789,756 / 9,548,800 / 69,197

reconciledCodexPricingRows only trims a suffix. The excess here is not a suffix, so each group lands in unresolvedRowGroups.

This account has no priority rows, so the priority-ownership cause does not appear. Two of the three days carry no second model, so their costUSD is nil. That is enough to blank the full 30 day Codex total.

Why an unresolved group now yields no cost at all

Commit 4befde4 ("fix: preserve Codex request-tier pricing across forks", 2026-08-11) changed the fallback for an untrusted group.

Before:

let cost = rowCostIsTrusted ? ... : canonicalCost   // CostUsagePricing.codexCostUSD

After:

let cost = rowCostIsTrusted ? ... : aggregateCost   // CostUsagePricing.codexAggregateCostUSD

codexCostUSD always returns a value for a priced model. codexAggregateCostUSD adds a guard:

if let thresholdTokens = pricing.thresholdTokens,
   max(0, inputTokens) > thresholdTokens { return nil }

That guard compares the long-context threshold of 272,000 against a day-summed input token count, not against a request context size. Every active day exceeds it. On this account the smallest day in the window is 60,867 input tokens and the largest is 142,004,895, so the fallback returns nil for every day in the window.

The intent of the commit is correct. Long-context tier rates must not apply to a summed day. The effect is that "do not misprice" became "do not price", and the dashboard escalates one nil day to a blank provider.

This also suggests that the reconciliation defect is older than the commit. Before 2026-08-11 an unresolved group still received a tiered aggregate price, so the defect stayed invisible.

Scope

A long-context threshold exists for gpt-5.5 and for gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna, in the bundled table and in the models.dev catalog. No *-codex family carries one: gpt-5-codex, gpt-5.1-codex, gpt-5.1-codex-max, gpt-5.2-codex, gpt-5.3-codex. An account that stays on the codex-suffixed models keeps a priced fallback and does not see this failure.

Test coverage

The review comment cites Tests/CodexBarTests/CostUsageScannerForkSplitTests.swift:63 as evidence of request-scoped pricing parity. That test builds a cache whose rows reconcile against the day aggregate, so it exercises the trusted-row path. The fallback runs only when rows are not trusted. No test constructs that state together with a day sum above the threshold.