Arize Phoenix: product and architecture
This Arize Phoenix review covers the LLM tracing and evaluation tool you can have running before you finish reading this sentence — uvx arize-phoenix serve is the whole installation — and one licence detail that decides whether it belongs in your stack at all. Phoenix is free, it is built on OpenTelemetry, and it is source-available under the Elastic Licence 2.0 rather than OSI open source. We evaluated it against its documentation, its GitHub repository, and the adoption signals we collect weekly.
Overview
Phoenix is published by Arize AI and is the open, local-first companion to Arize AX, the vendor's commercial observability platform. Our 14 September 2026 snapshot recorded about 11,500 GitHub stars, roughly 160,000 PyPI downloads a week for arize-phoenix, and about 5.6 million pulls of the arizephoenix/phoenix container image. The release cadence is brisk: arize-phoenix-v20.14.0 shipped on 18 September 2026.
Its market position is the fastest path from nothing to a first trace. The design intent is local-first — run it in a notebook, in a container, or as Phoenix Cloud — which makes it the tool people reach for while developing rather than after deploying.
The licence is the thing to settle before anything else. The project's own site says "ELv2 licensed", and the repository LICENSE is Elastic License 2.0. That is source-available: you can read it, run it, and modify it, but it is not an OSI-approved open-source licence, and a stack with an open-source-only requirement cannot include it however the marketing reads.
The audience is AI engineers who want to see what their agent did, now, without provisioning anything.
Key Features and Architecture
Phoenix organises around a five-step loop the documentation states explicitly: observe, annotate, hypothesise, experiment, measure. That is unusually honest product design — it names the workflow rather than listing features — and it is a good description of what debugging an agent actually involves.
Tracing captures every step: prompts, retrievals, tool calls, outputs. Instrumentation is OpenTelemetry-based through OpenInference, which means an application already emitting OTel spans needs no bespoke integration, and spans you send to Phoenix during development can go to a different backend in production without re-instrumenting.
Annotations let a human mark what worked and what broke, or an LLM judge do it at scale. This is the step most tools skip, and it is the one that converts a pile of traces into labelled data.
Datasets and experiments turn traces into test cases. A failure becomes a dataset row, a hypothesis becomes an experiment, and the experiment measures whether the change helped.
The Prompt IDE iterates prompts against those datasets rather than against a blank box.
Two newer capabilities are worth noting. Talk with your traces is a conversational interface over the trace data for investigation, annotation, and running experiments. Agent-native integration installs Phoenix as a skill for coding agents via npx skills add Arize-ai/phoenix, so an agent can instrument and query your traces.
Deployment covers local, self-hosted container, and Phoenix Cloud. The upgrade path is Arize AX, which shares the span format, so moving does not mean re-instrumenting.
Ideal Use Cases
Four situations favour Phoenix. The first is development-time debugging. A single command and you can see what your agent did, which is a materially different proposition from provisioning a platform and wiring an SDK, and it is why Phoenix often ends up in a repo before anyone decides on production observability.
The second is an OpenTelemetry estate. If your services already emit OTel, Phoenix is a destination rather than an integration project, and the spans remain portable.
The third is notebook-based evaluation work. Running the tool in the same notebook as the experiment removes the context switch, and for data scientists iterating on prompts that is the whole workflow.
The fourth is a team already on Arize AX, or expecting to be. Shared span format means development and production are the same data, which is not true when you pair an unrelated dev tool with a production platform.
Do not choose Phoenix if a licence requirement covers this layer. The Elastic Licence 2.0 is source-available, not open source, and no amount of "OSS Community" language changes what an automated licence check will conclude — Langfuse's MIT core or Helicone's Apache 2.0 are the alternatives that pass. It is also the wrong pick if you want a single vendor-supported production platform with a support contract, which is what Arize AX is sold as. And prompt management with deployment and rollback is not the focus here the way it is in Langfuse.
Pricing and Licensing
Phoenix costs nothing. The server is free to run yourself, whether locally, in a container, or self-hosted for a team, and the hosted Phoenix Cloud tier is also free. There is no paid Phoenix tier, no seat charge, and no feature held back for a commercial edition of Phoenix itself.
The commercial product is Arize AX, and it is a separate purchase rather than a Phoenix upgrade. AX Free covers 25,000 spans a month, AX Pro is $50 per month with 50,000 spans, and AX Enterprise is quoted with custom volumes and a self-hosted option. Those numbers describe AX, not Phoenix, and conflating them is the easiest mistake to make when budgeting.
The licence is the cost that is not measured in money. Elastic Licence 2.0 permits use and modification but restricts providing the software as a managed service to third parties, and it is not OSI-approved. For most teams running it internally that restriction never binds. For a team with a contractual or policy requirement that every component be open source, it is disqualifying, and the honest reading is that Phoenix is free but not open.
Compared with the alternatives: Langfuse's server is also free to self-host with an MIT core; Helicone is Apache 2.0 with a free tier; Braintrust is proprietary with a free Starter plan. Phoenix's distinction is that it is the cheapest to try and the least encumbered operationally, at the cost of the licence property.
Strengths & Trade-offs
Pros
- One command to a running instance, which makes it the lowest-friction way to see what an agent actually did.
- OpenTelemetry-based through OpenInference, so spans are portable and existing instrumentation works.
- Free everywhere — local, self-hosted, and the hosted Phoenix Cloud tier — with no paid Phoenix edition.
- A named workflow, observe to measure, rather than a feature list, and annotations are a first-class step rather than an afterthought.
- A shared span format with Arize AX, so moving to the commercial platform is not a re-instrumentation project.
Cons
- Elastic Licence 2.0 is source-available, not OSI open source, so it fails an open-source-only requirement despite the community framing.
- The free product is the on-ramp to a paid platform, and the roadmap incentive points toward AX over time.
- Prompt management with deployment and rollback is thinner than in tools built around it.
- Self-hosting at team scale is a service and a datastore to operate, which the one-command local experience understates.
- AX pricing is easy to mistake for Phoenix pricing, and the two are different products.