OpenInference vs OpenLLMetry vs OpenLIT in 2026: OTel for LLMs Compared

OpenInference, OpenLLMetry, and OpenLIT all sit on top of OpenTelemetry: each emits standard OTel spans for LLM calls, vector DB lookups, and framework steps. Choosing OpenInference vs OpenTelemetry GenAI conventions comes down to attribute names, and the three libraries also differ on languages and extras. OpenInference uses its own span kinds and llm.* attributes, OpenLLMetry contributed its conventions to OpenTelemetry, and OpenLIT adds evals, guardrails, and GPU monitoring, so pick the one whose spans your backend reads best.

TL;DR and which library to pick in 2026

If you only read one row: traceAI is the Apache-2.0 emitter for OTel GenAI spans across Python, TypeScript, Java, Go, and C# from one library. OpenInference fits the Arize Phoenix path, OpenLLMetry fits Python stacks that ship to Datadog, Honeycomb, or Grafana, and OpenLIT fits when GPU monitoring is in scope. For deeper reads: see the OTel instrumentation tools guide, traceAI deep-dive, and the LLM observability platform buyer guide.

What each library actually is

All three are Apache 2.0 projects that emit standard OTel spans. Arize AI maintains OpenInference as the default library for Phoenix, Traceloop built OpenLLMetry and upstreamed its conventions into OpenTelemetry, and OpenLIT pairs its Python, TypeScript, and Go SDKs with GPU monitoring, evals, and guardrails.

OpenInference

OpenInference is a set of conventions and plugins complementary to OpenTelemetry that enable tracing of AI applications. The repo had about 1.3k stars and 374 forks on November 4, 2026, with Apache 2.0 licensing. The project is maintained by Arize AI and is the default instrumentation library for the Arize Phoenix backend.

Coverage spans Python (30+ integrations including OpenAI, Anthropic, LangChain, LlamaIndex, DSPy, CrewAI, PydanticAI, and AutoGen AgentChat), TypeScript (OpenAI, Anthropic, LangChain.js, Bedrock, MCP, Vercel AI SDK), Java (LangChain4j, Spring AI, Google ADK for Java), and Go (OpenAI and Anthropic Go SDKs). Microsoft’s AutoGen README now marks the project archived and points new users to Microsoft Agent Framework.

The relationship to OpenTelemetry is that OpenInference defines a complementary specification layer. The spec is transport and file-format agnostic. Any OpenTelemetry-compatible backend can ingest OpenInference spans because they are still OTel spans with additional attributes following the OpenInference convention.

OpenLLMetry

OpenLLMetry is a set of extensions built on top of OpenTelemetry that provides tracing and telemetry for LLM applications. The repo had about 7.5k stars on November 4, 2026 and uses Apache 2.0 licensing.

Traceloop’s official docs list Python, JavaScript/TypeScript, Go, and Ruby getting-started paths: the main traceloop/openllmetry repo is Python, OpenLLMetry-JS is a separate JS/TS project, and traceloop/go-openllmetry is a separate Go SDK that is currently manual instrumentation per the docs (no automatic library instrumentation yet); Ruby has its own SDK. Traceloop announced in March 2026 that it is joining ServiceNow and that OpenLLMetry will remain open source.

Coverage spans 16 LLM providers (OpenAI, Anthropic, Google Gemini, Cohere, Mistral, Groq, Bedrock, Vertex AI, HuggingFace, Ollama, and others) and 7 vector databases (Chroma, Pinecone, Qdrant, Weaviate, Milvus, LanceDB, Marqo). It also covers 10 frameworks (LangChain, LlamaIndex, CrewAI, Haystack, LiteLLM, LangGraph, Langflow, OpenAI Agents, and others) and 24 tested destinations (Datadog, Honeycomb, New Relic, Grafana, SigNoz, Azure Application Insights, Google Cloud, and many others).

