[BUG] OTLP metric export silently stops when OTEL_RESOURCE_ATTRIBUTES has >12 entries (regression in 2.1.161)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
[BUG] OTLP metric export silently stops when OTEL_RESOURCE_ATTRIBUTES has >12 entries (regression in 2.1.161)
What happened
Setting CLAUDE_CODE_ENABLE_TELEMETRY=1 with OTEL_METRICS_EXPORTER=otlp and anOTEL_RESOURCE_ATTRIBUTES value containing more than ~12 entries causes Claude Code to export
zero metrics over OTLP. The HTTP export returns 200 (or there is simply no export attempt) — no
error on stderr, nothing in --debug-file. Logs and traces from the same process continue to export
normally, carrying all the same resource attributes. Reducing OTEL_RESOURCE_ATTRIBUTES to ≤12
entries makes metric export work again.
This started in 2.1.161 and is still present in 2.1.191 (latest at time of writing). The 2.1.161
changelog entry that lines up:
OTEL_RESOURCE_ATTRIBUTES values are now included as labels on metric datapoints, so you can slice usage metrics by custom dimensions like team or repo
It looks like the new "copy every resource attribute onto each metric datapoint" path trips an
attribute-count limit (or throws and is swallowed) once the datapoint's attribute set gets large,
killing the whole metric export. Logs/traces don't go through that path, which is why only metrics break.
What Should Happen?
Expected vs actual
- Expected: metric export is unaffected by the number of resource attributes (or, at worst, drops
the extra datapoint labels while still exporting the metric).
- Actual: the entire OTLP metric pipeline goes silent above ~12 resource attributes, with no error.
Error Messages/Logs
No errors logs available
Steps to Reproduce
Reproduction
Point at any OTLP metrics backend (or a local otel-collector with debug exporter).
Works (≤12 resource attributes) — metrics export:
CLAUDE_CODE_ENABLE_TELEMETRY=1 \
OTEL_METRICS_EXPORTER=otlp OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_EXPORTER_OTLP_ENDPOINT=https://<your-collector> \
OTEL_METRIC_EXPORT_INTERVAL=2000 \
OTEL_RESOURCE_ATTRIBUTES="a1=v,a2=v,a3=v,a4=v,a5=v,a6=v,a7=v,a8=v,a9=v,a10=v,a11=v,a12=v" \
claude --print "write a few paragraphs so the session lasts a few seconds"
# -> claude_code.session.count / cost.usage / token.usage all arrive
Broken (13 resource attributes) — metrics silently absent, logs/traces still arrive:
... OTEL_RESOURCE_ATTRIBUTES="a1=v,...,a13=v" ...
claude --print "..."
# -> no claude_code.* metrics; logs + traces still export with all 13 attrs
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.160
Claude Code Version
2.1.191
Platform
AWS Bedrock
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Threshold (measured)
≤12 OTEL_RESOURCE_ATTRIBUTES entries export; ≥13 do not. It is attribute count, not byte size
(13 short attrs break; 12 long-valued attrs are fine).
Workaround
OTEL_METRICS_INCLUDE_RESOURCE_ATTRIBUTES=false restores metric export (resource attrs then ride the
OTLP resource block only). Confirmed: with the flag set and 21 resource attributes,token.usage/cost.usage/session.count all export reliably on 2.1.191.
Suggested fix
In the path added by 2.1.161, either (a) cap/skip the per-datapoint resource-attribute copy without
aborting the export, or (b) raise/configure the limit and surface a warning instead of silently
dropping all metrics. A swallowed exception around the datapoint-attribute assignment is the most
likely culprit.
Impact
Anyone who sets a rich OTEL_RESOURCE_ATTRIBUTES (CI bots, multi-team setups with cicd./vcs./cost
attribution) loses all usage/cost metrics silently while logs/traces keep flowing — easy to not
notice for a long time.