Topic hub
Counting what your customers used, in a way that still holds up months later when one of them disputes the number. 51 articles on ingestion, dedupe, meter design, rating and storage — grouped in the order the problems actually bite.
An invoicing bug is visible and correctable — you issue a credit note and move on. A metering bug is not: an event that was never counted is gone, because the traffic has passed and there is nothing left to replay. That asymmetry is why metering deserves its own design attention rather than being treated as the easy half of billing.
Everything below is written from systems that are running, including the mistakes. Where a section describes a bug, it is usually one this codebase has had.
What a metering system has to guarantee before anything downstream of it can be trusted, and the shape of the API that provides it.
A metering API has one job a normal API does not: every event it accepts must still be countable, exactly once, months later, in front of a customer disputing the number. Idempotency windows and scope, event identity versus request identity, late and out-of-order events, aggregation changes mid-period, price versioning, and explainability.
September 5, 2026 · 10 min read
Most billing API evaluations start at the invoice endpoint, which is the end nobody fails at. Projects fail at ingestion: idempotency, late and out-of-order events, live balances, price changes that must not restate closed periods, and proving how a number was derived. The five questions to ask, and the bad answers to listen for.
August 26, 2026 · 9 min read
A usage meter that bills customers must count each event exactly once even when delivered twice, and still get the count right when events arrive late or out of order. How to do it with a stable per-event identifier, a dedup window, and an acceptance window, with the documented behavior of Stripe meter events, OpenMeter, and Lago.
June 2, 2026 · 9 min read
Most usage-pricing writing is about reading the meter your vendor gives you. This is about the layer underneath: the database that records usage and turns it into an invoice line. The default choice - a plain SQL usage_events table - breaks on the four invariants billing actually requires: idempotency (retries double-count without a stable event_id), immutability (mutable rows destroy the audit trail behind every charge), cheap account-month totals (SUM over millions of rows under a lock does not scale), and correctness under late data (a corrected event after you have invoiced silently changes a number you already billed). What a purpose-built metering store does instead: dedupe on ingest, append-only immutable segments, rollups as the fast path with raw as the truth and a raw-vs-rollup verify, and period close with a frozen snapshot plus pending adjustments. Why this is a real database problem - the same one driving the 2026 metering acquisition wave - and how UsageBox gives you idempotent, auditable, reconcilable invoices without the build.
June 15, 2026 · 9 min read
Ingestion is where billing projects actually fail. Retries, late arrivals, at-least-once collectors, and the counting that has to stay correct through all of it.
How we handle retries, idempotency, and observation so ingestion stays reliable under load.
July 24, 2025 · 10 min read
How usageDb turns an acknowledged usage event into a durable, billable fact: the three-phase ingest critical section, the fsynced write-ahead log, Strict vs Fast durability modes, and the memtable re-insert rule that keeps a failed flush from silently stranding data.
June 4, 2026 · 9 min read
How usageDb guarantees each billable event is counted exactly once: stable event_ids, blake3 128-bit payload hashing, the accepted/duplicate/conflict/rejected buckets, and cross-restart dedupe rebuilt from WAL and raw segments.
June 4, 2026 · 9 min read
We walk through how Firebase Auth, Firestore, and UsageBox work together to keep dashboards and alerts current to the minute.
October 8, 2025 · 5 min read
Ship containerized usage ingestion with GitLab CI, Docker Hub images, and environment promotions that keep billing data reliable.
December 19, 2025 · 8 min read
See the 2025 fixes, pricing tiers, FinOps alerts, and UsageBox meters, that stabilized us after 1M+ daily events melted our DIY billing.
August 17, 2025 · 10 min read
A meter is a value type, a unit and an aggregation. Those three choices decide what your invoice can say, and two of them are painful to change afterwards.
A billing meter is a small schema decision with invoice-sized consequences: value type, aggregation (sum, count, max, unique_count), and unit decide what you can ever bill. What each aggregation means, the mistakes that force re-metering, and the five lines to write down before your first event.
August 22, 2026 · 8 min read
Analytics MAU dedupes by cookie and misses blocked clients; billable MAU must be exact and reproducible. How to meter distinct users with a unique_count meter, which identifier to use, what counts as active, and how to verify the number before anyone is charged.
August 22, 2026 · 8 min read
All three count requests, so teams build one and pretend it covers the rest - then get an outage, an angry customer, or an indefensible invoice. The three questions, the three clocks, the failure modes of conflation, and the architecture where each counter does its own job.
August 22, 2026 · 8 min read
How to package raw events, sampling rules, and pagination so finance teams trust every response from your /usage API.
July 8, 2025 · 11 min read
Every product has usage that resists a simple counter — cached reads, sub-agents, crawlers, resold capacity, other people’s customers.
Prompt caching is the best per-call cost lever in 2026 - up to 90% off repeated context, stackable with batch discounts to ~25% of standard rates - but it quietly breaks cost tracking. A cached request still reports the full input-token count, so any tracker that multiplies total input tokens by the standard rate overstates spend on cache-heavy workloads (up to ~10x) and hides whether caching is working at all. The bug is real and current: the LiteLLM team logged "Anthropic cost tracking inaccurate for cached usage" (LIT-3771) in its June stability sprint, with an enterprise customer confirming it in production. The fix is an accounting rule, not a discount: meter cache writes, cache reads, and uncached input as three separately-priced events, and your dashboard goes from lying to load-bearing - surfacing both true cost and cache hit ratio.
June 18, 2026 · 6 min read
A single agent run fans out into tool calls, sub-agents, parallel branches, and silent retries, then returns one opaque token total - and the expensive question (which customer, feature, step, and model burned the spend) cannot be reconstructed from it after the fact. Attribution is a write-time property: every model call has to be tagged with a few dimensions (trace id, customer, feature, step, model) and emitted as a usage event the meter rolls up by any of them. This explains why provider exports and application logs cannot attribute agent cost, the exact dimension set that makes a token traceable, and the idempotency rule (count each event id once) that stops retries and at-least-once collectors from double-counting an agent's own spend. For AI products, attribution is not a report - it is the billing system.
June 22, 2026 · 8 min read
When you bill per request, per API call, or per GB, AI crawlers and scrapers can inflate a customer's usage and your own infrastructure bill. One developer was charged for 11 million Meta crawler requests in 15 days, and robots.txt will not save you because it is advisory. How to detect bot traffic, define what counts as billable, and exclude non-human events at the meter before they reach an invoice.
June 4, 2026 · 9 min read
Agencies running AI workloads for brands and platforms hosting tenants have a different billing question: what did each client consume, at what margin. Why a client tag is not a tenant, the parent-child account pattern, per-client margin views, and adopting the hierarchy before it hurts.
August 22, 2026 · 8 min read
Capture ingestion, retrieval fan-out, and context expansion so RAG invoices mirror knowledge-base value.
November 23, 2025 · 8 min read
Combine device events, edge inference, and OTA actions into a single ledger your customers can trust.
November 27, 2025 · 7 min read
RapidAPI enforces plan quotas at its gateway, but providers who need per-subscriber usage, cost-shaped dimensions, or marketplace and direct-channel parity need their own meter behind it. The proxy-secret trust model, subscriber auto-provisioning, the plan-sync webhook, and reconciliation that ends arguments.
August 22, 2026 · 9 min read
Metering produces quantities. Rating turns them into amounts, and the step between the two is where pricing decisions become reversible or permanent.
The unit you measure and the unit you bill are not the same unit, and collapsing them is what makes AI pricing impossible to change later. What each of the four units really costs to implement, where each one breaks, what outcome pricing actually requires, and the architecture that lets you switch between them without re-instrumenting your product.
September 5, 2026 · 11 min read
Selling prepaid credits on top of a usage meter is a small ledger with an ordering policy, not a wallet balance. How Stripe billing credits, Orb credit blocks, and Lago wallets each decide which credit burns first, what expires, how overage is billed, and what happens to a late event against an already-expired block.
June 4, 2026 · 9 min read
Use our 2025 token cost matrix, quota calculator, and runbook to stop surprise invoices while keeping AI usage flexible.
July 28, 2025 · 11 min read
How we divide responsibilities between Stripe and UsageBox so invoices stay accurate and auditable.
September 14, 2025 · 7 min read
The workflow we use to turn raw usage events into ASC-606 ready revenue entries without nightly scripts.
September 30, 2025 · 8 min read
A hands-on kata: take a raw AI usage event - a chunk of Claude tokens, a tool call, a credit burn - and turn it into a stable, auditable invoice line using UsageBox, in about 30 minutes, without building a billing database. Six steps against the real metering API: send your first usage event; make retries safe (idempotent dedupe by event_id, with same-id-different-payload surfaced as a conflict); read a cheap month-to-date total from rollups; pull the immutable audit trail behind a disputed line with /explain; close the period to freeze the invoice while corrections land as net adjustments; and run a raw-vs-rollup /verify so the fast number always equals the true number. Plus production notes, kata variations (per-model cost, live spend caps, vendor-bill reconciliation, ad-hoc SQL), and what you just avoided building.
June 16, 2026 · 7 min read
Why usage data resists a normal database, and what a purpose-built one does differently — written up from the engine underneath UsageBox.
usageDb is the open-source Rust storage engine behind UsageBox: append-only, immutable, idempotent, with hourly rollups built in. Apache-licensed on GitHub.
May 16, 2026 · 8 min read
usageDb is an open-source Rust storage engine for AI usage metering and billing. Part 1 of a 10-part internals series: the four billing invariants, the end-to-end architecture, the module map, and the UsageEvent data model.
June 4, 2026 · 8 min read
How usageDb precomputes account-month usage totals with hourly rollup segments and a manifest watermark, the three safety bounds the rollup worker respects so it never crosses unflushed or still-arriving data, force-drain, the COUNT caveat, and rebuild_rollups.
June 4, 2026 · 9 min read
How usageDb billing period lifecycle keeps invoice totals stable: closing a period captures a frozen snapshot, late Usage events are rejected, and Corrections surface as named, summed, auditable adjustments with a net_total.
June 4, 2026 · 9 min read
How usageDb's custom .seg columnar format uses dictionary, delta, zigzag-varint, run-length, and plain encodings plus per-column zstd and a blake3 checksum to turn huge but repetitive AI usage data into tiny, cheap-to-scan immutable billing audit segments.
June 4, 2026 · 9 min read
How usageDb keeps its single source of truth durable: temp-and-rename atomic commits with a parent-directory fsync, numbered manifest generations that roll back past a corrupt write, fail-closed recovery, and an exclusive process lock.
June 4, 2026 · 8 min read
How usageDb background compaction merges many small per-bucket segments into one well-sorted, well-compressed output, swaps it in through an atomic manifest commit, and defers deletion of the old immutable files behind a reader grace period so no in-flight query ever fails.
June 4, 2026 · 8 min read
How usageDb reads usage data back: two query paths, a deliberately strict SQL subset that refuses ambiguous billing queries, segment pruning from per-segment metadata, half-open time ranges, and explain/verify provenance endpoints.
June 4, 2026 · 9 min read
How usageDb, the open-source Rust usage database behind UsageBox, verifies its billing invariants: proptest property tests over thousands of random inputs, plus deterministic simulation testing that runs random crash, restart, and manifest-corruption sequences against a parallel reference model.
June 4, 2026 · 10 min read
Stripe took Metronome, Adyen took Orb, Salesforce took m3ter and Kong took OpenMeter. The buying question changed from which product is best to whose ecosystem you are joining.
Stripe took Metronome, Adyen took Orb, Salesforce took m3ter. A side-by-side of Stripe Billing, Metronome, Orb, Lago, Flexprice, OpenMeter, Amberflo, Chargebee and UsageBox — what each one meters, where each one stops, and the five questions to ask before you commit to an ecosystem.
September 5, 2026 · 11 min read
Metronome is a Stripe product as of January 2026. If you chose it for a metering engine that was independent of any payment processor, that is the part that changed. Orb, Lago, Flexprice, OpenMeter, Amberflo, Chargebee and splitting the meter from the biller — what each is good at, when not to move at all, and a migration checklist.
September 5, 2026 · 9 min read
Lago is one of the few usage-billing platforms an acquisition cannot take away from you, and for many teams the right answer is to stay. Two things comparisons miss: the free self-hosted stack is not the one behind its throughput numbers, and AGPLv3 has real terms. Flexprice, OpenMeter, Amberflo, Chargebee, Orb and Metronome, matched to the complaint you actually have.
September 5, 2026 · 9 min read
Adyen closed its acquisition of Orb on 1 July 2026 and runs it under an incubator model, so nothing breaks today. The sentence to read carefully is that multi-PSP support "continues initially". Metronome, Lago, Flexprice, OpenMeter, Amberflo and Chargebee compared, plus how to tell whether you actually need to move.
September 5, 2026 · 9 min read
OpenMeter is Kong's, but it is Apache 2.0 — so unlike the other 2026 acquisitions, nothing can be taken back from a version you already have. What changed is the centre of gravity: it is becoming Konnect Metering & Billing. Lago, Flexprice, Amberflo, Metronome and Orb compared, and why the real question is whether you run Kong.
September 5, 2026 · 8 min read
Flexprice is the credits-native option — AGPL-3.0, self-hostable, publicly priced, on a Postgres–Kafka–ClickHouse–Temporal stack. Lago, OpenMeter, Amberflo, Metronome, Orb and Chargebee compared against it, plus the five things that make building a credit ledger yourself harder than it looks.
September 5, 2026 · 9 min read
Most teams looking for a Stripe Billing alternative have a metering problem, not a Stripe problem — and Stripe's own answer to it is now Metronome, which is also Stripe. How to tell the three complaints apart, when putting a metering layer in front of Stripe beats replacing it, and the real options if you are leaving the payment rail too.
September 5, 2026 · 8 min read
Stripe took Metronome, Adyen took Orb, Salesforce took m3ter, Kong took OpenMeter. Four acquisitions changed the buying question from which product is best to whose ecosystem you are joining — and why they all bought rather than built says something useful about how hard metering actually is. What to ask a vendor now, and why keeping raw events exportable is the cheap insurance.
August 26, 2026 · 7 min read
We share the staffing, maintenance, and opportunity costs that shaped our billing platform choice.
July 4, 2025 · 13 min read
Disputes, drift, retry storms and bill shock. The failure modes are predictable, which means most of them are preventable at design time.
How we trace a disputed charge back to the exact usage events and pricing rule that generated it.
September 2, 2025 · 5 min read
Detect token creep, tool bloat, and retry storms with real-time policies and evidence-led alerts.
December 4, 2025 · 7 min read
Why did one day of AI cost more than a month of servers? A retry storm. When a model call times out or 5xx's, retry logic fires again, and each attempt that reaches the provider is a fresh, fully-billed generation - even the ones your app throws away. A slow provider hour plus aggressive retries plus concurrency multiplies spend by the retry count, with no fixed ceiling the way a server bill has. The five controls that cap it (hard retry limit, exponential backoff with full jitter, circuit breaker, retry only retry-safe statuses, idempotency keys), why 429s are a trap, and why the meter has to count attempts - not just successes - so the storm shows up the same day instead of on the invoice.
July 24, 2026 · 7 min read
The June 2026 revolt against metered AI billing (the GitHub Copilot credit switch, "pay the same, get anxiety for free", Cursor forced usage pricing) is real, but the diagnosis is wrong. Usage-based pricing is not the betrayal. Shipping usage-based pricing without real-time metering, pre-flight cost, and enforcing caps is. The four engineering properties trust actually requires.
June 6, 2026 · 9 min read
Close the gap between what a model vendor like Anthropic or OpenAI bills you and what you metered and charged customers. A hands-on kata: pull your per-model total, verify your own rollups against a raw scan before you blame anyone, lay your number next to the vendor invoice, localize the gap with /explain and dimensions, separate a metering gap from unbilled pass-through overhead (retries, cached reads, system-prompt tokens), and close the loop with Correction events so the audit trail proves the reconciliation. Production notes, variations (daily reconciliation, per-customer margin), and FAQ.
June 16, 2026 · 8 min read
Week-by-week tasks that keep engineering, finance, and support aligned during a billing migration.
September 10, 2025 · 9 min read
UsageBox is the metering layer, not a billing suite: idempotent ingest with a documented dedupe window, a stated late-event policy, per-account key scoping, and raw events you can export.