Built for AI products

Track AI usage.
Bill it accurately.
Without rebuilding your stack.

UsageBox meters tokens, GPU minutes, agent runtime, and tool calls per customer. Open-source storage engine. Connects to Stripe or your own invoicing.

Idempotent
Ingestion
Immutable
Audit trail
Open source
Storage engine
POST /v1/events
curl -X POST https://api.usagebox.com/v1/events \
-H "Authorization: Bearer $UBX_KEY" \
-d '{
"event_id": "req_8x42jk",
"account_id": "acme-co",
"meter": "llm_tokens_in",
"model": "claude-4.5-sonnet",
"quantity": 12450,
"timestamp": "2026-05-16T18:42:11Z"
}'
 
# Idempotent. Retries are safe.
# Rolls up hourly. Invoiced via Stripe.

Why generic billing breaks on AI workloads

Stripe Billing, Chargebee, Recurly: built for SaaS subscriptions in the 2010s. AI usage is a different shape of problem.

Volume breaks generic billing

Stripe's metered usage assumes thousands of events per customer per month. AI products send millions per day. Generic tools throttle, fail silently, or charge you per-event.

Attribution needs a graph

An agent run is N tool calls + M LLM calls + K memory ops. Each costs different amounts. Generic billing tools can't roll those into a single billable unit without engineering work you keep redoing.

Attacks show up in the bill

A user can manipulate prompts to trigger expensive generations. Without per-user spend ceilings and real-time anomaly detection, the first sign of an attack is your AWS or OpenAI invoice next month.

Built for the way AI products actually meter

Six primitives. Each one designed for the AI billing patterns generic tools fight you on.

Token Metering

Meter LLM input + output tokens per request, per agent, per tenant. Idempotent ingestion handles retries without double-billing.

GPU Minute Pricing

Bill inference time, fine-tuning runtime, or per-job GPU usage. Catalog-driven pricing rules; no code changes to update rates.

Per-Agent Cost Attribution

Track cost for each agent run across N tool calls + M LLM calls + memory ops. Roll up to tenant invoices automatically.

Real-Time Anomaly Detection

Cost-amplification attacks land in your usage data first. Per-user spend ceilings, alerting on token surges, kill-switches.

Hourly Rollups

Raw events feed hourly aggregates. Invoice generation is O(1) per account, not a scan over millions of rows.

Stripe + Manual Invoicing

Plug into Stripe for self-serve. Or generate finance-ready invoices for enterprise contracts. Same metering pipeline.

The storage engine is open source

usagedb is the Rust storage engine UsageBox runs on. Append-only, idempotent, immutable raw event audit trail, hourly rollups for invoice queries. Apache 2.0 on GitHub.

Read the code that produces every invoice line. Fork it. Self-host the ingestion layer while still using UsageBox for the platform side. The right answer to “is your billing math correct” is “read the code yourself.”

pbudzik/usagedb

Or read the architecture overview in our usagedb article, then go deep with the 10-part engine internals series: ingest, dedupe, columnar segments, rollups, the query engine, and how it is tested.

Notes on AI billing

Practical writing on metering patterns, AI cost attribution, and what we learn from production billing systems.

Token Metering vs Task Quotas: Why Claude Code and Kimi Code Stopped Billing You by the Token (2026)

The unit of AI billing is changing: the leading coding agents are switching from token metering to task and session quotas because agents made token spend impossible to forecast. Claude Code rate-limits by rolling 5-hour sessions (not message count); Kimi Code meters 300 to 1,200 API calls per 5-hour window. This breaks token-based cost tracking at the root - you can no longer forecast a session's token spend, because the thing being rationed is your access to run tasks, not tokens. When the unit of billing moves from tokens to sessions, your cost model and your meter have to move with it: meter both the session or task quota that governs access and the token cost that still accrues underneath.

Read →

Does a 429 Count Against Your Rate Limit? Yes - and It Can Cost You Tokens (2026)

A rejected 429 request still counts. On the major LLM APIs a call that comes back 429 Too Many Requests generally counts toward your rate limit and can still consume tokens from your quota, so retrying immediately turns a brief throttle into a self-inflicted retry storm that keeps you rate-limited longer and burns quota the whole time. AWS Bedrock and Azure OpenAI add a twist: they enforce quotas at the cloud-account level that you raise via a support ticket, not a settings toggle. A 429 is a real cost line - wasted tokens plus engineering time - and it is invisible unless you meter failed calls, not just successful ones. How rate-limit tiers work, why retry storms happen, and how to instrument the failures.

Read →

The Free AI APIs That Actually Stay Free in 2026 (No Credit Card) - and the Rate Limits You'll Hit First

There is a real tier of AI APIs that stays free with no expiring trial and no credit card: OpenRouter serves DeepSeek R1, Llama 3.3 70B, and Gemma 3 at zero cost, and Google's Gemini API keeps a free experimentation tier - most of it OpenAI-SDK-compatible, which is why a curated GitHub repo of permanently-free endpoints went viral. The catch the "free" label hides: every tier has a hard ceiling (requests per minute, requests per day, or tokens per minute), and the moment you outgrow it you are silently moved onto a paid meter with no cap. "Free" is not "unmetered" - it is a smaller meter you are not watching yet. The free APIs that stay free, the ceiling you hit first, and why you should meter usage even at $0.

Read →

Start metering AI usage in 5 minutes

Free tier. No credit card. Open-source storage engine.

Get started free →