Why provider billing APIs are daily, not real-time
Last verified
Every major provider's billing API reports daily. OpenAI, Anthropic, xAI and Google Cloud Billing all work this way. It is not an oversight, and no amount of polling changes it.
Why
Billing is an accounting system, not a telemetry system. Between your request and a dollar figure sits metering, aggregation across a distributed fleet, rate-card application, discount and credit reconciliation, and correction for failed or partial requests.
That pipeline is built for correctness — the numbers have to survive an invoice dispute — and correctness at that scale costs latency. A system optimised to tell you within seconds would be a different system with different guarantees.
What that means for you
You cannot build a real-time spend alarm on billing data. The tightest loop available is roughly daily. A tool that promises real-time spend from a billing API is either wrong or estimating.
"Real-time" in this space means one of two things:
- A proxy. Your requests route through a third party that counts tokens as they pass and multiplies by a price table. Genuinely fast, at the cost of putting a vendor in your request path — see proxy-based vs billing-API cost tracking.
- Local estimation. Count tokens client-side, multiply by published prices. Fast, free, no third party — and drifts from the invoice whenever caching, batch discounts, or price changes apply.
Both are estimates. Only the billing API tells you what you will actually be charged.
A clean chart right after a leak proves nothing. This is the operationally dangerous consequence. If you suspect a key was compromised an hour ago, the billing data will very plausibly still look fine. Revoke on suspicion; do not wait for the chart to confirm it. How to tell if someone is using your key.
Designing around it
Daily is genuinely sufficient for the thing most people actually need. The failure mode people experience is not "I found out 6 hours late" — it is "I found out 3 weeks late, from an invoice."
So:
Hard limits for the worst case. A provider spend limit is the only control that bounds your maximum loss regardless of how late you notice. OpenAI spend limits: hard, soft, and what they miss.
Daily review for the normal case. One number, once a day, compared against what normal looks like. That catches runaway loops, model changes, and leaked keys within a day — which is early enough for all three to be recoverable.
Local counting for the tight loop, if you need it. If you must know cost per request as it happens, count tokens in your own code and treat it as an estimate. Reconcile against the billing API weekly.
The honest positioning
Since this is TKN's site: TKN reads billing APIs, so TKN is daily. It will not page you 90 seconds into a runaway loop, and any tool claiming it can — without proxying your traffic — is overselling.
What daily gets you is the thing that actually matters: knowing before the invoice instead of after it, with a kill switch attached for when the answer is bad. That's a smaller claim than "real-time", and it's the true one.