# Pydantic Logfire: tracing Python agents on OpenTelemetry, and which parts are open

> Four lines of code show you how a client's agent calls the LLM. Before you send those traces anywhere, ask where the data will live.

Original: https://fdetimes.net/en/tools/pydantic-logfire-opentelemetry-agent-tracing/

On your third day at a client, the agent gives a wrong answer and takes 40 seconds to do it. Nobody knows where that time goes: the LLM call, a SQL query or an internal API.

This is exactly the situation Logfire is built for. Pydantic presents it as an all-in-one AI engineering platform that puts every LLM call, request and query from your agents, services and hosts on a single timeline.

For an FDE, the value is speed. You do not have two weeks to stand up an observability stack before you can start debugging, and the client cannot wait that long either. The catch is that the tool is open in some places and closed in others, so you need to know exactly where the line falls before you recommend it.

## What actually runs in your code?

The official repo describes the Python SDK as an "opinionated" wrapper around OpenTelemetry, the open standard for traces, metrics and logs. There are also TypeScript and Rust SDKs, all under the MIT licence. Logfire ships more than 40 integrations, including FastAPI, Django, SQLAlchemy and HTTPX.

OpenTelemetry is the detail that matters most: the data you collect follows an open standard rather than a Pydantic-specific format. Pydantic's comparison page calls Logfire's instrumentation "fully portable", but because the SDK is its own wrapper, calls such as `logfire.configure()` and `logfire.instrument_fastapi(app)` are still Logfire's API.

Data is queried in standard SQL rather than a proprietary query language. At a client site this helps more than you might expect: their data engineers can read your queries straight away without learning a new syntax.

## Four steps, one FastAPI service

Imagine the client has a FastAPI service wrapping a customer support agent. According to the repo, getting started means installing the package, authenticating, configuring and then switching on the framework integration:

```bash
pip install logfire
logfire auth
```

```python
import logfire
from fastapi import FastAPI

app = FastAPI()
logfire.configure()
logfire.instrument_fastapi(app)
```

From here, every request to the service becomes a trace. Add integrations such as SQLAlchemy or HTTPX and database queries and outbound HTTP calls appear on the same timeline as the request. Back to the 40-second case: you would see at once which segment takes the time, instead of scattering `print` statements across someone else's codebase.

The first thing to do at a client is instrument exactly one service, the agent's most important path, and then write a SQL query that pulls out the slowest requests. A concrete answer in the first session is worth more than a handsome dashboard nobody opens.

## Is the free tier enough for a pilot?

The free Personal plan includes credit equivalent to 10 million logs, spans and metrics a month, with a hard stop at that level. Data is kept for 30 days on Personal and Team, and up to 90 days on Growth. Team costs $49 a month and Growth $249 a month; overage is $2 per million records, and every paid plan has a price cap so you can set a spending ceiling.

Run the numbers. Suppose each agent request produces 25 spans: the HTTP request, a few LLM calls and a few queries. At 2,000 requests a day that is 50,000 spans a day, about 1.5 million a month, comfortably inside the free tier.

At 20,000 requests a day the figure rises to about 15 million a month, above the Personal ceiling. On Team you pay the $49 monthly base fee plus 5 million excess records at $2 per million, or $10, for roughly $59 a month. Do this calculation with the client's real numbers before promising that "the free version will do".

## Limits to raise with the client up front

The biggest limit is not price. Logfire's UI and backend are closed source, and self-hosting requires an enterprise licence. For banks, healthcare providers or public-sector clients, where traces may contain prompts and customer data, without that licence the traces sit on Pydantic's platform rather than in the client's own infrastructure.

**Key point:** An open SDK does not mean an open platform: ask where the trace data lives first.

The 30-day retention is a real limit too. If the client needs to look back at incidents from last quarter, you will have to consider the Growth plan or export the data elsewhere yourself.

If the client has invested heavily in LangGraph, Pydantic itself concedes that such teams may prefer the dedicated graph-state UI offered by a competitor. Logfire's graph view is a Mermaid diagram generated from code for Pydantic Graph.

According to Pydantic, Logfire covers the full stack while LangSmith leans towards LLMs and agents; but since this is a vendor's own comparison page, test it yourself on the client's workload.

## What to learn first?

Learn OpenTelemetry before Logfire. Logfire is built on this open standard, so a solid grasp of traces, spans and how they connect lets you read the data even when the client picks a different backend. Logfire is an easy place to see those concepts working, since a few lines of code already give you traces.

When reading job descriptions, look for phrases such as "observability", "OpenTelemetry" or "production LLM systems". On a CV, a line like "added OTel tracing to a FastAPI agent and found the bottleneck slowing responses" is far more persuasive than a list of tool names.

At a client site, someone will sooner or later ask "where does this data go?" A good FDE has the answer before running `logfire auth`.

**Try this week:**

- Add logfire.configure() and logfire.instrument_fastapi(app) to a personal FastAPI service, send a few dozen requests and find the slowest one with a single SQL query
- Count the spans one request produces in that service and multiply by a client's expected daily requests to see whether you would exceed 10 million records a month
- Draft three questions about where trace data is stored and how long it is kept, to bring to your next discovery session

## Sources

- [Pydantic Logfire documentation](https://pydantic.dev/docs/logfire/)

- [pydantic/logfire (GitHub)](https://github.com/pydantic/logfire)

- [Pydantic Logfire Pricing](https://pydantic.dev/pricing)

- [logfire pricing change](https://pydantic.dev/articles/logfire-pricing-change)

- [Logfire vs LangSmith](https://pydantic.dev/logfire/vs-langsmith)