Problem
For Codex sessions, the reader collapses many real API requests into a single recorded "turn." Token totals for the session are correct (they're read from usage fields directly), but every per-turn metric derived from turn count — average tokens/turn, cost/turn, turns/session comparisons — is wrong by an order of magnitude.
Evidence (2026-07-30 fleet spend forensics)
- One Codex session recorded 42 turns, but the underlying transport shows 2,545 real API requests.
- That's a ~60x undercount of turn granularity for that session alone.
- Session-level token totals matched an independent count within 1.4%, confirming this is specifically a turn-boundary/grouping defect, not a token-accounting one.
Likely cause
Turn membership for Codex logs is probably still being assigned by a coarser heuristic (time-window or message-shape based) than the parentUuid-chain-walk approach already shipped for Claude sessions in #433. Codex's request/response shape doesn't carry the same chain-linkage, so requests within a single logical turn are being folded together instead of counted individually.
Fix
Give Codex sessions a turn-boundary definition that reflects actual API request count, or expose request count as a separate first-class field so per-turn metrics aren't silently averaged over the wrong denominator.
Problem
For Codex sessions, the reader collapses many real API requests into a single recorded "turn." Token totals for the session are correct (they're read from usage fields directly), but every per-turn metric derived from turn count — average tokens/turn, cost/turn, turns/session comparisons — is wrong by an order of magnitude.
Evidence (2026-07-30 fleet spend forensics)
Likely cause
Turn membership for Codex logs is probably still being assigned by a coarser heuristic (time-window or message-shape based) than the parentUuid-chain-walk approach already shipped for Claude sessions in #433. Codex's request/response shape doesn't carry the same chain-linkage, so requests within a single logical turn are being folded together instead of counted individually.
Fix
Give Codex sessions a turn-boundary definition that reflects actual API request count, or expose request count as a separate first-class field so per-turn metrics aren't silently averaged over the wrong denominator.