Metronome and Orb are billing platforms built for usage-based pricing. Both ingest raw usage events, let you define billable metrics as aggregations over those events, and attach prices, plans and prepaid commitments to the metrics. That flexibility is exactly what LLM products need, and it also means you have to decide how to model tokens before you write a single price.
Send rich events, decide pricing later
The most important principle is to send events that describe what happened, not what you plan to charge. A good LLM usage event carries the customer, a unique transaction or idempotency key, a timestamp, and properties for the model, the feature, each token class and the computed cost. Pricing logic then lives in billable metrics, which you can change without redeploying your application or replaying history.
{
"transaction_id": "tg_req_9f1c22",
"customer_id": "acct_4471",
"event_type": "llm_request",
"timestamp": "2026-05-05T10:22:41Z",
"properties": {
"model": "claude-sonnet-4.5",
"feature": "contract_review",
"input_tokens": 6000,
"cache_read_tokens": 12000,
"cache_write_tokens": 0,
"output_tokens": 900,
"reasoning_tokens": 0,
"cost_micros": 35100
}
}Billable metrics you will want
- Total model cost: sum of cost_micros, the basis for cost-plus overage pricing.
- Output tokens by model family: useful if you price frontier and small models differently.
- Requests per feature: for plans that sell a number of agent runs or documents.
- Cache read tokens: for internal reporting on how much of the bill caching avoided.
Metronome specifics
In Metronome, events are ingested with a transaction_id used for deduplication, a customer identifier and an event type, plus arbitrary properties. Billable metrics filter on event type and properties and aggregate a property with sum, count or max. Grouping a metric by a property such as model lets one metric drive different rates per model on the rate card.
Metronome commits and credits are the natural home for prepaid contracts: a customer commits to a dollar amount for the year, usage draws it down, and overage beyond the commit bills at the contract rate. If you meter cost in micros, the drawdown tracks your real cost mix automatically.
Orb specifics
Orb ingests events with an idempotency key, an external customer ID, an event name and properties. Billable metrics are defined as queries over those events, which makes it easy to express things like the sum of output tokens where the model starts with claude, or cost where the feature is not internal. Plans attach prices to metrics, and plan versions let you migrate customers to new rates on a schedule.
Orb's prepaid credits work similarly to commits: a credit ledger per customer, drawn down by usage, with expiry and top-up rules. Credits priced in dollars and drawn down by cost metrics are the simplest model to explain to finance.
Per request or per window
Both platforms handle high event volumes, but one event per model request is still a lot of events for a busy product, and most of the detail is unnecessary for billing. A practical middle ground is to aggregate per tenant, model and feature over a short window, a minute for example, and send one event per combination with an idempotency key derived from the window. Keep the per-request ledger in your metering layer for audits and disputes.
Common modeling mistakes
- Sending only total tokens, which makes cost-weighted pricing impossible later.
- Computing cost in the billing platform from a hard-coded price per token, which goes stale when the provider changes prices or a fallback model serves the request.
- Using a different customer key in the gateway and the billing platform, so events land on the wrong account or nowhere.
- Billing internal and evaluation traffic because it was never tagged.
Test with a shadow month
Before you invoice anyone, run a shadow month: send events to the billing platform with draft plans attached, let it compute invoices that are never sent, and compare them with what finance expects from the metering ledger. Shadow invoices surface unmapped customers, missing properties and boundary problems while they are still free to fix.
How PALM SOUQ connects
PALM SOUQ billing sync supports Metronome and Orb natively, alongside Stripe and Lago. You map tenants to billing customers, choose per-request or windowed delivery, and select which properties to include. The cost on each event is the cost PALM SOUQ computed at request time from the serving model and the token classes, so your billable metrics, your quotas and your margin reports share one source of truth.
Ananya Iyer
Head of FinOps Research, PALM SOUQ
Chartered accountant and former SaaS finance lead at a Chennai-based CRM company. Maintains the LLM Price Index and the margin models behind the runaway cost calculator.