Every agent run, model call and tool call recorded as one trace, alongside the HTTP requests and database queries around them, and queried with SQL. Free for 10 million spans a month.
import logfire
logfire.configure()
logfire.instrument_pydantic_ai()
logfire.instrument_asyncpg()
LLM observability is the practice of recording what an AI application actually did in production, and being able to ask questions about it
afterwards. Traditional monitoring tells you a request returned 200 in 900ms. LLM observability tells you the agent called the wrong
tool twice, retried, spent 14,000 tokens and produced an answer nobody checked.
The unit that matters is the run, not the call. A single run is usually a tree: several model calls, tool invocations, retrieval steps, and sometimes handoffs between agents across more than one service. Recording that tree with the causal chain intact is what separates an answerable question from a pile of individual requests.
An LLM-only tool shows you the model call. It does not show you the SELECT that made retrieval slow, the API timeout inside a tool call,
or the vector search that quietly returned nothing. Those are where production AI actually breaks, and they are not LLM problems, they are application
problems that happen to be adjacent to a model.
Logfire is a full OpenTelemetry backend that also understands agent runs. One request through FastAPI, Postgres, a vector search and a model call is one trace. When an agent stalls because a downstream service is degraded, the connection is visible rather than inferred across two products.
import logfire
from pydantic_ai import Agent
logfire.configure()
logfire.instrument_pydantic_ai()
logfire.instrument_httpx()
logfire.instrument_asyncpg()
agent = Agent('openai:gpt-5-mini')
result = agent.run_sync('Why did checkout slow down?')
Each instrument_* call is one line, and they compose: instrumenting the agent framework, the HTTP client and the database driver is what
produces a single trace rather than three disconnected ones. Other frameworks work the same way through the OpenTelemetry GenAI conventions and OpenInference.
Full details are in the integrations guide.
An agent run is a tree: model calls, tool invocations, retrieval steps and handoffs to other agents. Logfire records it as one trace with that structure intact, so you can see which tool was called, what it returned, and which step actually cost the time. Agents are detected from the OpenTelemetry GenAI conventions and from OpenInference, so this works across frameworks rather than only with Pydantic AI.
Every model call carries its token counts and its cost, so you can see spend by model, by provider and by agent, alongside latency, error rate, output tokens per second, cache reads and tool-call rate. Cost is read from the span rather than estimated afterwards, and it is queryable like any other attribute, so 'which agent spent the most last week' is a query rather than a spreadsheet.
Open supported model spans and read the exchange as a conversation: system, user, assistant and tool messages in order, with tool names, arguments, payloads and token badges. Pydantic AI and selected native OpenTelemetry GenAI integrations provide the richest view. The fields shown depend on what the instrumentation emits; OpenInference and other bridges may omit message, tool or cost details.
Keep prompts out of your code with versioned, labeled templates the SDK fetches at runtime. Roll a new prompt out to a percentage of traffic, target it at a subset of users, and roll it back without shipping. Every resolution is recorded, so you can tell which version produced which run.
Turn a production trace into a test case, run experiments from code with pydantic-evals, and compare a candidate against a baseline case by case. Evaluation results are emitted as OpenTelemetry events and are queryable alongside production traces.
Logfire speaks OpenTelemetry natively. Instrument with our SDK or with plain OTel, send from any language that has an OTel SDK, and export the same data elsewhere whenever you want. Your instrumentation is an asset you own rather than something rented from a vendor.
A list is fine for eight agents and useless for a hundred. The honeycomb puts the whole fleet on one screen, one cell per agent, colored by the metric you are worried about and grouped by the dimension you suspect, here error rate, grouped by model.
Every model your application called, discovered from the same spans, no list to maintain, and no surprise when someone ships a new one.
The same view rolls up by provider, and this is where it stops being an inventory and starts being an SLO. Set a target on a provider and it reports against it, so "is OpenAI having a bad day" is a number you already have rather than a status page you go and read.
select
attributes->>'gen_ai.request.model' as model,
count(*) as calls,
avg(duration) as avg_seconds
from records
where attributes->>'gen_ai.request.model' is not null
and start_timestamp > now() - interval '7 days'
group by model
order by avg_seconds desc;Observability has produced a remarkable number of query languages: PromQL, LogQL, TraceQL, NRQL, SPL, ES|QL, KQL. The fragmentation is enough of a problem that the CNCF has an initiative to standardize them. Logfire uses SQL in PostgreSQL syntax, so there is nothing new to learn, and your traces, metrics and logs all answer to the same queries.
It is also the SQL a coding agent already knows. Point Claude Code, Cursor or Codex at the Logfire MCP server and ask why runs got slower last Tuesday: it writes the query, because the query is ordinary SQL rather than a dialect it has seen a handful of examples of.
Every AI-native vendor has a name for the thing underneath by now. Braintrust has Brainstore, Langfuse runs on ClickHouse. Ours is FusionFire, and it is the part of Logfire we are most pleased with.
It is built on Apache DataFusion, a columnar, streaming, vectorized engine that uses Apache Arrow as its in-memory format, and shaped around what AI observability actually asks of a database. Agent runs are wide: a single span can carry a whole conversation, its tool payloads, its token counts and its cost. Then you want to group by a model name or a customer id that nobody indexed in advance, across an enormous number of them.
The reason to say the name out loud is that ours is the one you can point ordinary SQL at. A purpose-built store usually arrives with a bespoke API, because the store is the product and the API is how you are kept close to it. Fast and familiar are not in tension here.
We are not going to publish a benchmark you cannot re-run yourself. But it is genuinely interesting engineering and we like talking about it, so ask us about it. In the meantime, here is somebody else's number rather than ours:
We migrated from LangSmith to Logfire and the time it took to query our agent traces went down by 96.2%.
Having it built primarily off a first-class observability platform is the big thing that sold me as we're not running just LLM agents. We want to see observability on your API endpoints and all that other stuff too.
LLM observability covers a single model call: the prompt, the response, tokens and cost. Agent observability covers a whole run, which is usually a tree: several model calls, tool invocations, retrieval steps and handoffs between agents, often across more than one service. The unit you care about is the run, not the call, so the trace has to keep the causal chain intact rather than showing you a list of individual requests.
Yes, and this is the main reason to use Logfire rather than an LLM-only tool. Logfire is a full OpenTelemetry backend, so a request that hits FastAPI, queries Postgres, runs a vector search and then calls a model produces one trace containing all of it. When an agent run is slow because the retrieval query was slow, you see it in the same waterfall rather than inferring it across two products.
Logfire detects agents from the OpenTelemetry GenAI semantic conventions and from OpenInference, so it works across frameworks rather than only with our own. Pydantic AI, LangGraph, OpenAI Agents SDK, CrewAI, smolagents, Agno, Google ADK, Strands, Semantic Kernel, Mastra and the Vercel AI SDK all arrive as structured runs. The integrations documentation carries a support matrix showing exactly which signals reach us from each one, which is worth reading before you commit to a framework.
Logfire is built on OpenTelemetry rather than wrapping it. Any language with an OTel SDK can send data, standard OTel instrumentation works unchanged, and you can export the same telemetry to another backend. There is no proprietary agent and no proprietary wire format, so your instrumentation stays portable.
Spans are batched and exported asynchronously on a background thread, so instrumentation does not sit in the request path. For high-volume services you can sample: head sampling decides before work happens, tail sampling decides after, so you can keep every failed or slow agent run while sampling the routine ones.
Personal includes 10 million spans, logs and metrics per month and pauses ingestion at the limit. On Team and Growth, usage beyond the included 10 million records costs $2 per million. Logfire does not add a separate per-score fee for evaluation results.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.