Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Local usage overcounts resumed sessions by treating inherited cumulative totals as new usage

Ouverte
  • Quelque chose ne va pas ?
#616 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

@Huang-siyuan y travaille déjà.

Depuis le 9/10/2026.

  • #617 par @Huang-siyuan — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
backend, data

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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, commit dd61b9abd37de5ded86e82b9fe8a83fd49d46fa5 (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.usage where available, with deduplication by response_id across 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_count display 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_usage when 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.

Langage dominant
TypeScript
Étoiles
4.3k
Forks
415
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Dimillian/CodexMonitor

Toutes les issues de Dimillian/CodexMonitor

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.