This page provides examples for common metering use cases, including the meter config and related usage event examples. If you are new to OpenMeter, we recommend reading the Creating meters guide first.

#AI Use Cases

Examples for common AI metering use cases for LLMs and GPUs.

#LLM Token Usage

In most cases, AI applications want to count token usage for billing or cost control purposes. Because a single AI interaction involves multiple tokens, you define your meter with the SUM aggregation and report token usage in the data's tokens property. Because most LLMs charge differently for input, output, and system prompts, and pricing varies by model, it makes sense to add provider, 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.

Create Meter in Cloud

meters:
  - slug: tokens_total
    description: AI Token Usage
    # Filter events by type
    eventType: prompt
    aggregation: SUM
    # JSONPath to parse usage value
    valueProperty: $.tokens
    groupBy:
      # Provider: openai, anthropic, etc.
      provider: $.provider
      # Model used: gpt4-turbo, claude-3-5-sonnet, etc.
      model: $.model
      # Prompt type: input, output, system
      type: $.type

Example Usage Event

Example usage event for the meter definition above.

{
  "specversion": "1.0",
  "type": "prompt",
  "id": "00001",
  "time": "2024-01-01T00:00:00.001Z",
  "source": "chat-app",
  "subject": "customer-1",
  "data": {
    "tokens": "123456",
    "provider": "openai",
    "model": "gpt-4o",
    "type": "output"
  }
}

#GPU Time

Metering GPUs is a common use case for customer billing, internal chargeback, and cost control.

Meter Definition

Create Meter in Cloud

meters:
  - slug: gpu_execution_duration_seconds
    description: GPU Time
    eventType: gpu_time
    aggregation: SUM
    valueProperty: $.duration_seconds
    groupBy:
     	hostname: $.hostname
     	region: $.region
      # Type of GPU: e.g. nvidia_A100
 	    gpu_type: $.gpu_type

Example Usage Event

{
  "specversion": "1.0",
  "type": "gpu_time",
  "id": "00001",
  "time": "2024-01-01T00:00:00.001Z",
  "source": "my-image-generator",
  "subject": "customer-1",
  "data": {
    "duration_seconds": "12345",
    "hostname": "my-hostname",
    "region": "us-east-1",
    "gpu_type": "nvidia_A100"
  }
}

#API Use Cases

Examples for common API metering use-cases.

#API Request Count

Products monetizing API usage may want to count the number of requests. With the COUNT aggregation, each event increases the meter by one. For grouping, you can add method and route. Note how the example reports the route template, not the actual HTTP path, to avoid differences caused by IDs and dynamic routes.

Meter Definition

Note that COUNT aggregation doesn't have a valueProperty.

Create Meter in Cloud

meters:
  - slug: api_requests_total
    description: API Requests
    # Filter events by type
    eventType: request
    aggregation: COUNT
    groupBy:
      # HTTP Method: GET, POST, etc.
      method: $.method
      # Route: /products/:product_id
      route: $.route

Example Usage Event

Example usage event for the meter definition above.

{
  "specversion": "1.0",
  "type": "request",
  "id": "00001",
  "time": "2024-01-01T00:00:00.001Z",
  "source": "api-service",
  "subject": "customer-1",
  "data": {
    "method": "GET",
    "route": "/products/:product_id"
  }
}

#API Request Duration

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.

Meter Definition

Create Meter in Cloud

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

Example Usage Event

{
  "specversion": "1.0",
  "type": "request",
  "id": "00001",
  "time": "2024-01-01T00:00:00.001Z",
  "source": "api-service",
  "subject": "customer-1",
  "data": {
    "method": "GET",
    "route": "/products/:product_id",
    "duration_seconds": "12345"
  }
}

#Kubernetes Pod Execution Duration

To track Kubernetes pod execution duration, check out our native Kubernetes collector that already reports usage events in this format.

Meter Definition

Create Meter in Cloud

meters:
  - slug: pod_execution_time
    description: Pod Execution Time
    eventType: kube-pod-exec-time
    aggregation: SUM
    valueProperty: $.duration_seconds
    groupBy:
      pod_name: $.pod_name
      pod_namespace: $.pod_namespace

Example Usage Event

{
  "specversion": "1.0",
  "type": "kube-pod-exec-time",
  "id": "f7f11c82-c415-4325-aec7-572606681817",
  "time": "2024-01-01T00:00:00.001Z",
  "source": "my-app",
  "subject": "customer-1",
  "data": {
    "duration_seconds": "123",
    "pod_name": "pod_name",
    "pod_namespace": "pod_namespace"
  }
}

#Advanced Examples

Common metering use cases with more complex requirements.

