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 reading the Creating meters 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.
meters: - slug: tokens_total description: AI Token Usage # Filter events by type eventType: prompt aggregation: SUM # JSONPath to parse usage value valueProperty: $.tokens groupBy: # Model used: gpt4-turbo, etc. model: $.model # Prompt type: input, output, system type: $.type
Example Usage Event
Example usage event for the meter definition above.
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.
meters: - slug: api_request_duration description: API Request Duration # Filter events by type eventType: request aggregation: SUM # JSONPath to parse duration value valueProperty: $.duration_seconds groupBy: # HTTP Method: GET, POST, etc. method: $.method # Route: /products/:product_id route: $.route
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.
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.