# Latitude LLM: agent observability that dispatches a coding agent to fix the failure

> Latitude is an MIT-licensed, TypeScript-based observability stack for AI agents. It captures traces, groups failures into tracked signals, and hands a coding agent the context to open a fix PR.

**latitude-dev/latitude-llm** — Open-source observability for AI agents. Find where your agents fail, dispatch your coding agent to fix it, and verify the fix against real traces.

- Repository: https://github.com/latitude-dev/latitude-llm
- Website: https://latitude.so
- Stars: 4,690 · Forks: 397
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/latitude-dev-latitude-llm

## What Latitude LLM actually solves for agent teams

Most LLM observability tools stop at the trace viewer. You get a waterfall of spans, a token count, a latency number, and a human who has to read it. Latitude's README frames the product around a different loop: observe, understand, fix, verify. The claim is that failing traces are automatically grouped into tracked signals with status, size and trend, and that Latitude then dispatches a coding agent (the README names Claude Code and Cursor) with the failing context and a deep link so it can open a pull request.

The audience is narrow and specific. It is for teams whose agents already run against real users, where failures are not exceptions but bad outputs: a tool call that returns the wrong shape, a multi-turn session that drifts, a retrieval step that silently returns nothing. Those failures do not throw. They accumulate. Latitude's pitch is that grouping them into signals with a trend line is more useful than a flat list of traces, because a signal with a rising count is a bug you can assign, and a trace is just evidence.

That is a real distinction, and it is also where the product's ambition creates its risk. Auto-grouping is a clustering problem, and the README does not describe the algorithm behind signals. If the grouping is noisy, you get a long list of one-off signals and you are back to reading traces.

## How tracing, signals and agent dispatch fit together

The mechanism starts at the SDK. In the TypeScript example, you construct a Latitude client with an API key, a project slug, and an instrumentations map that wraps an LLM SDK (the README uses OpenAI). From that point, supported LLM calls are captured as traces without per-call changes. The README also documents a capture() helper for adding user IDs, session IDs, tags or metadata at request, conversation or agent boundaries. Python and generic OpenTelemetry runtimes are supported too, with an OTel ingest path.

From there the data flow is: traces land in the platform, failing traces are clustered into signals, and a signal carries status, size and trend. The fix step is the unusual part. Instead of asking a human to read the signal, Latitude dispatches a coding agent with the sample traces and a deep link. The README also mentions Linear and webhook dispatch as delivery channels, and an MCP server that exposes the same actions to a coding agent.

The verification step closes the loop: the README says fixes are replayed against the real failing traces so fixed failures do not come back. That is the strongest idea in the product, because it turns a production failure into a regression case automatically. It is also the part with the least public detail. The README links to a regression-testing page but does not explain how a replayed trace is scored, or what happens when the model's output is nondeterministic between the original run and the replay.

## Installing the TypeScript telemetry SDK and sending a first trace

The fastest documented path is not a manual install. The README suggests pasting a prompt into Claude Code, Cursor, Windsurf, Codex, OpenCode or another coding agent, which installs a skill from github.com/latitude-dev/skills and wires up tracing. If you prefer to do it yourself, the manual TypeScript setup is three steps: install the package, construct the client with your API key and project slug, and shut it down at the end of the process.

First, add the telemetry package:

```bash
npm install @latitude-data/telemetry
```

Then wrap your existing LLM SDK. The README's example uses OpenAI and notes you should replace it with the SDK your app already imports:

```ts
import { Latitude } from "@latitude-data/telemetry";
import OpenAI from "openai";

const latitude = new Latitude({
  apiKey: process.env.LATITUDE_API_KEY!,
  project: process.env.LATITUDE_PROJECT_SLUG!,
  instrumentations: { openai: OpenAI },
});

const client = new OpenAI();

await client.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "Hello" }],
});

await latitude.shutdown();
```

You need an API key and project slug from latitude.so before this runs. After the call completes, the README states that every supported LLM call shows up as a trace in Latitude. The shutdown call matters in short-lived processes: without it, buffered telemetry can be lost before the process exits.

## Self-hosting Latitude means running four stateful services

The repository ships a docker-compose.yml, and reading it tells you more about the operational weight than the README does. The stack includes Postgres (the pgvector/pgvector:pg16 image, started with wal_level=logical), ClickHouse (clickhouse/clickhouse-server:26.2, exposing 8123 and 9000), Redis on 6379, a second Redis on 6380 configured with maxmemory-policy noeviction for BullMQ, Mailpit for local email, and Temporal (temporalio/auto-setup:1.27.2) with a Temporal UI. Postgres is initialized through docker/init-db.sh, and .env.example shows that the runtime database user is a restricted Postgres role subject to row-level security.

That is not a single-container deploy. Running Latitude yourself means operating two databases with different data models (transactional Postgres plus analytical ClickHouse), two Redis instances with different eviction policies, and a Temporal cluster for workflow orchestration. The .env.example makes the split explicit: CLICKHOUSE_* variables are consumed by the containers, while the application reads LAT_CLICKHOUSE_URL, LAT_CLICKHOUSE_USER, LAT_CLICKHOUSE_PASSWORD and LAT_CLICKHOUSE_DB, and production values must point at the service names rather than localhost.

