Cursor

Cursor exports its team's telemetry from Cursor's own servers. A team admin adds Status200 as the destination once, in Cursor's dashboard, and the whole team's tokens, estimated cost and tool calls arrive: nothing to install or set on developer machines.

How it works#

Before you begin#

• Cursor's Enterprise plan. The OpenTelemetry Export screen is not on other plans.
• An endpoint Cursor can reach from the internet. Cursor connects to you, from a fixed set of addresses. Status200 Cloud needs nothing more; a self-hosted Status200 behind a firewall must allow the egress addresses that Cursor lists on its OpenTelemetry Export page.

Set it up#

1. Create an ingestion key#

   In Status200, open Project Settings → Telemetry & APM → Ingestion Keys, click Create Ingestion Key and copy the key. Your OTLP base URL is https://status200.ru/otlp, or https://YOUR-ONEUPTIME-HOST/otlp if you host Status200 yourself.

2. Create the destination in Cursor#

   In Cursor's web dashboard, as a team admin, open Team Settings → OpenTelemetry Export and create a destination:

   Field	Value
   Endpoint (base URL)	https://status200.ru/otlp
   Header name	x-status200-token
   Header value	YOUR_INGESTION_TOKEN

   Enter the base URL without /v1: Cursor adds /v1/metrics and /v1/logs itself, and https://status200.ru/otlp/v1 would send to /otlp/v1/v1/metrics, where nothing arrives.

3. Test and enable#

   Click Test connection to check the URL and the header, then Enable. Export starts within about a minute; later edits to the header take about 30 seconds.

4. Check that data arrives#

   Use Cursor for a minute or two, then open Logs in Status200 and filter on the service name cursor: cursor.api.request records with token counts mean the key and the URL are right.

Cursor speaks OTLP over HTTP with binary protobuf only (no gRPC, no JSON), which Status200 accepts as it is. It stores the header encrypted, and sends to one destination per team: to send to Status200 and somewhere else, put a collector in front.

What you get, and what you don't#

So in Status200, Cursor shows on the Usage tab of Products → AI / LLM, from cursor.token.usage and cursor.cost.usage, but never in Calls or Conversations, which are built from traces. The per-request detail is the cursor.api.request event in the Logs explorer.

Families#

Each signal, and each family of telemetry, has its own switch in Cursor's settings:

Every family but conversation_content starts on. Families Cursor adds later start on too, unless you turn off auto_enable_new_families.

Metrics and events#

All three metrics are delta sums:

The data points carry no conversation or request id, so per-session cost is not in the metrics. cursor.model.name is the model asked for, with routed choices collapsed: a model breakdown has a row named Auto that cannot be split into the models Cursor routed it to.

The log event you will use most is cursor.api.request: one per request, with its input, output and cache token counts, the model and whether it was billed. cursor.api.error records a failed request (without the error message), and cursor.api.correction arrives later to say a request was not billed after all. Cursor's wire reference lists every event and attribute.

Every record carries these resource attributes:

Employee attribution#

Cursor names a person by cursor.user.id, an integer only Cursor can turn into a name, and often leaves it out for cloud agents. Status200 reads it as the employee, and cursor.team.id as the team, so the Usage tab ranks people and teams with no setup, but people show as integers.

• Both arrive as resource attributes (resource.cursor.user.id, resource.cursor.team.id), which Status200 reads.
• Cursor can also send cursor.user.email, but Status200 does not read it yet, so the employee email column stays empty for Cursor.
• gen_ai.user, llm.user and LiteLLM's end-user ids are never read as the employee: they name your customers, not your staff. See Employee and team attribution.

Where Cursor shows up in the Usage tab#

Cursor sends metrics and no GenAI spans, and the metrics only fill in for spans: if the same project receives GenAI spans with cost, Cursor's spend does not show. Send Cursor to a project of its own. See Spans come first, metrics fill in.

A Cursor row carries cost only: its calls and token cells show —, because cursor.cost.usage has no per-call detail. cursor.token.usage still feeds the token totals above the table (its input and output types; cache tokens are left out), and you can chart it on a dashboard by cursor.token.type.

curl -u YOUR_API_KEY: https://api.cursor.com/teams/members

How Cursor delivers#

These change what you see in charts, so know them before you report a gap:

• Metrics are sent at most once. A failed export is not retried, so a brief gap after a failure is expected: don't page on gaps in Cursor's metrics.
• Logs are sent at least once, deduplicated on cursor.event.id, and retried automatically for about 7 days.
• There is no ordering. A cursor.api.correction arrives after the request it corrects: order by the record's timestamp, never by arrival.
• Nothing is backfilled. Nothing from before you enabled the destination arrives, and a destination left broken loses what Cursor could not send.
• Disabling or deleting a destination drops data in flight. To change the ingestion key, edit the destination's header instead of deleting and re-creating it.

Cost is an estimate, not an invoice#

Cursor documents cursor.cost.usage as a best-effort estimate. It does not separate included usage from usage billed on demand; with your own model keys, it reflects only Cursor's token rate, not your provider's bill; and a later cursor.api.correction can take back usage it already counted. Read it as a trend. For a figure that matches the invoice, add up chargedCents from Cursor's Admin API.

Troubleshooting#

Next steps#