Usage data: deeper capture and quality fixes

[iamtoruk]

Findings from analyzing the first three days of usage snapshots (Jul 16-18, 25 installs). One ticket, six work items:

Deeper capture

• Per-provider breakdown in the daily snapshot. Today only providerCount is sent; the payload already has payload.current.providers keyed by name (app/renderer/App.tsx, usageSnapshotProps). Add providers: [{ name, costBucket }] (top 8), mirroring the models shape. Payload change is add-only per the CLI/app contract. Verify the API sanitizer allowlists the new field. This answers "which agent gets the usage/spend" (claude vs codex vs cursor vs gemini), which model names alone can't attribute.

Data quality

• Raw model ids leak through un-normalized. fireworks/models/kimi-k2p7-code, fireworks/routers/glm-fast-latest, etc. arrive verbatim while other rows carry display names. Same root as the provider display-name issue from the July audit.
• MODEL_PLACEHOLDER_M26 reported as a real model by one install — a placeholder from the normalization table shipped. Find and fix the table entry; consider a guard that drops MODEL_PLACEHOLDER_* names at the source.
• Skills came back empty in all 25 snapshots; MCP servers appeared exactly once. Either usage really is that rare or the collection path is broken/over-sanitized. Verify end-to-end locally with a profile that has known skill + MCP activity.

Robustness

• Client-side rate-limit cli_error. One 0.9.15 install emitted 804 timeout errors in a single day (56% of all events ever received). Cap per kind per day, or dedupe repeats.
• app_close almost never fires (1 close vs 48 opens) — the quit path races the outbound POST. Fix the flush-on-quit, or drop the event and derive session length another way.

[iamtoruk]

First three items landed in #742: per-provider snapshot capture, MODEL_PLACEHOLDER guard at both Antigravity resolution paths, and last-path-segment display fallback for unmapped path-style ids. Remaining: skills/MCP collection verification, cli_error rate limit, app_close race.

[ozymandiashh]

Picking up the three remaining items, to avoid anyone duplicating work: skills/MCP collection verification, the cli_error rate limit, and the app_close race. Work in progress on my fork, PRs to follow.

Verification result for the skills/MCP item, from a skills-heavy profile (dozens of Claude Code skills, 8+ MCP servers, 11 session files with real Skill tool_use in the last 7 days): status --format menubar-json --period today returns mcpServers populated (2 entries) but skills: []. So MCP collection works and its rarity in the snapshots is just rare usage, while skills collection is genuinely broken, not over-sanitized.

Root cause, verified on code: skillBreakdown is populated exclusively from turn.subCategory (src/parser.ts ~1368), and the classifier only sets subCategory when the turn's category is general (src/classifier.ts ~211). But classifyByToolPattern checks hasSkill last, so any turn that invokes the Skill tool alongside Read/Bash/Edit/MCP gets a real category (coding, exploration, ...) and the skill attribution is silently dropped. Skill invocations almost always trigger other tools in the same turn, hence skills empty in all 25 installs.

Fix direction: decouple skill attribution from turn classification (attribute whenever the turn carries Skill tool_use, keep category semantics unchanged), plus a claude parse-version bump so cached session summaries re-parse. For cli_error: client-side cap per kind per day. For app_close: bounded flush-on-quit (quit can never hang on telemetry).

One data point for the 804-timeout hunt: my install is ruled out (telemetry disabled, EU default-off), so that outlier is someone else's box.

[ozymandiashh]

The three remaining items are now covered:

• Skills collection (verification + fix): fix(classifier): attribute skills to skillBreakdown regardless of turn category #745. Root cause was skill attribution gated on the turn classifying as general; details in my earlier comment. Validated on real data: after the fix the same skills-heavy profile that returned skills: [] now reports non-empty skills in the weekly menubar payload. Note in the PR: the TUI By Activity panel nests skill sub-rows under general only, a small display follow-up now that skills span categories.
• cli_error rate limit + app_close race: fix(telemetry): cap cli_error per kind per day, flush app_close on quit #746. Cap is 20 per kind per calendar day and persists across relaunches (so a crash-looping install stays capped); quit now waits a bounded 1500ms for the final flush, with every step guarded so telemetry can never wedge quitting, and app_close survives a full queue.

Both PRs ran the full local gates (typecheck, targeted and full suites) plus an adversarial multi-model review pass; the hardening items that review surfaced (persistent cap counters, full-queue eviction, independent quit guards) are already folded into #746.

[iamtoruk]

All six items landed: #742 (provider capture, placeholder guard, path-id fallback), #745 (skills attribution fix — MCP collection verified working, rarity was real), #746 (cli_error capped at 20/kind/day persisted across relaunches, app_close flushed with a bounded 1500ms quit race). Everything ships with the next release cut from main. Known follow-up tracked in #745: TUI By Activity panel nests skill sub-rows under general only.