OpenLLMetry’s semantic conventions were upstreamed into OpenTelemetry. This means the OTel GenAI semantic conventions reflect Traceloop’s contribution. For teams that bet on the OTel GenAI standard, OpenLLMetry is one of the most direct paths to that standard.

OpenLIT

OpenLIT now calls itself an open-source agent harness engineering platform built on OpenTelemetry. The repo had about 2.9k stars on November 4, 2026 and uses Apache 2.0 licensing. The project provides vendor-neutral SDKs for Python, TypeScript, and Go that send traces and metrics aligned with OpenTelemetry semantic conventions.

OpenLIT lists 70+ integrations across LLM providers (OpenAI, Anthropic, Mistral, Amazon Bedrock, Vertex AI, vLLM, and more), frameworks (LangChain, LangGraph, LlamaIndex, CrewAI, Pydantic AI, Google ADK, and more), and vector stores (Pinecone, ChromaDB, Qdrant, Milvus, AstraDB, PostgreSQL). Its CLI also traces coding agents such as Claude Code, Codex, and Cursor with no code changes.

OpenLIT’s differentiators are GPU monitoring (OpenTelemetry-native GPU metrics), Fleet Hub for OpAMP-based collector management, SDK guardrails for prompt injection and sensitive topics, 11 built-in evaluation types including hallucination and bias detection, prompt management and vault functionality, and cost tracking with custom and fine-tuned model pricing. OpenLIT is free to self-host under Apache 2.0.

OpenInference vs OpenTelemetry GenAI semantic conventions

OpenTelemetry is the vendor-neutral framework for generating, exporting, and collecting traces, metrics, and logs. The OpenTelemetry GenAI semantic conventions add names for model calls under the gen_ai.* namespace, and they now live in their own repository with the span conventions still marked Development. Message content (gen_ai.input.messages, gen_ai.output.messages) is opt-in under these conventions, so check what your instrumentation records.

OpenInference names the same work differently. The OpenInference span kind is required on every span and tells the backend how to assemble the trace. Its values are LLM, EMBEDDING, CHAIN, RETRIEVER, RERANKER, TOOL, AGENT, GUARDRAIL, EVALUATOR, PROMPT, and DECISION, and model data lands in keys such as llm.input_messages, llm.model_name, and llm.token_count.completion.

Future AGI’s traceAI writes OTel GenAI attributes such as gen_ai.request.model and gen_ai.usage.input_tokens, and keeps OpenInference-compatible keys such as input.value, output.value, and retrieval.documents on the same spans. Its Python register() also takes a semantic_convention setting (Future AGI’s default, OpenTelemetry GenAI, OpenInference, or OpenLLMetry) and records it on the trace resource. Because the spans follow the OTel GenAI conventions, any OTel backend can read them.

Architecture and primitives

All three feed an OTel collector as the vendor-neutral target. Future AGI’s collector accepts OTLP spans from all three, with a documented recipe for each, and traceAI emits to any OTel backend.

Code samples

Every snippet below exports OTLP to the same collector, so you can swap libraries without touching the backend. OpenLLMetry and OpenLIT each take one init call pointed at http://collector:4318, while the OpenInference example wires an OTel tracer provider by hand and exports over gRPC on port 4317.

Instrument LangChain in Python with OpenInference

from openinference.instrumentation.langchain import LangChainInstrumentor
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://collector:4317"))
)

LangChainInstrumentor().instrument()

# Now any LangChain call emits OpenInference-conformant OTel spans
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o")
response = llm.invoke("Explain OpenInference in one paragraph.")

Instrument OpenAI in Python with OpenLLMetry

from traceloop.sdk import Traceloop
from openai import OpenAI

Traceloop.init(app_name="my-app", api_endpoint="http://collector:4318")

client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Explain OpenLLMetry."}],
)
# OTel GenAI semconv spans emitted automatically

Instrument Python, TypeScript, and Go with OpenLIT

# Python
import openlit
openlit.init(otlp_endpoint="http://collector:4318")
# All supported LLM providers and frameworks now traced

