Two $ai_generation fidelity bugs in the Claude Code session ingest

[mory91]

Hi! Two small bugs in the Claude Code session-end ingest path that affect what PostHog sees on $ai_generation events. Both reproduce on the current main (a004aa2). Happy to PR if useful.

1. Cache token properties missing the $ai_ prefix

posthog_llma/events.py → build_ai_generation emits:

properties = {
    ...
    "cache_read_input_tokens": cache_read_tokens,
    "cache_creation_input_tokens": cache_creation_tokens,
}

PostHog's LLM Analytics cost pipeline only reads the $ai_* namespace (docs call out $ai_cache_read_input_tokens / $ai_cache_creation_input_tokens), so cache reads/writes are dropped on the floor and $ai_total_cost_usd is computed from input+output only.

For Anthropic prompt-cached workloads the cache buckets dominate the bill, so reported cost can be ~25x lower than the actual spend. Concrete example from a real session: cache_read=150,109, cache_write=75,729, input=4, output=926 — PostHog showed ~$0.014, actual cost ~$0.343.

2. Extended thinking is emitted as {"type":"text"} instead of {"type":"thinking"}

posthog_llma/parser.py → _finalize_generation concatenates thinking and text blocks into a single output_text string, and event_builder.py → build_events wraps that as one text block:

content_blocks = []
if gen["output_text"]:
    content_blocks.append({"type": "text", "text": gen["output_text"]})

So when a Claude Code generation has both thinking and text blocks (common with extended thinking enabled), thinking content appears as plain assistant text in the PostHog UI instead of a dedicated thinking block — losing the visual distinction and breaking property queries that filter on block type. The streaming-merge work from #86 already tracks blocks by type in state["blocks_by_type"], so the typing info is right there in _finalize_generation, just collapsed before emission.

Thanks!

[grundmanise]

Confirming bug #1 still reproduces in marketplace build v1.1.41 (~8 months on). Second data point from a GitHub Actions run (claude-code-action@v1, model claude-opus-4-8, EU cloud) — single trace, 5 $ai_generation events:

• input 12,345 / output 8,492 tokens
• cache_read 143,394 / cache_creation 32,119 (sent as cache_read_input_tokens / cache_creation_input_tokens, no $ai_ prefix, exactly as you describe)
• PostHog $ai_total_cost_usd (summed) = $0.274, and in every event it equals input_cost + output_cost exactly → cache priced at $0
• Claude Code CLI total_cost_usd (authoritative) = $2.9939

One extra note: for our run the prefix fix alone doesn't fully close the gap — repricing the captured cache at standard Opus 4.8 rates (~$0.50/M read, ~$6.25/M write) only reaches ~$0.55, still ~5× under the billed $2.99. Could be Fast Mode / 1h-cache-TTL rates, or the parser under-counting generations — flagging in case it's separate. (Your Sonnet example reconciles exactly with the cache fix, so this residual may be session-specific.)

Robust alternative: Claude Code already computes an authoritative total_cost_usd — forwarding it (per-generation $ai_*_cost_usd, or session-level on $ai_trace) would make cost exact regardless of rate/TTL edge cases.