Local usage overcounts resumed sessions by treating inherited cumulative totals as new usage
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Start in src-tauri/src/shared/local_usage_core.rs, where previous_totals is initialized per file and the parser prefers total_token_usage over last_token_usage. Reproduce the double count with the two-file example in the issue, then check how token_usage_record entries and their response_id could be read and deduplicated. Done means the continuation file yields 10 input tokens for the second day, and regression cases cover resumed files, duplicate records, and cached input.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
The local usage scanner can count a resumed session's inherited cumulative token usage as new usage. This substantially inflates daily totals when one logical session spans multiple rollout files.
Environment and scope
- macOS, installed Codex Monitor version: 0.7.67.
- The same scanner logic is present in the latest fetched
main, commitdd61b9abd37de5ded86e82b9fe8a83fd49d46fa5(package version 0.7.68). - This report is based on source inspection and replaying the scanner's accounting algorithm against local rollout usage records. The numbers below are an algorithm reproduction, not a live Codex Monitor UI measurement or an invoice reconciliation.
Root cause
In src-tauri/src/shared/local_usage_core.rs, previous_totals is initialized to None for every file.
The parser prefers total_token_usage over last_token_usage, and subtracts a zero default for the first cumulative record.
A continuation file may start with the logical session's historical cumulative total. Subtracting zero attributes that entire history to the new record's date, even though most of it was already accounted for in earlier files. The scanner also does not currently consume token_usage_record or deduplicate those request records by response_id.
Minimal reproduction
For a legacy stream, place these usage events in two rollout files for the same logical session. Other metadata can follow the usual rollout format.
File A (previous day):
{"timestamp":"2026-10-08T10:00:00Z","type":"event_msg","payload":{"type":"token_count","info":{"total_token_usage":{"input_tokens":1000,"cached_input_tokens":0,"output_tokens":0},"last_token_usage":{"input_tokens":1000,"cached_input_tokens":0,"output_tokens":0}}}}
File B (continuation on the next day):
{"timestamp":"2026-10-09T10:00:00Z","type":"event_msg","payload":{"type":"token_count","info":{"total_token_usage":{"input_tokens":1010,"cached_input_tokens":0,"output_tokens":0},"last_token_usage":{"input_tokens":10,"cached_input_tokens":0,"output_tokens":0}}}}
Expected usage for October 9: 10 input tokens. Current scanner result: 1,010 input tokens.
Impact on actual local data
Using the same cutoff, 2026-10-09 20:19:54 UTC+08:00, for both calculations:
| Accounting method | Input | Output | Total |
|---|---|---|---|
| Current scanner algorithm | 198,138,953 | 1,014,542 | 199,153,495 |
Unique token_usage_record.payload.usage records, deduplicated by response_id |
28,898,641 | 146,226 | 29,044,867 |
The request-based calculation contains 342 unique requests and includes 26,920,192 cached input tokens within the input total. Cached input is not added again. The current algorithm produces approximately 6.86 times the request-based total.
Suggested fix and regression coverage
- Prefer per-request
token_usage_record.payload.usagewhere available, with deduplication byresponse_idacross files. Count input plus output; cached input remains a subset of input, and reasoning output must not be added twice. - Avoid counting both a request usage record and its accompanying
token_countdisplay event. Matching solely by timestamp proximity can be unreliable because those events may be delayed. - Retain a conservative fallback for older logs: use valid per-request
last_token_usagewhen available, suppress repeated cumulative snapshots, and treat an initial cumulative-only record as a baseline rather than new usage. - Add regression cases for resumed files, duplicate request records across files, mixed request/display records, legacy cumulative resets, and cached input accounting.
The goal is accurate local request usage, including cached input, rather than interpreting session history as new consumption. It should still be distinguished from provider-side billing or account quota data.
- Ngôn ngữ chính
- TypeScript
- Star
- 4.3k
- Fork
- 415
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Dimillian/CodexMonitor
-
Listed in Awesome Codex CLIĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
Dimillian/CodexMonitor#590 ·
-
Unable to select the commandĐang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 63/100
Dimillian/CodexMonitor#615 ·
-
Codex Monitor does not surface MCP browser tool approval prompts, making browser tools appear hungĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
Dimillian/CodexMonitor#612 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Dimillian/CodexMonitor#602 · 1 bình luận · 1 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
Dimillian/CodexMonitor#599 ·
Tất cả issue của Dimillian/CodexMonitor
Issue tương tự
-
status: needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
a2ui-project/a2ui#3158 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
hemilabs/ui-monorepo#2475 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
lingdojo/kana-dojo#32279 · 1 bình luận · 5 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
code-quality refactoring
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
github/gh-aw-firewall#9879 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Arrow-key cursor movement in combined diff view doesn't scroll to keep the cursor visibleĐang mởos:macos
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
Maintainer thường phản hồi trong vòng 1 ngày