Cost · · 3 min read
Agent spend, before the invoice
Agent spend accrues in thousands of small calls attributed to keys, not agents, until the invoice adds it all up for the first time. A usable floor reports it daily, by agent, with the gaps shown as gaps.
A team running seventeen agents in production described their spend visibility to Hacker News in one line: "The UI for all of that spending was our credit card statement. Once a month. After the fact." (HN) The team had seventeen agents built and shipped, so competence was not the issue. Nobody owned the number between an agent running and what it cost, and it surfaced wherever charges got added up first.
Why the default is invoice lag#
Agent spend arrives as thousands of individual token charges, one per model call, and a task takes a handful of calls or a few hundred depending on tool uses and retries. A routing layer often splits them across providers, choosing whichever model looks cheapest or fastest for that step.
Each charge bills to an API key, often shared across every agent a team runs, so the provider's usage page shows key-level totals with no per-agent breakdown. Someone has to build the join between key and agent before the number means anything. Until then, the invoice is the first place the charges get summed into a readable total, because it is the only aggregation that happens automatically.
The same gap shows up at small scale in a Show HN: a founder left an agent running, walked away for twenty minutes, and came back to a thirty-two dollar bill he did not expect. Nothing capped it at twenty minutes; it ended there because that is when someone checked.
What the floor should look like#
A usable floor has three parts.
- Month-to-date dollars and tokens by agent, not by API key, visible at any hour. If a key is shared, the runtime attributes each call to the run that made it at the moment of the call. A dashboard that reports only at the key level has not closed the gap; the invoice just arrives on a shorter loop.
- A projection to month end, built from the trend so far. "On pace for $4,200 this month" is a number someone can act on before the 30th. A running total with no trendline only reports what already happened.
- An honest account of runs with no usable cost evidence. A call can fail before the provider logs usage, a retry can duplicate a charge, and a proxy can drop the token count. Show each as a flagged gap. Dropping the run from the total, or counting it as free, leaves a team with a dashboard and no answer when asked what a run cost.
In Deixic, agent spend shows month-to-date model spend by agent.
Spend as its own approval class#
Past a threshold your team sets, a spend event deserves the same treatment as a production write: it waits for a human to see it before it executes. That is the negative-lag reasoning that applies to a database delete, applied to a dollar figure. A four-figure anomaly discovered on day thirty is a line item nobody can explain later, and one caught before it clears is something someone can ask about.
Ask your team this week what agent X cost yesterday. There are two acceptable answers: a number, or a flagged gap naming the runs it could not account for. Any other answer is the one to fix first.