Agents-OSS
EN
Submit

Langfuse vs Phoenix

Both are catalogued under Observability & Evals. The figures come from the GitHub API; the assessments are ours.

LangfuseTracing, prompt management and evaluation for LLM applicationsOfficialMITPhoenixTracing and evaluation that runs inside a notebookOfficialSource-available

At a glance

At a glanceLangfusePhoenix
LicenseMITSource-available
LanguagesTypeScript, PythonPython, TypeScript
DeploymentSelf-hosted / Managed cloudSelf-hosted / Runs locally / Managed cloud
MaturityEstablishedEstablished
Stars33.2k11.1k
Star growth over the last 7 days+7 ★+2 ★
Forks3.6k1.1k
Open issues781922
Last commit15 Aug 202615 Aug 2026
ActivityActiveActive

What each one does

Langfuse

Records what an agent actually did — every call, tool invocation and cost — and turns those traces into evaluation datasets. The managed service runs the same codebase you can self-host with Docker Compose, so migrating in either direction stays cheap. Some enterprise features sit outside the MIT core; check which tier you need before committing.

Full entry →

Phoenix

Built on OpenTelemetry, so traces are portable rather than locked to one vendor, and it will run locally next to the code you are debugging. Licensed under Elastic 2.0 — fine for internal use, restrictive if you intend to offer it as a managed service.

Full entry →

What you can do

Langfuse

  • Instrument an app function by function — Importing from langfuse.openai import openai captures each OpenAI call with its model parameters, and every function you wrap in @observe() is recorded as its own nested step — the README's main() and story() pair — so retrieval and agent code appears in the trace only once it is decorated too.
  • Version prompts outside your code — Prompt Management holds prompts centrally with version control, and caching on both server and client means fetching the current version adds no latency to your application.
  • Turn traces into test sets — Datasets build benchmarks for pre-deployment testing, scored with LLM-as-a-judge, code evaluators, manual labelling or collected user feedback.
  • Retry failures in the playground — From a bad result in a trace you can jump straight into the LLM Playground and re-run it against a different prompt or model configuration.
  • Self-host on your own infrastructure — docker compose up for a local instance, a Helm chart as the preferred production path on Kubernetes, and Terraform templates for AWS, Azure and GCP.

Phoenix

  • Instrument an app automatically — npx @arizeai/phoenix-cli setup (or px setup once Phoenix is installed) detects your framework and LLM provider, installs the matching OpenInference instrumentation and wires up trace export.
  • Run the platform locally — uvx arize-phoenix serve brings up the full platform with nothing installed, and the same build ships as a Docker Hub image and a Helm chart for cluster deployment.
  • Replay a captured LLM call — The Playground reruns a traced call with a different prompt, model or parameters, and prompt management keeps those changes under version control with tagging.
  • Measure changes as experiments — arize-phoenix-evals scores response and retrieval quality against versioned datasets, so a prompt or retrieval change is compared as a tracked experiment rather than by eye.
  • Query traces from a coding agent — The remote MCP server built into Phoenix exposes a /mcp endpoint that Claude Code, Cursor and other MCP clients can use to read traces, datasets and experiments.

Other comparisons