Codex sessions on ChatGPT Plus/Pro auth show 0 calls — two bugs (16KB read cap + null token info)

[ozymandiashh]

Summary

Codex sessions created via ChatGPT Plus/Pro subscription auth (auth_mode: "chatgpt" in ~/.codex/auth.json) are silently dropped by CodeBurn, showing 0 calls / $0.00 cost even when sessions are large and active. Two distinct bugs combine to cause this.

Reproduction

• Codex CLI logged in via ChatGPT Plus/Pro (not API key)
• Use Codex normally for several hours
• Run codeburn today or open the menu bar app

Expected: session count + token usage shown (cost can be $0 since subscription is flat fee, but tokens/calls should be visible).

Actual: Codex shows 0 calls / $0.00, even though sessions exist on disk and contain thousands of token events.

Environment

• CodeBurn: 0.9.5 (Homebrew menu bar build)
• Codex CLI: latest, auth_mode: chatgpt, chatgpt_plan_type: pro
• macOS 14.x
• Sessions at ~/.codex/sessions/2026/05/ — 14 files, recent ones >250KB each

Root cause #1 — session_meta line exceeds 16KB read cap (release-only bug)

The shipped Homebrew binary at /opt/homebrew/Cellar/codeburn/0.9.5/bin/codeburn:551 reads only the first 16384 bytes of a session file to parse the meta line:

const buf = Buffer.alloc(16384)
const { bytesRead } = await fh.read(buf, 0, 16384, 0)
const text = buf.toString('utf-8', 0, bytesRead)
const nl = text.indexOf('\n')
const line = nl >= 0 ? text.slice(0, nl) : text
return JSON.parse(line)  // throws on truncated JSON → null returned → file skipped

Real measurement from my latest Codex session:

$ head -1 ~/.codex/sessions/2026/05/03/rollout-2026-05-03T01-45-58-*.jsonl | wc -c
21828

The first line is 21,828 bytes — gets truncated at 16,384, JSON.parse throws, discoverSessionsInDir() skips the file entirely. Session never enters the pipeline.

The main branch source at src/providers/codex.ts already streams properly (createInterface over createReadStream), so npm install -g codeburn@latest from main may already fix this. The Homebrew/menu bar 0.9.5 artifact does not include the streaming fix.

Fix: rebuild the release artifacts from current main, or bump the buffer cap if streaming isn't desired.

Root cause #2 — ChatGPT subscription doesn't emit token counts

Even after fixing #1, sessions would still show 0 tokens because Codex CLI on ChatGPT subscription emits token_count events with info: null. The endpoint behind ChatGPT Plus/Pro returns rate-limit percentages instead of raw token counters.

Sample event from my session (1308 such events in one file, all with info: null):

{
  "timestamp": "2026-05-02T22:57:30.040Z",
  "type": "event_msg",
  "payload": {
    "type": "token_count",
    "info": null,
    "rate_limits": {
      "primary": {
        "used_percent": 11.0,
        "window_minutes": 300,
        "resets_at": 1777771246
      },
      "secondary": {
        "used_percent": 35.0,
        "window_minutes": 10080,
        "resets_at": 1777973328
      },
      "plan_type": "pro"
    }
  }
}

Compared to API-key auth where info contains:

{
  "last_token_usage": { "input_tokens": 1234, "output_tokens": 567, ... },
  "total_token_usage": { ... }
}

In src/providers/codex.ts around line 255, the parser reads info.last_token_usage / info.total_token_usage — both undefined when info: null, so all token fields stay 0, and the totalTokens === 0 guard at line ~296 makes the entry skip. Session is parsed but yields no calls.

Suggested fix for #2 (estimation fallback, modeled on cursor.ts)

Track message text length during the session and estimate tokens when info is null, similar to how providers/cursor.ts handles older Cursor versions:

+ const CHARS_PER_TOKEN = 4
+ let estimatedInputChars = 0
+ let estimatedOutputChars = 0

  // when iterating response_item entries:
+ if (entry.type === 'response_item' && entry.payload?.type === 'message') {
+   const role = entry.payload.role
+   const text = (entry.payload.content ?? []).map(c => c.text ?? '').join('')
+   if (role === 'user') estimatedInputChars += text.length
+   else if (role === 'assistant') estimatedOutputChars += text.length
+ }

  // before the totalTokens === 0 guard:
+ if (inputTokens === 0 && outputTokens === 0 && (estimatedInputChars > 0 || estimatedOutputChars > 0)) {
+   inputTokens = Math.ceil(estimatedInputChars / CHARS_PER_TOKEN)
+   outputTokens = Math.ceil(estimatedOutputChars / CHARS_PER_TOKEN)
+ }

Cost can stay at $0 (subscription is flat fee), but calls and estimated tokens become visible, which is what users on ChatGPT Plus/Pro want — to see where their subscription quota goes.

Bonus: the rate_limits.primary.used_percent and secondary.used_percent fields could be surfaced as a "subscription quota used" indicator alongside the estimated tokens. This is unique data only ChatGPT-auth users have.

Why this matters

ChatGPT Plus is $20/month — many CodeBurn users are on it (cheaper than API for heavy use). Right now they see €0.00 and conclude CodeBurn doesn't track Codex at all, when in reality their data is just being silently dropped. Even an estimation with a "(estimated)" label would be more useful than total invisibility.

