Feature Request: Alternative Authentication for Analytics API Infrastructure Integration

Ideas Feature Requests
,
1

Feature request for product/service

API Keys

Describe the request

Hi Cursor team,

We’re building internal infrastructure to track AI agent usage across different coding agents.

One gap we hit with Cursor is that Cursor transcripts do not appear to include token usage information.

For comparison, Claude Code writes usage data directly into its transcript events, for example:

{
  "type": "assistant",
  "message": {
    "id": "msg_1",
    "usage": {
      "input_tokens": 100,
      "cache_creation_input_tokens": 20,
      "cache_read_input_tokens": 0,
      "output_tokens": 10
    }
  }
}

This makes it straightforward for infra systems to collect per-message usage, including cached and non-cached tokens, without needing a separate admin-level API integration.

For Cursor, we could use the Analytics API, but it requires an API key with admin-level access. That feels risky for shared infrastructure. We would prefer not to put a broad admin key into a common usage-collection service.

Could Cursor support token usage in transcript data?

  • input tokens
  • output tokens
  • cache read tokens
  • cache creation/write tokens
  • model name
  • request/message id

Our main requirement is simple: we need a reliable way to collect Cursor usage for internal cost attribution and agent comparison, without giving shared infrastructure an admin API key.

Is this something Cursor already supports, or is it on the roadmap?

5

Hi @_9056372!

Thanks for the feedback!

In the last few weeks, we shipped Admin API keys with read-only access, which should significantly reduce the risk. Were you aware?

Screenshot 2026-04-27 at 11.51.04
Screenshot 2026-04-27 at 11.51.042072×458 22.2 KB

8

Thanks, read-only API keys make sense and are definitely better than admin keys.

Our main concern is still where the key should live. For shared infra or CLI usage across multiple repos/teams, putting any API key in repo config, local config, or a multi-user environment feels risky, even if it is read-only.

Another issue is onboarding: we would need every team that integrates with our infra to configure their own Cursor team API key. That also feels awkward and hard to maintain.

We can keep the keys in an internal service, but then we need to build extra infra just to collect usage.

Have you considered supporting the Claude Code approach, where token usage is written directly into transcript events? That would avoid the API key problem and make per-message usage collection much simpler.

Is there a recommended Cursor pattern for this today?