OpenInference: OpenTelemetry Conventions for Tracing LLM Calls
OpenTelemetry Instrumentation for AI Observability
At a glance
- What is it?
- OpenInference is a specification plus a set of per-framework Python packages that map LLM, retriever and tool calls onto OpenTelemetry spans. It is worth adopting if you already run an OTel pipeline and want model-level attributes in it; it is the wrong layer if you need an evaluation or dataset store.
- Who is it for?
- Adopt OpenInference if you already operate an OpenTelemetry collector and want LLM spans to carry attributes your existing backend can query, and if the frameworks you use appear in the instrumentation table. Do not adopt it if you need an evaluation harness, dataset versioning or a hosted trace UI, because none of those live in this repository.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap OpenInference fills between an LLM SDK and an OTel collector
A standard OpenTelemetry HTTP instrumentation will tell you that a request to api.openai.com took 1.8 seconds and returned 200. It will not tell you which model was called, what the prompt was, how many tokens were billed, or which retrieved document was pasted into the context window. Those facts live inside the SDK call, not in the HTTP layer. The README describes OpenInference as "a set of conventions and plugins that is complementary to OpenTelemetry to enable tracing of AI applications", and the specification is designed "to provide insight into the invocation of LLMs and the surrounding application context such as retrieval from vector stores and the usage of external tools such as search engines or APIs". The audience is therefore narrow and specific: platform or ML engineers who already run a tracing backend and want LLM calls to appear in the same waterfall as the rest of their services. It is not aimed at someone who wants a standalone prompt-debugging tool with no existing telemetry stack.
Semantic conventions first, then one package per framework
The architecture has three layers. At the bottom is openinference-semantic-conventions, which the README calls the "Semantic conventions for tracing of LLM Apps". This is the contract: a fixed vocabulary of attribute names that describe a model invocation, a retriever hit or a tool call. Above it sits openinference-instrumentation, described as "Reusable utilities, decorators, configurations, and helpers for instrumentation", which the individual framework packages build on. The top layer is a long list of per-framework packages: openinference-instrumentation-openai, openinference-instrumentation-vertexai, openinference-instrumentation-agno, openinference-instrumentation-ag2, and others covering LangChain, LlamaIndex, Haystack, Pydantic AI, smolagents, MCP and the Vercel AI SDK according to the repository topics. Each framework gets its own distribution rather than one monolithic package, which keeps the dependency footprint of an OpenAI-only application free of LangChain. The cost of that choice is version drift: the repository publishes separate release tags such as python-openinference-semantic-conventions-v0.1.37, python-openinference-instrumentation-v0.1.63 and python-openinference-instrumentation-vertexai-v0.1.25, all dated within hours of each other in the material supplied. Three independently versioned artefacts have to stay in step, and nothing in the README states a compatibility matrix between them.
Getting a trace out of an instrumented application
The README does not include a full quickstart in the excerpt available here, so the exact registration call cannot be quoted with confidence. What the repository layout does establish is the package set you install from PyPI: openinference-semantic-conventions, openinference-instrumentation, and the framework-specific package, for example openinference-instrumentation-openai or openinference-instrumentation-vertexai. Because the project is complementary to OpenTelemetry rather than a replacement, the export path is the standard OTel one: an OTLP endpoint configured through the usual OpenTelemetry environment variables, with the instrumentation packages emitting spans whose attributes follow the OpenInference conventions. The README states that OpenInference "is natively supported by Arize Phoenix and Arize AX, but can be used with any OpenTelemetry-compatible backend as well". That sentence is the practical setup guide: pick a backend that accepts OTLP, point the exporter at it, and the OpenInference attributes arrive as span attributes. For the exact installer and registration snippet, read the README of the specific instrumentation package on PyPI rather than the top-level repository, since that is where the per-framework instructions live.
The versioning surface is the real operational cost
The maintenance burden here is not the code, it is the release cadence. The three releases listed for 2026-09-10 land within roughly four hours of each other, and the semantic conventions package is already at v0.1.x after 37 patch releases. A specification that is still pre-1.0 means attribute names can change, and an attribute rename is a silent breaking change for anything downstream that filters or aggregates on it. If your dashboards group by a prompt or token attribute, a patch bump of openinference-semantic-conventions can empty them without any error appearing in your application logs. The instrumentation packages inherit that risk because they emit whatever the conventions define. There is no statement in the README about a deprecation policy or a stability guarantee for the attribute vocabulary, so treat the conventions as moving. Pinning exact versions of all three layers and upgrading them together, deliberately, is the only defensible approach given what the material shows.
Where OpenInference is the wrong tool
OpenInference stops at telemetry. It does not store datasets, run evaluators, score outputs or manage prompt versions. If your question is "did this change make the answers better", this repository has nothing to say about it. It also assumes you have somewhere to send OTLP data. There is no bundled collector and no bundled UI in the material provided; the README points at Phoenix and Arize AX as native backends, which means a team with no existing observability stack is looking at two installations, not one. A second limitation is language coverage. The README's instrumentation section is organised by language and the only language with a package table in the supplied excerpt is Python, matching the repository's stated primary language. Topics mention JavaScript-ecosystem frameworks such as the Vercel AI SDK, but the packages documented in the excerpt are Python distributions. A polyglot team will get inconsistent trace depth across services. Finally, span attributes carrying prompts and retrieved documents are user data. The material says nothing about redaction or sampling controls, so the instrumentation will export whatever the SDK call contained unless you add that yourself at the collector.
How it differs from LangSmith and from Phoenix
The nearest comparison in the LLM tooling space is LangSmith, and the difference is architectural rather than feature-level. LangSmith is a hosted platform with its own SDK and its own trace format; you adopt its client and its backend together. OpenInference inverts that: the wire format is OpenTelemetry, the attribute vocabulary is the OpenInference specification, and the backend is replaceable. The trade-off is real in both directions. LangSmith gives you evaluation runs and dataset management in the same product, which OpenInference does not attempt. OpenInference gives you traces that sit alongside your existing service telemetry and survive a backend migration, which a proprietary client does not. The other comparison is internal to Arize: Phoenix is the trace UI and evaluation tool, and the README states that OpenInference is natively supported by it. Phoenix is a consumer of these conventions, not a competitor to them. If you want the UI, you install Phoenix; if you want the attribute contract that makes the UI meaningful, that is this repository.
Licence and the practical adoption boundary
The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved, and it includes a patent grant. Nothing in the material indicates any additional restriction on the instrumentation packages. This is not legal advice; if you vendor or fork the semantic conventions into a proprietary product, have counsel review the notice requirements. The adoption boundary is straightforward once you separate the two artefacts. The specification is cheap to read and cheap to conform to even if you never install a Python package, because it is edited as markdown files in the spec directory and is described as transport and file-format agnostic. The instrumentation packages are the part that carries the upgrade cost, and that cost scales with how many frameworks you instrument. Instrument one framework first, confirm the attributes arrive intact in whichever backend you use, and only then add the second. That single check, performed before you commit, tells you more than any compatibility table the project has not published.
Editorial conclusion
Adopt OpenInference if you already operate an OpenTelemetry collector and want LLM spans to carry attributes your existing backend can query, and if the frameworks you use appear in the instrumentation table. Do not adopt it if you need an evaluation harness, dataset versioning or a hosted trace UI, because none of those live in this repository. Before committing, check the release history for the specific instrumentation package you need on PyPI, and confirm the semantic-convention version your backend parses matches the one the instrumentation emits, since the spec, the shared helper package and each framework package are versioned separately.
Community notes