LLMOps Platform Comparison 2026: Guide to the Leading Tools

Production LLM applications fail in ways traditional DevOps tooling never anticipated. A model that passed your A/B tests last week starts returning subtly wrong answers under load. Your cost dashboards show a 40% spend spike with no corresponding traffic increase. A prompt injection attack slides past your safeguards and starts exfiltrating user data. These are not hypotheticals — they are the daily failure modes of LLM-native systems.

LLMOps platforms exist to surface these failures before they reach production, monitor them when they do, and give engineering teams the tools to debug and fix them fast. The category has fragmented into distinct segments: full-stack observability platforms, evaluation-first tools, security and guardrail specialists, and lightweight tracing utilities. Choosing the wrong one for your stage of maturity is a expensive mistake.

This guide cuts through the noise. Six platforms evaluated across the criteria that actually matter: evaluation depth, observability coverage, security capabilities, integration ecosystem, pricing model, and the developer experience tax each one imposes. By the end, you will know which platform belongs in your stack.

How mature does your LLMOps stack need to be before you pick a platform?

Before comparing platforms, you need to know where you are. LLMOps adoption follows a recognizable maturity curve:

• Level 1 — Experimental: Manual prompt testing, local scripts, occasional screenshot-based evaluation. No structured observability. Cost tracking via API bills manually reconciled.
• Level 2 — Monitored: Basic log aggregation for LLM calls. Latency and error rate dashboards. Token counts tracked per endpoint. Rudimentary prompt versioning in git.
• Level 3 — Production-Grade: Automated evaluation pipelines with regression testing. Embedding-based drift detection. Guardrails and PII detection. Agentic observability — tracing multi-step agent loops. Cost attribution at the user, session, and feature level.

Most teams start at Level 1. The best platforms meet you where you are and let you grow into Level 3 without requiring a full platform rewrite when you get there.

The Evaluation Framework

Every platform claims to do everything. The honest comparison maps features to the five problems teams actually need to solve:

1. Evaluation capabilities — Can you test whether your prompts and models are getting better or worse over time? This means automated regression testing, support for RAG evaluation frameworks like Ragas and TruLens, and prompt versioning with diffs.
2. Observability and tracing — Can you see exactly what your LLM pipeline is doing at request time? OpenTelemetry support is the gold standard here. Latency breakdowns, token attribution, and trace visualization across multi-step chains matter.
3. Security and guardrails — Can you catch PII leakage, detect prompt injection attacks, and enforce output constraints before they reach users? This is non-negotiable for any customer-facing application.
4. Integration ecosystem — Does it work with LangChain, LlamaIndex, your cloud provider, and your existing monitoring stack? Lock-in is a real risk in this space.
5. Cost and performance — Token tracking, throughput limits, pricing model transparency, and the operational overhead of running the platform itself.

The platforms below are evaluated across all five dimensions.

Segment A: The All-in-One Enterprise Platforms

Braintrust — The Evaluation-First Developer Platform

Braintrust built its reputation on being the platform that takes evaluation seriously. While competitors started with tracing and added evaluation as an afterthought, Braintrust was designed around automated regression testing from day one. If you are serious about PromptOps — the practice of systematically improving prompts through testing — Braintrust is built for you.

The platform's core workflow is straightforward: define evals as code, run them against your LLM calls, track scores over time, and gate releases on eval pass rates. Their open-source SDK supports custom scorers, which means you are not locked into their predefined metrics. RAGAS, LLM-as-judge, and exact-match scoring are all supported out of the box.

For teams that want the broader landscape of evaluation tooling — including RAGAS and TruLens as standalone choices and the eval-pipeline architecture that makes any of these production-reliable — the LLM evaluation frameworks guide covers the full stack and shows where Braintrust slots in.

Braintrust also covers tracing, but it is secondary to evaluation. Their tracing is functional — request logs, latency, token counts, and support for multi-step chains — but it lacks the depth of dedicated observability platforms. If evaluation is your primary pain point and you are already handling tracing elsewhere, Braintrust slots in cleanly.

Key capabilities

• Automated regression testing with custom scorers and RAGAS support
• Prompt versioning with diffs and rollback
• Evaluation pipeline with CI/CD integration (GitHub Actions, CircleCI)
• Dataset management for benchmark suites
• Function calling and JSON mode validation

What it does not do well

• Native guardrail or PII detection — requires separate tooling
• Deep OpenTelemetry integration out of the box
• Multi-modal model evaluation (images, audio) — roadmap item as of Q1 2026

Pricing

Free tier with 10,000 eval runs/month. Pro at $75/month for unlimited evals and advanced dataset features. Enterprise plans with SLA guarantees available on request. Self-hosted option for enterprise.

Best for

Teams that treat prompt engineering as a serious discipline and need automated regression testing to prevent prompt regressions from reaching production.

Arize AI Phoenix — Deep Observability and Embedding-Based Drift Detection

Arize Phoenix occupies the opposite end of the LLMOps spectrum from Braintrust. Where Braintrust starts with evaluation, Phoenix starts with observability and adds evaluation capabilities as a layer on top of deep tracing infrastructure. If you have ever tried to debug why your RAG pipeline started returning worse answers two weeks ago and had no visibility into the embedding space drift, Phoenix is designed for exactly that scenario.

Phoenix is open source and self-hostable, which is a significant differentiator for teams that cannot send their data to third-party SaaS platforms. The platform instruments your LLM calls and captures traces at the request level, but its real strength is the post-hoc analytical layer on top: drift detection using embedding distance metrics, latency percentiles by model and prompt, and throughput trends over time. For the standalone deployment and instrumentation walkthrough — the OTel exporters, the self-hosted container setup, and the dataset-and-evaluation pattern that this comparison treats as one of six platform angles — the dedicated Arize Phoenix guide goes deeper on the implementation details.

The evaluation story in Phoenix is newer and less mature than Braintrust's, but it covers the essentials: you can define metrics, track them over time, and set alerting thresholds. Phoenix is adding LLM-as-judge evaluation and Ragas integration, but these features are less polished than the core observability layer as of early 2026.

Key capabilities

• Embedding-based drift detection — identifies embedding distribution shift before it manifests as quality regressions
• Full request tracing with latency breakdown by stage (retrieval, inference, post-processing)
• RAG pipeline analysis — trace retrieval quality and correlation with answer quality
• OpenTelemetry native — export traces to any OTel-compatible backend
• Self-hosted and open source — no data leaves your infrastructure
• Integrates with LangChain, LlamaIndex, and Haystack

What it does not do well

• Evaluation CI/CD integration — not designed for automated regression gating
• Guardrail or security features — completely absent
• Cost tracking — token attribution is basic, not at the user/session level

Pricing

Fully open source and free to self-host. Arize also offers a cloud SaaS version with additional features: managed infrastructure, collaborative dashboards, and enterprise SLA. Cloud pricing is usage-based, starting at $100/month for teams at scale.

Best for

Teams that need deep RAG observability and embedding drift detection, particularly those operating in regulated environments where self-hosting is a hard requirement. For teams that have already chosen Phoenix and now need the surrounding blueprint — dataset design, evaluator taxonomy, eval-vs-prod drift reconciliation, the runbook for incident triage on a Phoenix-backed stack — the LLMOps observability blueprint is the worked-example complement to this comparison.

What changed in Arize Phoenix 19.13.0?

Phoenix 19.13.0, released August 1, is a focused additive drop on top of 19.11.0. It is not a platform bump — no eval-harness surface changes, no breaking changes, no auth/MCP changes — and the release body lists exactly two operator-visible changes that each close a real workflow gap. The headline wins are span/trace annotations in span exports (which makes postmortem triage reproducible across Phoenix instances and other OTLP backends) and the lifted metric-chart selection limit in experiments (which makes the metrics dashboard usable on long-running eval projects without a manual refresh). Headline changes from the 19.13.0 release notes:

