Three tools dominate LLM/agent observability right now, each built around a different bet: open self-hosting, eval-driven CI/CD, or OpenTelemetry portability. Here is what the pricing table does not tell you.
Every team building an agent hits the same wall around month two: the demo worked, the eval set looked fine, and then production traffic started producing outputs nobody can explain. A tool call returns malformed JSON on 2% of requests. A RAG pipeline starts citing the wrong document after a prompt tweak three deploys ago. Someone asks "why did the agent do that" and the honest answer is "we don't know, we didn't log it."
This is the gap LLM observability tools fill: capturing every prompt, tool call, retrieval, and score well enough that you can reconstruct what an agent actually did, not just what you hoped it did. Three tools dominate the conversation right now — Langfuse, Braintrust, and Arize Phoenix — and they're not interchangeable. Each one was built around a different bet on what matters most: open self-hosting, eval-driven CI/CD, or OpenTelemetry portability. The list prices don't compare cleanly because each bills on a different unit, and a feature-parity checklist misses the real differentiator, which is which workflow each tool was designed around first.
| Langfuse | Braintrust | Arize Phoenix | |
|---|---|---|---|
| License / hosting | MIT, self-host free with no feature gates | Proprietary SaaS only | Elastic License 2.0 (source-available), self-host free; managed tier is Arize AX |
| Free tier | 50k observations/mo, 2 users, 30-day retention | 1 GB data, 10k eval scores, unlimited users (credit-funded) | Self-host: unlimited, forever. Managed AX: 50k spans/mo at $50/mo flat |
| Entry paid tier | Core: $29/mo, 100k units included | Pro: $249/mo | AX: $50/mo (managed Phoenix) |
| Core design center | Prompt management + tracing + eval harness, balanced across all three | Eval-first — dataset/scorer/experiment loop, with tracing feeding it | OpenTelemetry-native tracing via OpenInference conventions |
| Instrumentation | Native SDKs (Python/JS/TS) plus OTel export | Native SDK, framework-agnostic wrappers | Pure OTel + OpenInference semantic conventions — vendor-neutral by design |
| CI/CD eval gating | Supported via SDK + eval API | Purpose-built: scorers run in CI, block merges on regression | Possible via Phoenix Evals, less turnkey |
| Notebook / research fit | Moderate | Moderate | Strong — runs in Colab, local Jupyter, no server required |
| Backed by | Acquired by ClickHouse (Jan 2026), unchanged self-host offering | $80M Series B (Feb 2026, led by Iconiq), $800M valuation | Arize AI, backend also powers Arize's ML monitoring product |
Prices and tier names shift fast in this market — check each vendor's pricing page before budgeting, and note that none of these numbers translate directly since Langfuse bills per "observation" (trace + spans + scores), Braintrust bills per span and eval score processed, and Phoenix's managed tier bills per span with self-hosting free and uncapped.
Langfuse's MIT license is the real headline — there's no asterisk, no feature gate that only unlocks on the paid tier, no "community edition" that's quietly missing the eval harness. Prompt versioning, release-channel tagging, LLM-as-judge scoring, and human annotation queues all ship in the free, self-hosted build. For a team with a "our data doesn't leave our VPC" requirement, this is close to the only real answer among the three.
The cost is operational. Langfuse's self-hosted stack needs PostgreSQL, ClickHouse, Redis, and S3-compatible object storage running together. ClickHouse in particular is not a "spin up a container and forget it" dependency at any real trace volume — replication, backup, and schema migration all become your team's job once you're past a few million traces a month. Langfuse Cloud exists precisely to take that off your plate, and its usage-based pricing (graduated down to $6/100k units past 50M units/month) is competitive against the alternative of paying an engineer to babysit ClickHouse. The January 2026 acquisition by ClickHouse itself — done alongside ClickHouse's own $400M Series D — reads less like a threat to the open-source promise and more like the obvious pairing: the company that makes the database Langfuse depends on now owns the project.
Braintrust's pitch is structural, not just feature-based: everything is organized around the eval loop — dataset, scorer, experiment — and tracing exists to feed that loop rather than to stand on its own as a debugging surface. If your team already treats evals as a first-class engineering artifact (versioned datasets, scorers checked into the same repo as the agent code, regressions blocking merges the way a failing unit test would), Braintrust's CI/CD integration is the most turnkey of the three: scorers run automatically in the pipeline, results get statistical-significance treatment, and a regression can hard-block a deploy.
The tradeoff is lock-in and cost model. There's no self-hosted Braintrust — it's SaaS only, which is a nonstarter for teams with strict data-residency requirements. And because Braintrust meters both data volume and eval scores, a team running large eval suites frequently (which is exactly the workflow Braintrust is built for) can see costs scale faster than a pure-tracing tool would. The generous free tier (1M spans/month, unlimited users) makes it easy to prototype the whole workflow before that becomes a real budget line.
Phoenix's bet is different from the other two: don't build a proprietary trace format, build on OpenTelemetry and let OpenInference — Arize's semantic-convention layer defining span kinds like LLM, Tool, and Retriever, and attributes like llm.token_count.total — standardize what an "LLM span" even means. Because the underlying data is standard OTLP, switching backends later is genuinely cheap: Langfuse and other OTel-native tools can ingest OpenInference spans directly, so instrumenting for Phoenix doesn't strand you if you outgrow it.
Two caveats matter here. First, "open source" isn't quite right — Phoenix ships under the Elastic License 2.0, which is source-available, not OSI-approved. For a team just self-hosting for internal use, ELv2 changes essentially nothing; it starts to matter only if you intend to resell Phoenix as a hosted product yourself. Second, Phoenix's trace UI is span-tree-first, inherited from its ML-monitoring roots, and several practitioners have noted it lacks the transcript-style conversational view that agent-heavy teams often want when debugging a multi-turn tool-calling loop. It's genuinely excellent for notebook-driven experimentation and for teams that already have OpenTelemetry infrastructure, less purpose-built if your primary need is "let a non-engineer read through what the agent said."
The decision collapses faster than the feature matrix suggests once you ask two questions: where does your data have to live, and what's the actual failure mode you're trying to catch?
None of this is exclusive, either — it's common to see Phoenix or an OTel collector in front, fanning traces out to more than one backend during an evaluation period, precisely because OpenInference/OTLP makes that cheap. If you're instrumenting an agent that calls external tools over MCP — Utilix's own MCP server is one example of the kind of tool-call surface worth tracing — the span you want to capture is the same regardless of which backend receives it: tool name, arguments, latency, and whether the call succeeded. Get that instrumentation right once, in a standard format, and the choice of backend becomes far lower-stakes than it looks from the pricing page.
Takeaway: don't pick an observability platform by feature checklist — pick by what's actually load-bearing for your team (self-host requirement, eval-as-CI-gate workflow, or OTel portability), and instrument with OpenTelemetry/OpenInference conventions where you can, so the choice stays reversible.