You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
v2.0.0 dedup logic discards real token data when proxy writes two records per message (tokens=0 placeholder + real values) #18
Title:v2.0.0 dedup logic discards real token data when proxy writes two records per message (tokens=0 placeholder + real values)
Body:
Bug Description
v2.0.0 introduced deduplication via createUniqueHash() (messageId + requestId). When using a proxy (e.g. mimo, ccswitch) that writes two records per message to the .jsonl files — a placeholder with tokens=0 first, then a second record with real token counts — the dedup keeps the zero-value record and discards the real one.
This causes the status bar and webview to show drastically incorrect usage (e.g. \$0.20 instead of \$7.98 for today).
Root Cause
Proxies like mimo write records to jsonl in a streaming fashion:
// Record 1 — written immediately when streaming starts (placeholder)
{"message":{"id":"msg_xxx","usage":{"input_tokens":0,"output_tokens":0}}, "timestamp":"2026-06-01T03:43:44.657Z"}
// Record 2 — written after response completes (real values)
{"message":{"id":"msg_xxx","usage":{"input_tokens":271,"output_tokens":5774}}, "timestamp":"2026-06-01T03:43:46.182Z"}
Both records share the same messageId (and both have no requestId), so createUniqueHash() generates the same hash for both. The dedup in loadUsageRecords() keeps the first occurrence and skips the rest:
// dataLoader.js line ~320
const uniqueHash = this.createUniqueHash(data);
if (uniqueHash && processedHashes.has(uniqueHash)) {
continue; // ← skips the real-value record
}
Impact
Metric
Before dedup (raw)
After dedup (v2.0.0)
Today non-zero records
191
4
Today cost
~$7.98
$0.20
All-time cost
~$79.85
~$0.20
Out of 188 unique message hashes for today, 185 had the first record with tokens=0 and the second with real values.
Suggested Fix
When a duplicate hash is encountered, compare token sums and keep the record with higher values instead of blindly skipping:
Hi @zhaoxiao9302 — this is a fantastic report. The root cause analysis is correct, the suggested fix is the right shape, and the 185/188 stat is exactly the kind of evidence that makes a bug investigation go fast.
Thank you!
I'm planning the fix essentially as you proposed: switch processedHashes from Set<string> to Map<string, number> (hash →
record index), and on a duplicate hash keep whichever record has the higher total token sum. That naturally handles proxy-induced "placeholder + real" pairs without needing to detect the proxy itself.
I'll ship this in v2.0.1 this week. CHANGELOG will reference your issue with proper attribution.
Some users (myself included) have been seeing under-reported DeepSeek and CC Switch usage that I now believe is the same bug — your report explains it. Doubly appreciated.
Hi @zhaoxiao9302 — great report, great fix suggestion. v2.0.1 ships exactly the approach you described: processedHashes is now a Map<string, number> (hash → record index) and on a duplicate hash we keep whichever record has the higher total token sum.
Your 185/188 stat was very helpful for verifying the fix. CHANGELOG credits you.
Closing. Let me know if you see anything unexpected.
Activity
Carl723000 commentedon Jun 2, 2026
Hi @zhaoxiao9302 — this is a fantastic report. The root cause analysis is correct, the suggested fix is the right shape, and the 185/188 stat is exactly the kind of evidence that makes a bug investigation go fast.
Thank you!
I'm planning the fix essentially as you proposed: switch
processedHashesfromSet<string>toMap<string, number>(hash →record index), and on a duplicate hash keep whichever record has the higher total token sum. That naturally handles proxy-induced "placeholder + real" pairs without needing to detect the proxy itself.
I'll ship this in v2.0.1 this week. CHANGELOG will reference your issue with proper attribution.
Some users (myself included) have been seeing under-reported DeepSeek and CC Switch usage that I now believe is the same bug — your report explains it. Doubly appreciated.
fix(v2.0.1): dedup, DeepSeek pricing, quota always-show, loading spin…
v2.0.1: dedup fix, DeepSeek pricing, auto-refresh toggle, loading fix (…
Carl723000 commentedon Jun 3, 2026
Hi @zhaoxiao9302 — great report, great fix suggestion. v2.0.1 ships exactly the approach you described:
processedHashesis now aMap<string, number>(hash → record index) and on a duplicate hash we keep whichever record has the higher total token sum.Your 185/188 stat was very helpful for verifying the fix. CHANGELOG credits you.
Closing. Let me know if you see anything unexpected.