fix(codex): scope token dedup key to fork parent so subagent replays collapse - #681
Conversation
…collapse Fork/subagent children replay the parent's token_count history into every child file with identical cumulative totals but a distinct per-file session id. The dedup key was scoped by session id, so sibling replays never collapsed and each copy was counted. Scope the key to forked_from_id so sibling replays share one key; unrelated sessions keep their own id.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1d2ca695ac
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The fork-parent dedup key only changes parser output, but cached UnifiedMessages store their dedup_key. Files already in source-message-cache.bin were returned with old per-child keys, so the fix was latent for already-scanned sessions (the junhoyeo#679 case). Bump the cache schema version to force a one-time reparse.
junhoyeo
left a comment
junhoyeo
left a comment
There was a problem hiding this comment.
LGTM. Fork-parent-scoped dedup is the right fix — preserves the #651 regression intent while collapsing sibling replays. The CACHE_SCHEMA_VERSION bump from 17 to 18 correctly forces a re-parse of stored entries so old dedup keys cannot bleed through, and the test diff (4→3 messages, 150→140 / 15→14) is well-explained.
2 participants
Codex subagent/fork fan-out replays the parent's
token_counthistory into every child file. Each replayed row has the same cumulative total but a distinct per-file session id, and the dedup key is scoped by session id, so the copies never collapse and every sibling gets counted. One real day reported 12.9B tokens and tripped the daily submit cap; deduped it is ~1B (#679).Scope the codex
token_countdedup key toforked_from_idinstead of the child's own session id. Sibling replays share one key and collapse. Non-forked sessions keep their own id, so unrelated work never merges.From 175 real session files on the affected day:
token_countrows are cross-file duplicates (4,450 rows replayed across 16 files each, etc).This changes
test_..._deduplicates_parent_replay_across_forks. Its two sibling forks each do one own turn that lands on a byte-identical cumulative total, and it asserted both survive; with parent-scoped keys they collapse, so the assertion is updated. In real data, identical sibling cumulative vectors are the replay signature rather than independent work, since the cumulative encodes each fork's divergent context size. If you would rather preserve that case, the alternative is a cross-file pass that collapses only contiguous shared runs instead of single rows; happy to switch.Closes #679.
Summary by cubic
Fix token overcounting in Codex by scoping
token_countdedup keys to the fork parent (forked_from_id) so sibling subagent replays collapse. Also bump the message cache schema to reparse stalededup_keys and apply the fix to previously scanned sessions; closes #679.forked_from_idto collapse identical cumulativetoken_countrows across sibling forks; fallback to the session id for non-forked sessions, so unrelated sessions never merge.dedup_keys.Written for commit 0545dee. Summary will update on new commits.