Tracking: migrate OpenInference Python instrumentations into this repo

[lmolkova]

This issue tracks porting the OpenInference Python instrumentation packages into
opentelemetry-python-genai, so that GenAI instrumentation is built on the shared
opentelemetry-util-genai utilities and emits telemetry that conforms to the
GenAI semantic conventions.

Important

• Use the instrumentations from https://github.com/open-telemetry/donation-openinference/ as the source
  (once seeded). DO NOT use https://github.com/Arize-ai/openinference/.

• Before starting work on a specific library, please ask to be assigned in the table —
  for example, by leaving a comment on this issue.

• Prioritize packages with more downloads and the ones your organization is interested in.

• Make sure to link this issue from the migration PRs.

Candidate packages (ordered by recent PyPI downloads):

OI package	Downloads last month	Assignee	Status and link(s) to PR	Notes
openinference-instrumentation-langchain	2,303,629	@wrisa @keith-decker @lzchen @rads-1996	#181 (closed, not merged) #188 - merged #261 - merged #272 - merged #281 - merged #302 - merged #305 - merged #334 - merged #296 - open
openinference-instrumentation-openai	1,988,421	@eternalcuriouslearner	#184 - merged #269 - merged #278 - merged #282 - merged #355 - merged #358 - open
openinference-instrumentation-pydantic-ai	777,820		Won't port	Has native instrumentation
openinference-instrumentation-anthropic	715,867	@eternalcuriouslearner	#191 - merged #269 - merged #302 - merged
openinference-instrumentation-claude-agent-sdk	625,120		#297 (closed, not merged)
openinference-instrumentation-openai-agents	576,006	@eternalcuriouslearner	#302 - merged #100 - stale
openinference-instrumentation-google-adk	572,630		Won't port	Has native instrumentation
openinference-instrumentation-agno	505,207	@DylanRussell	#301 - merged (skeleton) #328 - merged #350 - open
openinference-instrumentation-litellm	504,172	@alexander-akhmetov @jgordley		Has native instrumentation, check the policy before starting
openinference-instrumentation-google-genai	472,235	@DylanRussell	#165 - merged #176 - merged #232 - merged #233 - merged #271 - merged #283 - merged #304 - merged #326 - stale
openinference-instrumentation-crewai	415,635	@venkata-pavani	#224 (closed, not merged) #308 - merged (skeleton) #363 - open #384 - draft	Native instrumentation, not compatible, context
openinference-instrumentation-llama-index	413,031	@eternalcuriouslearner	#309 - merged (skeleton)
openinference-instrumentation-haystack	393,875	@srinjoy356	#318 - open #373 - open	Overlapping PRs, one should be closed. Has native instrumentation, check the policy before starting
openinference-instrumentation-bedrock	350,897	@DylanRussell	#359 - open (skeleton)	Overlaps with opentelemetry-instrumentation-botocore in contrib, which already instruments Bedrock Runtime. Needs a plan to avoid double instrumentation, see discussion
openinference-instrumentation-instructor	130,202
openinference-instrumentation-mistralai	120,700		Won't port	Has native instrumentation
openinference-instrumentation-dspy	119,851
openinference-instrumentation-groq	117,114	@royrhea	#368 (closed, not merged) #313 - open
openinference-instrumentation-vertexai	114,965		Won't add	The library is deprecated
openinference-instrumentation-smolagents	114,073	@alexander-akhmetov	#349 - merged (skeleton) #352 - open #340 - draft
openinference-instrumentation-mcp	83,845		Won't port	Has native instrumentation
openinference-instrumentation-portkey	33,488
openinference-instrumentation-autogen	13,098			Has native instrumentation, check the policy before starting
openinference-instrumentation-beeai	12,368			Has native instrumentation, check the policy before starting
openinference-instrumentation-strands-agents	10,318	@Shriprasad-P		Has native instrumentation, check the policy before starting
openinference-instrumentation-agent-framework	7,385			Has native instrumentation, check the policy before starting
openinference-instrumentation-autogen-agentchat	3,831			Has native instrumentation, check the policy before starting
openinference-instrumentation-guardrails	3,390
openinference-instrumentation-pipecat	1,419			Has native instrumentation, check the policy before starting
openinference-instrumentation-agentspec	690