#Counting unique events

In some cases, you may want to count unique events, such as unique sessions. To achieve this, you can use the UNIQUE_COUNT aggregation.

Meter Definition

Create Meter in Cloud

meters:
  - slug: unique_sessions_total
    description: Unique Sessions
    eventType: login
    aggregation: UNIQUE_COUNT
    valueProperty: $.session_id

Example Usage Event

{
  "specversion": "1.0",
  "type": "auth_check",
  "id": "00001",
  "time": "2024-01-01T00:00:00.001Z",
  "source": "auth-service",
  "subject": "customer-1",
  "data": {
    "session_id": "session_id"
  }
}

#Moving multiple meters with one event

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.

meters:
  - slug: api_requests_total
    description: API Requests
    eventType: request
    aggregation: COUNT
    groupBy:
      method: $.method
      route: $.route
  - slug: api_request_duration_seconds
    description: API Request Duration
    eventType: request
    aggregation: SUM
    valueProperty: $.duration_seconds
    groupBy:
      method: $.method
      route: $.route
  - slug: api_request_ingress_bytes
    description: Request Ingress Bytes
    eventType: request
    aggregation: SUM
    valueProperty: $.ingress_bytes
    groupBy:
      method: $.method
      route: $.route

Example Usage Event

Note how the data payload contains the union of values and group bys of all three meters.

{
  "specversion": "1.0",
  "type": "request",
  "id": "00001",
  "time": "2024-01-01T00:00:00.001Z",
  "source": "api-service",
  "subject": "customer-1",
  "data": {
    "method": "GET",
    "route": "/products/:product_id",
    "duration_seconds": "123",
    "ingress_bytes": "456",
    "egress_bytes": "789"
  }
}

#Counting state changes

In some cases, you want to count how many states a workflow or task goes through as it progresses — for example, from created to in_progress to success. The challenge is that if you report a usage event for every state change and track state as a group by, answering a simple question like how many workflows there were in total would always require filtering by state (such as created), which is easy to forget and error-prone.

The recommended way to model states is to create separate meters per state.

Meter Definition

meters:
  - slug: workflow_created
    description: Workflows Created
    eventType: workflow_create
    aggregation: COUNT
    groupBy:
      task_type: $.task_type
  - slug: workflow_succeeded
    description: Workflow Succeeded
    eventType: workflow_success
    aggregation: COUNT
    groupBy:
      task_type: $.task_type
  - slug: workflow_failed
    description: Workflow Failed
    eventType: workflow_fail
    aggregation: COUNT
    groupBy:
      task_type: $.task_type

Example Usage Event

Demonstrates workflow creation and success events.

[
  {
    "specversion": "1.0",
    "type": "workflow_create",
    "id": "00001",
    "time": "2024-01-01T00:00:00.001Z",
    "source": "task-queue",
    "subject": "task-1",
    "data": {
      "type": "image-generate"
    }
  },
  {
    "specversion": "1.0",
    "type": "workflow_success",
    "id": "00001",
    "time": "2024-01-01T00:00:00.001Z",
    "source": "task-queue",
    "subject": "task-1",
    "data": {
      "task_type": "image-generate"
    }
  }
]

#Other Examples

#Translate AI Demo

The following example meters are for an imaginary Translate AI product that translates PDF documents between languages. For example, you can use an LLM like GPT-4 to translate a PDF document from German to English. For this use case, you want to track the number of pages, words, and LLM tokens used for each translation.

Example Usage Event

For each translation, you can send an event with the number of pages, words, and LLM tokens used.

{
  "specversion": "1.0",
  "id": "0b8bb322-90c2-4b46-b541-0380bac1b9a5",
  "source": "myapp",
  "type": "translate",
  "subject": "customer-123",
  "datacontenttype": "application/json",
  "time": "2025-02-18T16:37:44Z",
  "data": {
    "model": "gpt-4",
    "pages": 23,
    "tokens": 10200,
    "words": 6912
  }
}

Meters

Meter to count the number of pages translated:

meters:
  - slug: pages_total
    description: Number of pages translated
    eventType: translate
    aggregation: SUM
    valueProperty: $.pages

Create Pages Meter in Cloud

Meter to count the number of words translated:

meters:
  - slug: words_total
    description: Number of words translated
    eventType: translate
    aggregation: SUM
    valueProperty: $.words

Create Words Meter in Cloud

Meter to count the number of LLM tokens used:

meters:
  - slug: tokens_total
    description: Number of LLM tokens used
    eventType: translate
    aggregation: SUM
    valueProperty: $.tokens
    groupBy:
      model: $.model

Create Tokens Meter in Cloud

Common Examples