fix(cli): a synthetic transcript message is not a billed request #686

What happens

Running aidd telemetry read against a real 5134-record session produced seven records with model: "<synthetic>".

They are not calls. Claude Code writes them into its own transcript as assistant messages it fabricated itself:

model: <synthetic>  usage: all counters 0
content: "You've hit your session limit · resets 10:40am (Europe/Paris)"

model: <synthetic>  usage: all counters 0
content: "API Error: Your computer went to sleep mid-response. The response above may be incomplete."

Why it matters, and why it is small

Every counter is zero, so no total is wrong. But <synthetic> shows up as a model in a by-model breakdown, sitting beside claude-opus-5 and claude-sonnet-5 as though it were one, and it inflates the record count. A reader who has not seen this issue will wonder what model that is.

The fix, and the rule behind it

A transcript message whose model is <synthetic> is not a billed request and yields no record. mapClaudeCodeTranscriptToSinkRecords currently emits one for it.

The general rule this belongs to is already stated in the phase's own acceptance criteria — an absent counter yields no record, never a fabricated zero. This is the same principle one step further: a present counter that is zero across the board, on a message the tool itself marks synthetic, is not an observation either.

Filter on the <synthetic> marker rather than on all-counters-zero. The marker is what the tool actually signals, and a real call whose counters all read zero — improbable, but not impossible — should still be recorded.

Done when

• A transcript containing a synthetic message yields no record for it, asserted against a captured fixture carrying one.
• A by-model breakdown of a real session lists only models.
• A message with all-zero counters that is not marked synthetic still yields a record, so the filter stays on the signal rather than on the symptom.

Relations