Setting the file. One moment.
Skill 104 · Resolving Ingestion Warnings
Subchapter 104.9
references/fixing-invalid-ai-token-property.mdMarkdown2 KBView on GitHub
An AI event ($ai_generation, $ai_span, …) carried a token property that wasn’t a valid number — $ai_input_tokens, $ai_output_tokens, or a similar count sent as a string, object, or malformed value.
The event was ingested but the property was nulled.
Category event, severity warning: token usage and cost analytics silently lose that data point.
Token counts must arrive as plain numbers. The usual sources of bad values:
"1204", "1,204", "1204 tokens",usage instead of usage.total_tokens),NaN/undefined from a missing usage block on streamed or failed responses.posthog:execute-sql: SELECT timestamp, details FROM system.ingestion_warnings WHERE type = 'invalid_ai_token_property' AND timestamp > now() - INTERVAL 7 DAY ORDER BY timestamp DESC LIMIT 20. The details JSON names the exact property, the received value, and its valueType — that’s usually the whole diagnosis.$ai_* properties (manual capture or instrumentation wrapper) and check the types.Send numbers:
posthog.capture({
distinctId,
event: '$ai_generation',
properties: {
$ai_input_tokens: response.usage.prompt_tokens, // number
$ai_output_tokens: response.usage.completion_tokens, // number
},
})Guard the missing-usage case (streamed/failed responses): omit the property rather than sending undefined or a placeholder. Prefer PostHog’s LLM analytics SDK integrations over hand-mapping usage fields — they handle provider differences.
Re-run a generation, re-query system.ingestion_warnings with posthog:execute-sql (filter type = 'invalid_ai_token_property', timestamp after your fix) — no new occurrences — and confirm token counts and costs appear for new traces (posthog:query-llm-traces-list).