Migration guidance

• Build on opentelemetry-util-genai. Avoid emitting spans, metrics, or events directly — use the
  shared utilities so all packages produce consistent, conformant telemetry, share the same configuration
  options and extensibility hooks, and to reduce maintenance toil.
• Do use AI to help with the port and the review. Minimize use of AI when talking to humans.
• Use the provided migration and review skills (to be added in Add skills to help with instrumentation migration #143) to drive the port consistently.
• Contribute back to the migration skills so the workflow improves as we go.
• If migration needs a design decision or some discussion, create individual issues for these
• Keep the PR scoped to the migration only. Do not instrument new operations and do not
  add new features beyond what the source instrumentation already does. Adding missing tests
  for the migrated behavior is encouraged.

Naming

• Package names follow the opentelemetry-instrumentation-genai-{lib} pattern, where {lib} is
  the PyPI name of the instrumented library — e.g. crewai →
  opentelemetry-instrumentation-genai-crewai, importing as
  opentelemetry.instrumentation.genai.crewai. This MAY be different from the suffix used by OpenInference.

Version support

• Consider supporting only the latest major version of the instrumented library and dropping
  compatibility with older versions, to reduce maintenance toil.

Existing packages

• For libraries that already have a package in this repo (marked "Existing package" above), do
  not re-port from scratch. Instead, analyze the delta between the OpenInference
  instrumentation and the existing code — operations covered, scenarios, attributes, captured
  content — and contribute only what's missing or improved back into the existing package.
  Do not modify existing code. If refactoring is helpful, do it as a follow-up to the migration PR.

Semantic conventions

• When there is no convention for a specific operation or scenario, file a bug in
  open-telemetry/semantic-conventions-genai
  to get it specified.
• In the meantime, report an empty span where appropriate (e.g. an operation span without
  speculative attributes). Do not report unconventional / non-spec attributes.
  Leave TODOs in the code pointing to the semconv issue.

Tests

• Add conformance tests for the important scenarios of each library:
  • LLM clients: inference + tool calling + reasoning + multi-modal content, embeddings.
  • Agents: invoke_agent + tools, workflows, orchestration.
• Add missing unit test coverage for the instrumentation logic (if anything is missing).

[DylanRussell]

I can check out openinference-instrumentation-google-genai

[eternalcuriouslearner]

I can check out the following instrumentations:

openinference-instrumentation-openai-agents
openinference-instrumentation-openai-agents
openinference-instrumentation-openai
openinference-instrumentation-anthropic

[DylanRussell]

is the idea with the donation that the arize people will no longer maintain their version of these instrumentations, and we will eventually take them over ? do we have to have like feature parity with them ? The spans they emit look very different so it'll be pretty much impossible to have complete compatibility, but they are doing various things we don't do but we could do.. like looking for random variables in the context that the user can optionally set and get them propagated into the span (https://github.com/open-telemetry/donation-openinference/blob/main/python/openinference-instrumentation/src/openinference/instrumentation/context_attributes.py#L214-L256 ).. lots of little random stuff like that which we could possibly add

[DylanRussell]

Alright I've looked over openinference-instrumentation-google-genai:

• They monkey patch a whole bunch of methods that our instrumentation doesn’t (we only instrument the generate_content methods: https://github.com/open-telemetry/donation-openinference/blob/main/python/instrumentation/openinference-instrumentation-google-genai/src/openinference/instrumentation/google_genai/__init__.py#L22-L38

• Our own generate_content instrumentation in general is much more complete // in-line with the otel semantic conventions

• https://github.com/open-telemetry/donation-openinference/blob/main/python/openinference-instrumentation/src/openinference/instrumentation/context_attributes.py#L214-L256 – they let the user set some attributes in the Context that then make it into the spans..

• They put the thought signature in a bunch of places (seems we have an open issue to add this GenAI semconv needs vendor-neutral reasoning parts and continuity tokens semantic-conventions-genai#192 )

• They json dump the entire request/response into attributes (input.value and output.value)

• They only emit a trace/spans.. They don’t emit events. They don’t emit the execute_tool span..

• Bunch of other minor differences that don't seem worth mentioning.. diff between the gen ai instrumentation in our repo :https://www.diffchecker.com/sgN7o4nN/

I think the main takeaway is we can / should monkey patch more methods, we can use their instrumentation to guide us a little bit but it probably makes more sense to just roll our own...

[eternalcuriouslearner]

Here are my takeaways for anthropic instrumentation:

1. OpenInference patches more Anthropic SDK surface than we do: Completions, Messages, and BetaMessages.
2. Our package currently patches only Messages.create, Messages.stream, and AsyncMessages.create.
3. Our streaming path already uses the accumulated message snapshot / accumulate_event pattern, so there is no need to port OpenInference’s streaming wrapper.
4. The actionable stable gaps are AsyncMessages.stream, Messages.parse, and AsyncMessages.parse.
5. We intentionally leave out Completions and BetaMessages to keep the instrumentation focused on the stable Messages API. We can add BetaMessages later if there is broader community demand.
6. I too noticed Dylan’s observations (around reasoning parts, input.value and output.value) and other observations from this migration doc.

Takeaway: Anthropic instrumentation is nearly stable and there is no need to port their instrumentation. I recommend adding instrumentation around remaining AsyncMessages.stream, Messages.parse, and AsyncMessages.parse functions.

[Necmttn]

Migration acceptance should prove correlation, not only attribute naming. For each ported instrumentor, run fixtures that preserve session or conversation id, turn or message id, tool-call id, model, token buckets, cost source, and a raw-provider usage pointer.

Then assert an OTel receiver can ingest the spans without double-counting transcript-derived usage. That gives backend tools a migration path from OpenInference attrs to OTel GenAI conventions while raw fields stay available for diagnostics.

---

Generated with ax.

[lmolkova]

@Necmttn I noticed you left a few comments on GenAI-related topics that are generated with AI. While using AI is not a problem, please consider using AI to polish your thoughts only. Please make sure your comments are actionable, informative, or help to move the discussion forward.

[eternalcuriouslearner]

OpenInference's OpenAI instrumentation is patching the whole request layer around OpenAI.request / AsyncOpenAI.request and custom adapter logic around response structure to cater for chat, completions, embeddings and responses. Traditionally this is a kind of anti-pattern from the monkey-patching approach we adapted around instrumenting GenAI SDKs. If we adopted this pattern we need to do copious amount of refactor. I don’t particularly see any benefit in the refactor as OpenInference is not adding materially more semconv-aligned coverage than we are covering today. Given the maturity we have in OpenAI instrumentation it's better to stick with current approach of monkey-patching individual functions instead of a large refactor.

[trask]

@Necmttn following up on @lmolkova's note above: I've hidden the set of AI-generated comments you posted across the GenAI issues on 2026-06-21, as off-topic/low-relevance under our Generative AI Contribution Policy.

To be clear, using AI isn't the problem, and disclosing it is appreciated. The issue is that these were bulk, unedited tool output that didn't engage with the specifics of each thread. As the policy puts it, "regurgitating the output of an LLM is unlikely to be particularly helpful," and the human contributor needs to stay in control and add their own context and judgement.

You're very welcome to participate, please just post in your own words on topics you're actively working through, with comments that are specific and actionable for that thread. Thanks for understanding.

[jgordley]

@alexander-akhmetov and I can take openinference-instrumentation-litellm to start with 🙂

[eternalcuriouslearner]

I can take openinference-instrumentation-claude-agent-sdk.

[alexander-akhmetov]

@jgordley and I checked LiteLLM and it now has native instrumentation: https://docs.litellm.ai/docs/observability/opentelemetry_v2 (for the proxy). For the SDK/extensions there is an older v1 version which supports GenAI semantic conventions.