// TypeScript
import openlit from "openlit";
openlit.init({ otlpEndpoint: "http://collector:4318" });
// Supported LLM providers and frameworks now traced

// Go
import "github.com/openlit/openlit/sdk/go"
openlit.Init(openlit.Config{OtlpEndpoint: "http://collector:4318"})

When to pick which

Start from your backend and your languages, then weigh the extras. Your backend decides which span attributes it reads best, and your language mix narrows the list, since OpenLLMetry’s Go SDK is still manual instrumentation. GPU monitoring, built-in evals, and collector management matter only if they are on your roadmap.

Pick OpenInference if

• Your backend is Arize Phoenix or any OTel-compatible system.
• You need broad agent framework coverage including LangChain, LlamaIndex, DSPy, CrewAI, AutoGen, BeeAI, Haystack, Pydantic AI.
• You need TypeScript, Java, or Go instrumentation alongside Python.
• You value the OpenInference complementary specification approach.

Pick OpenLLMetry if

• Your backend is Datadog, Honeycomb, New Relic, Grafana, or SigNoz, where OpenLLMetry has direct integration paths.
• Your stack is Python (or Python plus JS/TS via OpenLLMetry-JS, or Python plus Go via the separate traceloop/go-openllmetry SDK with manual instrumentation per the docs).
• You want vector-database tracing depth (7 supported vector DBs).
• You value the upstreamed OTel GenAI semantic conventions and want the most direct path to that standard.

Pick OpenLIT if

• You need multi-language SDKs (Python, TypeScript, Go).
• GPU monitoring is in scope.
• You want built-in evals next to instrumentation rather than adding a separate eval layer.
• Fleet Hub for OpAMP-based collector management is part of your operational model.
• You want SDK guardrails or coding-agent tracing next to your traces.

Common mistakes when picking among the three

• Treating the choice as permanent. All three emit OTel spans; the right question is which one fits your backend, languages, and frameworks.
• Picking by stars. OpenLLMetry had the most GitHub stars on November 4, 2026 (about 7.5k), but stars do not show language or backend fit. Pick by ecosystem fit.
• Mixing libraries on the same call path. If you instrument OpenAI calls with both OpenInference and OpenLLMetry, you get duplicate spans. Pick one library as the primary instrumentation.
• Ignoring semantic-convention drift. The OTel GenAI span conventions are still marked Development and now live in their own repository, so attribute names can change between releases. Lock the OTel SDK version in CI.
• Skipping the backend test. The same OTel span can render very differently in Arize Phoenix, Langfuse, Datadog, Honeycomb, Grafana, or SigNoz. Test the actual rendering before picking.

Where traceAI is strongest across languages

traceAI is Future AGI’s Apache-2.0 OpenTelemetry instrumentation library across five languages: framework instrumentors in Python and TypeScript, client wrappers in Java, middleware in Go, and manual spans in C#. It writes OTel GenAI attributes such as gen_ai.request.model, so any OTel backend can read it.

For teams that want eval scores on their spans, Future AGI pairs traceAI with evals and the Agent Command Center gateway on one platform with an Apache-2.0 core. Evals run on traced spans, as historic or continuous runs, and the gateway switches between 100+ providers when you change the model name.

Teams already running one of the three can keep it. Future AGI documents OTLP recipes for sending OpenInference spans, OpenLLMetry traces, and OpenLIT traces to its collector, with no Future AGI package needed for the OpenInference and OpenLLMetry routes.

Where your OTel spans go next

You started out asking which library produces the spans your backend understands best. All three export OTLP, so the choice stays reversible: a new backend later means a new exporter endpoint. The next decision is what your backend does with those spans. Future AGI’s collector reads all three over OTLP, and Future AGI adds evals on traced spans plus the Agent Command Center gateway on the same platform.

Self-host the Apache-2.0 core from the future-agi repo and point your existing OTLP exporter at it.

Sources

• What is OpenTelemetry
• OTel semantic-conventions-genai repository
• Microsoft AutoGen repository
• Microsoft Agent Framework repository