The honest reading: if your team does not already run ClickHouse and Temporal, self-hosting Latitude is a meaningful infrastructure commitment. The managed option at latitude.so exists precisely because of that. The README's free tier includes 20K credits per month, 30-day data retention and unlimited seats, which is generous for evaluation but short for post-incident forensics if you need to look back at a failure from two months ago.

## Where Latitude is the wrong tool

If you need vendor-neutral, long-term span storage and nothing else, Latitude is heavier than the problem. The SDK emits OpenTelemetry-compatible data, and you can send that to any OTel backend for a fraction of the operational surface. Latitude's value is in the signal grouping, the dispatch loop and the replay verification. If you are not going to use those, you are paying for a UI and a schema you do not need.

The second wrong-fit case is determinism. The verify step replays fixes against real traces. For agents with temperature above zero, or with tool calls whose results change between runs, a replay is not a like-for-like comparison, and the README does not document how the product handles that. Teams building highly stochastic agents should treat the verification claim as something to test on their own traffic before trusting it.

The third is cost sensitivity at the trace level. Tracing every LLM call produces a lot of data, and ClickHouse is in the stack because the volume is expected to be large. A team that wants sampled traces only, or that already has a mature OpenTelemetry pipeline with its own storage, will find the migration cost hard to justify.

## How Latitude differs from a plain OpenTelemetry backend

The obvious alternative is running OpenTelemetry into a general-purpose observability backend: spans in, dashboards out, alerting on top. That approach is more portable and has no opinion about your agent. It also puts the entire burden of interpretation on you. A span tells you a tool call failed. It does not tell you that the same failure has occurred 400 times this week, that it started after a prompt change, and that a coding agent could probably fix it if it saw three examples.

The difference in approach is where the intelligence sits. A generic backend treats agent failures as telemetry to be queried. Latitude treats them as issues to be resolved, with a lifecycle: signal created, signal sized, agent dispatched, fix proposed, fix replayed. The MCP server and CLI exist so that the same actions are available from inside a coding agent, which is a deliberate bet that the person debugging the agent is already sitting in an editor.

That bet is defensible, but it also couples Latitude to the coding-agent ecosystem. The README names Claude Code and Cursor specifically. If your team does not use an agentic coding tool, the fix half of the loop degrades into a manual workflow, and what remains is a trace viewer with clustering.

## Licence, releases and the cost of staying current

Latitude is MIT licensed, which places few restrictions on commercial use, modification or redistribution. The repository's package.json carries "license": "MIT", and the README links to the LICENSE file. MIT does not cover the hosted service's terms, data retention or pricing, so teams mixing self-hosted tracing with the managed platform should read those separately. Nothing here is legal advice.

On releases, the most recent listed are openclaw-telemetry-cli-0.1.0 and openclaw-telemetry-0.1.0 on 2026-09-09, and typescript-sdk-9.12.0 on 2026-09-08. The TypeScript SDK is at major version 9 while the telemetry CLI packages are at 0.1.0, which tells you the SDK is the mature surface and the newer telemetry tooling is early. The last push to the default branch (development) was on 2026-09-10.

Upgrade cost is dominated by the self-hosted stack rather than the SDK. Changing ClickHouse versions, Temporal versions or the Postgres image means testing migrations across two databases; the repository has a migrate script that runs Postgres migrations and ClickHouse migrations together. If you self-host, budget for that on every upgrade, not just for the npm package bump.

## Conclusion

Adopt Latitude if your agents run in production and you want failing traces turned into tracked, fixable issues rather than a dashboard nobody reads. Skip it if you only need raw OpenTelemetry spans, or if you cannot run Postgres, ClickHouse, Redis and Temporal alongside your app. Before committing, verify the self-host stack on your own hardware, check whether the free tier's 30-day retention matches your debugging window, and confirm which model providers the telemetry package instruments in the version you install.

## FAQ

### What is Latitude LLM?

It is an open-source observability platform for AI agents, MIT licensed and written primarily in TypeScript. It captures traces, groups failing ones into tracked signals, dispatches a coding agent to propose a fix, and replays the fix against the real failing traces.

### What does Latitude measure?

The README describes capturing every trace, including multi-turn sessions, tool calls and full execution paths. It also groups failing traces into signals with status, size and trend, so you can see what is breaking and how often.

### Is Latitude LLM free to use?

The README states you can use Latitude for free with 20K credits per month, 30-day data retention and unlimited seats. The repository is MIT licensed and ships a docker-compose.yml for self-hosting.

### Which LLM providers does Latitude support?

Latitude describes itself as provider-agnostic. The README lists OpenAI, Anthropic, Amazon Bedrock, the Vercel AI SDK and LangChain among the documented integrations, with Python and any OpenTelemetry-compatible runtime also supported.

### Can I self-host Latitude LLM?

Yes. The repository includes a docker-compose.yml that starts Postgres, ClickHouse, two Redis instances, Mailpit and Temporal, plus a .env.example with the required LAT_ prefixed application variables. It is a multi-service deployment, not a single container.

## Sources

- [latitude-dev/latitude-llm on GitHub](https://github.com/latitude-dev/latitude-llm)
- [License: MIT](https://github.com/latitude-dev/latitude-llm/blob/development/LICENSE)
- [Project website](https://latitude.so)
- [README](https://github.com/latitude-dev/latitude-llm/blob/development/README.md)
- [Releases](https://github.com/latitude-dev/latitude-llm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/latitude-dev-latitude-llm