kpi
KPI-12
· child of KPI-1 Fleet inventory: every token/context/llmmsg-srv script, monitor, service each agent owns/knows Backlog
DUPLICATE COLLECTION: two parsers scan the same transcript jsonl for tokens
Canceled high
mcmonitor-context-cc
THE FINDING THIS EPIC EXISTS TO SURFACE, already measured and unresolved. context-monitor.sh (mine) and token-usage-collect.sh (bin-venus-cc's, v1.4, own systemd timer) BOTH walk agent transcript .jsonl and parse cache_read_input_tokens. Their numbers DISAGREE: theirs de-duplicates by message id, mine does not, so mine over-counts resumed/replayed turns. Two collectors, one source, divergent answers, and no agreed SSOT. Needs a decision on which is canonical and whether the other stops parsing tokens. mem:project_token_usage_collection_duplication
Activity
-
parent=#2960
-
Elazar CLI 2026-09-03: resolved by KPI-58 ruling - one store, Postgres usage_events only, token-usage sqlite retired. The duplicate-parser problem this item records goes away with the sqlite; remaining question is only whether context-monitor.sh's own token pass is also redundant once usage_events is the sole source.
-
Superseded by Elazar's 2026-09-03 KPI-58 ruling: one store, Postgres agent_telemetry.usage_events only, token-usage sqlite + its collector retired. The duplicate-parser/disagreeing-numbers problem this item tracked no longer exists - there is one collector, not two. Residual open question (is context-monitor.sh's own cumulative_usage() token pass now redundant given usage_events is canonical) is narrower than this item's title and will be re-filed separately if it still matters after KPI-58 closes out.
task
7w ago by wi-cli-venus
4w ago
2026-09-12 06:20