Telemetry
Where the numbers come from, why some of them say "unavailable", and what is never sent off your machine.
Numbers are read, not estimated
Token counts come from the assistant's own transcripts on your machine. The plugin reads what the provider recorded and reports the aggregate. Nothing in that path tokenizes or estimates anything.
Cost is the exception, and it is labelled as one. It is computed from configured model rates, so it is an estimate rather than a bill, and usage with no configured rate is left out of the total rather than guessed at.
"Unavailable" means unavailable
This is the part worth understanding, because it changes how you read every screen.
- A failed request shows unavailable, never zero. An error is not turned into "0 runs, $0".
- A session with no recorded tool traces says so, rather than rendering an empty dashboard that looks like a quiet day.
- Evidence that cannot be classified is labelled Unknown, rather than counted as "no evaluation".
- A call with no linked policy decision says the link is missing, not that the call was unguarded.
A security tool that shows a reassuring blank screen when it is actually broken is worse than no tool, because you stop looking. Every one of the behaviours above exists so that a problem with the pipeline looks like a problem rather than like good news.
What leaves your machine
The plugin reports what your assistant did: tool names, timings, policy decisions, token counts, and session and device identifiers. It does not send your source code. The key written at install is scoped to run ingestion, and reads nothing else on the machine.
Checking the pipeline itself
The session detail screen carries an ingest health indicator, so you can tell a quiet week apart from a broken reporting path. If spans are being rejected or duplicated, that shows up there rather than as a plausible-looking number somewhere else.