Codex cost history can misattribute long gpt-5.5 sessions to gpt-5

[hhh2210]

Summary

CodexBar 0.26.1 can show a large gpt-5 cost/token bucket even when the local Codex session JSONL only records gpt-5.5 turns.

Reproduction evidence

On a local Homebrew-installed CodexBar 0.26.1 build, the cost history tooltip showed for 2026-05-18:

• gpt-5: about 22M tokens / $5.59
• gpt-5.5: about 3.8M tokens / $3.72

The generated cache at ~/Library/Caches/CodexBar/cost-usage/codex-v6.json had the same split:

"2026-05-18": {
  "codex-auto-review": [97987, 48256, 145],
  "gpt-5.5": [3826443, 3471104, 6845],
  "gpt-5": [21808861, 20239872, 109701]
}

But scanning the raw ~/.codex/sessions/2026/05/18/*.jsonl files directly showed turn_context models as gpt-5.5 / codex-auto-review, with only one zero-token fallback attribution to gpt-5.

Likely cause

CostUsageScanner.parseCodexFile allows Codex lines up to 256 KiB, but only retains a 32 KiB prefix. Current Codex turn_context rows can exceed 32 KiB. One real turn_context row was 33,922 bytes and contained payload.model = gpt-5.5. When that row is treated as truncated and skipped, subsequent token_count events without an explicit model fall back to gpt-5, causing the cost history to over-report gpt-5.

Expected behavior

Long turn_context rows should still preserve model attribution for following token_count events, and existing bad Codex cost caches should be invalidated so the UI recalculates the corrected model split.

Version

Observed with Homebrew-installed CodexBar 0.26.1. The same prefixBytes = 32 * 1024 pattern is still present on current main as of 2026-05-18.

[hhh2210]

Additional context to make the report less ambiguous:

• This was observed from the Homebrew-installed CodexBar 0.26.1 app, not a locally built checkout. The app process was /Applications/CodexBar.app/Contents/MacOS/CodexBar, version 0.26.1 / build 63, modified May 15 2026.
• The misleading split was read from CodexBar's generated local cost cache (~/Library/Caches/CodexBar/cost-usage/codex-v6.json) and matched the UI tooltip, so the report is about CodexBar's local cost-log scanner/cache layer, not about upstream OpenAI billing or subscription charges.
• The raw source logs were the local Codex CLI/session JSONL files under ~/.codex/sessions/2026/05/18. Direct parsing found turn_context models of gpt-5.5 and codex-auto-review; the large gpt-5 bucket only appeared after CodexBar scanning.
• Current main has newer Codex cost-cache/schema work (codex-v7), but the scanner still keeps only a 32 KiB prefix for each Codex line while allowing a 256 KiB max line. That means the official/mainline cache refresh does not fully fix this class of bug: if a modern Codex turn_context exceeds 32 KiB, the model context can still be dropped before the following token-count events are attributed.
• A clean fix should preserve the full allowed Codex line when scanning model-bearing context rows and bump the Codex cache artifact version again, so already-misattributed cost caches are recomputed instead of continuing to display stale gpt-5 buckets.

[hhh2210]

Follow-up after implementing the fix in #1014:

The final patch does not rely on simply raising the Codex line prefix from 32 KiB to a larger threshold. That would only move the failure point.

Instead, it changes the JSONL scanner to retain the configured prefix for truncated rows and then uses that retained prefix only for Codex turn_context model recovery. Normal JSON parsing still skips truncated rows. This means an oversized turn_context can still update currentModel when the model appears near the front of the row, which is the shape seen in the local Codex CLI JSONL that produced the bad generated cost cache.

The patch also makes an explicit token_count model authoritative over stale turn-context state and bumps the Codex cache artifact to codex-v8.json, so previous local codex-v6/codex-v7 cost-cache attribution does not keep affecting the UI after upgrading.

[hhh2210]

One related follow-up that came out of this debugging: #1016.

That issue is deliberately separated from this correctness bug. The attribution problem here is a scanner state issue, not a general throughput bottleneck. #1014 keeps the fix small and pure Swift. #1016 is only asking whether larger local JSONL histories should eventually get a profiled fast path, and whether maintainers would prefer pure Swift optimization, Rust/SIMD, or no extra implementation until there is benchmark evidence.