[FEATURE] Include logical model name as OTel attribute when modelOverrides is configured

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

When modelOverrides is configured in settings.json, Claude Code resolves the logical model name (e.g., claude-sonnet-4-6) to a provider-specific identifier (e.g., a Bedrock inference profile ARN) before making API calls. The OTel telemetry emitted by Claude Code only includes the resolved model ID, not the original logical name.

This makes it difficult to aggregate or filter telemetry by model in observability platforms, since the resolved IDs are opaque ARNs rather than human-readable model names. Users must implement custom transform rules in their OTel collector pipeline to recover the logical name from the ARN — a brittle workaround that requires maintaining a separate mapping outside of Claude Code.

Proposed Solution

When modelOverrides is configured, emit both the resolved model ID and the original logical model name as distinct OTel attributes on all telemetry. For example:

• model.id — the resolved value (e.g., the Bedrock ARN or provider-specific ID)
• model.name — the logical name from settings.json (e.g., claude-sonnet-4-6)

This allows users to group, filter, and alert on model usage using stable, human-readable names in their observability platform, while still retaining the resolved ID for debugging and provider-level attribution. No changes to the OTel schema would be required when modelOverrides is not configured — model.id and model.name would simply be the same value.

Alternative Solutions

1. OTEL_RESOURCE_ATTRIBUTES

The logical model name could be set manually as a static resource attribute via OTEL_RESOURCE_ATTRIBUTES. However, this is a static value scoped to the entire process and does not reflect per-request model resolution. It also requires the user to duplicate configuration that already exists in modelOverrides.

1. OTel Collector transform rules

A relabeling or transform rule in an OTel collector pipeline could map resolved ARNs back to logical model names. This works but requires maintaining a separate ARN-to-name mapping outside of Claude Code, is brittle when model overrides change, and is not feasible for users who export directly to an OTLP endpoint without a collector in the pipeline.

1. Do nothing

Users who only observe telemetry from a single model or do not use modelOverrides are unaffected. However, for teams using Bedrock inference profiles or other provider-specific IDs, the current behavior produces opaque model dimensions that are difficult to use in dashboards and alerts.

Priority

Low - Nice to have

Feature Category

Other

Use Case Example

_No response_

Additional Context

_No response_