[Feature]: Add support for Arize Phoenix as an OTEL-compatible backend

[Claud]

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

[dialupdisaster]

Thanks for raising this. From the plugin side, there is already a good amount of baseline compatibility today: opencode-plugin-otel exports 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:

• basic transport compatibility (telemetry successfully arrives in Phoenix)
• configuration/docs compatibility (documented Phoenix setup and example env vars)
• UI compatibility (the traces/spans render well in Phoenix and are useful to inspect)
• semantic compatibility (span names/attributes match what Phoenix expects for the best LLM observability experience)

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]

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_ai attributes. 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.