• App: include span and trace annotations in span exports (#14990) — Until 19.13.0, span exports (the OTLP path that ships spans to a secondary analyzer — Jaeger, Honeycomb, Datadog APM, a fresh Phoenix instance) carried the raw span attributes but dropped the span and trace annotations that operators attach during triage (correctness, relevance, custom labels, evaluator scores). The export round-trip was lossy: an investigator who annotated a span in Phoenix could not share that annotation with a colleague on a different backend, and the exported trace looked "clean" of any human signal. 19.13.0 carries the annotations into the exported payload as OTLP attributes (one per annotation, prefixed with the annotation key), so a downstream consumer sees the same operator signal Phoenix itself shows. This is the change that makes "share a trace with a vendor" actually reproducible — pair with the OTLP JSON export that 19.6.0 added, and the round-trip is now lossless for both the raw span shape and the human annotation. The beyond-the-stack-trace AI debugging workflow depends on this surface when an investigation crosses Phoenix and a secondary analyzer.
• Experiments: lift metric chart selection limit (#14987) — Until 19.13.0, the experiments metrics view capped the number of metric series that could be rendered on the chart, and on a long-running experiment with many evaluated runs the chart silently dropped series. The cap forced a manual series-prune dance before the chart became readable. 19.13.0 lifts the cap, so a project with hundreds of evaluated runs renders the full metric surface without manual intervention. The same fix landed on the project charts in 19.11.0 (#14901); 19.13.0 closes the matching gap on the experiment surface so both views behave consistently. For teams that gate releases on experiment metrics (the pattern the LLM evaluation frameworks guide walks through), this is the line where the experiment chart stops being the place the eval results go to disappear. Pairs with the eval gating pattern the LLMOps observability blueprint maps.

No migration is required between 19.11.0 and 19.13.0; the change set is additive and 19.12.0 was a no-PR bridge release on the way through. Upgrade with pip install --upgrade "arize-phoenix==19.13.0" or the matching container, then verify two things: an annotated span that you export as OTLP JSON contains the annotation attributes when re-imported into a second Phoenix instance, and an experiment with hundreds of evaluated runs renders its full metric chart without manual series-pruning. For teams that have not yet pinned a version in production, 19.13.0 is the new floor — it closes the export-round-trip gap that 19.6.0 left open and aligns the experiments chart behavior with the project chart behavior that 19.11.0 shipped. Pairs naturally with the self-hosted Arize Phoenix implementation guide for the upgrade path and with the probabilistic observability discipline when those richer exports feed non-deterministic eval pipelines.

What changed in Arize Phoenix 19.11.0?

Phoenix 19.11.0, released July 30, is a focused drop that pushes the project view toward real production dashboards and finishes a small but useful hardening of the subagent telemetry. Three operator-visible changes matter most: project-level evaluation charts are now first-class (not buried under the dataset tab), subagent tool calls are counted on the online eval path so a runaway agent loop is visible in the trace card, and the chart-selection cap that forced a manual refresh every few dozen series is gone. There is also a pinned note-taking bar on span details that survives navigation between spans — small on paper, real during a war-room investigation.

• Project evaluation metrics charts (#14481) — A new charts panel on the project view renders evaluation metric time series for the whole project, not just for individual datasets. For teams that gate releases on a single quality metric across many datasets (the workflow the LLMOps observability blueprint walks through), the project view is now where you go first; the per-dataset panels stay for drill-down. This is the move that finally lets Phoenix replace a side-by-side Grafana dashboard for the eval scorecard use case.
• Evals: count subagent tool calls online (#14843) — The online-eval path now counts subagent tool calls as they happen, and the totals show in the LLM span card header. A multi-step agent that loops its subagent fifteen times before returning an answer is no longer invisible in the trace summary — the count surfaces in the card before you click into the span. Pair with the agentic incident harness playbook when a high tool-call count is the first signal that something has gone wrong.
• Project: defer metric chart loading and lift the chart selection cap (#14901) — Project-level charts now lazy-load and the chart-selection cap is removed, so the view survives projects with hundreds of evaluation series. The previous cap forced a manual refresh on a long-running eval project; that flow is now smooth. For self-hosted instances serving many concurrent evaluators, the deferred load also reduces cold-start memory pressure on the dashboard server.
• Sandboxes: Pydantic logo for the Monty provider icon (#14900) — A purely cosmetic alignment with the rest of the provider icon set; the Monty provider now uses the Pydantic mark. No behavior change.
• Show tool and tool call counts in LLM span card headers (#14841, closes #14712) — Related to the subagent-count change above: the span card header now shows both the tool name and the count of calls. This is what surfaces "called search 14 times" directly in the trace tree without expanding the span — exactly the kind of summary that turns a 30-minute triage into a five-minute one when the on-call is racing an incident.
• Trace: pinned note-taking bar for span details (#14845) — A small but persistent improvement: the note bar on span detail now pins to the layout instead of scrolling away as the span scrolls. Investigators taking notes on a long span no longer lose the input box mid-annotation. This pairs with the beyond-the-stack-trace AI debugging workflow where the trace is the artifact and the notes are the postmortem.

No migration is required between 19.9.0 and 19.11.0; the change set is additive across the 19.10 → 19.11 chain. Upgrade with pip install --upgrade "arize-phoenix==19.11.0" or the matching container, then verify three things: a project with more than twenty evaluation series renders without manual refresh, a span card on a multi-tool agent shows the tool-call count without expanding the span, and a long span retains its note bar while scrolling. For teams that have not yet pinned a version in production, 19.11.0 is the right floor — it is the release where Phoenix's project view starts to behave like a real eval dashboard rather than a dataset explorer.

What changed in Arize Phoenix 19.9.0?

Phoenix 19.9.0, released July 28, is a non-breaking upgrade from 19.8.0. It is a small drop with two visible quality-of-life fixes and one operator-meaningful hardening under the hood. The headline wins are the narrow-width chart panel fix and the all-spans-at-once expand/collapse control on the trace view — both reduce friction on the screens engineers actually spend time in.

• Chart panels stay readable at narrow widths (#14804) — Charts no longer squeeze their labels into illegible text on narrow viewports. For teams running Phoenix on a laptop during incident triage, this matters; the same trace view on a 13-inch screen used to clip axis labels and force a horizontal scroll. The readability fix lands in both the span-level and the project-level charts.
• Expand or collapse all span info sections at once (#14796) — A single click now toggles every span info section open or closed. Triage work on a long agent trace used to require dozens of clicks to fully expand input/output/eval sections. The faster cycle matters when an on-call engineer is racing a latency budget. For teams that script Phoenix investigations through an agent, the Codex multi-agent v2 encryption black-box incident describes the class of cases where a human-in-the-loop still benefits from this view being fast.
• MCP code-mode execution runs in subprocess isolation (#14784) — The MCP server that Phoenix v19 exposes now sandboxes code-mode execution in a subprocess. A runaway or hostile code-mode query can no longer wedge the MCP server itself; the worst case is one subprocess dying, not the whole debugging surface. If you already use the Phoenix MCP server end-to-end, this is the hardening that lets you point an automation at it without standing up a separate sandbox.
• Empty span annotation tool input is no longer ambiguous (#13533) — When the annotation tool received an empty input, the UI was unclear about what state the span was in. The tool now reports the empty state explicitly. The self-hosted Arize Phoenix guide walks through the annotation workflow this fix touches.
• Floating agent location survives new chat (#14795) — A small but persistent annoyance is fixed: the floating agent's on-screen location now persists when you start a new chat. Before this, the agent jumped back to its default position on every new chat, which made long multi-chat investigations jarring.

No migration is required between 19.8.0 and 19.9.0. Upgrade with pip install --upgrade "arize-phoenix==19.9.0" or the matching container, then verify that one chart at narrow width renders without clipping, one long trace expands/collapses all sections with a single click, and one MCP code-mode query survives a deliberate exception. For a cost view that benefits from the updated bundled token-price table, the LLM FinOps strategies guide explains which cost signals still belong in your own attribution layer rather than relying on the default table.

What changed in Arize Phoenix 19.8.0?

Phoenix 19.8.0, released July 27, is a non-breaking upgrade from 19.7.0. Its visible feature is Claude Opus 5 support in both the agent's curated model list and the playground. The more important operator changes are smaller: Phoenix updates its built-in token-price table, reports PXI API-key errors to the user instead of leaving an opaque auth failure, and falls back to text when a span carries an invalid MIME type.

• Claude Opus 5 is registered in the agent and playground — You can select the model without maintaining a local provider override. If model choice is part of a broader production approval process, the AI model monitoring versus APM guide explains which quality signals still sit outside a normal trace.
• Built-in model prices are refreshed — Cost views now use the updated bundled token-price data. Treat that table as a default rather than a billing ledger; negotiated rates and provider discounts still belong in your own cost attribution layer.
• PXI authentication failures are actionable — API-key errors now reach the UI. That saves time during incident triage because an auth failure no longer looks like an empty trace or a stalled agent. The AI debugging guide beyond stack traces covers the evidence to preserve when the failure crosses model, tool, and identity boundaries.
• Invalid span MIME types degrade to text — Malformed content metadata no longer makes the span unreadable. Phoenix renders the payload as text so an operator can inspect it and fix the producer.
• Python 3.14 installs work around a broken dependency — Phoenix excludes bashkit 0.14.2, which had broken installs on Python 3.14. The release also adds an advanced self-hosting encryption guide.

No migration is required between 19.7.0 and 19.8.0. Upgrade with pip install --upgrade "arize-phoenix==19.8.0" or the matching container, then verify that one playground request, one PXI request, and one malformed-content test span render correctly. For a clean deployment baseline before that smoke test, use the self-hosted Arize Phoenix implementation guide.

What's New in Arize Phoenix 16.5.0

Arize Phoenix 16.5.0, released 2026-06-01, is a feature-heavy drop that pushes the PXI agent from a tracing helper toward a fully interactive debugging surface. The biggest additions are conversation controls and a new skill for annotating spans directly from the agent:

• Playground save-prompt tool — A new tool in the Phoenix playground lets you persist a prompt you are iterating on as a named, versioned artifact. Previously you had to copy prompts out by hand; now they live alongside your datasets and evaluations in the same UI.
• Chat message rewind, fork, and copy controls — The PXI agent chat now supports rewind (step back to an earlier message), fork (branch a new conversation from any prior message), and copy (duplicate a message for editing). This is the single biggest UX improvement to the PXI agent since launch — debugging long agent traces was painful before because you had to replay the whole trace to test a fix.
• annotate-spans skill for the PXI agent — A new built-in skill that lets the PXI agent attach annotations (correctness, relevance, custom labels) to spans as it reasons over a trace. The agent can now do evaluation work mid-investigation, not just summarize the trace.
• read_prompt_tools and write_prompt_tools added to PXI — The PXI agent can now read and write prompt tool definitions, enabling it to build and modify its own tool set rather than just calling predefined ones. This is the foundation for self-modifying agent workflows on Phoenix.
• summary argument for PXI bash tool with UI preview — The PXI bash tool now accepts a summary string and renders it in the chat UI as a human-readable preview, making long-running shell tasks much easier to follow.
• Seeded default sandbox configs for local adapters — Local Phoenix deployments now ship with default sandbox configurations, removing a manual setup step that tripped up first-time self-hosters.

No breaking changes. Upgrade via pip: pip install arize-phoenix>=16.5.0. Running pip install --upgrade arize-phoenix without a version pin will land on the latest version. The PXI conversation-control changes are pure additions — existing traces and prompts continue to work unchanged.

What's New in Arize Phoenix 19.15.0

Phoenix 19.15.0 shipped 2026-08-03 as a small UI-performance drop on the project page — two PRs, both targeted at the annotation metrics view. The release is not a feature drop, it is a fix for the rendering pattern that made annotation metric charts block the rest of the project page from rendering until each chart's data call returned. For teams running Phoenix self-hosted on a project page with more than a handful of annotation metric widgets, this is the release where the project page first paint stops stalling on slow annotation backends.

The two PRs from the 19.15.0 release notes:

• Defer annotation metric chart loading (#14968) — Annotation metric charts no longer block project-page first paint. Until 19.15.0, the chart panel issued its data call inline, so a slow annotation backend (or a backend that timed out before the chart's own timeout) held the rest of the project page in a loading state. 19.15.0 defers the chart data fetch to after first paint, so the page renders the rest of the UI before the chart populates. For self-hosted Phoenix users on a slow annotation backend, this is the release where the project page stops going blank during annotation queries. Pairs with the LLM monitoring dashboard templates guide for the dashboard pattern that benefits from non-blocking chart loads.
• Fetch annotation metric charts independently (#14938) — Each annotation metric chart now fetches independently rather than as part of one aggregate request. Until 19.15.0, a single failed annotation chart caused the entire annotation metrics panel to render as broken; 19.15.0 isolates failures per-chart so a partial backend failure degrades gracefully instead of taking the whole panel down. For teams running multi-tenant annotation backends where one tenant's slow query could starve the rest, this is the release where the worst-case UI failure mode becomes "one missing chart" instead of "blank panel".

No breaking changes, no API changes, no DB migrations. Upgrade via pip install --upgrade arize-phoenix. For teams pinned to 19.6.0 in production, the upgrade is a drop-in — the only behavior change is the render order on the project page, which is observable on a slow annotation backend and invisible on a fast one.

What's New in Arize Phoenix 19.6.0

Phoenix 19.6.0, released 2026-07-24, lands four days after 19.4.0 and is a focused user-facing drop — every change is either a new client filter, a UI export path, or a polish item that an operator hits daily. Nothing here changes the trace ingestion shape or the OAuth/MCP surface that the 19.0/19.1/19.4 cadence shipped; treat this as a quality-of-life release that closes real workflow gaps. Headline changes:

• Client: span_ids filter on get_spans (Python and TypeScript) (#14697) — The Python and TypeScript client get_spans calls now accept a span_ids filter, so a script can pull an exact set of spans by ID rather than re-issuing a full session query and post-filtering. For the on-call flow that "I have five trace IDs from the alert, give me just those spans" loop, this collapses a multi-second roundtrip into a single API call. Pair with the agentic incident harness playbook when the span set comes from a multi-agent incident and you need to follow the chain across tools.
• UI: download selected spans or traces as OTLP JSON (#14693) — The trace and span detail views now let you select rows and export them as OTLP JSON rather than a flat CSV. The OTLP shape preserves attributes, events, and resource fields, so the export round-trips cleanly into a secondary analyzer (Jaeger, Honeycomb, or a fresh Phoenix instance). This is the missing piece for the "share a trace with a vendor" workflow — CSV flattened the OTel attributes to one row per span and lost the parent/child structure.
• Deps: arize-phoenix-evals pinned to 3.3.0 (#14679) — The bundled evaluators package is bumped to 3.3.0, which picks up the latest scorer fixes and the refreshed RAGAS integration. If you pin arize-phoenix-evals separately in your environment, verify that your pin is still compatible; if you let Phoenix manage the evals install (the default for the self-hosted image), the 3.3.0 lift is automatic on upgrade.
• UI: consistent span-detail input/output cards + session view polish (#14699) — The input/output cards in the span detail view now share a consistent layout with the session view, and the session annotation panel extends to full drawer height (#14700). Pure polish, but the "read five spans in a row" loop is now measurably faster because the eye does not re-layout between cards. For teams that use Phoenix as the primary trace review surface during incident triage, this is the kind of small fix that compounds over a war room.

No breaking changes. Upgrade via pip install --upgrade "arize-phoenix==19.6.0" or pull the matching container. The release is additive across the 19.4 → 19.5 → 19.6 path: trace ingestion shape is unchanged, OAuth/MCP config flags from 19.0 still apply, and the JS Vercel AI SDK 7 spans from 19.4 continue to land through OpenInference v3. If you upgraded to 19.4 the same week, the safe move is to roll 19.6.0 on the same cadence — the span_ids filter and the OTLP JSON export are the two changes that justify the rebuild, and neither needs a config flag to enable. For teams operating Phoenix as the backbone for probabilistic eval pipelines, the cleaner span-level export pairs naturally with the trace sampling guidance in the probabilistic observability discipline — when you need a deterministic replay of a single non-deterministic trace, the OTLP JSON round-trip is now lossless.

What's New in Arize Phoenix 19.4.0

Phoenix 19.4.0, released July 22, finishes a rapid 18.0-to-19.4 transition. Phoenix is no longer only an open-source tracing UI: 19.0 added a default-on OAuth2 authorization server and an in-process MCP endpoint, 19.1 added one-command agent registration with px setup mcp, and 19.4 upgrades the JavaScript telemetry path for Vercel AI SDK 7.

• OAuth2 plus MCP now ship inside Phoenix — discovery endpoints, CLI login, and the /mcp Streamable HTTP server are enabled by default. Operators can disable each surface independently with PHOENIX_ENABLE_OAUTH2_AUTHORIZATION_SERVER, PHOENIX_ENABLE_MCP_SERVER, and PHOENIX_ENABLE_MCP_CODE_MODE. For the broader identity boundary around agent tools, the MCP enterprise authorization guide maps the OBO, scope, and audit controls Phoenix still expects around the server.
• Breaking key-mint policy — Phoenix 19.0 rejects API-key-authenticated GraphQL calls that create user or system keys. Automation must move to a human session token or PHOENIX_ADMIN_SECRET; list and revoke calls remain available. This closes a durable-key replacement path rather than changing trace ingestion.
• Vercel AI SDK 7 spans work through OpenInference v3 (#14563) — phoenix-otel now uses openinference-vercel v3. If you attribute traces per developer or tool session, compare the resulting identity fields with the per-engineer AI usage observability schema before rolling the JS SDK fleet-wide.
• Reverse-proxy hardening — IP rate limiting now applies when PHOENIX_HOST_ROOT_PATH is set (#14612), OAuth discovery responds to HEAD requests (#14611), and the trace header is split into identity and metadata rows (#14568).

Upgrade with pip install --upgrade "arize-phoenix==19.4.0". Before the server roll, regression-test unattended key issuance and session-window dashboards, then verify AI SDK 6 and 7 spans side by side. Phoenix publishes no performance benchmark for this release; the ranking-moving change is the expanded OAuth/MCP platform surface, not a claimed speedup. The probabilistic observability discipline is a useful companion when those richer traces feed non-deterministic evals.

What's New in Arize Phoenix 18.0.0

Arize Phoenix 18.0.0, released 2026-07-14, is the first major-version bump on the 17.x line and the release where the session-time-range filter semantics change. Until 18.0.0, session-time-range filters used the old "range contains the session start time" semantics — a session that started inside the filter window was returned, but sessions that straddled the window boundary (started before, ended inside) could be silently missed depending on the exact filter shape. 18.0.0 switches to interval-overlap semantics — a session is returned if any part of the session's time range overlaps the filter window. This is the right semantic for an observability tool (it matches what the operator expects when they pick "last 24h"), but it is a breaking change for any dashboard or saved query that relied on the old "filter contains the session start" behavior. The MIGRATION.md documents the exact change. Headline changes:

• BREAKING: sessions use interval-overlap semantics for time-range filters (#14023) — The single breaking change in 18.0.0. Until 18.0.0, a session-time-range filter matched sessions whose start time fell inside the filter window. 18.0.0 matches sessions whose time range overlaps the filter window, which is the standard interval-overlap definition used by Grafana, Honeycomb, Datadog, and the rest of the observability industry. For teams with saved dashboard queries that depended on the old "start-time contains" semantics, 18.0.0 will return additional sessions that the old filter missed (which is the correct observability behavior) — verify your session-count rollups and your alerting thresholds on the day of the upgrade. The MIGRATION.md walks through the exact behavior change and the saved-query migration recipe. For teams running Phoenix as the agentic-observability backbone for production agents (the workflow the agentic observability guide and the LLM observability guide 2026 map), 18.0.0 is the line where session-level dashboards finally match what the on-call sees in the trace explorer — a long-session agent that started yesterday and finished today now correctly appears in today's window, which it would have silently missed before.
• Sessions: interval-overlap filter semantics across the sessions UI (cd17357) — The implementation PR. The session-time-range filter, the session-stats side panel, and the session-card totals all pick up the new semantics in lockstep. For teams that have built internal dashboards that read from the Phoenix sessions API directly, the API response shape is unchanged but the set of returned sessions shifts — a regression-test pass against your session-count rollups is the right pre-upgrade check.

This is a major-version bump for a reason — it is the first Phoenix release with a real breaking change in the 17.x series. Treat the upgrade as a coordinated exercise: roll the server, run the saved-query regression pass against MIGRATION.md, and re-validate the session-rollup dashboards that the on-call rotation depends on. The interval-overlap semantics are the right shape for production observability and they bring Phoenix in line with the rest of the observability industry, so the long-term value is real — but the upgrade-Friday break risk is real too, especially for teams that have built dashboards or saved queries on the old "start-time contains" semantics. Upgrade via pip install arize-phoenix>=18.0.0 or pull the matching container. The arize-phoenix-client SDK has no breaking change at this version — you can roll the server to 18.0.0 without bumping the client, but verify your client version supports the new session-filter semantics before relying on them programmatically. If you are mid-eval-cycle and do not want to absorb the breaking change yet, 17.30.0 (the last 17.x release) is the conservative production pin until you have a migration window scheduled. The migration is forward-only — there is no flag to revert to the old semantics — so plan the rollup-dashboard verification before you cut over.

What's New in Arize Phoenix 17.1.0

Arize Phoenix 17.1.0, released 2026-06-02, lands a day after 16.5.0 and pushes the PXI agent deeper into authoring territory — the agent can now load datasets and author its own LLM-based evaluators without leaving the chat surface. The headline additions:

• Playground PXI load_dataset tool — The PXI agent can now load a dataset directly from the Phoenix playground, turning the chat into a self-serve eval loop. You can ask the agent to "load the customer-support-q3 dataset, run the latest prompt against it, and flag any rows with relevance below 0.7" without leaving the chat.
• LLM-evaluator authoring for the PXI agent — The PXI can now author LLM-as-judge evaluators from inside the chat. Describe the rubric in natural language and the agent scaffolds a working evaluator, attaches it to your dataset, and surfaces the results. This collapses the loop from "decide what to evaluate" to "have results in hand" into a single conversation.
• Skill loading display — The PXI agent UI now shows which skills are loaded into the current conversation, including custom and built-in skills. Previously you had to remember what was attached; now you can see it inline and toggle skills on or off without restarting the trace.
• Warning colors and search-off icon — Quality-of-life polish: warning callouts in the UI now use a distinct color palette that does not collide with error states, and a clear "search off" icon appears when filters are applied without a search term (the prior behavior was silent — easy to wonder why your queries returned nothing).
• Bug fix: docs MCP init failure no longer aborts server startup — A startup crash where a failed docs MCP initialization would take the whole server down has been fixed; the server now starts even if the optional docs MCP fails to initialize, and the failure is logged at warning level rather than as a fatal. This matters for air-gapped or restricted-network deployments where the docs MCP cannot reach its upstream.

No breaking changes. Upgrade via pip: pip install arize-phoenix>=17.1.0. The PXI authoring additions are pure additions — existing traces, prompts, and evaluators continue to work unchanged. If you self-host, the docs MCP failure mode is the only behavior change worth noting: expect a warning line in your server logs on cold start in restricted networks, where you previously would have seen a hard startup failure.

What's New in Arize Phoenix 17.2.0

Arize Phoenix 17.2.0, released 2026-06-03, is a follow-up that tightens the assistant deployment surface and refreshes the prompts table on a schedule. The release also expands the PXI guide with deeper coverage of skills, controls, and extensibility. Headline changes:

• PXI route info tool — A new tool in the PXI agent surfaces route information for the deployment, giving the agent (and you, in the chat) a clear picture of which paths the assistant is serving from. Useful for debugging multi-deployment setups where requests can land on different roots.
• Bug fix: assistant chat history scoped to deployment root — Previously, the assistant chat history could leak across deployments when a Phoenix instance served multiple deployments from the same root path. The fix scopes chat history to the deployment root, so a debug session in one deployment no longer pollutes the history of another.
• Prompts table now refreshes periodically — The prompts table in the Phoenix UI now refreshes on a polling interval rather than requiring a manual reload. This was a small but persistent papercut for anyone iterating on prompts in a separate tab — the table would go stale within minutes and there was no obvious indicator.
• Documentation: PXI guide expanded with skills, controls, and extensibility — The PXI guide now has full coverage of skill authoring, conversation controls (rewind, fork, copy), and how to extend the PXI agent with custom tools. This is the doc expansion that the 16.5.0 / 17.1.0 features deserved — they shipped first, the docs catch up now.

No breaking changes. Upgrade via pip: pip install arize-phoenix>=17.2.0. The deployment-root scoping for chat history is the only behavior change worth verifying if you run multiple deployments from the same Phoenix server — confirm your team is no longer relying on cross-deployment chat history visibility before upgrading.

What's New in Arize Phoenix 17.3.0

Arize Phoenix 17.3.0, released 2026-06-10, is a week-after follow-up on the 17.x cadence and the release where the PXI agent becomes genuinely useful for owning a regression suite. The headline is governance: the agent can now manage eval datasets end-to-end (list, create, edit, delete across datasets, examples, splits, and labels) but every write is gated by an inline Accept/Reject approval card, so a prompt-injection-driven data corruption is contained by a human-in-the-loop checkpoint. The other additions are smaller and more tactical, but they all add up to a noticeably faster on-call workflow. Headline changes:

• PXI: dataset management tools for the agent (#13679) — The in-app PXI agent gains a complete surface for managing datasets: list / create / edit / delete across datasets, examples, splits, and labels, plus span-to-example capture. Every write goes through an inline Accept/Reject approval card with viewer gating, so the agent cannot silently mutate a 10k-example regression suite. Closes #13588 and #13616. This is the change that finally makes "let the agent own the regression suite" a defensible production posture — the agent can run the workflow, but the human holds the keys.
• App: inline, editable time range selector (#13536) — A new inline time range editor on the dashboard. On-call engineers triaging a regression can now adjust the trace window from the dashboard itself, no URL bar edits, no bookmark juggling. Cuts the time-to-root-cause on incident dashboards from seconds to one click — the kind of papercut fix that compounds when you are on the third war room of the week.
• PXI: copy trace ID chat action (#13647) — One-click copy of the trace ID from the PXI chat surface, so the SRE can pivot straight to the matching APM span, eval run, or alert rule without alt-tabbing to a trace view. Trace ID is the universal join key in LLM ops, and until now getting it out of the chat required opening the trace. Sits in the assistant toolbar without cluttering the primary chat controls.
• Trace UI: preserve place and auto-truncate large tool outputs (#13581) — Two changes bundled into one PR. First, when you expand a tool inside a span, the scroll position now stays anchored to the top of that tool rather than jumping to the bottom — a real ergonomic improvement for the "scroll back to see what the tool actually returned" loop. Second, large tool IO is now wrapped in the existing truncation utilities, so multi-megabyte tool outputs no longer freeze the trace tab. If you have ever had Phoenix lock up during an incident review because a single span had a 4MB tool output, this is the fix.
• Playground: claude-fable-5 model support (#13684) — The latest Anthropic snapshot is now surfaced in the Playground model picker. Teams that pin to the latest Claude releases can run side-by-side evals against claude-fable-5 immediately, with no env-var workaround or custom model adapter.
• Bug fix: tolerate JMESPath type errors in OAuth2 claim extraction (#13631) — For SSO customers, the bug that makes Phoenix start 403-ing on role-gated routes after an IdP changes a claim shape. JMESPath type errors during email / group / role claim extraction are now treated as absent claims, so thin ID tokens can fall back to UserInfo or normal strict / default handling. Exactly the kind of upgrade-Friday break this patch prevents.

No breaking changes. The release body has no breaking-changes section, and the ScaledObject-style chart tag pattern does not apply — Phoenix 17 has been on a weekly minor cadence (17.0 on 2026-06-02, 17.1 the same day, 17.2 on 2026-06-03, 17.3 on 2026-06-10), so treat each 17.x release as a normal patch-equivalent upgrade. If you are following a pinned chart version, this is a non-event; if you are on latest, you are already on 17.3.0. Upgrade via pip install arize-phoenix>=17.3.0 or pull the matching container, and the only thing worth verifying on the way up is that the PXI agent's new dataset-management tools have the role gating you expect for your team — the inline Accept/Reject card is the safety net, but it is worth confirming it is enforced for the principals your eval pipeline runs as.

What's New in Arize Phoenix 17.4.0

Arize Phoenix 17.4.0, released 2026-06-11, is a one-day follow-up to 17.3.0 and lands three features that close long-standing gaps in the PXI agent and the time-range UI. None are breaking; all are pure additions. The release is paired with an independent arize-phoenix-client 2.9.0 SDK drop on the same day, so server and client are decoupled — you can roll them separately:

• PXI: local slash commands in the chat menu (#13683) — The in-app PXI agent gains a discoverable slash-command surface. Custom local commands can be registered to the chat menu, so team-specific eval recipes ("/score-threshold", "/regress-snapshot") are one keystroke away instead of buried in a prompt template. For teams that have standardized PXI workflows, this turns tribal knowledge into a UI affordance — junior engineers discover the commands their seniors rely on without reading a runbook.
• PXI: select, read, and edit dataset evaluators (#13645) — The PXI agent can now list, read, and edit LLM-based evaluators bound to a dataset, not just run them. Closes the loop on evaluator maintenance: an eval that starts producing noisy scores can be inspected, edited, and re-run without leaving the chat surface. The dataset-management tools that landed in 17.3.0 (gated by Accept/Reject cards) handle the data side; 17.4.0 handles the scorer side. The two together mean the agent can own a regression suite end-to-end, with human approval at every write boundary.
• UI: search and free-form durations in the time range selector (#13703) — The dashboard time range selector now accepts free-form durations (e.g., "3h12m", "17d") and is searchable. On-call engineers triaging a regression no longer have to round to a preset interval — pin a window to the exact second the alert fired. A papercut fix, but the kind that compounds during incident review when you are jumping between dashboards.
• Bug fix: refresh built-in model token prices (#13685, #13698) — Two PRs land back-to-back to keep the cost ledger honest as providers adjust their public pricing. If you have ever noticed your Phoenix cost dashboard drifting from the provider's actual invoice by a few percent, this is the cleanup. Worth noting for finance and chargeback workflows that quote Phoenix cost numbers downstream.

No breaking changes. Treat 17.4.0 as a normal patch-equivalent upgrade on the 17.x line — release notes contain no breaking-changes section and the new PXI surfaces are pure additions behind the same role-gating as 17.3.0. Upgrade via pip install arize-phoenix>=17.4.0 or pull the matching container. The arize-phoenix-client SDK release (v2.9.0) is independent — you can hold the client at v2.8.x while rolling the server to 17.4.0, or take both. If you self-host and your network blocks the docs MCP, the same warning-on-cold-start behavior introduced in 17.1.0 applies; nothing new to verify there.

What's New in Arize Phoenix 17.5.0

Arize Phoenix 17.5.0, released 2026-06-12, is a one-day follow-up to 17.4.0 and the first release in the 17.x cycle to ship a calendar-picker for the time range selector — a long-standing UX gap that paper-cut the on-call workflow. The release also adds a subagents toggle for assistant settings, deepens the PXI agent's product knowledge, and ships nine bug fixes. None are breaking; all are pure additions. Headline changes:

• Agent: subagents toggle in assistant settings (#13733) — A new toggle in the assistant settings panel lets you enable or disable subagents for the PXI agent. For teams standardizing on a single-agent workflow (where the agent plans and executes without delegating), the toggle makes that posture explicit and visible. For teams experimenting with subagent orchestration, the toggle is the single switch that turns the surface on. Closes a recurring configuration ask from teams that hit the subagent path unintentionally and wanted a way to opt out without editing config files.
• Agents: improved product knowledge (#13705) — The PXI agent now ships with deeper product knowledge out of the box, so the chat surface can answer Phoenix-specific questions (e.g. "where is the cost ledger backed up?" or "how do I attach an evaluator to a span?") without first pulling live documentation. Reduces the round-trip between the chat and the docs tab, especially for engineers on their first few Phoenix deploys.
• UI: pick a time range from a calendar in the time range selector (#13713) — The dashboard time range selector now includes a calendar picker alongside the existing free-form duration input that landed in 17.4.0. On-call engineers can now click through to a date instead of typing "3d 4h 12m" by hand — a papercut fix that compounds when you are scrubbing incident timelines at 2am. The free-form input remains for precise ranges.
• Bug fix: add Anthropic computer-use beta header (#13242) — The Anthropic integration now sends the computer-use beta header on requests that exercise the computer-use tool. Without the header, Anthropic's API silently 400s on the first tool call. If you instrumented an agent that drives a browser via the computer-use API, 17.5.0 unblocks the trace path end-to-end.
• Bug fix: focus PXI input on open (#13653) — When the PXI chat surface opens, the input field now auto-focuses. Saves one click per session — minor, but the kind of ergonomic fix that makes the chat feel like an actual chat instead of a form you have to manually activate.

No breaking changes. Treat 17.5.0 as a normal patch-equivalent upgrade on the 17.x line. The new subagents toggle is opt-in and defaults to the previous behavior; the calendar picker is additive alongside the free-form input from 17.4.0. Upgrade via pip install arize-phoenix>=17.5.0 or pull the matching container. The nine bug fixes ship alongside the three features and the docs additions; nothing requires a config change.

What's New in Arize Phoenix 17.6.0

Arize Phoenix 17.6.0, released 2026-06-15, is the day's drop on the 17.x weekly cadence and lands three features that close the loop on the agent-owning-the-eval-suite narrative that 17.3.0/17.4.0 started. The release is small in PR count but large in capability surface — the agent can now edit experiment runs as a first-class action, and the metrics layer gains a time-series view of annotation scores that has been on the roadmap since the PXI skill work landed. Headline changes:

• Agents: experiment editing and eval skills (#13704) — The PXI agent gains a complete surface for editing experiment runs and authoring eval skills from inside the chat. Combined with the dataset-management tools from 17.3.0 and the dataset-evaluator editing from 17.4.0, the agent can now own the full regression-suite lifecycle (load dataset, run experiment, edit failed runs, attach evaluator, re-run) without leaving the chat. This is the release that makes "agent-owned eval pipeline with human approval" a real workflow rather than a slide-deck idea.
• Metrics: trace and session annotation score time series (#13722) — A new time-series view that plots annotation scores (correctness, relevance, custom labels attached via the PXI annotate-spans skill from 17.5.0) over time, both per-trace and per-session. For teams that use annotation as their quality signal, this turns the annotation workflow from a one-shot action into a trend you can dashboard and alert on. Pairs naturally with the LLM evaluation frameworks guide when you are deciding which signals to track.
• UI: pan and zoom time range controls with live streaming toggle (#13725) — The dashboard time range selector now supports pan and zoom interactions and adds a live-streaming toggle that keeps the trace stream open during incident review. On-call engineers can now scrub through a regression timeline the way they would in Grafana, and the live-streaming toggle is the single switch that turns the dashboard into a "watch what is happening right now" surface during a P0. The free-form input and calendar picker from 17.4.0/17.5.0 remain for precise ranges.
• Bug fix: sort projects by trace start_time to use composite index (#13752) — A backend correctness-and-performance fix: project listings were sorting by trace start_time but using a non-composite index, which made the query slow on large Phoenix instances. The fix uses the composite index, so the project picker is fast even when you have thousands of traces in a single deployment.

No breaking changes. Treat 17.6.0 as a normal patch-equivalent upgrade on the 17.x line — the release body has no breaking-changes section and the new PXI surfaces are pure additions gated by the same role checks introduced in 17.3.0. Upgrade via pip install arize-phoenix>=17.6.0 or pull the matching container. The composite-index fix is the one you should notice immediately on the project picker; the three features ship as additive surfaces and do not change existing behavior. If you are wiring the new annotate-spans skill output into the metrics time series, the agentic observability guide shows how to correlate that signal with the broader agent-trace analytics layer.

What's New in Arize Phoenix 17.7.0

Arize Phoenix 17.7.0, released 2026-06-16, is the day's drop on the 17.x weekly cadence and lands three features that round out the observability and agent surfaces that 17.3.0 through 17.6.0 built up. The release is small in PR count — three features, one bug fix, one docs cookbook — but each feature is high-leverage: the token-detail metrics close a long-standing cost-analytics gap, agent session context gives the PXI agent memory across turns, and shareable trace time-range URLs finally let on-call engineers paste a link to a colleague that reproduces the exact window they are looking at. Headline changes:

• Metrics: token detail metrics charts (#13764) — A new token-detail metrics view that breaks token usage down by model, prompt, and run with the same fine-grained surface the trace UI has had for latency. For teams using Phoenix as a cost-dashboard backbone, this is the surface that finally closes the gap between "I know my bill is high" and "I can see which prompt template is the largest contributor." Pairs naturally with the token cost by workflow guide — the labeling approach there can be applied directly to the new chart layer.
• Agents: session context (#13727) — The PXI agent gains a session-context layer, giving it working memory across a multi-turn investigation. Previously each message in a long debugging session was effectively stateless from the agent's perspective, and on-call engineers had to re-explain the trace context on every follow-up. With session context the agent carries the trace, hypothesis, and the failed-tools history forward — the same way a human SRE would if they had been staring at the dashboard for an hour. Closes a long-standing gap in the PXI surface and makes the agent usable for the long, multi-message traces that production incidents actually generate.
• UI: shareable trace time range URLs (#13761) — The time range selector that 17.4.0/17.5.0/17.6.0 progressively enriched with free-form input, calendar picker, pan and zoom, and live streaming now writes its state back to the URL. On-call engineers can paste a link to a colleague that opens Phoenix at the exact window they were looking at, with the live-streaming toggle in the right state and the time range intact. This is the papercut that compounds when a P0 crosses timezones and the secondary on-call has to reconstruct the senior's view from a Slack screenshot.
• Bug fix: encode trace IDs in trace/span routes (#13785) — A UI correctness fix: trace IDs that contain characters requiring URL encoding (slashes, colons, percent signs) now route correctly when building trace or span deep links. Previously the un-encoded IDs would 404 or land on the wrong trace, and the failure was silent — the breadcrumb still looked like a valid Phoenix page. If you have ever had a deep link to a trace from a chat tool fail to load, this is the fix.
• Docs: jailbreak and prompt injection defense cookbook (#13729) — A new cookbook covering end-to-end jailbreak and prompt-injection defense patterns on the PXI agent, including the evaluation recipes you can use to regression-test the guardrails. Worth pairing with the prompt injection detection guide if you are building a Phoenix-based eval pipeline that includes security regression coverage.

No breaking changes. Treat 17.7.0 as a normal patch-equivalent upgrade on the 17.x line — the release body has no breaking-changes section and the new PXI / metrics surfaces are pure additions gated by the same role checks introduced in 17.3.0. Upgrade via pip install arize-phoenix>=17.7.0 or pull the matching container. The session-context and shareable-URL changes are the most visible to on-call engineers; the token-detail charts and the trace-ID URL-encoding fix are the ones that show up quietly in the dashboards and deep links you have been building for the last few months.

What's New in Arize Phoenix 17.8.0

Arize Phoenix 17.8.0, released 2026-06-17, is a single-day follow-up to 17.7.0 and the release where the PXI agent's surface formally gains its new identity. The release body re-frames PXI as the "Phoenix Intelligence agent" across the README and the in-product copy, and ships the first PXI surface that is GraphQL-native rather than REST-wrapped. Headline changes:

• Agents: PXI Agent GraphQL skill (#13732) — The PXI agent gains a native GraphQL skill, letting it query Phoenix's metadata graph directly instead of going through the REST API. In practice this is a latency win for the agent's own investigation loops: a PXI debugging a regression no longer pays a REST round-trip per span lookup, and the agent can issue batched GraphQL queries for the "show me every span in this trace with this annotation" patterns that come up constantly in incident triage. The skill is additive — the REST surfaces from 17.3.0 through 17.7.0 still work, so the upgrade is safe. For teams that have wired the PXI agent into a regression-runner pattern (PXI owns the eval, you own the deploy), this is the release that makes the agent feel less like a chat front-end and more like a first-class observability primitive. Pairs naturally with the open source LLM monitoring stack guide if you are standardizing on Phoenix as the trace backbone in a multi-tool deployment.
• UI: pre-load background respects saved theme and OS preferences (#13815) — A papercut fix that the on-call workflow has been waiting for. The pre-load flash used to assume the light theme regardless of the user's saved preference, which is the kind of papercut that compounds when you open Phoenix from a dark-themed browser in a dark server room at 3am. After 17.8.0 the pre-load background matches the saved theme (and falls back to the OS preference when no theme is saved). Small change, very visible.
• UI: consolidated and standardized icon set (#13805) — A consistency pass across the navigation and trace surfaces. The previous release train shipped new surfaces quickly (17.3.0 through 17.7.0 added five major features) and the icon set drifted as a result; 17.8.0 normalizes it. The trace UI, the dataset manager, and the experiment runner now use the same icon vocabulary.
• Docs: PXI entry reframed as "Phoenix Intelligence agent" (#13803) — The README's PXI entry is updated to use the new "Phoenix Intelligence agent" framing. PXI as a chat-surface acronym is being replaced by the longer "Phoenix Intelligence agent" name across the documentation entry points, with "PXI" retained as a short form for in-product use. The change is documentation-only and has no behavior impact, but the new framing is the one to use in any external copy you write about Phoenix from this release forward.

What's New in Arize Phoenix 17.8.1

Arize Phoenix 17.8.1, released 2026-06-17, is a same-day patch on the 17.8.0 line that closes a single integration regression. Headline changes:

• Bug fix: resolve route path through FastAPI 0.137 _IncludedRouter in Prometheus middleware (#13822) — FastAPI 0.137 introduced an _IncludedRouter shape that changed how route paths resolve in middleware. Phoenix's Prometheus exporter was written against the older shape, and on FastAPI 0.137 the exposed metrics started carrying the included-router prefix twice (e.g. /api/v1/api/v1/metrics instead of /api/v1/metrics). Prometheus tolerated it, but scrape configs that pinned the exact job_name path on the included router started failing the match. The fix re-resolves the route path through the new _IncludedRouter shape. If you are running Phoenix against FastAPI 0.137 and pulling the Prometheus endpoint into a scrape config with strict path matching, 17.8.1 is the line to be on. The regression does not affect non-Prometheus deployments (the LangSmith / OTel export paths use a different code path) and the previous 17.8.0 release notes still apply.

What's New in Arize Phoenix 17.9.0

Arize Phoenix 17.9.0, released 2026-06-19, is the first release after the 17.8.x pair and the release where the PXI agent gains a server-side bash tool that you can scope with an explicit kill switch. The release also adds OAuth2 role-resync for SSO customers, label filtering for prompts and datasets, per-tool-call execution summaries in the chat surface, and a small batch of bug fixes. None are breaking; the agent changes are all additive and gated by existing role controls. Headline changes:

• Agents: server-side bash tool + PHOENIX_AGENTS_DISABLE_BASH kill switch (#13767, #13841) — The PXI agent can now run shell commands server-side rather than asking the operator to paste output back in. Useful for the "show me the last 200 lines of this pod's log" or "what is the current value of this configmap" patterns that come up constantly during incident triage. The capability ships with an explicit kill switch, PHOENIX_AGENTS_DISABLE_BASH=1, for teams that want the eval-harness benefits of the agent without granting it server-side shell access — important if your security model treats the agent surface as untrusted-by-default. Bug fix #13842 adds an explicit network deny when the agent is configured with web access disabled, so the bash surface cannot be used as a covert egress channel. For teams that have standardized on agent-scoped auth (the pattern the MCP enterprise authorization guide walks through for MCP tools), this is the Phoenix-native equivalent: the tool exists, but it is disabled by default and only enabled after a deliberate config flip.
• Auth: ROLE_RESYNC for OAuth2 IDPs to preserve manual role overrides (#13838) — SSO customers who grant a user an out-of-band Phoenix role (admin / viewer / custom) used to have those manual overrides clobbered on every login when the IdP returned the role claim. 17.9.0 introduces a ROLE_RESYNC mode that preserves manual overrides across IdP resyncs. If you have ever had a Phoenix admin quietly lose their role after a routine Okta group sync, this is the fix — and it is also the kind of fix that compounds for compliance audits where "who had what role on what date" is a real question. Pair this with the JMESPath type-error tolerance from 17.3.0 and SSO is now actually safe to roll out to a regulated environment.
• Prompts/datasets: filter by label, manage labels from the list, prompt model column (#13830) — The prompts and datasets list pages gain label-based filtering, in-line label management, and a "model" column on the prompts view. For teams that have built up dozens of prompt variants across model migrations, this is the missing UI affordance to find the prompt you actually want without grepping the filesystem. Pairs naturally with the dataset-management tools from 17.3.0 and the evaluator-editing tools from 17.4.0 — Phoenix now has the full "find the thing, edit the thing, run the thing" loop without leaving the UI.
• PXI: render every tool call individually with execution summaries (#13824) — The PXI chat surface used to collapse multi-step agent invocations into a single summary block, which made it hard to debug "which sub-step failed" patterns. 17.9.0 renders each tool call as its own line with an execution summary (duration, success/failure, key output fields), so a 10-step agent run reads as 10 distinct rows rather than one opaque blob. The pattern matters most for teams running PXI as a regression investigator: when a tool-call fails on step 4 of 10, the trace points at the failing step rather than forcing the operator to re-run with verbose logging.
• UI: usage counts for dataset and prompt labels (#13831) — Labels on datasets and prompts now display a usage count (e.g. "production / 14 prompts / 3 datasets"). Small UI addition, but the kind that prevents accidental label sprawl — you can see at a glance whether a label is in use before you delete it.
• Bug fixes: server bash network policy, GraphQL error surfaces, UI nits — Bug fix #13842 (already noted above) closes the network-egress gap on the new bash tool. Bug fix #13835 surfaces actionable GraphQL errors for opaque node/trace id handling — instead of a generic 500, you get "node not found: span_id=abc123, trace_id=def456" which makes trace-correlated debugging much less of a guessing game. UI fixes in #13832 (app frame corner overflow) and #13829 (annotation display and summary preview nits) close two papercuts that compounded during long incident-review sessions.

No breaking changes. The 17.9.0 release body has no breaking-changes section; the server-side bash tool is additive, the OAuth2 role-resync is opt-in via ROLE_RESYNC, and the prompts/datasets label work is purely UI. Upgrade via pip install arize-phoenix>=17.9.0 or pull the matching container. If you operate a regulated deployment where server-side agent bash is a non-starter, leave PHOENIX_AGENTS_DISABLE_BASH unset and 17.9.0 ships the rest of the agent improvements (the GraphQL skill from 17.8.0, the per-tool-call rendering, the label filtering) without the bash surface — that is the cleanest split for teams that want eval-harness benefits without granting shell. The OAuth2 ROLE_RESYNC mode is the one to verify if you have ever lost an admin role after a sync; it is opt-in and has to be enabled per-deployment.

What's New in Arize Phoenix 17.10.0

Arize Phoenix 17.10.0, released 2026-06-22, is a small but targeted drop on the 17.x weekly cadence and the first release where trace-level annotations surface in the trace header rather than only in the side panel. The release also adds Go OpenInference integration docs to the README, which matters more than it looks — Go is the language Phoenix's own server and many high-throughput agent runtimes are written in, and the SDK gap was a real friction point for teams instrumenting from Go services. Headline changes:

• Annotations: trace-level annotations surface in the trace header (#13853) — Annotations on a trace used to live only in the side annotation panel; you had to click into the trace, scroll to annotations, and read them out of context. 17.10.0 promotes trace-level annotations (e.g. "this trace is the regression case", "this trace is gold-set test data") into the trace header so they are visible at a glance. For teams running curated eval sets where the labeling is the value, the header annotation is now the first thing a teammate sees — it changes the triage workflow from "open the trace, hunt for context" to "see the label, decide whether to dig in." This is also the on-ramp for the broader annotation-summary work that 17.11.0 builds on.
• Docs: Go OpenInference integrations added to README (commit 13bc9e5) — The Go OpenInference instrumentation libraries (the Phoenix tracing SDK for Go services) are now listed in the README integrations table. The Go SDK has existed for a while, but teams instrumenting from Go agent runtimes kept asking "is this supported?" because the README only listed Python and TypeScript integrations. 17.10.0 closes that documentation gap. If you have a Go-based agent runtime that you have been holding off on wiring into Phoenix because the docs were ambiguous, 17.10.0 is the line where the answer becomes unambiguous yes.

No breaking changes. The 17.10.0 release is unusually small for a minor version bump on the 17.x cadence — the trace-header annotation promotion is a UI feature and the Go README entry is docs-only — but it sets up the annotation-summary work that lands the next day in 17.11.0. Upgrade via pip install arize-phoenix>=17.10.0 or pull the matching container. There is nothing to verify on the way up beyond the standard regression suite; the Go README entry is the only externally-visible delta beyond the trace-header annotation feature.

What's New in Arize Phoenix 17.11.0

Arize Phoenix 17.11.0, released 2026-06-24, is the current release on the 17.x line and the one that turns the trace-annotation work into a first-class observability primitive: trace annotation summaries now surface in the project stats panel, the PXI eval harness emits agent-readable failure reports, and the agent endpoints are exposed in the Swagger UI when running with --dev. The release also pins a pydantic-ai-slim dependency cap to keep PyPI installs healthy. None are breaking; all the new agent surfaces are gated by existing role controls. Headline changes:

• Annotations: trace annotation summaries in the project stats panel (#13855) — The project stats panel now shows aggregate counts of trace annotations across the project (e.g. "regression: 12, gold-set: 4, prod-incident: 7"). Pairs with the per-trace header annotation promotion from 17.10.0 — together, you can scan the project stats to see "we have 12 traces flagged as regression in the last 24h" and click through to the individual traces. For teams that have been building annotation-driven triage workflows on top of Phoenix, this is the missing top-down view; without it, annotation data was only useful when you already knew which trace to look at.
• Evals: agent-readable failure reports for the PXI eval harness (#13737) — The PXI eval harness now emits failure reports in a structured, agent-readable format. The format is designed for the PXI agent itself to consume — when the harness flags a row as failing, the report is shaped so the PXI agent can pick up the failure, inspect the failing row, and propose a fix (prompt edit, evaluator edit, dataset split). This is the missing link in the "PXI owns the regression suite with human approval" workflow that 17.3.0 through 17.8.0 built up: the harness was generating failures, but PXI could not natively reason over them. Now it can. For teams running PXI as a regression-investigator (the pattern the AI operational debt guide flags as the highest-leverage agent use case for ops teams), 17.11.0 is the release where the loop closes end-to-end without a human having to transcribe failure reports into the chat.
• Agent: submit highlighted command on Enter in the skill prompt (#13868) — The PXI skill prompt now accepts Enter as a submit shortcut on a highlighted command, matching the muscle memory of every other chat surface. Papercut-level UX win, but the kind that compounds when you are running twenty PXI invocations in a row during incident triage.
• Server: agent endpoints exposed in Swagger UI when running with --dev (#13873) — The agent HTTP endpoints are now documented in the dev-mode Swagger UI. Useful for teams prototyping custom agent integrations against Phoenix — you can curl-test the agent surface from the Swagger page rather than reading the OpenAPI schema offline. The endpoints remain gated by the same role controls as the chat surface; this is purely a documentation surface.
• Bug fix: cap pydantic-ai-slim below 2.0 to unbreak PyPI installs (#13881) — pydantic-ai-slim 2.0 ships a breaking change in its public API that Phoenix's eval layer was not ready for. Pinning pydantic-ai-slim below 2.0 keeps PyPI installs healthy until Phoenix catches up. If you have been seeing PyPI install failures on a fresh pip install arize-phoenix after pulling the 2.0 release transitively, this cap is the unblock.
• Bug fix: restore outline shape for thumbs up/down feedback icons (#13871) — The thumbs-up/down annotation icons regressed to a filled shape that lost visual contrast against the trace background. 17.11.0 restores the outline shape, which is the version users actually recognize from the previous release.
• Docs: three eval-cookbook upgrades — Tutorials #13718 (email model comparison leveled up into an eval-harness cookbook), #13728 (session-level evaluation cookbook), and #13721 (realtime guardrails cookbook, reframed concept-first) all ship as part of the 17.11.0 docs push. The eval-harness cookbook in particular is the doc-level companion to the agent-readable failure reports feature — the cookbook shows you how to author an eval that emits the structured failure format the PXI agent can consume.

No breaking changes. Treat 17.11.0 as a normal minor upgrade on the 17.x line — the agent-readable failure reports, the project-stats annotation summaries, and the Swagger UI exposure are all additive, and the pydantic-ai-slim cap is a defensive dependency pin. Upgrade via pip install arize-phoenix>=17.11.0 or pull the matching container. The pydantic-ai-slim cap is the one to verify on the way up if you pin Phoenix's transitive deps in a lockfile (Conda / Poetry / uv) — confirm your resolver respects the cap or you may end up with a broken pydantic-ai-slim 2.0 install. If you have not been on 17.x yet, the safe upgrade path is 17.8.1 → 17.11.0 in one step; the eval-cookbook upgrades and the agent-readable failure reports are the features most worth reading the docs on. For teams standardizing on Phoenix as the trace backbone for a multi-modal monitoring setup (the kind of surface the multi-modal LLM monitoring guide walks through), 17.11.0's agent-readable failure reports are the first release where PXI can own the eval-harness end-to-end on multi-modal traces as well as text-only ones.

What's New in Arize Phoenix 17.14.0

Arize Phoenix 17.14.0, released 2026-06-30, is the latest drop on the 17.x weekly cadence and lands two changes that close the loop on the annotation-driven observability story that 17.11.0/17.12.0 built up. The release is small in PR count — one feature, one bug fix — but each is high-leverage: the project-settings annotation summary puts the annotation rollup on the same surface as the project stats, and the prompt-caching engagement on the PXI agent cuts Anthropic spend on the chat surface by reusing cached system-prompt blocks. The release ships alongside a arize-phoenix-client 2.11.0 SDK drop, so server and client remain decoupled on the same cadence. Headline changes:

• UI: annotation summary in project settings (#13850) — A new annotation summary card on the project settings page rolls up the per-span annotation counts and agreement rates for the project. Until 17.14.0, that summary lived in the trace explorer, which meant a project owner had to drill into individual traces to see the aggregate. The project-settings card is the right surface for that rollup — the project owner is the persona that cares about "is my annotation team actually annotating" rather than "what did this single trace annotate." For teams standardizing on Phoenix as the annotation backbone for a CI-eval loop (the workflow the LLM evaluation frameworks guide walks through), 17.14.0 is the line where the project-level annotation health is visible without leaving the settings page.
• Agents: engage Anthropic prompt caching in PXI (#13941) — A real cost-control fix for PXI users on Anthropic. Until 17.14.0, PXI chat invocations were sending the full system prompt on every API call, which on a long-lived agent session with a stable system prompt was a 5-10x cost penalty versus the cached path. 17.14.0 engages Anthropic's prompt caching for the PXI surface, so a long investigation reuses the cached system-prompt block and only pays full price on the first message. If you are running PXI on Claude Sonnet or Opus and the agent's own spend is showing up as a non-trivial line item on your Anthropic bill, 17.14.0 is the line where that line item drops back into the noise. Pairs with the LLM cost monitoring tools 2026 roundup for the broader pattern of tracking agent-side spend separately from user-side spend.

No breaking changes. Treat 17.14.0 as a normal minor upgrade on the 17.x line — both changes are additive, the project-settings annotation card is opt-in via the existing project settings route, and the Anthropic prompt caching is engaged automatically for Anthropic-backed PXI invocations. Upgrade via pip install arize-phoenix>=17.14.0 or pull the matching container. If you are running PXI on an Anthropic backend, expect a visible spend drop on the day of the upgrade; if you are running the open-source-only build, the project-settings annotation card is the single change worth verifying. The 17.14.0 server release is paired with arize-phoenix-client 2.11.0 on the same day — the two decouple cleanly, so you can roll the server forward to 17.14.0 on its own cadence and the client SDK on a faster cycle.

What's New in Arize Phoenix 17.15.0

Arize Phoenix 17.15.0, released 2026-07-01, is the latest drop on the 17.x weekly cadence and lands one new model provider pairing alongside a small but high-leverage bug-fix pair. The release is small in surface area — one feature, two bug fixes, one dependency bump — but the provider pairing matters for any team that has standardized on Claude Sonnet 5 on AWS Bedrock or direct Anthropic, and the Bedrock tool-import fix closes a real span-import regression that was breaking the playground trace round-trip. The release ships alongside an arize-phoenix-client 2.11.0 client bump, so the server and client move together on the same day. Headline changes:

• Playground: add Claude Sonnet 5 to Anthropic and AWS providers (7525402) — The Phoenix playground now lists Claude Sonnet 5 in the Anthropic and AWS Bedrock provider pickers. Until 17.15.0, teams that had standardized on Sonnet 5 for cost-sensitive serving had to enter the model ID by hand in the playground custom-model field, which was friction on the eval-authoring loop. 17.15.0 surfaces the model in the picker, so the prompt-iteration path is the same UX as the older Sonnet entries. If your eval dataset is benchmarked against Sonnet 5, the playground can now reproduce the production model path without the custom-model workaround. For teams running the broader eval-CI loop on Claude models, this also pairs naturally with the arize-phoenix-client 2.11.0 client release (same day) — the same Sonnet 5 ID is now usable from the Python client without a config patch.
• Cost: update built-in model token prices (afcc867) — The built-in cost map picks up the latest provider price cards, including the Sonnet 5 entry. Until 17.15.0, the Sonnet 5 cost rollup was based on a price-card placeholder that under-counted versus the real provider bill. 17.15.0 closes that gap. If your cost dashboard reconciles against the provider invoice, expect a small one-day bump on the day of the upgrade as the refreshed Sonnet 5 price flows through the rollup. For teams using Phoenix as the cost-attribution source-of-truth alongside a separate FinOps layer, the Sonnet 5 price refresh is the change worth verifying if you have any chargeback rules keyed to per-token cost.
• Playground: re-wrap unwrapped Bedrock tools at span import (#13940) (feacaa6) — A span-import correctness fix for Bedrock-backed traces. Until 17.15.0, Bedrock tool definitions that arrived without the wire-format wrapper were being imported into the playground as-is, which on a re-run through the playground surfaced as "tool not found" errors even though the tool was correctly registered on the upstream Bedrock invocation. 17.15.0 re-wraps the unwrapped tool definitions at import time so the playground sees the same shape the model saw at inference. If you have been hitting "tool not registered" errors when re-running Bedrock traces through the playground — a class of bug that the eval-authoring loop has been filing tickets about since the Bedrock integration added Sonnet 4 support — 17.15.0 is the line that closes it.
• Trace: preserve empty JSON object attributes in load_json_strings (#13847) (74ffd66) — A small but real ingest-path fix. Until 17.15.0, the load_json_strings ingest helper was silently dropping JSON-object attribute values that were {} (an empty object), coercing them to None. For trace payloads that carry a structured attribute like tool_args: {} (a tool was called with no arguments), the empty object was disappearing on ingest and showing up as tool_args: None in the trace explorer, which on a downstream eval that checked for the empty-object literal was producing false-positive "tool argument missing" failures. 17.15.0 preserves the empty object. If you have an eval pipeline that asserts on JSON-object attribute shape, the fix is silent but worth confirming on a representative trace.
• Deps: update arize-phoenix-client to 2.11.0 (209d065) — A dependency bump to align the server with the 2.11.0 client line (the same 2.11.0 release of the same day). If you are running the bundled server+client container, the bump is automatic; if you are running them separately, confirm both pins are at >= 2.11.0 to pick up the Sonnet 5 client support and the Bedrock tool re-wrap path on the client side as well.

No breaking changes. Treat 17.15.0 as a normal minor upgrade on the 17.x line — the Sonnet 5 provider pairing is additive (the older Sonnet entries still work), the cost-map refresh is non-disruptive, and the Bedrock tool re-wrap + the empty-object preserve are silent correctness fixes. Upgrade via pip install arize-phoenix>=17.15.0 or pull the matching container. If you are mid-eval-cycle on a Sonnet 5 workload, the provider-picker change is the visible win; if you are on Bedrock, the tool re-wrap is the change worth verifying on a representative trace; if you are tracking cost attribution at the percent level, the Sonnet 5 price refresh is the one-day bump to expect. The 17.15.0 server release pairs with arize-phoenix-client 2.11.0 on the same day — bump them in lockstep if you are pinning both, or hold the server at 17.15.0 while letting the client move on its own cadence, the two decouple cleanly.

What's New in Arize Phoenix 17.22.0 → 17.29.0 (the week's drops, 2026-07-09 → 2026-07-13)

Eight point releases of Phoenix shipped in the seven-day window from 2026-07-09 through 2026-07-13 — 17.22.0, 17.23.0, 17.24.0, 17.25.0, 17.26.0, 17.27.0, 17.28.0, 17.29.0 — plus the 2.13.0 client release on the same cadence. The release profile is "polish on top of polish": 17.22.0 through 17.26.0 ship one focused UI / PXI feature each and a small cluster of bug fixes, and 17.27.0 through 17.29.0 land the broader UI redesign (dataset / prompt authorship columns, column reordering, redesigned column selector, drag-and-drop on the traces / sessions / experiments tables) and the agent-side work (approval-gated annotation config tools, span-coding for PXI, server-side PXI tracing). The headline theme across the week: PXI agents moving from in-process browser instrumentation to server-side tracing (the architectural shift that 17.29.0 closes), the column-reordering redesign that finally lands across the trace / session / experiment / dataset / prompt tables in 17.27.0, and a long tail of small correctness fixes that surface as a cleaner on-call workflow. For the rationale on why this is one consolidated section rather than eight per-release sections, see the cadence note below; for teams on a weekly upgrade cadence, 17.29.0 is the recommended production pin and 17.28.0 the safe-harbor fallback. The headline changes from the eight release notes (17.22.0, 17.23.0, 17.24.0, 17.25.0, 17.26.0, 17.27.0, 17.28.0, 17.29.0):

• Agents: PXI tracing moves server-side (17.29.0, #14215) — The biggest architectural change in the week. Until 17.29.0, PXI tracing was largely an in-process, browser-side instrumentation that emitted spans from the agent's client runtime. The server-side move relocates the tracing surface into the agent-server component, which means browser instrumentation becomes an optional debug surface rather than a primary one. The practical change for production teams: the trace tree no longer depends on browser-side state for the agent half of the trace, so traces survive client disconnects, browser-tab refreshes, and worker crashes mid-turn in a way the in-process tracing could not. For teams that have standardized on PXI as their agent-debugging surface (the pattern the agent observability at 1,200+ agents OTel stack 2026 guide covers at fleet scale), 17.29.0 is the line where agent traces stop being a "the browser must stay open" liability.
• PXI: add remote export setup command (17.29.0, #14333) — A CLI companion to the server-side tracing move. The new phoenix pxi export-setup command walks an operator through the configuration steps to wire PXI traces into a remote OpenTelemetry-compatible backend (Tempo, Jaeger, Datadog APM, Honeycomb). Until 17.29.0, the export path required hand-editing the server config file with the OTLP endpoint, headers, and exporter-type fields, which was friction on the "I want to test PXI against my real backend" workflow. 17.29.0 collapses the setup to a single CLI invocation with sensible defaults. For teams standardizing on Phoenix as the trace backbone for a multi-tool agent deployment (the pattern the open source LLM monitoring stack guide walks through), 17.29.0 is the line where adding a new PXI-backed agent to an existing OTel pipeline becomes a one-command operation rather than a config-file exercise.
• UI: column reordering across the traces, sessions, and experiments tables (17.27.0, #14299) + redesigned column selector + drag-and-drop (17.27.0, #14298) + dataset / prompt authorship columns + rename to updatedBy (17.27.0, fb08fe6) + customize prompts table columns (17.27.0, a3c6b92) — A four-PR cluster that lands the broader UI redesign of the trace / session / experiment / dataset / prompt tables. Until 17.27.0, the column order on those tables was fixed: an operator who wanted latency or cost as the leftmost column had to scroll-and-eyeball. 17.27.0 ships drag-and-drop column reordering with a redesigned column selector, dataset / prompt authorship columns (with a rename of the metadata key to updatedBy), and per-table customization on the prompts surface. For teams running Phoenix as the eval-loop backbone (the workflow the LLM evaluation frameworks guide covers), 17.27.0 is the line where the eval-triage workflow becomes a "set your column order once, every table reflects it" pattern rather than a per-table scroll-and-find exercise.
• UI: design audit of alerts, counters, and session selection (17.27.0, #14315) + preview full span IO in table tooltips (17.27.0, #14305) — Two UI polish additions. The design audit lands a visual refresh across the alerts panel, the counters surface, and the session-selection flow — bringing the visual language in line with the rest of the dashboard. The span-IO tooltip previews the full span IO inline in the traces table, so an investigator can hover over a span row and see the IO without clicking through to the span detail. For teams using Phoenix as the trace backbone for a long-running agent deployment, the design audit and the span-IO tooltip are silent wins — they do not change data shape, but they remove two of the most common "where is the button I am looking for" friction tickets.
• Agents: approval-gated annotation config tools + span-coding for PXI (17.25.0, #13866) — A pair of PXI-side additions that tighten the operator-agent boundary. The approval-gated annotation config tools require an operator to approve a config change before PXI can apply it, which closes the "PXI reconfigured the eval taxonomy under our feet" failure mode. The span-coding for PXI surfaces a span-level code annotation on every PXI-emitted span, so a downstream eval pipeline can key to the coding key directly. For teams running PXI as a regression-investigator with an eval-CI loop (the workflow the LLM evaluation frameworks guide recommends), 17.25.0 is the line where the operator / PXI boundary becomes a visible approval surface.
• UI: add Metrics tab to the dataset page with experiment charts (17.25.0, #14106) + refine experiment metric charts (17.25.0, #14208) — Two dataset-page UI additions. The Metrics tab surfaces per-dataset aggregate metrics (eval pass-rate, latency p50/p95/p99, token volume, cost rollup) on a dedicated tab, so the dataset manager no longer requires an experiment run to surface aggregate stats. The experiment-metric-chart refinement improves the chart UX (axis labels, tooltip formatting, color contrast). For teams running dataset-as-source-of-truth workflows where the dataset manager is a daily surface, 17.25.0 is the line where aggregate metrics are visible without leaving the dataset page.
• UI: add session annotation editing in session details (17.28.0, #13852) + collapsible playground sections via TitledPanel (17.28.0, #14324) + modernize core Tabs with animated selection indicator and scroll snapping (17.28.0, #14325) — A three-PR UI polish cluster. The session annotation editing closes a long-standing gap: until 17.28.0, an operator could view session-level annotations but not edit them in-session (the edit had to happen at the span level). The TitledPanel collapsible sections reduce vertical scroll on the playground. The Tabs modernization lands the new tab UX (animated selection indicator, scroll snapping) that 17.27.0 previewed. For teams with session-level annotation workflows (the eval-iteration pattern the hallucination detection production playbook recommends), 17.28.0 closes the session-annotation-edit gap.
• GPT 5.6 family support (17.23.0, #14180) + PXI evals move to pytest plugin (17.24.0, #13999) + PXI onboarding gate UX (17.22.0, #14110) + forced tool choice menus clarified (17.26.0, #14279) — A four-PR cluster that closes smaller eval / provider gaps. The GPT 5.6 family adds the latest OpenAI model IDs to the eval playground. The PXI evals pytest plugin moves the PXI eval harness to a pytest-native plugin (cleaner integration with the standard pytest-CI loop). The PXI onboarding gate UX improves the first-run experience. The forced-tool-choice menu clarification fixes an ambiguity in the playground's tool-choice picker. Each is small; together they remove a class of "is this eval running correctly" friction tickets that show up in the first week of a 17.x stable deployment.
• Phoenix env file (17.25.0, #14188) + tracing video in README (17.29.0, #14334) — A pair of operator-experience additions. The env file ships a .env.phoenix template that an operator can copy-and-edit to wire Phoenix's most common configuration values (OTLP endpoint, S3 backing store, Postgres URL, server-side PXI tracing flag) without reading the full config reference. The README video is a 90-second walkthrough of the trace explorer — useful for onboarding new operators to the trace-tree workflow. For teams running Phoenix as the trace backbone for a multi-tool agent deployment, both are quiet wins that show up as a faster onboarding loop.

No breaking changes across the eight releases. Treat 17.29.0 as the normal minor upgrade target on the 17.x line — every change is additive (existing traces continue to render with the old column order, existing PXI traces still work even if you have not moved to server-side tracing, the new Metrics tab is a new surface rather than a replacement). Upgrade via pip install arize-phoenix>=17.29.0 or pull the matching container. For teams on a weekly upgrade cadence, 17.29.0 is the recommended production pin and 17.28.0 the safe-harbor fallback (skip 17.22.0 through 17.27.0 in a single-step upgrade if you prefer; the seven releases compose cleanly). For teams that have standardized on PXI as their agent-debugging surface, the server-side tracing move in 17.29.0 is the highest-leverage change in the week — every prior PXI trace was effectively dependent on browser-side state, and 17.29.0 is the line where agent traces survive client disconnects. For teams tracking how the LLMOps vendor comparison itself evolves, the column-reordering redesign and the per-table customization in 17.27.0 are the kind of feature surfaces that re-shape how the per-user workflow comparison between Phoenix, Braintrust, and LangSmith plays out — the same UX affordance on Phoenix may not exist yet on the competing surfaces, and that is a feature-parity delta worth tracking on the next benchmarking round. The LLM observability tools compared 2026 piece covers the surface-level comparison; the column-reordering + PXI server-side tracing combo is the next-iteration delta to verify against that comparison. For teams evaluating whether to evaluate PXI against a benchmark before adopting it (the workflow the LLM evaluation frameworks guide recommends), the 17.29.0 server-side tracing release is the right cut to validate against the eval suite — it is the line where PXI's tracing surface becomes testable in isolation rather than dependent on browser instrumentation. Note on cadence: this section consolidates 17.22.0 → 17.29.0 because eight per-release sections in a seven-day window becomes repetitive for the reader; for the per-release PR-detail view, each release link above points at the full GitHub release notes. If you are operating a "release-notes-as-documentation" workflow (publishing internal release summaries on the day each lands), the eight per-release sections in the changelog still apply — the consolidation here is a reader-experience choice, not a signal that the underlying cadence has changed.

What's New in Arize Phoenix 17.20.0

Arize Phoenix 17.20.0, released 2026-07-07, is the day's drop on the 17.x weekly cadence and lands one new UI feature (user-selected metric charts above the project tables), one cost data refresh (built-in model token prices), and a small batch of correctness fixes around the agents chat surface and the projects page. The release is intentionally tight in PR count — one feature, three bug fixes, one documentation pass — but each item is high-leverage for production teams. There are no breaking changes and no new platform-level surfaces; the change is the kind of polish that compounds into a faster on-call workflow. If you are running Phoenix as the trace backbone for a multi-tool agent deployment (the pattern the open source LLM monitoring stack guide walks through), 17.20.0 is the release that gives you the freedom to pick your own metric tiles at the top of the project view instead of inheriting a static preset. Headline changes:

• UI: user-selected metric charts above project tables (#14068) — The project-tables view (the surface that lists every project and is the entry point for the trace explorer, the dataset manager, and the experiment runner) used to show a fixed set of metric tiles that every tenant inherited on first render. 17.20.0 replaces the static preset with a user-selected set: each operator can pick which charts sit above the table (e.g. token volume, error rate, latency p99, eval pass-rate) and the choice persists across sessions. For teams that have standardized on Phoenix as the trace backbone for an AI infrastructure spread across multiple inference backends (the model-router patterns the LLM inference engine comparison and the dedicated vLLM vs Triton comparison map for vLLM / Triton / SGLang / TensorRT-LLM / Ollama), the per-user metric selection is the missing surface that lets each persona (cost, SRE, eval) see the chart that matters to them without scrolling past the others. Pairs naturally with the trace-tree search from 17.19.0 — once you have filtered the tree to a subset of spans, the user-selected metric tile is the surface you paste into the incident channel.
• Bug fix: agents chat surface error recovery improvements (#13833) — The PXI agent's chat surface used to surface a generic error banner when an upstream tool call failed mid-conversation, which forced the operator to reload the chat and lose the prior context. 17.20.0 adds targeted chat-error recovery: a failed tool call now shows the underlying error inline and offers a retry affordance that does not clear the rest of the conversation. For teams running PXI as a regression-investigator (the workflow the 17.11.0 agent-readable failure reports and the LLM evaluation frameworks guide recommend), 17.20.0 is the line where a transient tool failure no longer costs the entire working context.
• Bug fix: guard against nullish projects connection on the Projects page (#14086) — A frontend correctness fix. Until 17.20.0, the Projects page was throwing a console error on the first render when the projects connection was still loading (the typical cold-start window). The fix adds a nullish-connection guard so the page renders cleanly during the loading window instead of flashing a console error in the operator's DevTools. For teams that use the DevTools console as a regression signal during deploy verification, 17.20.0 stops the false positive. Pairs naturally with the broader front-end observability work that the AWS Trainium and Inferentia guide covers for cloud-hosted inference backends — the same "first render is dirty because the connection is still spinning up" failure mode shows up on the inference side, and the fix shape is similar.
• Cost: update built-in model token prices (#14082) — The built-in cost map picks up the latest provider price-card data. If your cost dashboard reconciles against the provider invoice at the percent level and you noticed a drift over the past few weeks as providers adjusted their public pricing, 17.20.0 brings the rollup back in line. For teams using Phoenix's cost rollup as the chargeback source-of-truth alongside a separate FinOps layer (the pattern the LLM cost monitoring tools 2026 guide maps), this is the data refresh to verify on the day of the upgrade — and if you want to sanity-check the new price-card values against a fresh forecast before you cut a chargeback report, the LLM API cost calculator lets you plug the per-million-token rates directly in and compare against your weekly volume.

No breaking changes. Treat 17.20.0 as a normal minor upgrade on the 17.x line — the user-selected metric chart picker is additive (the static preset remains the default for tenants that have not picked), the cost-map refresh is non-disruptive, and the chat-error recovery / nullish-connection guard are silent correctness fixes that surface as a cleaner on-call workflow. Upgrade via pip install arize-phoenix>=17.20.0 or pull the matching container. The per-user metric selection is the highest-leverage UX addition in the 17.x line since the trace-tree search in 17.19.0, and combined with the cost-map refresh it pairs cleanly with the broader eval-iteration loop that the user-persona pattern (cost / SRE / eval) covers. For teams tracking how the platform comparison itself evolves alongside the LLMOps vendor feature cadence, the comparison-surface updates in 17.20.0 (user-selected charts, cost-map refresh) are the right place to think about where the next benchmarking round will move the relative scores between Braintrust, LangSmith, and Phoenix — the per-user metric selection in particular is a feature that the LLM observability tools compared 2026 piece tracks against the equivalent feature surfaces on Portkey and Helicone.

What's New in Arize Phoenix 17.21.0

Arize Phoenix 17.21.0, released 2026-07-08, is the day's drop on the 17.x weekly cadence and lands a tightly-scoped mix of PXI-agent observability work (end-to-end turn tracing from browser to backend), an app-level global search command palette (⌘K), and a cluster of session-management improvements (orphan-session sweep, session stats side panel, session turn divider with copy, total session count on project card). The release is intentionally narrow in PR count — seven features, two documentation PRs — but each feature closes a real gap on the agentic-investigation workflow. There are no breaking changes. Headline changes:

• Agents: end-to-end PXI turn tracing from browser to backend (#14080) — The biggest change in 17.21.0. Until 17.21.0, the PXI agent's turn-level trace only captured the backend side of a turn — the LLM call, the tool calls, the post-processing. The browser side (the user-typed prompt, the UI events, the time the user spent reading before sending the next turn) was effectively a black box. 17.21.0 ships end-to-end turn tracing, where a single turn view stitches together the browser event, the backend span, and the model output. For teams that have standardized on the PXI agent as the primary agentic-investigation surface (the workflow the 17.11.0 agent-readable failure reports and the LLM evaluation frameworks guide recommend), 17.21.0 is the release where the "what was the user actually doing between turns" question finally has a real answer in the trace. Pairs with the per-user metric selection from 17.20.0 — once the turn trace surfaces browser latency, the per-user metric tile is the surface that exposes it.
• App: global search command palette (⌘K) (#14114) — A global, keyboard-driven search-and-jump palette surfaced via ⌘K. Until 17.21.0, navigating Phoenix from a project to a specific span, dataset, prompt, or experiment required the operator to click through the side nav and search within each surface. 17.21.0 collapses that to a single ⌘K palette that searches across projects, traces, spans, datasets, prompts, evaluators, and experiments. For teams running Phoenix as the trace backbone for a multi-tool agent deployment (the pattern the open source LLM monitoring stack guide walks through), 17.21.0 is the line where the on-call workflow stops being a click-marathon and starts being a single keystroke. The trace-tree search from 17.19.0 narrowed the search to within a tree; the ⌘K palette widens it to the whole deployment.
• Sessions: sweep orphaned sessions after a one-hour grace period (#14098) — Until 17.21.0, a session that started but never produced a closing event (a client disconnect, a worker crash mid-turn, an early session abandonment) would stay in the sessions table indefinitely. On a long-running deployment that was a slow background-bloat path: the sessions table grew unboundedly, the session-stats panels took longer to render, and the cluster-gc work had no anchor. 17.21.0 sweeps sessions that have been orphaned for more than one hour and removes them from the active set. For teams running PXI as a long-session agent surface (the customer-support use case the agentic observability guide covers), 17.21.0 is the line where the sessions table size stops being a deployment-time concern.
• App: session stats side panel for the sessions table (#14007) + session turn divider with copy (#14117) + UI: show total session count on project card (#14064) — Three session-table UI improvements. The stats side panel surfaces per-session aggregate stats (turn count, total tokens, tool-call count, average latency) next to the sessions table, so a triage investigator can spot a high-cost or high-latency session at a glance. The turn divider with copy adds a per-turn copy affordance so an investigator can pull a single turn's text out of the session without scrolling through the whole conversation. The project-card total-session-count is a small but compounding fix: the project list now shows how many sessions are in each project, so a long-running deployment that has been losing session-metadata drift can spot the project that has gone silent at a glance.
• App: read-only styles (#14111) — A small but visible UI correctness fix. Until 17.21.0, form fields that were intended to be read-only (eval configurations, prompt versions, dataset splits) still rendered as editable inputs, so an operator could inadvertently edit a field that was not intended to change. 17.21.0 ships a dedicated read-only style so read-only fields are visually distinct from editable ones. For teams running evaluators as a regulated surface (the eval-iteration pattern the hallucination detection production playbook recommends), 17.21.0 is the line where the read-only surface stops being a UI illusion and becomes a visible affordance.

No breaking changes. Treat 17.21.0 as a normal minor upgrade on the 17.x line — the end-to-end turn tracing is additive (existing traces continue to render as backend-only), the ⌘K palette is a new affordance (existing navigation paths still work), the session-management improvements are silent correctness fixes plus UI additions, and the read-only style is a UI polish. Upgrade via pip install arize-phoenix>=17.21.0 or pull the matching container. The end-to-end turn tracing is the highest-leverage observability addition in the 17.x line since the trace-tree search in 17.19.0 — the browser-event visibility is the missing half of the agentic-debugging workflow that the backend-only trace has been waiting for. The ⌘K palette is the highest-leverage UX addition since the per-user metric picker in 17.20.0. The two together compound: a triage investigator can now ⌘K to a session, click into a turn, see the browser event alongside the backend span, and copy a turn out for the incident channel — all without leaving the keyboard. If you are mid-eval-cycle on a session-heavy workload (customer-support agent, multi-turn coding agent), 17.21.0 is the release that closes both the user-event visibility gap and the navigation-friction gap at the same time. For teams tracking how the platform comparison itself evolves alongside the LLMOps vendor feature cadence, the agent-observability additions in 17.21.0 are exactly the surface that the agentic harness for AI incident response guide and the broader LLM observability guide 2026 map for production teams — the end-to-end turn trace is the kind of feature that re-shapes how an on-call rotation handles a session-level incident.

What's New in Arize Phoenix 19.3.0

Arize Phoenix 19.3.0, released 2026-07-20, lands as a one-week follow-up to 19.2.0 and is a polish-and-ergonomics drop rather than a platform-bump. The release is intentionally narrow — five features and one bug fix, no behavior changes elsewhere — and the headline surface is the auth and playground surfaces (the two surfaces that new operators hit first after install). There are no breaking changes and no eval-harness surface changes. Headline changes from the 19.3.0 release notes:

• Auth: negotiate HTTP/2 for OAuth2/OIDC provider requests (#14559) — The auth layer now negotiates HTTP/2 against the OAuth2/OIDC identity provider on outbound token-exchange calls. Until 19.3.0, Phoenix spoke HTTP/1.1 to the IdP, which on enterprise IdPs behind a load balancer could produce subtle latency cliffs and connection-pool exhaustion during deploy-time spikes. HTTP/2 multiplexes many token-exchange requests over a single TCP connection, which is the right shape for an IdP that handles Phoenix's service-account traffic alongside its user-traffic. For teams running Phoenix as the trace backbone for a regulated agent fleet (the pattern the LLM observability guide walks through), 19.3.0 is the line where the auth path stops being a hidden latency source on the deploy-day request envelope. If your IdP is behind a strict HTTP/1.1-only proxy, the negotiation falls back cleanly and the only visible behavior is the same auth flow as before — there is no flag to revert.
• Playground: filter model picker to provisioned providers (#14529) — The playground model picker (the dropdown where you pick which model the playground sends a test prompt to) now filters to providers that are provisioned for your deployment. Until 19.3.0, the picker listed every provider the playground SDK knew about, including ones that were not configured with credentials for your instance — so a click on Anthropic in an Anthropic-not-provisioned deployment would surface a credentials error mid-test instead of an option-disabled state up front. 19.3.0 scopes the picker to provisioned providers, so the dropdown only shows the models you can actually use. For teams running Phoenix as the eval surface for a multi-model routing layer (the workflow the multi-LLM routing guide covers), 19.3.0 is the line where the playground stops listing unreachable providers and starts reflecting the actual routing fleet you have configured.
• Settings: add documentation onramps (#14536) — The settings surface now ships inline documentation onramps. Previously, the settings page was a list of toggles with tooltips; 19.3.0 adds a contextual doc-link next to each settings group that opens the relevant Phoenix documentation section. For teams onboarding new operators to Phoenix as the trace backbone (the same workflow the dedicated Arize Phoenix guide documents end-to-end), the inline doc-link is the surface where the "what does this toggle do" question gets answered without leaving the settings page. The onramps ship for the most-visited settings groups first (model providers, evaluators, projects) and expand to the rest of the surface in subsequent 19.x releases.
• UI: add routed profile settings tabs (#14538) — The profile settings UI now uses routed tabs (one URL per settings group) rather than a single scrollable page. The change is small but shows up as a noticeable reduction in the "where is the API key settings tab" friction for new operators, and as a cleaner deep-link surface for runbook screenshots. For teams that maintain Phoenix runbooks for the on-call rotation (the same documentation pattern the LLM incident postmortem guide and the agentic harness guide recommend), 19.3.0 is the line where the settings page is link-stable at the tab level — a runbook can now point at /settings/evaluators and that URL resolves to the evaluator tab across deploys.
• Bug fix: agents omit trace metadata for PXI turns when tracing is off (#14557) — A correctness fix on the agent tracing path. Until 19.3.0, the PXI agent would still emit trace metadata for each turn even when tracing was explicitly disabled at the deployment level, which produced ghost spans on the disabled-tracing surface and inflated the trace-storage counter on dashboards. 19.3.0 suppresses the metadata emission when tracing is off, so the disabled path is actually silent. For teams running Phoenix with selective tracing on (the pattern that lets you disable tracing on dev deployments while keeping it on for prod), 19.3.0 is the line where the dev-deployment trace count actually drops to zero instead of carrying a low background-noise floor of ghost spans.

No breaking changes. Treat 19.3.0 as a normal minor upgrade on the 19.x line — the auth HTTP/2 negotiation is a transparent behavior improvement, the playground model-picker filter is a UX correctness fix, the documentation onramps and routed settings tabs are pure additions on the settings surface, and the PXI-tracing-off bug fix is a silent correctness improvement. Upgrade via pip install arize-phoenix>=19.3.0 or pull the matching container. The safe upgrade path from 18.0.0 is unchanged — 18.0.0 → 19.3.0 in one step is still additive throughout the 19.0 → 19.1 → 19.2 → 19.3 cadence, and the only behavior to verify remains whether your session-time-range filter still uses interval-overlap semantics (it does — 19.0 inherited the 18.0.0 change). If you operate Phoenix behind a strict HTTP/1.1-only IdP proxy and the HTTP/2 negotiation surprise is a concern, verify the auth fallback path in staging before rolling to prod; the negotiation falls back cleanly, but a network capture during the IdP handshake is the right pre-upgrade check. For teams tracking how the LLMOps vendor comparison itself evolves alongside the Phoenix release cadence, 19.3.0 is a useful signal: the HTTP/2 negotiation and the playground model-picker filter are exactly the surface-level polish moves that compound into a smoother operator experience, and the new tab-routed settings surface is one of the inputs the next benchmarking round against Braintrust, LangSmith, and Portkey should weigh.

What's New in Arize Phoenix 19.2.0

Arize Phoenix 19.2.0, released 2026-07-19, is the next minor release on the 19.x line and lands as a polish-and-integration drop rather than a platform-level shift. The release is intentionally small in surface area — three features (CLI startup banner improvement, server boot banner showing dev tooling info, and settings additions for Antigravity and OpenCode MCP client instructions), one dependency fix on the app side (inline codemirror-json-schema in vitest to fix ESM resolution), and one Windows-specific CLI fix (sanitize the startup banner so box-drawing characters do not corrupt on Windows consoles). There are no breaking changes and no eval-harness surface changes. The 19.x line itself continues the weekly-cadence shape that 17.x stabilized on, with each release landing as a focused drop rather than a platform-bump. The headline changes from the 19.2.0 release notes:

• CLI: improve server startup banner (3904c49) — A presentation-layer cleanup on the CLI startup banner. The Phoenix CLI now prints a tighter, more readable startup summary when bringing the server up locally — fewer redundant status lines, a clearer pointer to the URL where the UI is reachable, and a clean shutdown line. For teams that boot Phoenix in a notebook workflow or a CI smoke-test step, the banner is the first thing that surfaces in stdout, and the 19.2.0 cleanup makes the cold-start path legible. For teams that have standardized on Phoenix as the trace backbone for an ML pipeline observability stack, the CLI boot banner is the surface where Phoenix first shows up in a training-loop log, and the 19.2.0 banner is the readable shape to point your runbook at.
• Server: show dev tooling info in boot banner (7e36376) — The Phoenix server boot banner now surfaces the dev tooling versions (Python, key packages, and the active config profile) right next to the URL pointer. Until 19.2.0, an operator triaging a "why is my local Phoenix behaving differently than staging" question had to grep the source tree for which Python or which config profile the server was using. 19.2.0 surfaces those values inline. For teams running Phoenix as the trace backbone for production agent debugging (the workflow the beyond the stack trace AI debugging guide walks through), the dev-tooling banner is the surface where the operator finds the version mismatch first rather than the spot where they would have eventually discovered it.
• Settings: add Antigravity and OpenCode MCP client instructions (8180357) — The settings page now emits MCP client instructions for Antigravity and OpenCode alongside the existing Claude/Cursor/Continue instructions. Teams instrumenting Phoenix against the Antigravity runtime or the OpenCode agent harness — both of which are increasingly common targets in the broader AI development surface — get the same turn-key client config the other supported clients have had for the last few cycles. For teams evaluating the broader MCP-driven agent ecosystem (the pattern the dedicated Arize Phoenix guide covers for PXI), 19.2.0 is the release where Phoenix stops being Claude-Desktop-centric on the client instruction surface and ships a real cross-runtime config.
• App: inline codemirror-json-schema in vitest to fix ESM resolution (dc0d641) — A vitest/test-resolution fix on the app side. The codemirror-json-schema package was being resolved as an external ESM dependency, which broke the vitest transform on a clean install. 19.2.0 inlines the package so the test path resolves deterministically. Frontend correctness only — no behavior change for production users — but if you maintain a fork of Phoenix with custom app-side tests, 19.2.0 is the line where the vitest transform stops flaking on a fresh yarn install.
• CLI: sanitize startup banner on Windows (1474c9b) — A Windows-specific CLI fix. The Phoenix CLI startup banner uses box-drawing characters that the legacy Windows console renders as garbage glyphs. 19.2.0 detects the console encoding and strips the box-drawing characters on Windows, so the boot summary reads cleanly on a Windows host. Frontend polish, but if you have a Windows-based dev team that previously read the startup banner as mojibake, 19.2.0 is the line where the cold-start output becomes legible.

No breaking changes. Treat 19.2.0 as a normal minor upgrade on the 19.x line — the CLI banner improvements are presentation-layer, the dev-tooling banner is additive, the new MCP client instructions are pure-additions in the settings surface, and the vitest/Windows fixes are silent correctness improvements. Upgrade via pip install arize-phoenix>=19.2.0 or pull the matching container. If you have been on 18.0.0, the safe upgrade path is 18.0.0 → 19.2.0 in one step; the 19.x line has stayed additive throughout the 19.0 → 19.1 → 19.2 cadence, and the only behavior change to verify is whether the session-time-range filter still uses interval-overlap semantics (it does — 19.0 inherited the 18.0.0 change). If you are mid-eval-cycle on a Windows-based dev team, the banner-sanitize fix is the visible win; if you are evaluating the cross-runtime MCP surface, the Antigravity and OpenCode client instructions are the additions worth reading the settings page on. For teams tracking how the LLMOps vendor comparison itself evolves alongside the Phoenix release cadence, 19.2.0 is a useful signal: the cross-runtime MCP client coverage is exactly the kind of feature that re-shapes how Phoenix sits in the broader agentic-observability stack, and the new client surface is one of the inputs that the next benchmarking round against Braintrust, LangSmith, and Portkey should weigh.

What's New in Arize Phoenix 17.19.0

Arize Phoenix 17.19.0, released 2026-07-06, is the latest drop on the 17.x weekly cadence and lands a small but high-leverage pair of features: a real trace-tree search in the trace explorer, and a consolidated account menu in the side nav. The release is intentionally tight in surface area — two PRs, no behavior changes elsewhere — which is the right shape for the post-17.18.0 cadence where the week-over-week drops are landing as polish rather than platform-level additions. The headline changes:

• App: trace tree search (#14074) — The trace tree (the left-rail tree view that renders spans nested under their parent) now has a real search input. Until 17.19.0, the only way to navigate a long tree was to scroll-and-eyeball, which on a deeply nested agent trace (50+ spans under a single root) was effectively unusable for finding a specific span. 17.19.0 ships a search input that filters the tree by span name, span kind, or attribute substring, so an investigator can punch in tool:sql_query and see every SQL-tool span in the tree without scrolling. For teams running the trace tree as the primary triage surface (the pattern the agentic observability guide covers for production agent debugging), 17.19.0 is the line where the tree becomes a usable filterable surface rather than a visualization, and the search-to-span interaction drops out as one of the highest-leverage micro-fixes in the 17.x line so far. Pairs naturally with the 17.17.0 shift-click range selection on the spans table — once you have filtered the tree down to the relevant subset, the matching rows in the spans table are the obvious bulk-action target. For the eval-loop angle on the same shape — finding the spans that match a specific failure signature so an evaluator can bulk-annotate them — the hallucination-detection production playbook walks through the labeling patterns that the trace-tree search now makes one-keystroke to apply.
• App: consolidated account menu in the side nav (#14070) — The user-account surface (profile, theme, sign-out, version-status badge, and the per-deployment switcher) used to be split across two menus in the side nav. 17.19.0 collapses them into a single consolidated account menu at the top of the side nav. The change is small in surface area but shows up as a noticeable reduction in the "where is the sign-out button" friction for new operators, and as a cleaner nav structure for tenants that have multiple deployments pinned. For teams operating Phoenix in a multi-deployment pattern (the same pattern the 17.12.0 user.id attribution and the 2.10.0 prompt-route-contexts work enables), the consolidated menu is the user-facing complement to those server-side changes.

No breaking changes. Treat 17.19.0 as a normal minor upgrade on the 17.x line — both features are pure additions on existing surfaces, no data-path or auth changes, and the trace-tree search is the single most visible win for on-call investigators who have been scrolling long trees by hand. Upgrade via pip install arize-phoenix>=17.19.0 or pull the matching container. If you have not been on 17.x yet, the safe upgrade path is 17.8.1 → 17.19.0 in one step; the trace-tree search and the consolidated account menu are the visible wins, but every prior 17.x release adds additive surfaces that compound into the same triage workflow. The 17.18.0 disclosure-arrow consistency fix carries forward unchanged, so the trace tree and the spans table render with the same chevron affordance end-to-end.

What's New in Arize Phoenix 17.18.0

Arize Phoenix 17.18.0, released 2026-07-04, is the latest drop on the 17.x weekly cadence and lands one focused UI consistency fix. The release is tiny in surface area — a single feature PR — but the change touches a surface every evaluator hits on every review pass. The release ships alongside arize-phoenix-client 2.12.0 on the same cadence as the rest of the 17.x line. Headline change:

• App: consistent disclosure arrows (#14066) — A small but very visible UI consistency fix. Until 17.18.0, the disclosure arrows (the small chevrons that expand and collapse detail rows in the trace table, the prompt library, and the dataset viewer) used inconsistent glyphs depending on which view rendered them, which on a long incident review pass forced the eye to re-parse the same affordance three different ways. 17.18.0 collapses to a single chevron style across every disclosure surface. For teams that live in the trace table during incident triage, this is the kind of papercut fix that compounds — the review pass gets measurably faster when the affordances stop changing shape.

No breaking changes. Treat 17.18.0 as a normal patch-equivalent upgrade on the 17.x line — the disclosure-arrow change is purely visual and additive, no behavior change on any data path. Upgrade via pip install arize-phoenix>=17.18.0 or pull the matching container. The release pairs with arize-phoenix-client 2.12.0 on the same cadence as the rest of the 17.x line, so if you are pinning both, bump them together. If you have not been on 17.x yet, the safe upgrade path is 17.8.1 → 17.18.0 in one step; nothing intermediate requires a hold.

What's New in Arize Phoenix 17.17.0

Arize Phoenix 17.17.0, released 2026-07-04, is the day's earlier drop on the 17.x weekly cadence and lands two table-interaction features plus a one-line range-selection guard. The release is small but high-leverage for any team running an incident-review pass on a long trace table or scrubbing through span filters — the two features are exactly the ergonomic wins that show up as faster review passes and less copy-paste into spreadsheets. Headline changes:

• App: shift-click range selection in tables (#14060) — Shift-click now selects a contiguous range of rows in the trace table and the spans table. Until 17.17.0, row selection in the trace table was strictly checkbox-by-checkbox, which on a triage pass that wanted to operate on "all the rows between the alert-fired span and the user-visible error" meant clicking each checkbox by hand. 17.17.0 ships the standard shift-click range pattern that every other multi-select table surface has had for a decade. The follow-up bug-fix PR (#14063) restricts the range to same-depth rows, so a shift-click that crosses a tree boundary does not grab the wrong set.
• UI: recent searches in the span filter typeahead (#14062) — The span filter typeahead now surfaces recent searches alongside the suggestions. Until 17.17.0, re-applying the same filter (e.g. "show me all spans tagged tool:sql_query in the last 24h") meant retyping the filter each time. 17.17.0 persists the recent searches per-user and surfaces them at the top of the typeahead. A small but compounding ergonomic win for on-call engineers who scrub the same filter patterns repeatedly across a shift.

No breaking changes. Treat 17.17.0 as a normal patch-equivalent upgrade on the 17.x line — both features are pure additions on existing surfaces, and the range-selection guard is a safety fix on top of the new behavior. Upgrade via pip install arize-phoenix>=17.17.0 or pull the matching container. If you have not been on 17.x yet, the safe upgrade path is 17.8.1 → 17.17.0 in one step; the shift-click range and recent-searches typeahead are the visible wins for the trace-table review pass.

What's New in Arize Phoenix 17.16.0

Arize Phoenix 17.16.0, released 2026-07-04, is the day's earliest drop on the 17.x weekly cadence and lands a substantial feature set: agent authentication discovery, baseline tagging for experiments, an error column on spans and traces tables, REST endpoints for annotation configs and dataset labels, the first eval-code metrics in the JS client (precision / recall / F-score), and a small pile of UX polish. The release is large in PR count — eleven features and five bug fixes — but each is a pure addition that does not change existing behavior. The arize-phoenix-client 2.12.0 SDK ships the same day, so server and client move together on this release. Headline changes:

• Auth: agent authentication discovery via auth.md (#13864) — The PXI agent (and any other Phoenix-managed agent surface) can now discover its authentication configuration from an auth.md file in the working directory, rather than requiring every team to hand-roll the OIDC discovery call. The auth.md convention is a small, well-scoped schema — issuer URL, client ID, audience, and the scopes the agent needs. For teams wiring PXI into a CI runner or an internal SRE tool (the workflow the MCP enterprise authorization 2026 guide covers), 17.16.0 is the line where the auth side stops being a per-environment hand-edit and starts being a checked-in file.
• Experiments: baseline tagging (#13991) — A long-asks-for feature: experiment runs can now be tagged as "baseline" so the experiment-comparison view knows which run to anchor the diff against. Until 17.16.0, baseline selection was an out-of-band convention (the team remembered which run ID was the baseline); 17.16.0 ships a first-class tag so the comparison view auto-picks the right anchor. For teams running a regression suite that compares every run against a known-good baseline (the workflow the LLM evaluation frameworks guide walks through), this is the line where the baseline is enforced by the tool rather than by team discipline.
• API: assign annotation configs to projects over REST (#14028) — The REST API gains endpoints to assign annotation configs to projects, which closes a gap where the UI was the only way to wire an annotation config to a project. For teams scripting Phoenix setup in Terraform or in a config-as-code pipeline, 17.16.0 is the line where annotation configs are declaratively managed like the rest of the Phoenix surface.
• App: error column on spans and traces tables (#14052) — A new column on the spans table and the traces table surfaces the error state of each row at a glance. Until 17.16.0, surfacing error spans required opening each row and reading the span detail; on a triage pass against a long trace, that meant opening ten rows before you found the failing one. 17.16.0 puts the error indicator on the row itself, so a triage pass can scan-and-sort by error without the click-through. Pairs with the shift-click range selection that 17.17.0 ships (same day, separate release) — once the error column is visible, the range-select path lets you bulk-tag every error span in a single action.
• App: version count, latest version, and version tags columns on the prompts table (#14051) — The prompts table gains three columns that summarize the version history of each prompt: the total version count, the latest version timestamp, and any tags attached to the latest version. Until 17.16.0, the prompts table was a flat list of prompt names, and surfacing the version history required clicking into each prompt. The new columns make it possible to identify stale or untagged prompts at a glance, which on a managed-prompt-library workflow (the pattern the LLM evaluation frameworks guide walks through) is the difference between a quick scan and a per-prompt investigation.
• CLI: annotation-config get, create, and update (#13968) — The phoenix-cli gains subcommands to manage annotation configs from the terminal. Same purpose as the REST endpoints above — declarative management of annotation configs — but on the CLI path for teams that prefer terminal-first workflows.
• JS: precision / recall / F-score code evaluators in phoenix-evals (#14004) — The JS eval client gains three classic classification metrics as code evaluators. Until 17.16.0, JS eval pipelines either had to implement these by hand or use an external library. 17.16.0 ships them in the standard library so a CI eval can declare "this eval passes if precision >= 0.9" without a custom implementation. Pairs with the LLM evaluation frameworks guide for JS-native eval pipelines.
• Server: dataset label REST endpoints + name_contains filter on GET /v1/projects (#14024, #14029) — Two REST surface additions. The dataset-label endpoints close a gap where labels could be applied via the UI but not via the API, so CI-driven labeling workflows now have a first-class path. The name_contains filter on the projects endpoint adds a server-side filter for project lookups by substring, useful when scripting Phoenix against a large project fleet.
• UI: dismissable version update notice on the side nav (#14056) — A small UX add: when a new Phoenix server version is available, a notice appears on the side nav, with a dismiss action so the operator can clear it once they have noted the upgrade. Closes a long-standing nag about silent version drift on long-running Phoenix instances.
• Bug fix: undo PXI annotation by clicking the active thumbs button (#14048) — Until 17.16.0, an annotation made via PXI's thumbs-up/thumbs-down could not be undone from the chat surface; the operator had to open the trace and clear the annotation by hand. 17.16.0 collapses the action into a toggle on the same thumbs button — click thumbs-up to set, click thumbs-up again to clear.
• Bug fix: admin-gate settings version status, stop caching failed fetches (#14058) — The settings page now admin-gates the version-status check (so non-admin operators cannot see whether a new server version is available, which leaks the deploy schedule), and stops caching the failed fetches so a transient fetch failure does not pin the version-status display to "checking" forever.

No breaking changes. Treat 17.16.0 as a normal minor upgrade on the 17.x line — every feature is additive, every bug fix is silent, and the auth.md discovery + the baseline-tagging + the error-column + the eval-code metrics are the four changes most likely to show up as visible UX wins. Upgrade via pip install arize-phoenix>=17.16.0 or pull the matching container. The release pairs with arize-phoenix-client 2.12.0 on the same cadence as the rest of the 17.x line, so if you are pinning both, bump them together. If you have not been on 17.x yet, the safe upgrade path is 17.8.1 → 17.16.0 in one step; the eval-code metrics in the JS client and the baseline-tagging are the two features most likely to motivate a faster jump.

What's New in Arize Phoenix 17.13.0

Arize Phoenix 17.13.0, released 2026-06-30, is the day's earlier drop on the 17.x weekly cadence and lands three features and four bug fixes that broaden the PXI eval-harness surface and tighten the cost ledger. The release is small in surface area but high-leverage for the teams that have standardized on Phoenix for the eval-CI loop: the pxi CLI gains a TUI (terminal UI) for investigators who do not want to keep a browser tab open, the phoenix-client gains a pytest plugin for eval CI, and the cost ledger's built-in model token prices are refreshed against the latest provider price cards. The release also emits DML events for PXI local traces, which closes a long-standing gap in the local-trace ingest path. Headline changes:

• CLI: pxi tui (#13905) — A terminal UI for the PXI agent. Until 17.13.0, the only way to drive a PXI session was through the Phoenix web UI, which is fine for office hours but a real friction point for on-call work in a terminal-only environment (SSH into a bastion, no browser available). pxi tui ships a TUI that runs in the terminal, with the same chat surface, tool-call rendering, and trace-explorer integration as the web UI. For teams that treat Phoenix as a first-line incident-response tool, 17.13.0 is the line where the PXI surface is actually usable from a pager session. The TUI also exposes the same role controls as the web UI, so the production auth posture is preserved end-to-end.
• Phoenix-client: pytest plugin for eval CI (#13874) — A new pytest plugin that auto-collects Phoenix eval files, runs them against the configured Phoenix server, and gates on pass/fail using pytest's standard exit-code semantics. Until 17.13.0, teams running Phoenix evals in CI had to hand-roll the test-runner integration, which meant a separate CI lane for evals and a parallel test harness. 17.13.0 drops Phoenix evals into the same pytest tests/evals/ lane as the rest of the suite. For teams that have standardized on pytest (the canonical example in the LLM evaluation frameworks guide), 17.13.0 is the line where the eval-CI loop is a one-line addition to the existing CI matrix rather than a parallel system. The same capability lands in arize-phoenix-client 2.11.0 the same day, so the server-side pytest plugin and the client-side pytest plugin move together.
• Pydantic-AI: simplify turn output instrumentation (#13904) — A Pydantic-AI integration cleanup that simplifies the per-turn output instrumentation path. Until 17.13.0, the Pydantic-AI integration was instrumenting each model turn with a verbose envelope that bloated the trace payload. 17.13.0 collapses to a minimal envelope, which on a long multi-turn agent run is a 20-30% reduction in trace storage cost. The integration is a no-op behavior change for downstream trace consumers — the spans still carry the same logical data, just with less per-span overhead. Pairs with the AI operational debt guide's "trace storage cost" callout — on a Phoenix instance that retains traces for 90 days, this is the line where the storage line item on the bill drops.
• Cost: update built-in model token prices (#13935) — The built-in cost map refreshes against the latest provider price cards. Until 17.13.0, the cost rollup was based on price cards that were up to a few weeks stale, which on a model with a recent price change (the new Claude or GPT snapshots that ship mid-month) showed a few percent drift from the real provider bill. 17.13.0 closes the drift. If your cost dashboard reconciles against the provider invoice, expect a one-day bump on the day of the upgrade as the refreshed price cards flow through.
• Deps: update arize-phoenix-client to 2.10.0 (fc1a3df) — A dependency bump to align the server with the 2.10.0 client line (which the 2.10.0 release of the same day introduced). If you are running the bundled server+client container, the bump is automatic; if you are running them separately, confirm both pins are at >= 2.10.0 to pick up the direct server agent endpoint wrapper and the session context propagation.
• Bug fix: emit DML event for PXI local traces (#13936) — A local-trace ingest fix: until 17.13.0, PXI invocations that ran against a local Phoenix instance (the self-hosted pattern) were not emitting the DML events that downstream trace consumers expect. The missing DML events caused a class of "why is my PXI trace not showing up in the trace explorer" tickets on the on-call queue. 17.13.0 emits the events, so local PXI traces are visible in the same surfaces as server-side PXI traces.
• Bug fix: playground guard against empty dataset versions array (#13908) — The Phoenix playground was crashing on datasets with an empty versions array (a class of dataset that gets created when a dataset is imported but never versioned). The crash surfaced as a 500 on the playground load, with no recovery without a manual dataset re-import. 17.13.0 guards the empty-array case so the playground renders an empty-state instead of a 500.
• Docs: pytest/vitest/jest integration references added to phoenix-evals (#13942) — A docs-only addition: the phoenix-evals reference now links to the pytest, vitest, and jest integration entry points. The new docs are the user-facing companion to the pytest plugin — they walk through authoring an eval, running it via the new pytest plugin, and gating on the result in CI.

No breaking changes. Treat 17.13.0 as a normal minor upgrade on the 17.x line — the pxi tui, the pytest plugin, the pydantic-ai simplification, and the cost-map refresh are all additive. Upgrade via pip install arize-phoenix>=17.13.0 or pull the matching container. The pxi tui and the pytest plugin are the two features that move the needle the most for production teams; the cost-map refresh is the one to verify on the way up if you are tracking cost-attribution accuracy at the percent level. The release pairs with arize-phoenix-client 2.11.0 on the same day, so the server and client move together — if you are pinning both, bump them in lockstep. If you have not been on 17.x yet, the safe upgrade path is 17.8.1 → 17.14.0 in one step; there is no intermediate release you need to hold on. The PXI session-context work from 2.10.0 carries forward, and the 17.14.0 Anthropic prompt caching is the single biggest PXI cost-control change in the 17.x line so far.

What's New in Arize Phoenix 17.12.0

Arize Phoenix 17.12.0, released 2026-06-25, is the day's drop on the 17.x weekly cadence and the release where the Phoenix Intelligence (PXI) agent becomes addressable as a first-class HTTP resource: there is now a dedicated server agent endpoint, user.id can be attached to PXI traces as opt-in attribution, and the JS client gains a CI-friendly eval testing API. The release also ships five agent-surface bug fixes (bashkit summaries, subagent border de-duplication, the PXI logo shrink regression, empty subagent message parts, and PXI draft-input persistence across panel remounts), one retention fix, and a docs entry for the release notes themselves. None are breaking; the new agent surfaces are additive and gated by existing role controls. Headline changes:

• Agents: direct server agent endpoint (#13896) — The Phoenix Intelligence agent is now addressable via a dedicated server endpoint, separate from the chat surface that the PXI REST skill uses internally. For teams building custom integrations against the PXI surface — e.g. an internal SRE tool that wants to spin up a PXI session from a non-Phoenix UI — the server endpoint is the API to wire against rather than scraping the chat HTTP path. The endpoint is gated by the same role controls as the chat surface; nothing new to configure.
• Agents: opt-in user.id attachment to PXI traces (#13876) — PXI can now attach a user.id attribute to the traces it generates, as opt-in attribution. Until 17.12.0, every PXI-spawned trace ran with an unattributed user, which made per-investigator cost attribution impossible when multiple on-call engineers share a Phoenix instance. With 17.12.0, the agent picks up the user.id from the chat session context and writes it to the trace, so a trace explorer view that filters by user.id now surfaces "this PXI investigation was run by Sergio" rather than just "PXI ran 47 invocations." Particularly useful for chargeback workflows where you want to attribute the agent's own LLM spend to the operator who triggered it.
• Experiments: copyable trace ID in the trace details dialog header (#13887) — A small but high-leverage UX add: the trace details dialog now shows the trace ID as a copyable field in its header. Until 17.12.0, getting a trace ID out of the dialog required clicking into the trace and copying it from the URL bar. Now the field is one click away, which is the same pattern that the 17.3.0 PXI copy-trace-ID chat action shipped for the chat surface — 17.12.0 closes the symmetric case for the experiments/trace UI. Pairs naturally with the agentic observability guide when you are joining Phoenix trace IDs to APM spans or alert-rule dedup keys.
• JS: CI eval testing API added to phoenix-client (#13877) — The JavaScript client gains a CI eval testing API that mirrors the Python eval runner. Until 17.12.0, teams running JS-based eval pipelines (Node, Deno, browser-side eval harnesses) had to hand-roll the eval-runner HTTP path against Phoenix's REST surface. 17.12.0 ships a typed JS wrapper so a CI job can author an eval in TypeScript, run it against a dataset, and gate on pass/fail in the same way the Python SDK has supported since 17.4.0. If you have been holding off on Phoenix because your eval pipeline is JS-native, 17.12.0 is the line where the tooling tax disappears.
• Agents: stream call_subagent progress (#13885) — The PXI agent now streams call_subagent progress rather than blocking until the subagent returns. For a long-running subagent invocation (the kind that previously looked frozen in the chat surface), the parent now emits incremental progress markers so the operator sees the subagent is alive and making forward progress. Combined with the 17.9.0 per-tool-call rendering, this is the second half of the "PXI chat surface actually shows what is happening" pattern.
• Bug fix: add summaries to bashkit bash tool (#13897) — The server-side bash tool introduced in 17.9.0 now emits execution summaries (duration, exit code, key stdout/stderr markers) rather than just dumping raw output. Pairs with the 17.9.0 per-tool-call rendering and the AI operational debt guide's "PXI owns the regression suite" workflow — when the bash tool is invoked from a PXI investigation, the chat now summarizes the shell outcome the same way it summarizes a trace lookup.
• Bug fix: prevent double-bordered subagent tools and auto-open (#13900) — Subagent tool entries in the PXI chat surface used to render with a doubled border and would auto-open on first render, cluttering long investigation sessions. 17.12.0 collapses to a single border and respects the user's manual open/close state. Visual cleanup, but the kind that compounds across an hour-long incident triage.
• Bug fix: prevent PXI logo from shrinking (#13899) — A regression where the PXI logo would scale down at certain chat widths. Visual cleanup that lands alongside the border fix; together they keep the chat surface looking intentional rather than degraded.
• Bug fix: hide empty subagent message parts (#13895) — Subagent invocations that returned empty message parts (e.g. a tool call with no output) used to render as visible-but-blank rows in the chat. 17.12.0 suppresses empty parts entirely. Minor UX win; the chat now reads cleaner during a long PXI investigation.
• PXI: preserve draft input across panel remounts (#13910) — When the PXI chat panel remounts (e.g. you collapse and re-expand the panel, or the panel state resets after a route change), any draft input the operator was composing used to be lost. 17.12.0 preserves the draft across remounts, matching the muscle memory of every chat surface that has ever shipped.
• Retention: remove unbatched RETURNING clause from delete_traces (#13909) — A backend correctness fix: the delete_traces path was using an unbatched RETURNING clause that could exhaust memory on large trace deletions. 17.12.0 removes the unbatched clause so retention sweeps run in linear memory. If you run a retention policy that periodically prunes traces (the pattern the AI operational debt guide flags as a high-leverage cost-control move), 17.12.0 is the line that keeps those sweeps stable at scale.
• Docs: Phoenix release notes entry added (#13889) — Docs-only: a release-notes entry for 17.12.0 itself, which is the self-referential entry that ties the 17.x cadence docs into a single navigable surface.

No breaking changes. Treat 17.12.0 as a normal minor upgrade on the 17.x line — the server agent endpoint, the opt-in user.id trace attribution, the JS CI eval testing API, and the streamed call_subagent progress are all additive, and the bashkit summaries are a UX improvement on the 17.9.0 bash tool rather than a behavior change. Upgrade via pip install arize-phoenix>=17.12.0 or pull the matching container. The delete_traces retention fix is the only behavior change worth verifying on the way up if you run large trace-pruning sweeps — confirm your retention cron still completes within its window after the upgrade. For teams running PXI as a shared agent surface across an on-call rotation, the opt-in user.id trace attribution is the feature that finally makes per-investigator cost reporting possible; pair it with the MCP enterprise authorization guide if you are scoping PXI access through an MCP allow-list. If you have not been on 17.x yet, the safe upgrade path is 17.8.1 → 17.12.0 in one step; the JS CI eval testing API is the single biggest reason for JS-native eval pipelines to upgrade, and the streamed call_subagent progress is the reason any team running multi-step PXI investigations should upgrade.

What's New in Arize Phoenix Client 2.10.0

Arize Phoenix client arize-phoenix-client 2.10.0, released 2026-06-26, is a client-only drop that decouples the SDK version from the server version, so the eval and CI surface moves forward on its own cadence rather than waiting for the next server release. The release body lists five features and no breaking changes — every addition is opt-in and gated by the same role controls as the 17.x server line. Headline changes:

• Agents: direct server agent endpoint (#13896) — A typed client wrapper around the new server agent endpoint that 17.12.0 introduced. Until 2.10.0, teams building custom PXI integrations from a non-Phoenix UI (an internal SRE tool, a Slack bot, a custom eval runner) had to hand-roll the HTTP call against the chat surface. 2.10.0 ships a typed client method that targets the server endpoint directly, with role-based auth handled by the same middleware the chat surface uses. For teams that want to wire the PXI agent into a CI runner or a chatops surface without scraping the chat HTTP path, this is the SDK change that makes it a one-liner.
• Agents: session context (#13727) — The client now propagates a session-context payload that the PXI agent (server-side) carries across a multi-turn investigation. The client API mirrors the server feature: you pass a session token once per investigation, and the agent retains the trace context, the failed-tool history, and the working hypothesis across messages. For long, multi-message agent runs (the kind production incidents actually generate), session context is the change that makes the agent usable end-to-end without the operator re-explaining the trace on every follow-up. Pairs with the agentic observability guide when you are correlating PXI session output with broader agent-trace analytics.
• Agents: experiment editing and eval skills (#13704) — The client surface gains typed methods for editing experiment runs and authoring eval skills. The server-side capability landed in 17.6.0; 2.10.0 ships the matching client wrapper so JS-native and Python eval pipelines can call the same surface without scraping the Phoenix UI. The combination of dataset-management (17.3.0), evaluator editing (17.4.0), and experiment editing (2.10.0) is what makes the "PXI owns the regression suite with human approval" workflow defensible end-to-end: every write the agent makes has a typed client entry point, every write is gated by an Accept/Reject card on the server side, and the eval pipeline can run the full loop without a human transcoding the workflow into UI clicks.
• Phoenix-client: pytest plugin for eval CI (#13874) — A new pytest plugin that wires Phoenix evals into the standard pytest runner. Until 2.10.0, teams running Phoenix evals in CI had to hand-roll the test-runner integration. 2.10.0 ships a pytest plugin that auto-collects eval files, runs them against the configured Phoenix server, and gates on pass/fail using pytest's standard exit-code semantics. For teams that have standardized on pytest as the test harness (and the LLM evaluation frameworks guide uses pytest as the canonical example), 2.10.0 is the line where Phoenix evals drop into the same CI pipeline as the rest of the suite — no separate eval runner, no parallel CI lane, just a pytest tests/evals/ alongside pytest tests/unit/.
• PXI: prompt route contexts (#13834) — A client API for attaching route-context metadata to PXI invocations. The use case is multi-deployment Phoenix instances where the same agent runs against different route roots; the route context lets the client disambiguate which deployment a PXI session is targeting, so the traces, eval runs, and session state land in the right Phoenix project. For teams operating Phoenix in a multi-tenant pattern (a shared instance serving multiple product surfaces), this is the change that keeps the eval and trace attribution clean across deployments.

No breaking changes. Client 2.10.0 is decoupled from the server version — you can upgrade the client without touching the server. The recommended posture is to upgrade the client to 2.10.0 on its own cadence (the SDK release notes target a faster cycle than the server's weekly minor cadence) and to hold the server at the most recent stable 17.x line that has been validated in your environment. If you are running the JS client, the matching CI eval API landed in 17.12.0 and the Python-side pytest plugin in 2.10.0 is the symmetric Python addition. Upgrade via pip install arize-phoenix-client>=2.10.0 or npm install arize-phoenix-client@^2.10.0; no server upgrade is required. For teams that have standardized on Phoenix as the trace backbone for a multi-tool deployment (the surface the open-source LLM monitoring stack guide walks through), 2.10.0 is the client release that makes the eval-harness end-to-end loop a defensible production pattern rather than a slide-deck idea.

Should you upgrade to Phoenix 17.12.x or client 2.10.0?

The short answer is yes for almost every team. There are no breaking changes across 17.9.0, 17.10.0, 17.11.0, 17.12.0, or client 2.10.0 — all five are pure additions on the 17.x server line and the 2.10.x client line, and the 17.9.0 server-side bash tool is opt-in via an explicit config flip (PHOENIX_AGENTS_DISABLE_BASH=1 to disable it). The three server features that move the needle the most are the 17.12.0 server agent endpoint (lets you wire PXI from non-Phoenix UIs), the 17.12.0 opt-in user.id trace attribution (closes the loop on per-investigator cost attribution when multiple on-call engineers share a Phoenix instance), and the 17.11.0 agent-readable eval-harness failure reports (closes the loop on PXI owning the regression suite end-to-end). The two client features that move the needle are the 2.10.0 pytest plugin for eval CI (drops Phoenix evals into the same CI lane as the rest of the pytest suite) and the 2.10.0 direct server agent endpoint wrapper (typed client method for building custom PXI integrations from a non-Phoenix UI). If you are on 17.8.x, the safe upgrade path is to pip install arize-phoenix>=17.12.0 in one step; there is no intermediate release you need to hold on. If you are on 17.5.x or earlier, the upgrade goes through 17.8.1 first (the calendar-picker and the time-range URL state features from that release are the ones that compound the most for on-call), then to 17.12.0. The one team that should hold and read the release notes is anyone running Phoenix against a custom Prometheus scrape config that pins the exact job_name path on a FastAPI 0.137 backend — confirm the metrics endpoint is back to a single-prefix path after the upgrade (the 17.8.1 fix is what makes that stable across the 17.9–17.12 cadence). The other team that should pin a specific version is anyone in a regulated environment who does not want server-side agent bash on the chat surface — pin to 17.8.1 and explicitly set PHOENIX_AGENTS_DISABLE_BASH=1 as soon as 17.9.0 lands, or stay on 17.8.x and plan the upgrade once you have a deliberate policy decision on agent bash.

Weights & Biases Weave — Experiment Tracking Grows into LLM Observability

Weights & Biases built its name in traditional ML experiment tracking — hyperparameter sweeps, training curves, model versioning. Weave is their move up the stack into LLM-native observability, and it benefits enormously from W&B's existing infrastructure. If your team already uses W&B for model training, Weave is a natural extension.

Weave's strengths mirror W&B's core value proposition: best-in-class experiment tracking and collaboration tools, now applied to prompts and LLM chains. You get automatic versioning of prompts, datasets, and model outputs, with a UI that data scientists already know how to use. The integration story is particularly strong — Weave instruments LangChain, LlamaIndex, and OpenAI natively, with OpenTelemetry export for everything else.

The evaluation story is where Weave differentiates most clearly from pure-play observability tools. Because W&B already manages your model training experiments, Weave can correlate prompt performance with downstream model quality metrics — something no other LLMOps platform can do natively. If you are fine-tuning models and need to understand how prompt changes affect fine-tuned model performance, this is a unique capability. The operational side of that workflow — versioned datasets, eval gating in CI, the metrics you monitor on a fine-tuned LoRA serving in production — is covered in the fine-tuning in production guide, which pairs naturally with Weave's training-side correlation story.

Key capabilities

• Automatic prompt and dataset versioning with diffs
• Correlation of prompt changes with downstream model training metrics
• Full tracing for LangChain and LlamaIndex chains
• OpenTelemetry export for custom tooling
• Collaborative annotation and evaluation workflows
• Integrates with existing W&B experiment tracking infrastructure

What it does not do well

• Standalone evaluation without an existing W&B workflow — teams not already using W&B pay the full tooling tax
• Native guardrails — completely absent
• Cost tracking is an afterthought, not a first-class feature
• Self-hosted option — cloud only, which creates data governance issues for regulated environments

Pricing

Weave is free for individuals and small teams. Team plans with collaboration features start at $15/user/month. Enterprise plans with SSO, audit logs, and SLA guarantees are available on request.

Best for

Teams already invested in W&B for model training who want to extend their existing observability workflow into LLM evaluation without adopting a new tool.

Segment B: The Lightweight and Agent-First Tools

LangSmith — LangChain-Native Tracing with Deep Agent Support

LangSmith is the observability layer purpose-built for LangChain applications. If you are building with LangChain, LangSmith is not an optional add-on — it is the platform that makes LangChain production-ready. The tight integration means zero-configuration tracing for LangChain chains: every node in your chain is automatically traced, every latency measured, every token counted.

For agentic workflows specifically — where a language model drives a loop of tool calls, memory updates, and conditional branching — LangSmith is the clear leader. Multi-step agent traces can be visualized as waterfalls, showing exactly where time is being spent and where errors occur. This is not a trivial thing to build well, and LangSmith's implementation is genuinely best-in-class for agent tracing as of 2026.

Outside of the LangChain ecosystem, LangSmith is less compelling. Direct API support for non-LangChain applications exists, but it requires manual instrumentation that most teams find clunky compared to the zero-config LangChain integration. If you are not using LangChain, this is a significant consideration.

Key capabilities

• Zero-config tracing for LangChain chains — works immediately without instrumentation
• Best-in-class agent workflow visualization — waterfall traces for multi-step agent loops
• Dataset and evaluation runner with automated regression testing
• Prompt playground with online eval before deployment
• Rate limiting, retry configuration, and cost attribution per chain

What it does not do well

• Non-LangChain instrumentation — requires manual SDK setup, significantly more work than Braintrust or Phoenix
• Guardrail features — no PII detection or prompt injection prevention
• Self-hosted option — cloud only
• Strong vendor lock-in to LangChain ecosystem

Pricing

Free tier with 50,000 traced runs/month. Team plans at $80/user/month with unlimited traces and evaluation features. Enterprise plans with custom rate limits and SLA guarantees.

Best for

Teams building production LangChain applications who need deep agent tracing and are willing to accept the LangChain lock-in for that capability.

Promptfoo — CLI-First Evaluation for Developer Teams

Promptfoo is the anti-SaaS platform. It runs entirely in your CI pipeline or local development environment, defines everything in YAML, and produces evaluation reports as artifacts. If you want evaluations that are code, versioned in git, and runnable without a web UI, Promptfoo is purpose-built for that workflow.

The platform's evaluation model is rigorous: you define test cases with expected outputs, run your prompts against them, and get pass/fail results with score breakdowns. RAGAS support, LLM-as-judge, and custom scorers are all supported. The CLI output is designed for CI integration — exit codes, JSON reports, diff views — which makes it trivial to gate deployments on eval pass rates.

Promptfoo does not have a hosted tracing component. For teams that need live request tracing, Promptfoo pairs well with a separate observability tool like Phoenix or Helicone. The two responsibilities — evaluation and tracing — are cleanly separated, which is actually a healthy architectural choice.

Key capabilities

• CLI-first evaluation — runs in CI, outputs JSON reports, exit codes for gate-keeping
• YAML-defined test suites — versionable, diffable, reviewable in PRs
• RAGAS, LLM-as-judge, and custom scorer support
• Prompt playground with side-by-side comparison
• Self-hosted, open source, no data leaves your infra

What it does not do well

• Request tracing — no live observability, purely an evaluation tool
• Guardrails or security features
• Collaborative workflows — designed for individual/CLI use, not team annotation
• Cost tracking — absent

Pricing

Fully open source and free. Promptfoo also offers a cloud hosted version for teams that want collaborative features and hosted eval history without self-hosting. Cloud pricing starts at $25/user/month.

Best for

Developer teams that want rigorous evaluation integrated into CI/CD without adding another SaaS dependency. Excellent when paired with a separate tracing platform.

Segment C: The Guardrail and Security Specialists

Guardrails AI and NeMo Guardrails — The Safety Layer

LLM security and guardrails is a category that has exploded in importance as production LLM applications have become targets for prompt injection, data exfiltration, and jailbreaking. Two platforms dominate the open-source guardrail space: Guardrails AI and NVIDIA NeMo Guardrails.

Guardrails AI provides a Python library for defining output constraints — structure enforcement (JSON schema, regex patterns), quality metrics (length limits, format checks), and content moderation (PII detection, toxicity filtering). The platform integrates at the application layer, wrapping LLM calls with constraint validation. It is lightweight and easy to add to an existing stack, but it requires application code changes to instrument properly.

NVIDIA NeMo Guardrails is the more comprehensive solution for teams that need serious security posture. It supports topical guardrails (keeping conversations within defined topics), jailbreak detection, output PII filtering, and a rails definition language (RDL) for expressing constraints declaratively. NeMo is significantly heavier than Guardrails AI — it is designed for enterprise deployments where security is a hard requirement rather than a nice-to-have.

Key capabilities (Guardrails AI)

• Output constraint enforcement — JSON schema, regex, format validation
• PII detection and filtering
• Content toxicity filtering
• Lightweight, Python-native integration
• Open source

Key capabilities (NeMo Guardrails)

• Topical guardrails — force conversations to stay within defined topic boundaries
• Jailbreak detection and prevention
• Output PII filtering with named entity recognition
• Rails definition language for declarative constraint authoring
• Enterprise-grade security posture with audit logging

Pricing

Both platforms are open source and free to self-host. Guardrails AI has a hosted cloud option for teams that want managed infrastructure. NeMo Guardrails is NVIDIA-backed enterprise software — free to use, but with enterprise support contracts available for organizations that want SLA guarantees.

Best for

Guardrails AI for teams that need lightweight, Python-native output validation. NeMo Guardrails for enterprise deployments with serious security requirements, particularly those already in the NVIDIA ecosystem.

How do the six LLMOps platforms compare head-to-head?

The Verdict: Choosing the Right Platform

There is no single best LLMOps platform. The right choice depends on your primary pain point, your existing tooling, and your stage of LLMOps maturity. Here is the honest decision framework:

• Choose Braintrust if evaluation is your primary concern and you want to build a rigorous prompt regression testing practice. It is the best platform for teams that treat prompts as code.
• Choose Arize Phoenix if you need deep observability, embedding drift detection, and the ability to self-host. It is the clear winner for RAG pipeline debugging.
• Choose W&B Weave if your team is already using Weights & Biases for model training and you want a single platform for both training and production LLM observability.
• Choose LangSmith if you are building with LangChain and need best-in-class agent tracing. Accept the lock-in if that trade-off makes sense for your team.
• Choose Promptfoo if you want CLI-first evaluation that lives in your git history and CI pipeline. Best when paired with a separate tracing platform.
• Add Guardrails AI or NeMo Guardrails if you have a customer-facing LLM application and security is a hard requirement. Neither replaces a full LLMOps platform — they complement an existing choice.

Most production teams will end up using two or three of these tools in combination. The common pattern: Braintrust for evaluation + Phoenix for RAG observability + Guardrails AI for output validation. LangChain teams add LangSmith on top. The stack is not one-size-fits-all, and that is fine — the platforms are genuinely complementary rather than overlapping. If you need a runtime gateway that sits in front of all of these, LiteLLM production monitoring covers the unified layer; for the broader self-hosted pipeline, the open source LLM monitoring stack guide shows how Phoenix slots into a wider Grafana/Prometheus/OTel deployment.

Conclusion

The LLMOps category has matured enough that there are real best-in-class tools for each sub-problem. The teams that struggle are the ones who pick a single platform expecting it to do everything. The teams that win are the ones who match tools to problems: evaluation here, tracing there, guardrails at the edge. This guide is the starting point for that decision, not the ending point.

For monthly deep dives into the evolving LLMOps landscape, infrastructure patterns for production AI, and FinOps strategies for AI teams, subscribe to The Stack Pulse — the newsletter for engineers building production AI infrastructure.