What are LLM observability tools?
LLM observability tools capture what happens inside your LLM and agent applications: the traces, token costs, latency, errors, and output quality of every model and agent call. Teams use them to both debug failures and control spend.
Key Takeaways
- Most of these tools observe, evaluate, or execute predefined controls; only one acts autonomously on cost, latency, and reliability in production
- Open source is a real option: Langfuse, MLflow, Helicone, Portkey, and DeepEval are openly licensed; Arize Phoenix is source-available
- The tools are categorized into five jobs: Tracing platforms, evaluation-first tools, gateways, enterprise monitoring, and full-stack with autonomous action
- Most teams run more than one tool, so they should evaluate which tool is right for their specific job
Why LLM Observability Matters Now
LLM observability has shifted from optional to expected because AI systems are now in production, spending real money, and failing in ways traditional monitoring was never built to catch. Gartner expects 60% of software engineering teams to adopt AI evaluation and observability platforms by 2028, up from 18% in 2025, a jump that tracks how quickly agents and LLM features are reaching customers.
Debugging is the main pressure point because LLM and agent behavior is non-deterministic. In a 2025 study of 38 practitioners, 79% named non-deterministic execution as a major problem. And because ordinary logs do not capture the complete agent flow, 77% of practitioners in the study reported difficulty diagnosing root causes.
Cost adds a second problem, since token spend accumulates across providers, models, and teams. Without per-call attribution, a spike is hard to trace back to its source.
What makes this practical to solve now is standardization. Many of the tools below build on OpenTelemetry's GenAI semantic conventions, which cover OpenAI, Anthropic, AWS Bedrock, and Azure AI Inference, so instrumentation is becoming portable rather than locked to one vendor.
And the category has matured to match: Gartner formally named it in a February 2026 Market Guide.
How We Evaluated These Tools
Every tool on this list had to be production-ready and under active development as of July 2026. Beyond that baseline, we scored each tool on six criteria:
- Scope. Whether the tool covers tracing, evaluation, gateway routing, or the full stack
- Integration effort. Whether adoption requires code changes, an SDK, an OpenTelemetry exporter, or a base-URL swap
- Self-serve or sales-gated. Whether you can start for free or have to talk to sales
- Multi-provider support. Whether it works across OpenAI, Anthropic, Bedrock, and others
- Acts or displays. Whether the tool acts on its findings or surfaces them for a human to act on
- Enterprise governance. Whether it offers access control, PII handling, and deployment options regulated teams need
We also organized the tools into five distinct categories:
- Full-stack observability with autonomous action. Tools that act on what they observe, not just display it
- Open-source observability platforms. Self-hostable tracing, evaluation, and prompt management you run yourself
- Evaluation-first platforms. Tools that measure output quality and gate releases on it
- Gateways with observability. Tools that sit in the request path and add cost tracking, caching, and routing
- Ecosystem and enterprise. Deep ties to a framework like LangChain, or enterprise-grade monitoring and governance
We describe every tool using its own documentation and list real limitations for each one. And because most teams run more than one of these tools together, we note where a tool complements another rather than replacing it.
LLM Observability Tools Compared
Tool | Open Source? | Action Taken | Best For |
|---|---|---|---|
No | Acts autonomously | Real-time observability and autonomous optimization | |
Yes (MIT) | Displays and evaluates | Self-hosted, framework-agnostic observability | |
Source-available (ELv2) | Displays and evaluates | Lightweight, OTel-native dev workbench | |
Yes (Apache 2.0) | Displays and evaluates | Teams already running MLflow | |
No | Proposes changes | Evals wired into CI/CD | |
Yes (DeepEval, Apache 2.0) | Flags regressions | Code-first eval suites | |
No | Detects and enforces | Full-traffic evaluation at low cost | |
Yes (Apache 2.0) | Gateway controls | Fast cost tracking and caching via a proxy | |
Yes (MIT gateway) | Gateway controls | Resilient multi-provider routing | |
No | Displays and alerts | LangChain and LangGraph apps | |
No | Alerts and redacts | Teams already on Datadog | |
No | Evaluates and enforces runtime guardrails | Regulated enterprise trust and safety |
Full-Stack Observability With Autonomous Action
Sedai
Sedai is an optimization platform that brings governance, observability, and intelligent routing to every LLM call. Sedai is unlike other LLM observability tools because it autonomously takes action to reduce the cost and improve performance of AI agents, going beyond simple metric reporting.
How It Works
When a model call turns expensive, slows down, or fails, Sedai reroutes, retries, or fails over to another model autonomously. It is designed to optimize the agents you've already built, so it sits alongside your existing stack rather than replacing your tracing or eval tools.
Sedai runs as an intelligent layer on every call, capturing cost, token usage, and latency directly from its SDK so teams get a single source of truth across every provider instead of reconciling separate vendor bills.
Its Smart Routing then acts on that data. Rather than static, rule-based routing, it:
- Builds a dedicated router for each agent from that agent's real production traffic
- Identifies a Pareto set of candidate models
- Sends each prompt to the best fit for your cost, latency, or accuracy goals
Because the router translates requests and responses between provider formats on the fly, an application written for OpenAI, for example, can be routed to a better-fit model on Anthropic or Google without refactoring code.
Governance policies control which models each team can use, and built-in reliability handles retries and cross-provider fallbacks.
Integration is a one-line import across OpenAI, AWS Bedrock, Vertex AI, and Azure Foundry, with more to release in the future.
Pros
- Acts autonomously in production: Reroutes, retries, and fails over instead of alerting a human
- Traffic-trained routing: Smart Routing builds a per-agent router from real production traffic, not generic benchmarks, with Manual and Auto modes
- Single source of truth: Consolidated cost, usage, and latency across every provider, project, and model
- Governance: Org and project-level policies control which models each team can use
- Zero-code adoption: One import, no rewrites, with cross-provider API translation so you can switch models without touching code.
Cons
- Not a tracing or eval workbench: You cannot author your own test suites or manage annotation queues the way you can in Langfuse or Braintrust
- Provider coverage still expanding: OpenAI, AWS Bedrock, Vertex AI, and Azure Foundry today, with more to come.
- Analysis depth: Built for governance, routing, and reliability rather than deep trace debugging or hallucination scoring
Why Choose Sedai
- You want observability acted on autonomously and safely in production, not just shown on a dashboard.
- You run agents across several providers and want routing, reliability, and governance in one layer
- You want per-agent routing tuned to your traffic without manual benchmarking or code changes
Best For
Teams that want observability across providers and want the data acted on autonomously in production.
Open-Source Observability Platforms
Langfuse
Langfuse is the open-source leader in LLM observability, offering tracing, prompt management, evaluations, a playground, and datasets under an MIT license. It suits teams that want a self-hostable backend they fully control.
Currently, its GitHub repository has more than 31,000 stars.
How It Works
The core does not impose product-level usage caps, although teams pay for and manage the underlying infrastructure. Run it self-hosted on Docker or Kubernetes, or use the managed Langfuse Cloud. Its evaluations cover both LLM-as-a-judge and code-based checks.
You can connect Langfuse through:
- Its native Python and JavaScript SDKs
- Drop-in integrations for the OpenAI SDK and more than 100 libraries and frameworks
- A standard OpenTelemetry exporter
That OpenTelemetry support keeps you flexible, since the same instrumentation can point at another backend later instead of locking you in.
Pros
- Open source (MIT): No usage caps on core features
- Broad framework support: OpenAI SDK drop-in; LangChain, LlamaIndex, and OpenTelemetry-based instrumentation
- Complete platform: Tracing, prompt management, evaluations, playground, and datasets in one place
- Deploy anywhere: Self-hostable via Docker or Kubernetes, or use Langfuse Cloud
Cons
- Open-core licensing: Some enterprise modules require a license key
- No zero-code path: Adoption means SDK or OpenTelemetry instrumentation
- Displays and evaluates: Automates tracing and evaluation; application remediation remains external
Why Choose Langfuse
- You want to self-host and fully own your observability data
- You use multiple frameworks and want portable, OTel-based instrumentation
- You need tracing and evals without usage caps on the core
Best For
Teams that want a self-hosted, framework-agnostic observability platform they own end to end.
Arize Phoenix
Arize Phoenix is an OpenTelemetry-native observability and evaluation tool that runs from a single pip install or Docker container. It fits engineers who want a lightweight tracing and eval workbench during development.
How It Works
Phoenix is built on OpenTelemetry and OpenInference instrumentation, which makes its traces portable.
It documents four features:
- Tracing that captures model calls, retrieval, and tool use step by step
- Evaluation through LLM-based evaluators, code checks, or human labels
- Prompt engineering with versioning and replay
- Datasets and experiments for comparing versions systematically
Pros
- Lightweight start: Pip install or a single Docker container
- Portable traces: OpenTelemetry- and OpenInference-native
- Full dev workbench: Tracing, evaluation, prompt engineering, and dataset experiments
- Free to self-host
Cons
- Production limitations: Managed alerting and online evals live in commercial Arize AX
- Source-available, not open source: Elastic License 2.0 allows self-hosting but ELv2 is not an OSI-approved open-source license
Why Choose Arize Phoenix
- You want a fast, local tracing and eval workbench during development
- You value OpenTelemetry-native instrumentation you can later forward to Arize AX
- You do not yet need production-grade alerting
Best For
Engineers who want a fast, OpenTelemetry-native tracing and evaluation environment while building.
MLflow
MLflow is the open-source ML platform whose tracing feature is a fully OpenTelemetry-compatible way to observe LLM and agent applications. It fits teams already running MLflow who want agent traces in the same place as their experiments.
How It Works
MLflow Tracing captures the inputs, outputs, and metadata of each intermediate step in a request. Instrumentation can be a single line, for example mlflow.openai.autolog(), or manual decorators for custom spans. It integrates with OpenAI, LangChain, LlamaIndex, and DSPy.
MLflow also supports human feedback on traces and systematic evaluation, and it is licensed under Apache 2.0 with no feature gating. Tracing was introduced in MLflow 2.14.0 and expanded for generative AI in MLflow 3.0.
Pros
- Apache 2.0, fully free: No feature gating
- One-line auto-tracing: For example, mlflow.openai.autolog(), plus manual decorators
- OpenTelemetry-compatible: Integrates with OpenAI, LangChain, LlamaIndex, and DSPy
- Mature ecosystem: Reuses MLflow's experiment-tracking foundation
Cons
- You run the server: Self-hosted tracking-server model unless you use Databricks
- Newer at LLM observability: Tracing is recent next to its classic ML heritage
- No built-in alerting: No threshold alerts or anomaly detection; teams need separate tooling or managed Databricks capabilities.
Why Choose MLflow
- Your team already runs MLflow for ML experiments
- You want agent tracing in the same place as your models
- You want a free, open-source, OTel-compatible option
Best For
Teams standardized on MLflow who want LLM and agent tracing without adding another vendor.
Watching LLMs Isn't Optimizing Them
Most LLM observability tools tell you what's going wrong. Sedai fixes it for you.

