OpenLIT: OpenTelemetry-Native Tracing for AI Agents and Coding Agents

The gap OpenLIT fills between application logs and agent behaviour

A production agent is not one request. The README's own diagram lists the parts: LLM calls, tool calls, retrieval, memory, sub-agents, prompts and code changes, all feeding an evaluation step that produces cost, quality and error signals. Standard application logging captures none of that structure. A log line tells you a function returned; it does not tell you which tool the agent chose, what prompt produced the choice, or what that turn cost.

OpenLIT targets the teams that already feel this. The repository layout points at the intended audience: the SDK directory holds Python and TypeScript instrumentation, the CLI directory holds the coding-agent installer, and the examples directory carries ready-made apps for LangGraph, CrewAI, OpenAI Agents, Anthropic, Bedrock, Gemini, LiteLLM, Mem0 and a non-LLM HTTP case. That spread suggests the project expects mixed stacks rather than a single-framework shop.

The evaluation side is the second half of the pitch. The README lists built-in LLM-as-a-Judge evaluations for hallucination, bias and toxicity, which means the platform is not only a trace viewer. It is trying to answer whether an output was good, not just whether it succeeded.

How OpenLIT works: SDK instrumentation, OTLP export, ClickHouse storage

The mechanism is deliberately conventional. The SDK instruments supported LLM providers, frameworks and vector databases, then exports OpenTelemetry traces and metrics. You can point it at an endpoint in code or through the standard environment variable, and the README shows both forms.

The backend is a two-service Docker Compose stack. A ClickHouse service stores telemetry, and an OpenLIT container serves the dashboard and API. The compose file sets INIT_DB_HOST to clickhouse, INIT_DB_PORT to 8123 and INIT_DB_DATABASE to the openlit database by default, with credentials coming from OPENLIT_DB_USER and OPENLIT_DB_PASSWORD and defaulting to default and OPENLIT. ClickHouse itself exposes 9000 and 8123, and the OpenLIT container listens on port 3000 by default.

There is a second storage path worth noticing. The compose file sets SQLITE_DATABASE_URL to file:/app/client/data/data.db alongside the ClickHouse connection. Telemetry goes to ClickHouse; the SQLite file appears to hold application-side data such as users and sessions. The README does not explain the split, so treat that as an inference from the compose file rather than documented behaviour.

The coding-agent path works differently from the SDK path. Instead of importing a library, you install a CLI, point it at an endpoint with openlit configure, then run openlit coding install --vendor= for cursor, claude-code or codex, or --vendor=all. The CLI writes the instrumentation into those tools rather than into your application code.

Installing OpenLIT and tracing your first agent call

The README's quickstart is four steps. Clone the repository, start the stack with Docker Compose, open the dashboard on port 3000, then install the SDK. The compose command is the whole server setup; there is no separate migration step in the quickstart.

git clone https://github.com/openlit/openlit.git
cd openlit
docker compose up -d

After the containers report healthy, the dashboard is at http://127.0.0.1:3000. The ClickHouse healthcheck runs every 5 seconds with a 100 second start period, so a first start can take well over a minute before the OpenLIT container has a working database behind it.

Install the SDK for your language. Both package names are exactly as the README gives them.

pip install openlit
npm install openlit

For Python, initialisation is a single call. The README's example calls openlit.init() with no arguments and states that OpenLIT then automatically instruments supported providers, frameworks and vector databases.

import openlit

openlit.init()

If the default endpoint is wrong for your setup, set it in code or through the environment. The README gives both, and the port is 4318.

export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:4318"

For coding agents the flow is separate. Install the CLI with the platform script, configure the endpoint, install the vendor integration, then check it.

curl -fsSL https://raw.githubusercontent.com/openlit/openlit/main/cli/scripts/install.sh | sh
openlit configure --endpoint http://127.0.0.1:4318
openlit coding install --vendor=all
openlit doctor

The README states that sessions then appear in the Coding Agents dashboard. What you should see after the Python quickstart is traces, metrics, cost and performance data for your application in the main dashboard.

Where OpenLIT is the wrong tool

