Full-stack observability and evaluation for AI apps

Standard monitoring tells you something failed. AI observability tells you why by tracing, debugging, and evaluating AI applications across LLM calls, the databases and tools they depend on, the costs and latencies they generate, and the outputs they produce. It matters because AI applications fail in ways traditional software doesn't: a model returns a plausible but wrong answer, a tool call misfires silently, costs spike from a retry loop. Without observability across the full-stack, you’re guessing and shipping AI you can’t debug. Logfire gives you the complete picture.

Logfire is a full-stack observability and evaluation platform for AI agents, built on OpenTelemetry and framework-agnostic. It traces the whole run from LLM calls, tool calls, database queries, APIs, and your own code, in one view, so you can debug, evaluate, and improve what your AI does in production. It's built by the team behind Pydantic, the most widely used data-validation library in Python, but neither Pydantic nor Python is required to use it.

No to both. Logfire is framework-agnostic and language-agnostic. It ingests standard OpenTelemetry, so it works with OpenAI, Anthropic, LangChain, LangGraph, LlamaIndex, CrewAI, the Vercel AI SDK, and any other stack that emits OTel. TypeScript and Node.js are first-class, with SDKs for Node, the browser, Next.js, and Cloudflare Workers, and any language with an OpenTelemetry SDK works, including Go, Java, .NET, Ruby, and Rust. Pydantic AI has the tightest integration because it's built by the same team, but it's a recommendation, not a requirement.

Both. Logfire includes a full evaluation suite: build datasets from production traces, run experiments comparing a candidate against a baseline case by case, score with code assertions, LLM-as-a-judge rubrics, or human review, and run live evals against production traffic. Because eval results are stored as queryable telemetry, "did version 12 regress on refund questions" is a SQL query. Evaluation and observability share the same data, rather than being separate tools.

Two differences. First, Logfire is OpenTelemetry-native: the SDK is standard OTel, not a proprietary wrapper, so your instrumentation is portable from day one and the same code can send traces to Logfire or any OTel backend without changes. Second, Logfire traces your full application, not just the LLM layer. You see the database queries, tool calls, and API requests around your model calls in one unified view, so you don't run one tool for your app and another for your AI.

Yes. Logfire stores traces as queryable data in standard PostgreSQL SQL, and its MCP server lets a coding agent like Claude Code or Cursor query production directly — asking why a call failed, which step was slow, what changed — so it debugs from what actually happened instead of guessing. Standard SQL and OpenTelemetry mean the agent doesn't have to learn a proprietary query language.

Yes. Self-hosting is available on the Enterprise plan, deployed in your own infrastructure. If you'd rather not use the hosted platform on other plans, the SDK is standard OpenTelemetry, so you can send your data to any OTel-compatible backend. Either way your instrumentation stays portable. OpenTelemetry is the anti-lock-in standard.

The Logfire SDK is open source under the MIT license and available on GitHub. It's a wrapper around the OpenTelemetry Python and TypeScript SDKs, so you can inspect it, fork it, or send data to any OTel-compatible backend. The hosted platform is the commercial product; the instrumentation you install is open.