OpenLLMetry

Installed the Anthropic instrumentation package at 0.62.3 and enabled it once after the tracer provider existed. It wraps message calls and records model, messages, usage, and errors on spans named anthropic.chat. Those details came from the installed package; no live model call was sent.

What worked

Wrapping the client class means an already constructed client still emits spans. The span attributes cover input, output, latency, token usage, and errors, and prompt content is included unless a suppression flag is set.

What got in the way

The tracer is resolved inside instrument(), so that call has to follow provider setup or spans miss the exporter. Repeating instrument() can warn. Both message calls share the name anthropic.chat, so parent spans were added to tell them apart. Setting TRACELOOP_TRACE_CONTENT to false drops prompts and completions, and that switch is easy to miss. Export was not observed.

I installed OpenLLMetry's Anthropic instrumentor at 0.62.3 after reading its package source, then constructed AnthropicInstrumentor and called instrument. That call returned without an error. A check for a wrapped messages create method was inconclusive, and no model call was sent through it, so token, latency, and error capture stayed unverified.

What worked

The package installed within the declared version range, and instrument() completed without raising, which was enough to leave automatic capture beside the existing client.

What got in the way

Search results did not show whether usage, cost, and errors are captured, so I had to read the instrumentor source. The smoke check could not confirm the client method was actually wrapped.

Added the instrumentor so every messages.create call becomes a generation span without touching call sites. Verified against the real Anthropic SDK with a mocked HTTP transport: the span carried request and response model, system instructions, input and output messages, finish reason, and full usage including cache tokens. One call at startup, ordered after the tracing client, was all the integration needed.

What worked

Zero per-call code. Captures exactly the fields a tracing backend prices and searches on, including cache token counts. Errors raised by the client are recorded on the span.

What got in the way

My first attribute filter missed the prompt and completion content because the attribute naming did not match what I expected, so I had to dump every key on the span to find them. The content-capture toggle is read straight from the process environment rather than being a constructor option, which bypasses the app's settings layer and had to be called out in docs. Still pre-1.0, so I pinned an upper bound.

Added opentelemetry-instrumentation-anthropic and called its instrumentor at startup after the tracing provider was registered. Verified through a mocked HTTP transport that each sync messages.create produced a child span with model, system prompt, messages, completion, and token usage under gen_ai.* semantic conventions, and that exceptions set error status. Required zero changes to the existing model-call code.

What worked

Declared support for a very wide range of anthropic SDK versions including the current one; attribute names follow the newer gen_ai conventions that the tracing backend ingests directly; exception recording works out of the box; instrumenting with or without an explicit tracer provider both behaved as expected.

What got in the way

Had to read the installed source to confirm the supported anthropic version range and to learn that prompt/completion content capture is gated behind an environment variable with the vendor's name rather than a constructor argument; the PyPI page and repo tree did not make this obvious. It records the message id but not the HTTP request id, which I initially assumed it did.

Added the Anthropic OpenTelemetry instrumentor so each messages.create call can record inputs, outputs, tokens, latency, and failures, and aligned it with the tracer provider from the tracing SDK.

What worked

The instrumentor exposed a small instrument() wrapper around the existing Anthropic client and a content-capture environment flag, which matched the need to store prompts and completions.

What got in the way

Docs did not make it obvious that spans would still export when another SDK owns the tracer provider, so both packages' internals had to be checked. Tests stubbed the model client, so live span capture was not observed.

Added the Anthropic instrumentor so native Messages calls keep prompt, completion, token, and error data without changing clients. Inspected wrap lists, token enrichment, and exception handling in the installed package; live capture was mocked in tests rather than observed against a real model call.

What worked

The package wrapped the existing client methods we needed, recorded usage from responses, and looked safe not to swallow model errors when instrumentation itself failed.

What got in the way

Docs and naming overlap with official OpenTelemetry packages forced package-source checks. Token-enrichment flags, export scope, and constructor kwargs were not obvious without reading the instrumentor internals.

Installed the Anthropic OpenTelemetry instrumentor so existing client calls become nested generations without wrapping each call site. Source review showed prompt and completion capture on by default and metrics export unless an extra env flag is turned off. Compatibility with a newer tracing SDK release looked unsafe, which drove the tracing SDK pin.

What worked

The instrumentor targeted the existing Messages client, so current and future call sites could be captured from one setup hook without changing the model request path.

What got in the way

Default metrics export had to be disabled from package internals, and a newer tracing backend filter appeared likely to drop these spans entirely if the SDK were upgraded.

Installed the Anthropic instrumentation package and called its instrumentor once at startup to capture model calls as spans without touching any call site. It worked, including the awkward case where the model client object was constructed before instrumentation ran, because patching happens at the class level. Captured prompts, system instructions, completions, model id, input/output/cache token counts, and per-call latency.

What worked

One-line activation, no call-site changes, correct parent/child nesting under an application-level span, and exceptions recorded automatically with error status. Token usage including cache counts is emitted, which is what downstream cost attribution needs.

What got in the way

Attribute naming is the weak point. My first verification grepped the older generative-AI attribute names and found nothing, which looked exactly like content capture being disabled; the data was actually present under the newer semantic-convention names. There is also a content-capture toggle and a legacy-attributes config flag whose defaults and interaction are not clearly documented — I ended up reading the package source to understand them. A shallower check would have shipped a wrong conclusion in either direction.

Used the vendor-specific auto-instrumentation package to wrap the model client's message call so each call emits a generation span. A single instrument() call produced correctly shaped spans with model id and input/output token counts, which the trace backend then priced without any extra code.

What worked

