Feature Request: Emit cost / premium-request metric via OpenTelemetry (parity with Claude Code's claude_code.cost.usage)

[kewinremy]

Describe the feature or problem you'd like to solve

The Copilot CLI's OpenTelemetry export is great for usage analytics, but it emits no cost or billing metric. The metrics currently available are:

• gen_ai_client_token_usage (input/output tokens, by model)
• gen_ai_client_operation_duration
• github_copilot_agent_turn_count
• github_copilot_tool_call_count / ..._duration
• github_copilot_mcp_server_connection_count

None of these carry a cost figure. As a result, anyone building a cost dashboard has to re-derive spend on the consumer side — either by hand-coding per-million-token list prices per model (an API-equivalent estimate that is not the actual Copilot bill), or by trying to reconstruct premium-request consumption, which isn't possible from the telemetry because:

• premium requests are billed per prompt × a per-model multiplier (overage $0.04/request), not per token;
• github_copilot_agent_turn_count has no model label, so turns can't be multiplied by the correct per-model multiplier;
• request counts include agentic tool iterations, which inflate any call-count proxy.

So the one thing teams actually want — "how much did this cost / how many premium requests did it consume" — is the one thing the telemetry can't express today.

Prior art: Claude Code

Claude Code already exports cost directly via OTel (docs):

Metric	Description	Unit
claude_code.cost.usage	Cost of the Claude Code session	USD
claude_code.token.usage	Tokens used	tokens

This makes a "cost per model / per session" dashboard a one-line query with no client-side price tables.

Proposed solution

Emit a first-class cost/billing metric from the Copilot CLI's OTel exporter, ideally with the same labels already present on the token metric (gen_ai_request_model / gen_ai_response_model, and session.id if available). Any of the following would solve it, in rough order of preference:

1. github_copilot.premium_request.count — premium requests consumed, labeled by model (this is the true Copilot billing unit). The CLI already knows the prompt boundaries and the model multiplier, so it can compute this authoritatively where consumers cannot.
2. github_copilot.cost.usage (unit USD) — direct parity with claude_code.cost.usage, for accounts on API/consumption pricing.
3. At minimum, a multiplier attribute on an existing per-model metric, plus a documented "1 premium request per prompt" counter, so consumers can compute cost correctly.

Example prompts or workflows

In Grafana/Mimir, a dashboard panel would become:

sum by (gen_ai_response_model) (github_copilot_premium_request_count)

instead of today's brittle client-side approximation:

sum(gen_ai_client_token_usage_sum{gen_ai_token_type="input",gen_ai_response_model=~"claude-opus.*"})*5/1e6
+ sum(gen_ai_client_token_usage_sum{gen_ai_token_type="output",gen_ai_response_model=~"claude-opus.*"})*25/1e6
+ ...   # repeated per model class, hard-coded list prices, NOT the real Copilot bill

Additional context

Related, but none cover emitting a cost/credit OTel metric:

• Allow tracking of spent dollar amount in session #3474 — track dollar amount spent in a session (UI/session, not telemetry)
• Cost data availability in the GitHub Copilot hooks #3686 — cost data in Copilot hooks (hooks, not OTel metrics)
• OTel telemetry support for Copilot CLI (parity with Claude Code) #2471 — OTel telemetry parity with Claude Code (closed; established the metrics that ship today, but no cost metric)

Context: I built a self-hosted Grafana stack for Copilot CLI telemetry and had to fake the cost panel with client-side list-price math, which I can only honestly label "API-equivalent estimate, not your Copilot bill." A CLI-emitted premium-request/cost metric would make this exact and trustworthy.