Bug: Local token usage & estimated cost are under-reported due to ignoring subagent rollout session logs

[qiuruiyu]

Issue Description

Summary

CodexBar's local log parser under-reports the total daily/monthly token usage and estimated cost when users run complex tasks. This happens because CodexBar's local scanning logic relies solely on top-level session IDs registered in ~/.codex/session_index.jsonl and fails to scan rollout files generated by spawned subagents (child threads).

How to Reproduce / Technical Details

1. Run a complex coding task in Codex CLI or Claude Code via the Codex MCP plugin that triggers agentic loops (where the model defines and spawns subagents).
2. Codex CLI handles these subagents by creating separate execution threads. In the filesystem, they write their own session rollout logs under:
   ~/.codex/sessions/YYYY/MM/DD/rollout-<subagent-session-id>.jsonl
3. Because these subagents are internal child threads, their session IDs are not registered in the top-level user session index ~/.codex/session_index.jsonl.
4. CodexBar's local parser reads session_index.jsonl to locate files to parse. As a result, it completely bypasses the subagent rollout logs, leading to a massive gap in reported vs. actual token usage.

Real-world Example from Logs

On July 14, 2026 (local timezone UTC+8), I ran a task that spawned multiple subagents (Gauss, Hubble, Schrodinger, etc.).

• Actual Usage (Direct Log Sum of all files in directory): 331M tokens with an estimated cost of $269.96.
• CodexBar's Chart Output: 83M tokens with an estimated cost of $65.71.

The math behind the discrepancy:

• The parent session (019f6137-a3e2-7c72-ace4-126c54369a4a) cost $60.07. Combined with minor VSCode / Exec sessions, it totaled exactly $65.71 (what CodexBar displayed).
• However, the subagent sessions (Gauss costing $52.37, Hubble costing $52.04, Schrodinger costing $51.23) were completely ignored by CodexBar's scanner because their session IDs were missing from session_index.jsonl.
• Note: Although the cloud-based "Weekly/Monthly Limit" percentage (fetched via browser cookies/API) correctly counted the subagent requests, the "Estimated Cost" charts, project list, and total token usage meters were under-reported.

Expected Behavior

CodexBar's local parser should scan all rollout-*.jsonl files present in the daily session folders or discover subagent sessions by parsing parent-child relationships (e.g. checking payload.source.subagent in session_meta lines of the parent rollout files) instead of relying strictly on session_index.jsonl.

System Environment

• OS: macOS 14+ (Apple Silicon)
• Codex CLI Version: 0.144.2 (or similar)
• CodexBar Version: Latest (v0.33.0+)

[Yuxin-Qiao]

Thanks for the detailed report — I tried to reproduce the underlying scanning behavior rather than dismissing the numbers.

On v0.43.0, I tested the local cost scanner with isolated parent/child rollout fixtures placed in the dated sessions/YYYY/MM/DD layout. The fixtures deliberately have no session_index.jsonl, but both rollout files are still discovered and the child's non-duplicated usage is included. The focused parent/child scanner integration tests pass as well.

So I could not reproduce the specific proposed mechanism where a child rollout is skipped solely because it is absent from session_index.jsonl: the current scanner enumerates the .jsonl files in each dated sessions directory directly.

That said, the 331M vs 83M gap is large enough that I would still like to understand the real cause. Could you share, if possible:

• the exact CodexBar version;
• a redacted parent rollout plus one child rollout that was omitted, including their relative paths under .codex;
• the selected history date range/timezone; and
• whether clearing the local cost-history cache and refreshing changes the result.

That would let us check for a format, location, date-boundary, or cache-specific case that the generic parent/child fixture does not cover. Thanks!

[qiuruiyu]

Update: corrected root cause — rollout files are NOT skipped; a fork-baseline subtraction wipes out subagent usage

After a deeper forensic pass on the same machine, I need to correct the hypothesis in my original report. session_index.jsonl is not the problem: CodexBar (tested on 0.43.0, and the enumeration logic on current master is the same) lists the date-partitioned session folders directly, and its scan cache (~/Library/Caches/CodexBar/cost-usage/codex-v9.json) contained 154 of 154 rollout files in the scan window, each with parsedBytes == file size. Every file — including all subagent rollouts — is found and fully read.

The tokens are lost in the counting step instead.

Root cause

1. Codex CLI ≥ 0.144 (multi-agent) writes a top-level forked_from_id into the session_meta payload of every spawned subagent thread (alongside parent_thread_id and source.subagent.thread_spawn), and also into resumed sessions.
2. These threads' token_count counters start from zero: their first event has total_token_usage == last_token_usage (≈14.7k in my logs). They do not replay or continue the parent's cumulative totals.
3. CodexBar's fork-baseline logic (Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner.swift — codexForkParentId → resolveForkBaseline, the totals-only fork accounting referenced as Fix Codex fork token replay overcount #1164 / 45b68c3) sees forked_from_id, resolves the parent's cumulative totals at fork time, and credits the child only max(0, child_total − parent_baseline).
4. Because the child's counter contains only its own usage, subtracting the parent baseline silently deletes almost all of it.

Evidence — exact to the token

