Collector: Crush

[willwashburn]

Target

Crush (crush.ai) — AI coding agent.

Data

• Path: crush.db (SQLite), location varies per project — tokscale resolves via \$XDG_DATA_HOME/crush/projects.json (project registry), fallback ~/.local/share/crush/projects.json
• Format: SQLite with a sessions table that stores cost only, no per-message tokens
• Auth: Passive read only

References

• tokscale: crates/tokscale-core/src/sessions/crush.rs (442 lines) — the reference implementation.

Coverage

• Session ID: yes
• Model: yes
• Usage: cost only. No token-level breakdown at all. Tokscale allocates session cost proportionally across local-day buckets, using assistant message count as the weighting factor.
• Cache: not available
• Tool calls: not available

Gotchas

• Weakest granularity in the catalogue — even weaker than Mux (#next, aggregate per-model) because Crush doesn't even have token counts, only dollar cost. For burn's meta-goal, a Crush-only session is essentially opaque.
• Cost-only semantics affect all downstream features. burn waste, burn claude-md, per-tool-call attribution, subagent trees — none of these can work on Crush data. Reader should set TurnRecord.granularity: 'cost-only' and emit a TurnRecord.usage with zeros but a non-zero derived cost field.
• Schema may evolve. Crush is a young product; if they add per-message tokens later, the reader should handle both the cost-only and token-bearing schemas. Defensive field access.
• Project registry indirection. The projects.json file tells the reader where each project's crush.db lives. Walker must go through the registry, not scan /Users/foo/.local/share/crush/ directly.

Work

• Implement packages/reader/src/crush.ts emitting TurnRecord with source: 'crush'.
• Introduce TurnRecord.granularity field (shared with Mux collector issue) — values like 'per-message' (normal) vs. 'cost-only' (Crush) vs. 'per-session-aggregate' (Mux). Consumers skip low-granularity data in tool-call-attribution views.
• Walker reads projects.json to find DB locations.
• Fixtures under tests/fixtures/crush/ with a representative DB + projects registry.
• Wire into ingest walker.

Priority

Very low. The data is too thin to support burn's diagnostic features. Add if a user asks for cost-total coverage — but don't promise more than that.