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.