Evaluation-First Platforms
Braintrust
Braintrust is a proprietary platform built around evaluations, combining an eval framework, logging, a prompt playground, and an assistant called Loop. It fits teams that want quality evaluations wired into their CI/CD pipeline.
How It Works
Braintrust’s core primitive combines a dataset, a task, and scorers into a repeatable eval. It automatically wraps OpenAI and Anthropic clients without requiring manual instrumentation around each call.
As for the assistant, Loop, it:
- Analyzes logs and traces
- Generates SQL filters from natural language
- Creates datasets from log patterns
- Generates scorers
- Proposes prompt changes.
Per Braintrust’s Loop documentation, Loop asks for confirmation before executing certain actions by default, and auto-accept is an option a user can turn on. So Braintrust automates the analysis and proposes changes, but a human must still approve them.
Pros
- Evaluation-first workflow: Dataset, task, and scorers, built to fit CI/CD
- No-code trace capture: Auto-wraps OpenAI and Anthropic clients
- Loop assistant: Analyzes logs and proposes prompts, scorers, and datasets
- Developer tooling: Prompt playground and multi-language SDKs
Cons
- Closed-source: Self-hosting only on the Enterprise tier
- Free tier caps: Starter limits processed data and score volume
- Proposes, doesn't act: A human confirms Loop's changes by default
Why Choose Braintrust
- You want quality evals wired into your CI/CD pipeline
- You want an assistant that drafts eval and prompt improvements for review
- You are comfortable with a proprietary, usage-priced platform
Best For
Teams that want an evaluation-driven workflow with CI/CD quality gates and an assistant that suggests improvements.
Confident AI
Confident AI is the hosted platform built on top of DeepEval, the open-source LLM evaluation framework. It fits teams that want a rigorous, code-first evaluation suite with score-regression gates.
How It Works
DeepEval is open source under Apache 2.0. It ships more than 50 research-backed metrics from general scorers like G-Eval and DAG to agent-specific ones like task completion and tool correctness.
Evaluations can be written as standard pytest-style tests, so teams can run them automatically on every code change and fail the build when output quality drops below a configured threshold.
Everything above is the open-source framework you run yourself. Confident AI is the hosted version on top, adding the pieces teams need to run evals in production, like shared datasets, release-blocking quality gates, and red-teaming.
Pros
- Built on DeepEval (Apache 2.0): More than 50 research-backed metrics
- Code-first workflow: Pytest-style tests with score-regression gates
- Agent-ready metrics: Task completion, tool correctness, and red-teaming
- Local-first evaluation
Cons
- Evaluation-first, not full APM: Built for LLM tracing and evals, not infra monitoring
- Judge-model overhead: LLM-as-a-judge metrics carry cost and variance
- Sales-gated extras: Advanced and on-premises features require a sales conversation
Why Choose Confident AI
- You want a rigorous, open-source-backed eval suite
- You want regression testing gates in CI/CD
- Evaluation, not tracing or routing, is your priority
Best For
Teams that want a granular, open-source-backed eval library with regression testing in their pipeline.
Galileo
Galileo is a proprietary reliability platform that observes, evaluates, and guardrails GenAI and agent applications using its own small evaluation models. It fits teams that want to evaluate all of their production traffic cheaply.
How It Works
Galileo's Luna-2 evaluation models stay under 200ms even when running 10 to 20 checks at once on L4 GPUs. And at $0.12 per million tokens versus $5.00 for a frontier model like GPT-5.4, they cost roughly 98% less than using that model as the judge.
Its Insights engine automatically clusters similar failures, surfaces root-cause patterns, and prescribes fixes such as adding few-shot examples; a single click can generate an evaluator from an identified issue. Guardrails can also be applied without changes to agent code.
Pros
- Low-cost, low-latency evaluation: Luna-2 stays under 200ms even at 10 to 20 checks at once, at about 98% less than a frontier-model judge ($0.12 vs. $5.00 per million tokens)
- Automated root cause: Insights engine auto-clusters failures and surfaces patterns
- No-code guardrails: Applied without changes to agent code
- Free tier available
Cons
- Closed-source: Trace-based pricing scales with volume
- Recommends, doesn't implement: Insights prescribes fixes, engineers apply them
Why Choose Galileo
- You want to evaluate all production traffic cheaply, not a sample
- You want automated failure-pattern detection
- You need production guardrails alongside evaluation
Best For
Teams that want full-traffic evaluation and automated failure-pattern detection at low cost per token.
Gateways With Observability
Helicone
Helicone is an open-source observability platform and AI gateway that instruments LLM apps through a simple base-URL change. It fits teams that want cost tracking and caching live in minutes.
How It Works
Helicone offers two modes: gateway and async logger.
As a gateway, it sits in front of your provider and adds edge caching with savings shown in the dashboard, plus automatic fallbacks and rate limiting. As an async logger, its SDK records requests after they reach the provider, which keeps Helicone off the critical path but gives up the gateway features. Both modes include cost and latency tracking with prompt management.
The platform is Apache 2.0 licensed and self-hostable.
Pros
- One-line integration: A base-URL swap
- Open source (Apache 2.0) and self-hostable
- Gateway feature set: Cost tracking, edge caching, rate limiting, and fallbacks across 100+ models
- Fast path to cost visibility
Cons
- Inline dependency: Gateway mode sits in the critical request path, adding potential latency and another availability dependency
- Observes and controls requests: Does not act on your application logic
Why Choose Helicone
- You want cost tracking and caching live in minutes
- You prefer a proxy or gateway model over SDK instrumentation
- You want an open-source option you can self-host
Best For
Teams that want the fastest path to cost visibility and caching through a proxy.
Portkey
Portkey is an AI gateway with an open-source core that sits between your application and more than 1,600 models. It fits teams that want resilient multi-provider routing with built-in controls.
How It Works
Portkey handles:
- Automatic routing and fallbacks across providers
- Load balancing across API keys
- 20+ deterministic guardrails plus LLM-based guardrails, including PII redaction and jailbreak detection
- Observability and cost controls
Integration is a base-URL swap against an OpenAI-compatible endpoint or its SDK. The gateway is MIT-licensed and self-hostable through a single command, Docker, Kubernetes, or a VPC, and the managed platform adds a hosted layer.
Pros
- Open-source gateway (MIT): Self-hostable, including in a VPC
- Resilient routing: Fallbacks and load balancing across 1,600+ models
- Guardrails built in: 20+ deterministic and LLM-based guardrails, including PII redaction and jailbreak detection
- Base-URL swap integration
Cons
- Limited OSS: Full observability requires Enterprise
- Tier-gated budgets: Budget controls sit in higher tiers
- Inline middleware: Every request flows through it
- Not autonomous: Routing is configuration-driven
Why Choose Portkey
- You want a resilient multi-provider gateway
- You need guardrails and cost controls at the gateway layer
- You want an open-source core with enterprise self-hosting
Best For
Teams that want a resilient multi-provider gateway with guardrails and cost controls.
Ecosystem and Enterprise
LangSmith
LangSmith is LangChain’s proprietary observability and evaluation platform, offering the deepest integration with LangChain and LangGraph among the tools in this comparison. It fits teams building on that ecosystem.
How It Works
LangSmith provides:
- Trace-level debugging
- Offline and online evaluations
- Dataset management
- Monitoring dashboards
- Annotation queues
- A prompt hub.
It works with or without the LangChain framework and supports OpenTelemetry natively, so you can point any OTel exporter at its endpoint. Its strongest use is turning production issues into offline test cases within the LangChain workflow.
Pros
- Deepest LangChain and LangGraph integration
- Full eval loop: Trace-level debugging plus offline and online evaluations
- Expert review tooling: Annotation queues, dataset management, and monitoring dashboards
- Native OpenTelemetry support: Works beyond LangChain
Cons
- Self-hosting: Enterprise-only and requires teams to operate supporting infrastructure
- Ecosystem-optimized: Built first for LangChain workflows
- Detects and surfaces: Humans act on what it finds
Why Choose LangSmith
- You build on LangChain or LangGraph
- You want the tightest-integrated tracing and evals for that stack
- You want to turn production issues into offline test cases
Best For
Teams building on LangChain or LangGraph who want the tightest-integrated tracing and evaluation.
Datadog LLM Observability
Datadog LLM Observability brings LLM and agent tracing into the broader Datadog platform, correlating it with existing APM and infrastructure monitoring. It fits teams already on Datadog.
How It Works
Datadog captures end-to-end traces of LLM chains and agent workflows. At production scale, it clusters conversations by topic and flags anomalies, so quality problems surface without anyone reading individual traces. It also covers the security side, scanning prompts and responses for sensitive data, redacting it, and detecting prompt injections.
Instrumentation is an auto-instrumenting Python SDK, and the product natively supports OpenTelemetry’s GenAI semantic conventions, mapping attributes like token usage and provider name automatically.
Pros
- One platform: Correlates LLM traces with existing APM and infrastructure monitoring
- Production-scale analysis: Topic clustering and anomaly detection
- Security built in: PII redaction and prompt-injection detection
- Standards-native: OpenTelemetry GenAI conventions support with an auto-instrumenting SDK
Cons
- Platform lock: Requires Datadog
- Cost scaling: Per-span pricing can surge for high-volume agents
- Surfaces and evaluates: Remediation is a human or ops task
Why Choose Datadog
- You already run Datadog and want LLM traces in the same place
- You need production-scale clustering and anomaly detection
- You want LLM telemetry correlated with infrastructure and APM
Best For
Teams already invested in Datadog who want LLM traces alongside the rest of their stack.
Fiddler
Fiddler is a proprietary enterprise platform for AI observability and security across traditional ML models, LLM applications, and multi-agent systems. It fits regulated organizations where AI decisions carry legal or safety consequences.
How It Works
Fiddler's Trust Service scores outputs for safety, privacy, and quality using purpose-built models. The checks include toxicity, jailbreaks, PII, and hallucination.
Its purpose-built Centor evaluation models return results in under 80ms with no external API calls, and its guardrails integrate with NVIDIA NeMo Guardrails to intercept prompts and responses at runtime.
It retains the drift, explainability, and model-monitoring capabilities of its ML heritage. Detection, scoring, and guardrail interception run automatically.
Pros
- Enterprise trust and safety: Governance across ML and LLM systems
- Trust Service scoring: Built-in safety, privacy, and quality metrics (toxicity, PII, jailbreaks, hallucination).
- Sub-80ms evaluation: Centor models return safety, quality, and privacy scores in under 80ms with no external API calls
- Runtime guardrails: Native NVIDIA NeMo Guardrails integration
- Model-monitoring heritage: Drift and explainability
Cons
- Sales-gated: Closed-source with no public self-serve pricing
- Heavier setup: Enterprise deployment effort
- Detection, not remediation: Fixes stay with human engineers
Why Choose Fiddler
- You are a regulated enterprise needing trust and safety controls
- You run both traditional ML and LLM systems
- You need runtime guardrails and governance at scale
Best For
Regulated enterprises that need trust, safety, and governance across both ML and LLM systems.
How To Choose the Right LLM Observability Tool
Choosing the right LLM observability tool comes down to the problem you have now, since the categories above map cleanly onto specific needs.
Most teams end up using more than one of these tools together, so the question is less "which one" and more "which one for which job."
Your situation | Choose | Why |
Deep trace debugging, and you want to own your data | Langfuse | Open-source core (MIT), self-hostable, framework-agnostic |
An OpenTelemetry-native tool you run yourself | Arize Phoenix or MLflow | Portable OTel instrumentation, free to self-host |
Catching quality regressions before they ship | Braintrust or Confident AI | Evals wired into CI/CD as quality gates |
Evaluating all production traffic affordably | Galileo | Small eval models under 200ms; about 98% cheaper than a frontier-model judge |
Cost tracking and caching with almost no code | Helicone | Base-URL swap gateway; fastest start in comparison |
Multi-provider resilience and guardrails in the request path | Portkey | Routing, fallbacks, and 20+ deterministic guardrails at the gateway |
You build on LangChain or LangGraph | LangSmith | Deepest LangChain integration in this comparison; annotation queues |
You already run Datadog | Datadog LLM Observability | LLM traces correlated with the APM you have |
Regulated enterprise trust and safety | Fiddler | Sub-80ms Centor eval models, runtime guardrails, 35+ PII entity types |
You want the data acted on autonomously, not just displayed | Sedai | Reroutes, retries, and fails over in production; runs alongside the tools above |
The criterion that separates the field is what happens after the trace shows the problem. Most of these tools display the data, a growing number automate the analysis and propose a fix, and gateways enforce controls in the request path.
But, if you want the observability data acted on autonomously in production, rerouted, retried, and failed over without a human executing the change, that is where Sedai fits. It integrates alongside the tracing and eval tools above rather than replacing them.
FAQs
Sedai is the one tool that actually acts on what it observes. See how Sedai optimizes the agents you've already built → Book a demo.

