This page provides examples for common metering use cases, including the meter config and related usage event example.
If you are new to OpenMeter, we recommend you to read the Meter Overview guide first.
In most cases, AI applications want to count token usage for billing or cost control purposes.
As a single AI interaction involves consuming multiple tokens, we define our meter with the SUM aggregation and report token usage in the data's tokens property.
As most LLMs charge differantly for input, output and system prompts and different models it makes sense to add model and prompt type to the group by.
Meter Definition
Note that valueProperty and groupBy use JSONPath to parse out specific fields from the event.
Products monetizing API usage may want to count the number of requests.
With choosing the COUNT aggregation each event will increase the meter by one.
For grouping we can add method and route.
Note how we report the route template not the actual HTTP path to avoid differences around IDs and dynamic routes.
Meter Definition
Note that COUNT aggregation doesn't have a valueProperty.
Similar to the API request, you can decide to track the request duration.
This is basically how serverless products like AWS Lambda charge their customers.
If you want to track both the request count and duration, you can check out our advanced example.
In OpenMeter, a single event can move multiple meters if the event type matches.
Let's see an example of tracking an API request's occurrence, execution duration, and network usage.
Meter Definition
Note how we define three meters with the same eventType.
Example Usage Event
Note how the data payload contains the union of values and group bys of all three meters.
In some cases you want to count how many states a workflow or task went through as it progresses for example from created to in_progress and success.
The challenge is that if you report a usage event for every state change and track state as a group by answering simple questions
like how many workflows were in total would always require filtering by states like created, which is easy to forget and error-prone.
The recommended way to model states is to create separate meters per state.
Meter Definition
Example Usage Event
Demonstrates workflow creation and success events.