[FEATURE] Separate Telemetry settings for each profile vs machine-scope

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's OTel metrics (claude_code.token.usage, claude_code.cost.usage, etc.) carry no attribute indicating which backend actually served the request — Anthropic's direct API, AWS Bedrock, Google Vertex AI, or a self-hosted gateway. CLAUDE_CODE_ENABLE_TELEMETRY and the OTLP endpoint are configured once per environment and apply regardless of provider.

This breaks cost/usage attribution for organizations that mix providers across their fleet. Concretely: an org deploys Claude Code configured for Bedrock (CLAUDE_CODE_USE_BEDROCK=1) and points telemetry at a collector feeding their own Bedrock cost-tracking pipeline (CloudWatch/Athena/DynamoDB). Any user on that same fleet who also holds a personal or native Anthropic Console API key — with CLAUDE_CODE_USE_BEDROCK unset for that session — still emits identical telemetry to the same collector, because emission isn't conditioned on provider. Their native-API usage silently gets counted as Bedrock spend, and there is no metric or resource attribute available to filter it back out after the fact. We confirmed this isn't fixable downstream (e.g. in a collector/aggregator Lambda) since the discriminating signal was never emitted by the client in the first place.

We also found that OTEL_RESOURCE_ATTRIBUTES — the natural workaround for tagging a deployment's own provider — has been reported as not applying to metrics at all, only to log/events (#16537), which would make a client-side tagging workaround unreliable even if attempted.

Proposed Solution

Add a built-in attribute (e.g. api.provider or gen_ai.system) to every emitted metric and event, populated automatically from which code path served the request: anthropic, bedrock, vertex, or foundry/gateway — mirroring how CLAUDE_CODE_USE_BEDROCK/CLAUDE_CODE_USE_VERTEX already determine routing internally. This requires no new configuration surface; it just exposes information Claude Code already has at request time.

As a secondary fix, ensure OTEL_RESOURCE_ATTRIBUTES is applied consistently to metrics as well as events, so orgs have a manual fallback for tagging until/unless the automatic attribute above ships.

Alternative Solutions

Document and stabilize the existing indirect signal (presence/absence of request_id on api_request events differs between direct API and third-party providers) as an official, supported way to distinguish provider — though this is fragile and clearly not designed for this purpose.
Allow the OTLP endpoint itself to be set conditionally based on active provider (e.g. only emit telemetry when CLAUDE_CODE_USE_BEDROCK=1), so orgs can at least exclude non-Bedrock sessions from the org collector instead of needing to filter them out downstream.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

An organization runs Claude Code fleet-wide with CLAUDE_CODE_USE_BEDROCK=1 and org-wide OTel telemetry pointed at an internal collector that feeds a Bedrock cost-management pipeline (CloudWatch → Athena/DynamoDB) used for chargeback and quota enforcement. Some employees also hold personal or team-issued native Anthropic Console API keys for other work and occasionally run Claude Code against the direct API instead of Bedrock. Because telemetry emission doesn't distinguish provider, that native-API usage is indistinguishable from Bedrock usage in the collector, inflating reported Bedrock spend and corrupting per-user quota/cost figures with no way to separate it out after ingestion.

Additional Context

Related documentation: Monitoring usage
Related bug: OTEL_RESOURCE_ATTRIBUTES not applied to metrics, only events (#16537)
Claude Code already knows the active provider at runtime (it's what selects the SDK client/base URL); this is a request to surface that existing internal state as telemetry data, not to build new provider-detection logic.