Happy to PR

I can submit a PR for either fix (or both) if welcome. Let me know if there's a preferred shape — flag-gated estimation, separate "estimated" field in the data model, etc.

[ozymandiashh]

Clarification on cost display: I should have stated this more clearly in the original post.

The desired behavior is NOT to leave cost at $0. The whole point of CodeBurn for subscription users is to see what the equivalent API cost would have been — that's how we evaluate whether the $20/month ChatGPT subscription is actually saving us money vs paying per token.

So the flow should be:

1. Estimate input/output tokens from message text length (when info: null)
2. Feed those estimated tokens through the existing LiteLLM pricing pipeline (calculateCost() in src/models.ts)
3. Display the result with a clear label such as ~$X.XX (API-equivalent, est.) or a dedicated column

This way a ChatGPT Plus user can see at the end of the month:

"I would have spent $147 on the API. My $20 subscription saved me $127."

Or:

"I only spent $8 worth of API equivalent. The subscription isn't paying for itself this month."

That's the actionable signal — and it requires almost no extra code beyond the estimation fallback I already proposed, since the cost calculation pipeline is already there. Just don't short-circuit it when auth_mode is chatgpt; instead, route estimated tokens through it and add a costIsEstimated: true flag (or similar) for display.

Happy to include this in the PR if you want a single change rather than two passes.

[iamtoruk]

Both issues from this report are now fixed in 0.9.6 (and main).

Root cause #1 — 16KB read cap (fixed in 0.9.5 via PR #189)

The readFirstLine function now streams via createReadStream + readline with a 1MB cap instead of a fixed 16KB buffer. Your 21KB session_meta lines parse correctly. This was already shipped in 0.9.5; the Homebrew formula has been updated to 0.9.6.

Root cause #2 — ChatGPT subscription info: null estimation (fixed in 0.9.6 via commit 8cf68e7)

When info is null in token_count events, CodeBurn now estimates tokens from accumulated message text (4 chars ≈ 1 token) and feeds them through calculateCost() so subscription users see API-equivalent spend. A costIsEstimated flag is set on these calls.

We've also added UI differentiation in main (will ship in 0.9.7): costs that include any estimated portion display with a ~ prefix (e.g. ~$147.32) and the dashboard overview shows (incl. $X.XX est.) so users can clearly distinguish real vs estimated costs.

What we found testing with a ChatGPT Plus account

We tested against a real ChatGPT Plus (chatgpt_plan_type: "plus") account and found that the behavior varies from what you described:

• Your report: all 1,308 token_count events had info: null
• Our test: only 1 out of 23 token_count events had info: null — the remaining 22 had full last_token_usage with real input_tokens, cached_input_tokens, output_tokens, and reasoning_output_tokens

This suggests the all-null behavior may be specific to:

• The Pro plan (chatgpt_plan_type: "pro") vs Plus
• An older Codex CLI version
• A different OpenAI backend rollout

Either way, both code paths now work: real tokens flow through the normal pipeline, and null-info events get estimated with clear UI labeling.

Could you test with npm install -g codeburn@0.9.6 and confirm your sessions are now visible? If you're still seeing all-null info fields, the estimation path will handle it — and we'd be curious to know your exact Codex CLI version and plan type.

[ozymandiashh]

Tested with 0.9.6 from Homebrew. Both fixes work — Codex sessions are now visible. A few data points to confirm and one new finding:

Environment:

• CodeBurn: 0.9.6 (Homebrew)
• Codex CLI: 0.128.0
• macOS 14.x
• Auth: auth_mode: chatgpt, chatgpt_plan_type: plus in current auth.json
• However, my older sessions on disk still show plan_type: "pro" in the rate_limits payloads. I appear to have been on Pro until 2026-04-08 and then on Plus, so my original report was correct for the time it was filed. My current account is Plus.

info: null distribution in a current Plus session (sampled first 500 MB of one rollout):

• 3,284 token_count events total
• 1 with info: null
• 3,283 with full last_token_usage

So in current Plus, the estimation fallback is rarely hit. Your 22/23 finding holds up. The all-null behavior in my original report (1,308 / 1,308) appears to have been specific to the Pro-era + an older Codex CLI; recent Codex emits real info for nearly all events on Plus.

---

New issue while testing: oversize-file cap silently drops large sessions

--verbose revealed this on my latest run:

codeburn: skipped oversize file /Users/.../sessions/2026/05/03/rollout-...jsonl
  (259470209 bytes > cap 134217728)

One of my recent long coding sessions hit 247 MB in a single .jsonl file. The 128 MB MAX_SESSION_FILE_BYTES cap drops the entire session from the report unless --verbose is on.

I went ahead and fixed it: #207

The Codex provider was reading the file in full and then doing content.split('\n'), which doubles peak memory and pushes V8 toward its 512 MB string limit even if you bump the cap. readSessionLines was already a streaming generator in fs-utils.ts (used by readFirstLine), so the PR just switches the Codex parser to consume it and lifts the cap to 2 GB for the streaming path only.

Empirical impact on my account:

	Before (0.9.6 stock)	After PR #207
Cost (7d)	€358.69	€550.67
Calls	4,536	6,111
Input tokens	20.1 M	37.3 M

The 247 MB session is now included; smaller sessions parse identically.

All 419 tests pass on the branch. PR description has full detail and a test plan.