LLM-COST

cost_alert_status() is read-on-view — nothing polls, emails, or pages it, so an alert is indistinguishable from no alert until a human opens the platform cost console. Two are firing (measured 2026-08-07 11:10 UTC): a daily_spend_spike of $27.44 against a trailing-7d average of $11.07 (a 2.48× multiplier), and an unpriced_model alert for openrouter openai/gpt-5.4 (35 events in 7d).

The unpriced model has no rate_card row, so its spend prices to nothing — 763,976 prompt + 11,501 completion tokens, first seen 2026-08-02, last 2026-08-03. The two layers disagree about how they hide it: the SQL layer prices to NULL and excludes the row, while the console's priceUsageRow returns a literal 0 and discloses it via a badge — the dollars are absent either way, but only one says so in the number. rate_card has 12 rows against 8 distinct (provider, model) pairs seen in the last 7 days, so this is a specific gap, not a starved card.

Two separable steps: (1) price the model — add the rate_card row, cheap and fixes the immediate under-count; (2) decide whether alerts need a channel at all — the enrichment_health_sweep pattern (pg_cron → internal-key endpoint → Sentry) already exists and runs 144/144 clean daily. A 2.48× day is exactly the thing you'd want to hear about without opening a tab.

The cost console compares our token-derived estimate against what providers actually invoice us — the only honest answer to "are these numbers right". Measured 2026-08-07 11:09 UTC: provider_billing_daily holds 5 rows, all hand-entered (source='manual'), 0 importer rows, last entered 2026-07-13, latest billing date covered 2026-07-12. So the panel compares live estimates against actuals ~4 weeks stale, and nothing in the UI says so.

The ElevenLabs importer exists and is deployed with ELEVENLABS_API_KEY set on the running mawja-api process, but its only caller is a dev_tools CLI subcommand — no schedule, endpoint, or cron — so it has produced zero rows. Precise framing: "reconciliation has stopped" overstates it — five manual entries is a process that was never started, not a cadence that lapsed.

What it costs: without actuals the estimate is unfalsifiable. The June reconciliation is the proof it matters — it validated the rate card as exact per-SKU against the Google invoice and attributed the gap to token under-capture in media extraction (~⅓ of billed tokens recorded), a finding only reachable with an invoice to compare. Options: automate the importers (the pg_cron pattern is proven — enrichment_health_sweep runs 144/144); keep it manual but make staleness visible ("actuals last cover 2026-07-12"); or decide it's not worth it pre-launch — but then the console shouldn't render a silently-degrading capture percentage.

The platform cost console renders revenue and gross margin per tenant, both computed from tenant_pricing — which holds 0 rows (measured 2026-08-07 11:09 UTC). The margin half of the unit-economics view has never had an input since it shipped; whatever it displays is derived from nothing.

This is a data gap, not a code gap — the code paths are deployed and correct, the table was simply never seeded, which is why it's filed as a decision rather than a bug. And it is not urgent for the reason it looks urgent: Mizo is not live and has no customers (every tenant is friends/family), so there is no revenue to represent — the question is "what should this surface do while there is no revenue".

Options: seed it when pricing is real and render the tiles as explicitly unavailable until then; hide the revenue/margin half and leave the cost side (real and well-populated) standing on its own; or leave it — but then "margin is zero" is indistinguishable from "margin is unknown". Options 1 or 2 both beat a number with no provenance sitting next to numbers that have plenty. Related to #3132: together they are the two data inputs the cost console's derived figures depend on, both empty or stale.