How to Trace the Anthropic Claude API in 2026 - Three Ways to Add Observability and Cost Tracking

If you already traced your OpenAI calls, tracing Claude is the same instinct with one wrinkle - there is no drop-in wrapped Anthropic client the way there is for the OpenAI SDK in most tools, so you reach for a decorator, a proxy, or OpenTelemetry instead. That is a small difference in mechanics and no difference in why you bother. The moment a user reports a bad answer, the only thing that helps is a record of the exact prompt Claude got and the exact response it returned. And Claude’s Messages API hands you clean token counts, so tracing doubles as cost tracking almost for free. Here are the three ways, with working setup for each.

What you are capturing, and why it is worth it

Every Anthropic Messages API response carries a usage object with input_tokens and output_tokens, and when you use prompt caching it adds cache-creation and cache-read counts. That usage data is the reason to trace Claude even before you have a bug - it is how you attribute cost to a feature, a customer, or one greedy prompt. A trace pairs those token counts with the prompt, the response, the latency and any tool calls, so you get debugging and cost accounting from one integration. Multiply the tokens by Anthropic’s current per-token rates to get dollars; the trace gives you the tokens.

Approach 1: the decorator or span (recommended)

This is the cleanest path for a Python or TypeScript app. You wrap the function that calls Claude, and the tracer records inputs, outputs, tokens and timing without sitting in the request path. With Langfuse the pattern is its @observe decorator plus a manual capture of the model call - illustrative, verify against current docs:

import anthropic
from langfuse import observe, get_client

client = anthropic.Anthropic()
langfuse = get_client()

@observe()
def ask_claude(prompt: str):
    resp = client.messages.create(
        model="claude-sonnet-4",       # check current model ids in Anthropic's docs
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )
    langfuse.update_current_observation(
        input=prompt,
        output=resp.content[0].text,
        usage_details={
            "input": resp.usage.input_tokens,
            "output": resp.usage.output_tokens,
        },
    )
    return resp.content[0].text

The decorator creates the trace, and the usage_details line feeds Langfuse the token counts straight off the response so it can compute cost. The tracer observes from the side - it never sits between your app and Anthropic, so if the tracing backend hiccups, your Claude call still goes through. Langfuse is MIT-licensed and free to self-host, framework-agnostic, and maps the OpenTelemetry GenAI conventions if you want to standardize later. The operational catch is that its v3 self-host is a four-service stack, so the $29/mo cloud tier is the shortcut if you would rather not run it. This mirrors the SDK-wrapper approach in how to trace OpenAI API calls - same philosophy, adapted to Anthropic’s SDK.

Approach 2: the proxy gateway (least code, read the warning)

The proxy needs the least code of all - you point your Anthropic client at a gateway base URL and it logs every call, with no SDK, in any language. Helicone built its product around this and does support the Anthropic SDK, so you change one base URL and get a dashboard of requests, tokens and cost.

Here is the honest problem. Mintlify acquired Helicone in March 2026 and put it in maintenance mode - security and bug fixes only, no roadmap, and Mintlify is helping customers migrate off. For a new project that fact overrides the convenience. The proxy model is also structural risk on its own terms - it sits in your request hot path, so if the gateway is down your Claude calls fail even when Anthropic is healthy, and every proxied call adds latency. Helicone offers an async logging mode that dodges both, but then you have lost the zero-code convenience that was the only reason to pick a proxy. So the proxy is the easiest way to trace Claude, and Helicone did it well - just do not start fresh on a frozen product in 2026.

Approach 3: OpenTelemetry (the standards-clean option)

If your organization has standardized on OpenTelemetry, instrument your Claude calls to emit OTel spans and send them to any OTLP backend. Langfuse runs as an OpenTelemetry backend, receiving traces on an OTLP endpoint over HTTP and mapping the GenAI semantic conventions - gRPC is not supported yet. Braintrust also exposes an OTLP endpoint and works with standard OpenTelemetry exporters, adding evals and regression testing on top of the traces.

This is the most vendor-neutral route - your instrumentation is standard OTel, so you can repoint it at a different backend later without touching app code. It is also the most setup, so reach for it when OTel is already a requirement, not a preference. The primer on OpenTelemetry for LLM observability covers the semantic conventions in depth.

Which approach for Claude?

Approach	Code change	In your hot path?	Best tool here
Decorator / span	A few lines	No	Langfuse
Proxy gateway	One base URL	Yes	Helicone (frozen - see above)
OpenTelemetry	OTel setup	No	Langfuse / Braintrust

For most teams tracing Claude in 2026, the decorator on Langfuse is the answer - a few lines around your call, token-level cost tracking off the usage object, actively developed and free to start. To turn these traces into savings, pair this with how to reduce LLM costs, and for the wider picture see the best LLM monitoring tools. Code shape here follows each tool’s standard integration pattern and Anthropic’s SDK - verify both against current docs, since this category ships breaking changes monthly.