Spend · Spend by topic
Spend by topic
Telemetry already answers what the AI spend cost per repo, developer, and model. The Spend by topic sub-tab (under Spend, Telemetry) adds the workstream dimension: every captured session is grouped into a topic named from its own prompts, joined to what those sessions cost. Sessions that do not group honestly read unclustered, never force-assigned, and topic costs plus the unclustered remainder always sum to the window's captured spend.
Lexical topics (the default)
The default mode is deterministic and free. Each session contributes one digest (its first prompt plus any reviewer label, capped at a 240-character preview, never a full transcript), and digests cluster with character n-gram similarity: no LLM, no embeddings, no network. The same window always produces the same topics, so a number quoted in a review meeting can be recomputed exactly.
Semantic generations and pinning
The Regenerate topics (semantic) button embeds the same digests (on-device model by default, your own embedding key when configured) and clusters them by meaning. Each run is saved as a generationyou can pin as the tab's default; unpin and the live lexical view returns. The newest 10 generations are kept; a pinned one is never pruned.
Initiatives
Initiatives are an explicit, operator-owned mapping, never a guess. Two ways to assign spend:
- Repo level: an optional
initiativefield on a repo inrepos.config.jsonclaims all of that repo's session spend. - Topic level:the Initiative column on the tab assigns one topic's spend; assignments live in a local file (
spend-initiatives.jsonin the data dir).
Repo level wins: a session in a repo with a repo-level initiative counts once, under that initiative, even when its topic is assigned elsewhere. Whatever neither mapping covers reads unassigned, so the rollup rows plus unassigned always sum to the captured spend.
What spends tokens, when
| Action | Spends tokens? |
|---|---|
| Lexical topics, initiative assignments, the rollup | Never. Deterministic, offline. |
| Semantic regenerate with the on-device model | Never. No keys involved. |
| Semantic regenerate with a BYOK embedding provider | Yes: embedding tokens, bounded to at most 500 digests of 240 characters per generation. |
| The LLM-labels checkbox | Yes: one short Haiku call per generation through your own key, counted against the daily synthesis cap. The unattended nightly refresh never takes this path. |
On the hosted dashboard
With a bound device, cloud sync on, and spend-topics publishing enabled, the desktop pushes a distilled snapshot (top topics plus the initiative rollup; no prompt excerpts, no session ids, no developer names) once per hour, and the Leadership page renders it with an as-of stamp. No desktop publishing yet means an honest empty state, never a fabricated table.