Verdict
Choose by backend, not by schema aesthetics. If your traces might ever land in a general-purpose APM - Datadog, New Relic, Grafana/Tempo, or a future backend you have not picked yet - emit gen_ai.* via OpenLLMetry: Datadog's LLM Observability docs state support for OpenTelemetry GenAI semantic conventions and say outright that 'OpenInference is not supported' (docs.datadoghq.com/llm_observability/instrumentation/otel_instrumentation), which makes gen_ai.* the only convention with a credible claim to universal portability. If you are committed to Arize Phoenix or Arize AX as your trace UI, OpenInference is the native format - Phoenix's own docs describe translating OpenLLMetry and OTel GenAI spans into OpenInference via span processors before they display consistently (arize.com/docs/phoenix, translating-conventions page), so emitting anything else there means running a translation layer forever. The honest caveat cuts against OpenLLMetry's main selling point: the official OTel GenAI conventions it tracks are still marked in-development, while Arize documents OpenInference itself as stable - you are trading schema stability today for standards alignment tomorrow. And if you refuse to choose, one backend dissolves the dilemma: Langfuse's OTLP endpoint documents mapping for OpenLLMetry, OpenInference, and raw gen_ai.* spans alike.
The two projects sit at different layers of the same OpenTelemetry stack. OpenLLMetry is Traceloop's Apache-2.0 auto-instrumentation suite whose conventions were upstreamed into the official OpenTelemetry GenAI work, so its output tracks the canonical gen_ai.* attribute namespace (model, token counts, tool calls) - the schema OTel's own GenAI observability blog posts describe, with the important asterisk that those conventions remain experimental/in-development per opentelemetry.io and Arize's semantic-conventions docs. OpenInference is Arize's Apache-2.0 specification defining its own attribute namespace, span-kind taxonomy (LLM, CHAIN, TOOL, RETRIEVER, EMBEDDING, and agent-specific kinds), and MIME-type handling - still valid OTLP, but a different schema, documented as stable at arize-ai.github.io/openinference. Ingestion is where the choice bites, and the matrix is asymmetric. Native gen_ai.* consumers: Datadog LLM Observability (OTel 1.37+ GenAI conventions, with OpenInference explicitly unsupported, per docs.datadoghq.com), Braintrust (implements the OTel GenAI conventions per its own OpenTelemetry tracing guide), and any generic OTLP store like Grafana Tempo or Honeycomb, which will hold either schema but render both as plain spans without LLM-aware UI. OpenInference's first-class home is Arize Phoenix/AX; Arize's docs note gen_ai.* spans are accepted into AX but do not receive the same UI treatment as OpenInference-tagged spans. Langfuse is the deliberate neutral: its OpenTelemetry integration docs (langfuse.com/integrations/native/opentelemetry) describe an OTLP endpoint compliant with the GenAI semantic conventions that maps spans from OpenLLMetry, OpenInference, and gen_ai.* emitters into Langfuse observations. Sources: opentelemetry.io GenAI observability posts, docs.datadoghq.com, arize-ai.github.io/openinference, arize.com/docs (Phoenix translating-conventions and AX semantic-conventions pages), langfuse.com/integrations, and futureagi.com's 2026 OpenInference-vs-OpenLLMetry roundup.
Decision Table
| Criterion | Edge | Explanation |
|---|---|---|
| Portability across general-purpose backends | OpenLLMetry (Traceloop) - OTel-native instrumentation emitting gen_ai.* semantic conventions Best edge | gen_ai.* is the OpenTelemetry-official namespace, and schema-aware APM support is consolidating on it: Datadog LLM Observability documents OTel 1.37+ GenAI convention ingestion while explicitly stating 'OpenInference is not supported' (docs.datadoghq.com/llm_observability/instrumentation/otel_instrumentation), and Braintrust implements the GenAI conventions directly (braintrust.dev OpenTelemetry guide). OpenInference spans remain valid OTLP anywhere, but outside Arize's ecosystem they render as generic spans - the LLM-aware dashboards, token accounting, and cost views key off gen_ai.* attributes they do not carry. |
| Schema stability today | OpenInference (Arize) - a separate span convention (openinference.* attributes, span-kind taxonomy) on top of OpenTelemetry Best edge | This is the uncomfortable row for the standards-track argument: the official OTel GenAI semantic conventions that OpenLLMetry follows are still marked experimental/in-development (opentelemetry.io GenAI observability posts; Arize's semantic-conventions docs make the same point), meaning attribute names can still shift under you between convention releases. Arize documents OpenInference as a stable spec with a fixed attribute schema and span-kind taxonomy (arize-ai.github.io/openinference/spec). Teams that hard-code dashboards, alerts, and cost pipelines against attribute names feel convention churn directly. |
| Agent-trace expressiveness | OpenInference (Arize) - a separate span convention (openinference.* attributes, span-kind taxonomy) on top of OpenTelemetry Best edge | OpenInference ships a span-kind taxonomy purpose-built for agent traces - CHAIN, TOOL, RETRIEVER, EMBEDDING, RERANKER, and agent-level kinds with defined MIME-type handling for structured payloads (arize-ai.github.io/openinference/spec). The gen_ai.* conventions cover model calls, token usage, and tool invocation well, but the richer agent-graph semantics (what kind of step is this span, how are retriever documents attached) are further along in OpenInference - one reason Phoenix's agent-trace UI is as legible as it is. |
| Alignment with the official OpenTelemetry direction | OpenLLMetry (Traceloop) - OTel-native instrumentation emitting gen_ai.* semantic conventions Best edge | OpenLLMetry's conventions were upstreamed into the OpenTelemetry GenAI work, so emitting via OpenLLMetry means your data converges on the canonical schema as those conventions stabilize (opentelemetry.io GenAI observability; futureagi.com's 2026 comparison notes the lineage, and that Traceloop's work continued under ServiceNow's ownership). OpenInference is and intends to remain a separate convention layer: interoperable with OTel transport, but not the namespace the broader OTel ecosystem is standardizing on. If your bet is 'in three years every backend speaks gen_ai.* natively,' OpenLLMetry is the side of that bet. |
| Arize Phoenix / AX experience | OpenInference (Arize) - a separate span convention (openinference.* attributes, span-kind taxonomy) on top of OpenTelemetry Best edge | Phoenix is OpenInference-native: its docs describe using span processors or the GenAI-translation package to convert OpenLLMetry and OTel GenAI spans into OpenInference before they display consistently (arize.com/docs/phoenix translating-conventions), and Arize AX accepts gen_ai.* spans but without the full UI treatment OpenInference spans get (arize.com/docs/ax semantic-conventions). If Phoenix is your trace UI - a common choice, since it is one of the strongest OSS agent-trace viewers - emitting OpenInference natively avoids running a translation shim in your pipeline permanently. |
| Backend-agnostic ingestion without choosing | Tie | A third party wins this row: Langfuse. Its OTLP endpoint documents compliance with the OTel GenAI semantic conventions and mapping for spans produced by OpenLLMetry, OpenInference-instrumented apps, and raw gen_ai.* emitters alike, rendering model calls as Langfuse generations with token and cost mapping (langfuse.com/integrations/native/opentelemetry and langfuse.com/faq on existing OTel setups). Generic OTLP stores (Grafana Tempo, Honeycomb) also accept both - but as schema-blind spans. Langfuse is the one documented backend that is both LLM-aware and convention-agnostic, which makes it the pragmatic sink while your organization postpones the standards decision. |
| Governance and vendor risk | Tie | Both are Apache-2.0, both are single-vendor-stewarded in practice: OpenLLMetry by Traceloop (now under ServiceNow ownership per 2026 ecosystem roundups on futureagi.com - an acquisition that cuts both ways: more resources, less independence), OpenInference by Arize. OpenLLMetry's escape hatch is that its schema is being absorbed into CNCF-governed OpenTelemetry itself, which outlives any one company; OpenInference's mitigation is a stable published spec that anyone can implement. Neither gives you the multi-vendor governance story that, say, OTLP transport itself has. |
Choose OpenLLMetry (Traceloop) - OTel-native instrumentation emitting gen_ai.* semantic conventions if...
- Teams shipping traces into general-purpose APM (Datadog, New Relic, Grafana stack) alongside application traces - gen_ai.* is what those backends key their LLM-aware features on.
- Organizations standardizing on OpenTelemetry end-to-end that want agent traces on the same official-conventions track as HTTP and DB spans.
- Teams that have not picked a final backend and want maximum optionality from one instrumentation choice.
- Polyglot stacks leaning on OpenLLMetry's broad auto-instrumentation coverage across Python and JS/TS providers and frameworks.
Choose OpenInference (Arize) - a separate span convention (openinference.* attributes, span-kind taxonomy) on top of OpenTelemetry if...
- Teams committed to Arize Phoenix or AX as the trace UI - OpenInference is the native schema and everything else is translated in.
- Agent-heavy systems that want the richer span-kind taxonomy (CHAIN, TOOL, RETRIEVER, EMBEDDING) today rather than waiting for the official conventions to stabilize equivalents.
- Teams burned by convention churn that value a documented-stable spec over standards-track alignment.
- Eval-centric workflows where traces feed Phoenix's dataset and experiment tooling directly.
Decision rules
- 01If your traces must land in Datadog, the decision is made for you: Datadog documents OTel GenAI convention support and explicitly does not support OpenInference - emit gen_ai.* via OpenLLMetry.
- 02If Phoenix or Arize AX is your committed trace UI, emit OpenInference natively - otherwise you run a gen_ai-to-OpenInference translation processor in your pipeline forever.
- 03If you have not chosen a backend yet, default to gen_ai.* via OpenLLMetry: it is the only schema with a credible path to being understood natively by every LLM-aware backend, and generic OTLP stores hold it fine meanwhile.
- 04If schema churn is your top risk (dashboards, alerts, and cost pipelines keyed to attribute names), weight OpenInference's documented stability against the still-in-development status of the official GenAI conventions - and pin instrumentation library versions either way.
- 05If your org cannot decide, point both at Langfuse: its OTLP endpoint documents mapping for OpenLLMetry, OpenInference, and raw gen_ai.* spans, so teams can emit differently without losing a shared view.
- 06Whatever you emit, put an OpenTelemetry Collector in the path from day one - convention translation (there is an OpenInference GenAI-translation package for exactly this) becomes a config change instead of a redeploy of every service.
Migration Notes
- OpenInference to gen_ai.*: expect attribute-level rework in every dashboard and alert; span structure survives (both are OTLP) but names and span-kind semantics do not map one-to-one, and the in-development status of GenAI conventions means a second, smaller migration when they stabilize.
- gen_ai.* to OpenInference: Phoenix's translation tooling (span processors, the GenAI-translation package documented at arize.com/docs/phoenix) can do this at the collector so you migrate the pipeline before re-instrumenting services - do it in that order.
- Run the dual-emit test before committing: route one high-traffic service through an OTel Collector to both target backends for a week and diff what each UI actually shows you - the gap between 'accepts the spans' and 'renders them usefully' is the real migration cost.