Missing AI agent cost data is not zero

My agent spend ledger showed $0 for the day. The agents had run all morning. The number was a lie, and the bug behind it is one almost every cost tracker ships with.

Short version: when a provider's billing data has not arrived yet, a naive cost tracker records $0 for that period. For AI agents that run unattended, this hides the exact spending you built the tracker to catch. The fix is to model missing data as a distinct "unknown" state, never as zero, so a day you cannot measure reads as unmeasured instead of free.

Why a $0 day is the dangerous one

I run a fleet of scheduled agents. They digest articles, review drafts, sweep a queue overnight. Real model calls, real dollars. I built a daily spend ledger to answer one question every morning: what did yesterday cost, and am I about to blow the budget?

The first version summed whatever cost data it had and printed a total. Most mornings it printed a small number. Some mornings it printed $0.

The $0 mornings were not free mornings. They were mornings where the provider billing data had not reported yet. Usage lags. Some providers only give you a CSV export you pull later. So at 07:00 when the ledger compiles, the cost of the run that finished at 05:30 often is not available.

The ledger had no way to say "I don't know yet." It only knew how to add. No data plus no data equals zero. So it reported zero, looked green, and moved on.

The failure hides exactly what you were watching for

Here is why this is worse than a normal rounding error. Agents run while you sleep. A retry loop, a runaway tool call, a prompt that balloons context: these spend money at 3am with nobody watching. That unattended spend is the whole reason a budget tracker exists.

Billing lag and runaway spend show up at the same time. The surprise charge arrives late from the provider, which means the day it happened is precisely the day your ledger had no data for. A tracker that reads missing data as $0 fails in the one situation you built it for. It tells you everything is fine on the days you most need a warning.

Model three states, not one number

The fix is small, and it is a data-modeling fix, not a math fix. A cost period has three states, not one:

A day with no billing data is unknown. The report says so in plain words. It does not get to pose as a cheap day. When the provider export lands, the day flips to known and the real cost backfills in.

This sounds obvious written down. It is the same null-versus-zero bug that has burned every database schema since forever. Zero is a measurement. Missing is the absence of one. Collapsing them throws away the single most important fact: whether you actually know.

What this looks like in practice

My ledger now writes one of those three states per source per day. If an export has not been pulled, that line says unknown, and the daily total carries an "incomplete" marker until every source reports. I would rather see "we cannot confirm yesterday's spend" than a confident, wrong $0.

The rule I wrote down for every agent that touches the ledger: missing provider billing data is not zero. Mark it unknown until a real export or API confirms the number.

That one line stops the green-dashboard trap. A system that defaults to zero when it is blind will always look healthy in the moment right before the bill teaches you otherwise.

Stop the spend, do not just measure it

The ledger tells you what a run cost after the fact. It does not stop a run from spending the money in the first place. For that you want a hard cap on the agent itself.

That is what I built AgentGuard for: a budget, token, and rate limiter you wrap around an agent so a runaway run stops at a ceiling instead of grinding until the invoice surprises you. It does not care whether your billing data has arrived. It counts spend as it happens and pulls the plug at the number you set. Free to install: pip install agentguard47.

What does your cost tracker show on a day the billing data is late: a real unknown, or a comforting $0?