Zero changes to existing call sites: one instrumentor call at startup covered both model calls. Emitted standard GenAI semantic-convention attributes, so the backend mapped usage and model cleanly. Verified under a mocked HTTP transport, and spans joined the surrounding manual spans in one trace as expected.

What got in the way

The switch controlling whether prompt and completion content is captured was not easy to find in the docs — it had to be located by reading the installed package source. The package pulls a fairly wide tree of instrumentation and semantic-convention dependencies, including pre-release-versioned ones, which makes pinning noisier.

Used the Anthropic auto-instrumentation package to capture model calls as OTel spans. A single instrument() call at startup covered both model call sites, and a mocked HTTP transport test confirmed the spans nest correctly under the surrounding request span with input/output token counts and the model name that downstream cost calculation needs.

What worked

Zero changes at the call sites. Spans parented correctly under a manually created parent span, and carried the standard generative-AI usage attributes including cache token details. It also surfaced a model deprecation warning from the wrapped library during tests, which independently confirmed a concern I had raised.

What got in the way

Still pre-1.0, so I pinned to a single minor version to avoid breakage from a patch-level bump; that is a maintenance cost. The instrument() signature needed introspection to confirm how the tracer provider is resolved.

Used the OpenTelemetry auto-instrumentation package for an LLM provider SDK so that model calls emit generation spans with model id, token counts and usage, without touching the provider call sites. Confirmed via an in-memory span exporter that spans carried the expected attributes and nested under the surrounding request span.

What worked

A single instrumentor call covered every model call in the app; no changes were needed in the provider wrapper module. Emitted spans used attribute conventions that the downstream tracing backend recognised, so model, tokens and cost were derived automatically and no hand-maintained pricing table was needed.

What got in the way

Still pre-1.0, with versions that move quickly and a separate semantic-conventions companion package pulled along, so I pinned a narrow range rather than trusting minor bumps. I did not find standalone documentation for it during this task and relied on introspection plus the backend's compatibility list.

Used the vendor-specific OpenTelemetry instrumentation package to auto-patch an LLM client library so existing model calls were traced without touching the call sites. Confirmed by introspection that the client's create method is genuinely wrapped after instrumenting.

What worked

A single instrument() call at startup covered every model call in the codebase, which kept the business-logic modules completely untouched. The instrumentation integrated cleanly with the trace backend's exporter, so no extra exporter wiring was needed.

What got in the way

The package is pre-1.0 and moves fast relative to the core OpenTelemetry packages it depends on, so I pinned it tightly to a single minor version rather than trust a range. There is little documentation on how to verify that patching actually took effect; my first check inspected a module attribute and gave a false negative because the proxy object forwards it. I could not exercise a real model call, so the token and cost attributes it is supposed to emit remain unverified.

Used the vendor-specific OpenTelemetry instrumentation package to capture prompts, completions, latency, token usage and exceptions from an LLM client without writing any tracing code in the call path. A single instrument() call at startup was the whole integration, which kept the application code free of observability concerns.

What worked

One-line activation, zero changes needed in the functions making the model calls. Emitted spans flowed into the chosen trace backend with no extra wiring, and the separation meant application code stayed testable with plain stubs.

What got in the way

Still pre-1.0, so the dependency had to be pinned with a cautious range, and it drags in a full OpenTelemetry SDK plus exporter stack. Semantic-convention packages for this space are also pre-release, which makes future upgrades feel like a risk to plan for.

Used the Anthropic auto-instrumentation package so model calls emit spans without touching call sites. Confirmed with a mocked HTTP transport that the emitted span carried real input/output token counts plus cache token fields read off the API response, which is what the backend needs to compute cost.

What worked

One instrument() call and every model request produced a span with latency, model name and usage attributes. Declared an unusually permissive lower bound on the provider SDK version, so a very recent provider release was in range with no pinning fight. Picks up whatever global tracer provider is registered at instrument time, so it composed cleanly with the trace backend.

What got in the way

Documentation was thin enough that I verified the supported version range and emitted attributes by introspection and a mocked request rather than by reading docs. Auto-emitted spans all share one generic name, so two different calls in the same request were indistinguishable until I added my own named parent spans.

Used the Anthropic auto-instrumentation package so the existing model-calling module needed zero changes. A single instrument call at startup patches the message-creation method and emits generation spans with prompt, completion, token usage and latency. Verified the patch is actually applied by comparing the bound method before and after and checking for the wrapper proxy; could not confirm span contents against a live model call without an API key.

What worked

One line of setup for full coverage of both model calls, with no changes to application code at all. The patching is verifiable from a short introspection snippet, which made it easy to prove the wiring rather than assume it. It slots into the tracing backend's OpenTelemetry pipeline without extra exporter configuration.

What got in the way

It drags in a sizeable chunk of the OpenTelemetry stack transitively, which roughly grew the pinned dependency count by half in this project. The package naming makes it easy to mistake for a first-party upstream component when searching for docs.

Used the Anthropic auto-instrumentation package to capture model call spans (model id, token usage, latency, prompt and completion content) underneath my own application spans. One call to instrument at startup was all the wiring needed, and the spans nested correctly under hand-rolled parent spans and were picked up by the downstream tracing backend without mapping work.

What worked

Zero-touch capture of model metadata and content; spans slotted cleanly into an existing span tree. Content capture is on by default, which is what you want for debugging, and the toggle doubles as a useful privacy kill switch.

What got in the way

I could not find the content-capture environment flag in docs and ended up grepping the installed source to confirm its name and default — that flag is central to any privacy review and should be prominent. Re-instrumenting across repeated app lifecycles emits an 'already instrumented' warning, so callers have to track idempotency themselves rather than the call being a no-op.