Five independent sessions on 2026-07-13/14 (all values are cumulative input_tokens + output_tokens from the raw rollouts, compared against lastCountedTotals in CodexBar's cache):

Session	Raw final	Parent baseline at spawn	Raw − baseline	CodexBar counted
subagent "Gauss" (019f613d-57dd)	62,239,687	60,698,252	1,541,435	1,541,435 ✔
subagent "Hubble" (019f613d-1048)	61,584,293	60,253,874	1,330,419	1,330,419 ✔
subagent "Schrodinger" (019f613d-33a6)	60,830,450	60,476,000	354,450	354,450 ✔
resumed parent (019f6137-a3e2)	263,299,952	58,975,169 (ancestor's final)	204,324,783	204,324,783 ✔
2× subagents of 019f5a5a (Jul 13)	37.4M / 36.0M	~29.7M each	7.7M / 6.3M	7.7M / 6.3M ✔

Cross-checks:

• Days with no forked_from_id session (Jul 10–12) reconcile to the token — the parser is otherwise exact.
• The parent's totals do not include its children (the three children burned ~185M within a 6-minute window while the parent's own counter grew only 4.07M), so summing per-file totals does not double count.
• For local day 2026-07-14 (UTC+8, same day-key convention CodexBar uses): raw logs total 324.3M in+out, CodexBar shows 82,962,078 ($65.71 — matching my original screenshot). ~74% of the day's usage was clipped by the baseline subtraction.

Reproduction

Live reproduction (needs Codex CLI ≥ 0.144):

1. Run a Codex session and let it accumulate a noticeable amount of tokens (say ≥ 1M) — this becomes the baseline B.
2. From that session, spawn a subagent (multi-agent thread_spawn).
3. Observe the child rollout under ~/.codex/sessions/YYYY/MM/DD/: its session_meta payload carries forked_from_id: <parent id> and source.subagent.thread_spawn, and its first token_count event has total_token_usage == last_token_usage (counter restarted from zero).
4. Let the child use < B tokens, then compare CodexBar's Estimated Cost against the raw log: the child contributes ~0.

Forensic check against an existing cache (this is how the table above was produced):

verify_clip.py — compares CodexBar's cache with the raw rollouts

#!/usr/bin/env python3
"""Prints every session where CodexBar counted less than the raw rollout total.
The clipped amount equals the parent's cumulative totals at fork time."""
import json, os, glob

HOME = os.path.expanduser("~")
cache = json.load(open(f"{HOME}/Library/Caches/CodexBar/cost-usage/codex-v9.json"))

def io(d):
    d = d or {}
    return (d.get("input_tokens", d.get("input", 0)) or 0) + \
           (d.get("output_tokens", d.get("output", 0)) or 0)

for path, entry in sorted(cache["files"].items()):
    if not os.path.exists(path):
        continue
    meta, final = None, None
    for line in open(path, errors="replace"):
        try:
            obj = json.loads(line)
        except ValueError:
            continue
        p = obj.get("payload") or {}
        if obj.get("type") == "session_meta" and meta is None:
            meta = p
        if p.get("type") == "token_count":
            t = (p.get("info") or {}).get("total_token_usage")
            if t:
                final = t
    if not meta or not final:
        continue
    raw, counted = io(final), io(entry.get("lastCountedTotals"))
    if raw - counted > 1_000_000:
        src = meta.get("source")
        src = "subagent" if isinstance(src, dict) and "subagent" in src else src
        print(f"{os.path.basename(path)}")
        print(f"  forked_from={meta.get('forked_from_id')}  source={src}")
        print(f"  raw={raw:,}  counted={counted:,}  clipped={raw-counted:,}")

Why some users cannot reproduce this

The clipped amount equals the parent's cumulative totals at spawn time, and the clip is max(0, child − baseline), so the bug is invisible when:

• subagents are spawned early in a fresh parent session (baseline ≈ 0);
• the child's usage far exceeds the baseline (only the first B tokens are lost — small relative error);
• the parent rollout file is missing (baseline resolution fails and the unresolved-fork path counts via last_token_usage, which is roughly correct);
• Codex CLI < 0.144 (no forked_from_id written).

My workflow happens to maximize it: long-running parents that had already burned ~60M before spawning, with children whose entire usage (~61M each) sits below the baseline — so 97%+ of each child was deleted.

Suggested fix

The baseline subtraction is only valid when the child actually continues the parent's counter. Two complementary guards:

1. Generic (covers unknown future sources): when resolving a fork baseline, compare the child's first observed total_token_usage against the resolved baseline. If it is far below the baseline, the counter restarted from zero — skip the subtraction. (In my data, restarted children start at ~14.7k vs baselines of 29–60M, so any threshold works.)
2. Explicit: skip the subtraction when session_meta marks the thread as a subagent (source.subagent.* / string "subagent" / parent_thread_id present).

Note that in all cases observed on my machine — subagent spawns and a resumed session — the child counters restarted from zero, so it may be worth re-validating whether current Codex versions ever produce the "continued counter" fork layout that #1164 was built for.

Happy to provide the full rollout excerpts or run additional checks if useful. Suggested retitle: "Local token usage under-reported: fork-baseline subtraction misfires on subagent/resumed sessions whose token counters restart from zero."

[steipete]

Fixed by #2208, merged as 8489602f84ca278a4cb6944a97cca009b4412a87.

Final head 59a18fcc4e3729560f2e02ee701ef5202b1fd631 counts explicitly marked Codex subagents as independent counters and keys each rollout by its distinct thread id rather than the shared multi-agent tree session_id. Ordinary continuing forks still subtract the inherited parent baseline.

Proof:

• focused cost-scanner suite: 87/87 passed on the final head;
• synthetic black-box CLI fixture: restarted subagent usage was counted in full, ordinary fork usage counted only its post-fork delta, and a warm-cache repeat matched;
• structured autoreview: clean, no accepted/actionable findings;
• exact-head CI: both Linux builds/tests, both macOS shards, lint, aggregate, and security checks passed.

Thanks again for the detailed forensic follow-up, @qiuruiyu!