Repository navigation
[Feature]: Add support for Arize Phoenix as an OTEL-compatible backend #27
Description
Is your feature request related to a problem?
It would be great to have support for Arize Phoenix
as a backend for this plugin.
Phoenix is an open-source observability platform for LLM applications (traces, spans, evals) and already supports OpenTelemetry, which makes it a natural fit for opencode-plugin-otel.
Why this is useful:
Open-source and self-hostable alternative for LLM observability
Growing adoption in the ecosystem
Native OTEL support means integration should be straightforward
Enables local-first workflows without relying on proprietary SaaS
References:
https://github.com/Arize-ai/phoenix
https://docs.arize.com/phoenix
Happy to help test or contribute if needed 👍
Describe the solution you'd like
Configuration example for exporting traces to Phoenix
Optional preset / docs section for Phoenix setup
Validation that spans are correctly visualized in Phoenix UI
Describe alternatives you've considered
No response
Telemetry type
Metrics
Additional context
No response
Checklist
- I have searched existing issues and discussions for similar feature requests
- I have checked the changelog to see if this already exists
Activity
dialupdisaster commentedon Apr 16, 2026
Thanks for raising this. From the plugin side, there is already a good amount of baseline compatibility today:
opencode-plugin-otelexports standard OTLP over both gRPC and HTTP/protobuf, so in principle it should already be able to send telemetry to Phoenix without a Phoenix-specific exporter.What is less clear is what level of compatibility you’re looking for:
The UI point is the important one. Phoenix can ingest OTLP, but “data arrives” and “the Phoenix UI understands and presents it nicely” are slightly different things. Depending on what Phoenix expects, we may need nothing more than docs, or we may need to adjust some trace/span semantics so sessions, LLM calls, and tool calls show up in a more Phoenix-native way.
Could you clarify which of the above you want this issue to cover? If you have a specific Phoenix workflow or screenshot/example of the expected UI, that would help narrow the scope quite a bit.
dialupdisaster commentedon Apr 16, 2026
Quick update: I’m going to work on making the emitted traces more OpenInference-compatible.
The current plugin already exports standard OTLP, but Phoenix is much more native to OpenInference semantics than generic
gen_aiattributes. Aligning the spans more closely with OpenInference should improve how sessions, LLM calls, and tool calls render in Phoenix, and it should also help with other systems that adopt the same standard.I’ll treat this as a semantic compatibility improvement rather than just transport compatibility.
dialupdisaster commentedon Apr 21, 2026
Update: this has now landed and was released in
v0.8.0.What to expect:
v0.8.0, the emitted trace semantics are now more OpenInference-compatibleIn practical terms, Phoenix users should see better trace structure and more useful span metadata rather than just "raw OTLP made it to the collector".
A couple of expectations to set clearly:
If anyone tries this with Phoenix and notices gaps in how spans are grouped, labeled, or displayed, please share screenshots or trace examples and we can iterate further.
dialupdisaster commentedon May 1, 2026
Going to close this, I was able to verify the traces in Arize and grafana.