Instrument LLM apps with OpenTelemetry
The Currai team, Engineering — Apr 28, 2026
If your platform team already runs OpenTelemetry, you don't have to choose between your existing tracing standard and LLM-specific observability. Currai ingests OpenTelemetry spans through the standard OTLP endpoint, so the collector, exporters, and auto-instrumentation you already maintain can carry your LLM traces too.
Point your exporter at Currai
OTLP is just a protocol over HTTP. Configure the standard environment variables and your existing OpenTelemetry SDK ships spans to Currai with no code change.
Any span your app already emits — HTTP handlers, database calls, queue consumers — lands in Currai alongside the model calls, so a single trace spans your whole request, not just the LLM part.
Use the GenAI semantic conventions
OpenTelemetry has a set of conventions for model calls — attributes like the model name, token counts, and parameters. Set them on your spans and Currai reads them as first-class generations, with cost and usage where you'd expect.
The payoff: your generic infra spans and your model spans live in one trace, and the model spans still get token roll-ups and cost.
When to use OTLP vs the SDK
Both paths reach the same backend, so pick by where you already are:
- Use OTLP when you have an OpenTelemetry investment — a collector, existing auto-instrumentation, a platform standard — and want LLM traces to flow through it.
- Use the Currai SDK when you want the shortest path to a rich generation, with usage and parameters as named arguments rather than attributes you set by hand.
No vendor lock-in by construction
The reason to lean on OTLP is the same reason OpenTelemetry exists: the instrumentation is portable. Spans you emit to the standard endpoint aren't tied to one backend's proprietary client, so the code you write today keeps its value no matter where the data eventually lands. Currai meeting you at the open standard is the point — you bring the spans, we provide the LLM-aware views.
currai