How events are priced when a billable metric filter value is missing

Yes, you can still price events when the filter property isn't present on the event. Adding a filter to a billable metric does not exclude unfiltered usage from billing. Events that don't match any filter combination defined on the charge fall back to the charge's own default price, so every unit is still billed. This works because filters refine pricing on a metric, they don't gate which events the metric accepts.

How the default price works

A filter on a billable metric is a key plus a list of allowed values. On the plan, each charge can define prices for specific filter combinations, and the charge itself carries a default price that covers every combination not explicitly priced.

Three cases land on that default price:

• The event has no value at all for the filter key.

• The event carries a value that isn't declared in the metric's filter values.

• The event carries a declared value, but no filter override was added for it on the charge.

If you don't set a default price, Lago defines it as 0 based on the charge model, which means the unmatched usage is metered but billed at nothing. Set it deliberately rather than leaving it blank.

How to set up per-value pricing with a fallback rate

Add the filter key to the billable metric with the values you want to price individually, then on the charge set per-value prices as filter overrides and leave the charge's top-level price as the rate for everything else.

For an embedding_model filter declaring ada and titan, a charge with a base price of $0.05, an ada override at $0.10, and a titan override at $0.03 produces three separate invoice lines when you send a mix of tagged and untagged events:

Embeddings (ada)      200 units @ $0.10   $20.00
Embeddings (titan)    200 units @ $0.03   $6.00
Embeddings (default)  720 units @ $0.05   $36.00

The default line pools the untagged events together with any events carrying an undeclared value. Add an invoice_display_name to each filter and to the charge itself so the lines read clearly on the customer's invoice instead of repeating the metric name.

Caveats when adding a filter to an existing metric

• New values don't cascade to charges. Adding a filter value to the metric does not add a matching filter combination to charges on existing plans. You have to add the override on each charge yourself, otherwise the new value silently prices at the default rate.

• Undeclared values don't error. If you ship a new model in code before declaring it on the metric, its usage is billed at the base rate rather than rejected. Nothing in the API response will flag it.

• Values are case-sensitive. ada and Ada are different values, and only an exact match routes to the override.

• Pricing changes apply to the whole open period. Fees are evaluated against the active charge configuration at calculation time, not locked at ingestion. Events received earlier in the current period are repriced under the new configuration. Finalized invoices are unaffected.

Field reference

This article reflects guidance drawn from customer case resolutions. It is not officially supported documentation and may not apply to all situations.