Codex usage statistics inflated: fork/resume sessions double-count parent history tokens
Quick fix
Upgrade cc-switch to v3.18.0+ and rebuild the usage database to fix fork sessions double-counting parent history tokens.
Symptom
Section titled “Symptom”Codex fork 一个会话时，不应该因为 fork 文件里带有父会话历史记录，就让用量统计增加。When Codex forks a session, usage statistics should not increase just because the fork file contains the parent session's history records.
When Codex performs a fork (derive session) or resume (restore session) operation, the generated JSONL log files include the parent or original session's historical token cumulative snapshot. Older versions of the cc-switch Codex session usage importer processed these files by calculating token deltas per file independently, without distinguishing between historical snapshots and new request increments. This caused historical cumulative values to be written as new usage for the fork or resume session, severely inflating total token, cache hit, and cost statistics (some users reported deviations of 2.5 to over 20 times).
This issue involves multiple technical details: 1) parent session history token_count events copied in fork files are double-counted; 2) when total_token_usage regresses/replays within a single session, historical values are re-counted as new usage; 3) dual-segment filename rollouts generated by resume sessions are misjudged as "filename thread ID inconsistent with root meta ID" and permanently skipped, causing subsequent usage to be silently lost. Comments on Issue #3011 note that even after upgrading to v3.18.0, the token statistics overestimation issue caused by interleaved rate_limits.limit_id in non-fork root sessions still exists and requires a subsequent PR to fix.
Upgrade cc-switch to v3.18.0 or higher. This version introduces a new parser that filters copied parent history through explicit parent identity and token signature prefix alignment.
After upgrading, cc-switch will automatically back up and rebuild the existing usage database during the schema v16 upgrade, clearing historical incorrect usage data.
If usage statistics still silently stop after a resume session post-upgrade, check the sync logs for a "filename thread ID inconsistent with root meta ID" warning. This issue still exists in v3.20.0 and requires waiting for the official merge of the PR fixing dual-segment filename validation.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 5 real issues
- Will previous incorrect usage data be automatically corrected after upgrading to v3.18.0?
- Yes. v3.18.0 will automatically back up and rebuild the existing usage database when upgrading to schema v16, clearing incorrect data caused by fork history double-counting.
- Why is my Codex usage statistics over 20 times higher than actual?
- The Codex session usage importer in older versions of cc-switch treats the parent session history token_count snapshot copied in fork files as new usage, severely inflating total token, cache hit, and cost statistics.
- After upgrading to v3.18.0, why does usage statistics no longer increase after resuming a session?
- This is another bug still present in v3.20.0: dual-segment filename rollouts generated by Codex resume sessions are misjudged as thread ID inconsistency and permanently skipped. Check the sync logs for a "filename thread ID inconsistent with root meta ID" warning and wait for an official fix.
- Does v3.18.0 fix all Codex usage statistics inflation issues?
- No. v3.18.0 fixes the issue of fork sessions double-counting parent history tokens, but the statistics overestimation caused by total_token_usage regression/replay and interleaved rate_limits.limit_id within a single session still requires subsequent PRs to fix.
Related problems
Section titled “Related problems”This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.