OpenTelemetry Auto Router: expose resolved model or usage_event.id in Usage API

Ideas Feature Requests
,
1

I’m using Cursor Enterprise OpenTelemetry export to build usage and cost observability, and I found a limitation when using Auto Router models.

When a request goes through Auto Router, OpenTelemetry reports something like:

cursor.model.name = auto-smart

However, in the Cursor Usage dashboard, the same usage is associated with the actual resolved model, for example:

Claude Opus 5 (Auto Balanced)

This makes it impossible to calculate the real model cost from OpenTelemetry alone, because auto-smart doesn’t tell us which model actually handled the request.

There are two possible solutions that would solve this cleanly:

  1. Expose the resolved model in OpenTelemetry

Instead of only:

cursor.model.name = auto-smart

either make cursor.model.name contain the actual resolved model, or add another attribute such as:

cursor.model.requested_name = auto-smart
cursor.model.resolved_name = claude-opus-5

This would probably be the most useful solution for observability.

  1. Expose usage_event.id in the Usage API

The OpenTelemetry documentation already describes cursor.usage_event.id as the field that can be used for reconciliation with Cursor usage/billing data.

However, the Usage API currently doesn’t expose that ID.

If /teams/filtered-usage-events returned something like:

{
  "usageEventId": "...",
  "conversationId": "...",
  "model": "claude-opus-5",
  "chargedCents": 12.34
}

we could reliably join:

OpenTelemetry event
        │
 cursor.usage_event.id
        │
        ▼
Cursor Usage API
        │
 resolved model + exact cost

Right now we have:

OpenTelemetry:
usage_event.id ✅
resolved model ❌

Usage API:
usage_event.id ❌
resolved model ✅

So the reconciliation field documented by Cursor cannot actually be used end-to-end.

Either solution would solve the problem, although exposing both the requested and resolved model in OpenTelemetry would also be very useful for understanding Auto Router behavior.

This is especially important for Enterprise customers building internal cost allocation, chargeback/showback, and per-request observability.