fix: reconcile OpenCode's totalTokens against its component sum - #7
Merged
Conversation
ccusage's OpenCode collector derives totalTokens independently of the per-request input/cache/output fields it also reports, and the two can disagree by a small residual (observed: 2/10,000 on real data). That mismatch tripped snapshot-completeness and regression-guard checks in the local fragment merge, so OpenCode's historical rows were silently kept out of frozen fragments. Trust the component sum (the authoritative per-request counts) and recompute the reported total from it for OpenCode only; Codex/Claude Code totals are untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #6. ccusage's OpenCode collector reports
totalTokensindependently of its own input/cache/output component fields, and on real data the two disagreed by a small residual (589,483,361 vs 589,471,183 — about 2 in 10,000). That mismatch tripped thecomponent_mismatchregression guard inmachine_fragments._tool_regression_reason, so every OpenCode row was rejected as an unresolvable regression and never written to the local machine fragment — confirmed live onmac-m4-localduring today's manual publish run.tokensfrom the sum of its own input/cache_create/cache_read/output fields (the authoritative per-request counts), instead of trusting ccusage's independently-derived total.opencode_daily_pointsonly; Codex and Claude Code parsing are unchanged.Testing
node --test tests/*.test.mjs: 80/80 pass.python3 -m unitteston daily reconciliation / oneapi / ccusage-pricing / codex-jsonl suites: all pass.ccusage opencode daily --jsonoutput for 2026-08-11 (real Claude/DeepSeek/grok mix): fixed row now yieldssnapshot_complete: trueand per-model breakdown token sums matching the corrected total exactly.