The self-hosted design is the main limitation. Running ClickHouse plus the OpenLIT container is an operational commitment: you own upgrades, disk growth and backup. Nothing in the README describes retention policies, sampling controls or a rollback procedure, so plan to verify those yourself before pointing production traffic at it. The compose file mounts a named volume for ClickHouse data, which means the data survives container restarts, but that is not the same as a backup story.

The coding-agent integrations are vendor-specific and shallow by nature. openlit coding install --vendor= supports cursor, claude-code and codex. If your team uses a different coding agent, the CLI path does not cover you, and you are back to the SDK path with whatever instrumentation you write yourself.

Evaluation is LLM-as-a-Judge, which means the quality signal is itself produced by a model. The README lists hallucination, bias and toxicity as built-in types but does not describe how judge prompts are configured or how judge cost is accounted for. For teams that need deterministic, reproducible scoring, that is a real gap.

Finally, if all you want is token counts and spend per model, OpenLIT is heavier than the problem. The ClickHouse backend exists because the data model is trace-shaped, with prompts, tool arguments and retrieval payloads attached to spans. If you are not going to look at spans, you are paying storage and operational cost for detail you ignore.

OpenLIT against Langfuse and against raw OpenTelemetry

The two comparisons people actually search for are OpenLIT versus Langfuse and OpenLIT versus plain OpenTelemetry. They are different questions.

Against Langfuse, the distinction is the data model and the standard underneath it. OpenLIT's traces are OpenTelemetry traces, which means anything that already speaks OTLP can feed it, and the same instrumentation can be redirected to another OTLP backend without changing application code. OpenLIT also ships coding-agent instrumentation for Cursor, Claude Code and Codex, which is a narrower and more specific concern than general LLM application tracing. If your priority is prompt management and a hosted collaboration surface, a purpose-built LLM platform may fit better; if your priority is keeping one telemetry pipeline for both application traces and agent traces, the OpenTelemetry alignment is the reason to pick OpenLIT.

Against raw OpenTelemetry, the difference is what you do not have to build. OpenTelemetry gives you a protocol, SDKs and a collector, not a schema for LLM spans, not cost calculation, not a dashboard, and not evaluations. OpenLIT supplies those on top: automatic instrumentation for supported providers and frameworks, cost tracking across models, providers, users, sessions, agents and environments, custom pricing for fine-tuned models, and the evaluation types listed in the README. The cost is that you adopt OpenLIT's span conventions rather than defining your own, and the documentation does not describe an escape hatch for exporting in a different shape.

Licence, maintenance and the upgrade cost you are signing up for

OpenLIT is licensed under Apache-2.0. That permits commercial use, modification and redistribution, and it includes a patent grant. It does not give you any warranty or indemnity, and it does not oblige the maintainers to support your deployment. If you redistribute a modified version, Apache-2.0 requires you to preserve notices and state changes; that is the clause most teams overlook. This is a description of the licence text, not legal advice, and you should have your own counsel review anything you ship.

The repository is not archived, and the last push was on 2026-09-10. That is recent enough that the project is clearly still being worked on. Three releases cluster around the same period: openlit 2.0.0 on 2026-08-28, otel-gpu-collector 0.0.8 on 2026-08-26, and openlit 2.1.0 on 2026-09-10. Two major-version bumps in under a month is the number that matters for upgrade planning. The README does not document a migration path between 1.x and 2.x, so if you are pinned to an older SDK, budget time to read the release notes before bumping.

The dashboard and the SDK version independently. The compose file pulls ghcr.io/openlit/openlit:latest, which means a docker compose pull can move your server forward without any change to your application. Pin the image tag if you want server upgrades to be a deliberate act rather than a side effect of a pull.

Editorial conclusion

Adopt OpenLIT if you already run OpenTelemetry collectors or want a self-hosted ClickHouse-backed store for LLM and coding-agent traces, and you accept operating that stack yourself. Skip it if you want a managed backend with an SLA, or if you only need token accounting with no tool-call or prompt detail. Before committing, verify the SDK actually emits spans for your framework, confirm the OTLP endpoint and port your SDK sends to, and check whether the coding-agent integrations you need are listed by openlit coding install --vendor.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openlit/openlit on GitHub
3. Project website
4. README
5. Releases