2026-07-04 · 5 min read
Pre-request vs post-hoc LLM billing
Every LLM product eventually faces the same architecture question: do you check budget before the API call, or reconcile usage after? The answer depends on your pricing model and how fast your customers can spend.
Post-hoc billing: measure first, bill later
Post-hoc patterns ingest token events, aggregate them in batch windows (30s, 60s, or longer), and update balances asynchronously. This is the default for most analytics pipelines and works well for post-paid SaaS where you invoice at month end.
The weakness shows up with prepaid wallets and agent loops. By the time your rollup reflects the spend, dozens more LLM calls may have already fired. You are always enforcing on stale data.
Pre-request enforcement: ask before you spend
Pre-request checks flip the order: GET /budget/{id}/check runs before every LLM call. You pass an estimated cost; the system returns allowed: true or false based on current balance minus in-flight holds.
After the call, you still ingest actual token counts for accurate deduction. Pre-request is not a replacement for metering — it is the gate on the hot path, while post-window deduction keeps the ledger accurate.
When each pattern fits
Use post-hoc only when delayed enforcement is acceptable: post-paid billing, generous credit limits, or low-frequency human usage.
Use pre-request when customers prepay for tokens, agent loops can chain dozens of calls, or a single unchecked request could meaningfully overspend the wallet.
Many production stacks use both: FluxMeter for real-time enforcement, plus Lago or Stripe for invoicing and customer-facing billing.
Streaming adds a third step
Streaming responses introduce in-flight spend that neither pattern handles with a simple before/after check. FluxMeter uses reserve → stream → ingest → reconcile so effective balance accounts for tokens not yet finalized.
Without holds, a customer could start ten concurrent streams and overspend before any single stream completes.