Skip to content
Development
Skill

/phoenix-cli

Debug LLM applications using the Phoenix CLI (`px`, from @arizeai/phoenix-cli). Fetch traces, spans, and sessions, annotate them, analyze errors, measure how often a failure or pattern occurs across traces, inspect datasets, review experiments, query annotation configs, and use

From plugin
phoenix
12k10 skills18 agents1 MCP

Claude Code

$ npx -y skills add arize-ai/phoenix --skill phoenix-cli --agent claude-code

SKILL.md

phoenix-cli.SKILL.md
name: phoenix-cli
description: Debug LLM applications using the Phoenix CLI (`px`, from @arizeai/phoenix-cli). Fetch traces, spans, and sessions, annotate them, analyze errors, measure how often a failure or pattern occurs across traces, inspect datasets, review experiments, query annotation configs, and use the GraphQL API. Use whenever the user works with a Phoenix instance from the terminal, or wants to measure or investigate something in Phoenix with the CLI.
license: Apache-2.0
compatibility: Requires Node.js (for npx) or global install of @arizeai/phoenix-cli. Optionally requires jq for JSON processing.
metadata:
  targets: "agents"
  author: arize-ai
  version: "3.5.0"

Phoenix CLI

Invocation

px <resource> <action>                          # if installed globally
npx @arizeai/phoenix-cli <resource> <action>    # no install required

The CLI uses singular resource commands with subcommands like `list` and `get`:

px trace list
px trace get <trace-id>
px trace annotate <trace-id>
px trace add-note <trace-id>
px trace delete <trace-identifier>
px trace-annotations delete
px span list
px span annotate <span-id>
px span add-note <span-id>
px span delete <span-identifier>
px span-annotations delete
px session list
px session get <session-id>
px session annotate <session-id>
px session add-note <session-id>
px session delete <session-id>
px session-annotations delete
px dataset list
px dataset get <name>
px dataset delete <dataset-identifier>
px experiment list
px experiment get <id>
px experiment delete <experiment-id>
px prompt list
px prompt get <prompt-identifier>
px prompt delete <prompt-identifier>
px project list
px project get <name>
px project delete <project-identifier>
px annotation-config list
px annotation-config get <identifier>
px annotation-config create
px annotation-config update <identifier>
px annotation-config delete <id>
px auth login
px auth logout
px auth status
px profile list
px profile show [name]
px profile create <name>
px profile use <name>
px profile edit <name>
px profile delete <name>
px api graphql <query>
px docs fetch
px setup
px self update

Every `delete` above is gated: it requires `PHOENIX_CLI_DANGEROUSLY_ENABLE_DELETES=true` in the environment and prompts for confirmation unless `-y`/`--yes` is passed (`px profile delete` is local-only and takes `--yes` without the env gate). Without the env var the command exits without deleting anything.

Setup

export PHOENIX_ENDPOINT=http://localhost:6006
export PHOENIX_PROJECT=my-project
export PHOENIX_API_KEY=your-api-key  # if auth is enabled

`PHOENIX_ENDPOINT` is the base URL for API access. It usually holds the same URL as `PHOENIX_COLLECTOR_ENDPOINT`; when only the collector variable is set, the CLI uses it for API access too.

For interactive local use, `px auth login` stores an OAuth session in the selected profile; the session acts with the permissions of the user who logged in. API keys take precedence over OAuth tokens when both are configured. OAuth access tokens are refreshed automatically for REST, GraphQL, and PXI requests, and rotated tokens are persisted to the selected profile.

Always use `--format raw --no-progress` when piping to `jq`.

`px setup` — onboarding

`px setup` connects the app in the current directory to a Phoenix deployment and writes `.env.phoenix` (mode 0600, gitignored). The interactive flow is for humans — it prompts, launches coding agents, and polls for traces. **From an agent, always pass `--no-input`:**

# Register only: connection + .env.phoenix, no source changes.
px setup --no-input --endpoint http://localhost:6006 --project my-app --format raw

Headless requires a clean git repo and, by default, stops after writing the files — it will not touch source unless you ask. If auth is enabled, also set `PHOENIX_API_KEY`. The project doesn't need to exist — Phoenix creates it on first trace. Missing inputs exit `3` with exact remediation; cancel exits `2`.

To also instrument the app, name the lane — headless has no prompt to pick one from, so `--instrument` requires `--agent`:

px setup --no-input --instrument --agent claude --yolo --format raw

`--yolo` matters: a background agent has no terminal to approve its edits on, so without it the run stalls until trace verification times out. `--language python` skips the agent's language detection. `--docs-mcp` connects the Phoenix docs MCP server to the hand-off agent (`claude mcp add` for claude, config-file merge for cursor/opencode; codex unsupported) and skips the `.px/docs` download — the agent searches docs on demand instead; any failure falls back to the download. `--no-docs-mcp` suppresses the interactive offer. `--format raw` prints `{"endpoint","project","files","instrumentation","tracesVerified","tracesUrl"}` — check `tracesVerified`, which is set only when the API confirmed a trace arriving, not when the agent claims it finished.

A run whose wait ran out with no trace exits `6`, not `0`: the configuration and edits are real, but tracing is not confirmed working. Treat that as a failure to report, not a success — and do not substitute the hand-off agent's own exit code or summary for the verdict. Registering without `--instrument`, and a human answering "verify later" at the timeout prompt, both exit `0`.

`tracesVerified` is `false` for a registration-only run too, so it alone can't tell "nothing to verify" from "no trace arrived". Read `verification` (`verified` / `notVerified` / `deferred`, absent when there was nothing to verify) when you need the difference.

Re-runnable slices, so an already-registered repo skips the questions:

px setup instrument --agent claude   # instrument + verify only
px setup skills                      # install the Phoenix coding-agent skills

`px setup mcp` — register the remote MCP server

Wire the Phoenix remote MCP server (`<endpoint>/mcp`) into a coding agent so it can query Phoen

Read more
@arize-ai
Ships withphoenix

AI Observability & Evaluation

12k10 skills18 agents1 MCP
Get the whole plugin

Stars on GitHub

Momentum

stars in total
12.1k
Star history of arize-ai/phoenix on GitHub, a chart by star-history.com

Other skills on phoenix.

evaluators
Skill

evaluators

Author or refine a Phoenix evaluator — code or LLM-as-a-judge — that scores a run's output. Trigger when the user wants to create…

More skills from other plugins.

brainstorming
Skill
Popular
Auto-invoked

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…

@obra@obraInstall Skill
accessibility
Skill
Popular
Auto-invoked

accessibility

Design, implement, and audit accessible UI to WCAG 2.2 Level AA across Web, iOS, and Android — semantic ARIA roles and labels,…

ecc2d293k
@affaan-m@affaan-mInstall Skill
compiler-commit
Skill
Popular

compiler-commit

Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits…

react2d252k
@facebook@facebookInstall Skill

Questions about phoenix-cli.

Which coding agents can use phoenix-cli?
phoenix-cli installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.