Langfuse: open-source tracing, evals and prompt management

Langfuse records what your LLM application did, scores how well it did it, and versions the prompts it used, in one open-source platform. Server v4.58.0 shipped on 13 October 2026. The Python SDK is at 4.17.0 and the JS/TS SDK at 5.13.1.

Langfuse covers three jobs that teams otherwise buy separately:

• Observability. Traces of every LLM call, tool call, retrieval and agent step, grouped into sessions and attributed to users, with token usage, cost and latency.
• Evaluation. Scores from code, from people in annotation queues and from LLM-as-a-judge evaluators; datasets; and experiments that compare a new prompt or model against a baseline.
• Prompt management. Versioned prompts with deployment labels, fetched by your app at runtime and linked to the traces that used them, plus a playground.

In the stack it is the observability and evaluation layer. Your app sends spans through the Langfuse SDKs or any OpenTelemetry exporter, a gateway such as LiteLLM can send its own spans, and a collector in between can redact and sample.

ClickHouse acquired Langfuse in January 2026. The announcement says the whole team joined ClickHouse, there are no planned changes to licensing, self-hosting stays a first-class path and Langfuse Cloud runs as before. The licence file now names ClickHouse, Inc.: code outside the ee/ directories is MIT, and the few enterprise add-ons inside them need a licence key. Langfuse Cloud runs in the EU (cloud.langfuse.com), the US (us.cloud.langfuse.com), Japan and a HIPAA region.

Pick Langfuse when:

• You want one open-source tool for traces, evals and prompts, and you may self-host. Every core feature is MIT and unlimited when self-hosted, including enterprise SSO and organization-level roles.
• Product people edit prompts. Labels such as production let them ship a prompt version without a code deploy, and every trace shows which version ran.
• You want evaluations next to the traces they score: an LLM judge on live production observations, experiments on datasets in CI, human review in annotation queues.
• Your services already speak OpenTelemetry. Langfuse ingests OTLP over HTTP and reads both gen_ai.* and OpenInference attributes.

Look elsewhere when:

• You need infrastructure APM for every service. Langfuse is built for LLM traces; keep Datadog, Grafana or similar for the rest and send LLM spans to both if needed.
• You would self-host but cannot run ClickHouse, Postgres, Redis and object storage. Use Langfuse Cloud, or a lighter tool such as Arize Phoenix, which runs on SQLite or Postgres alone.
• You want gateway features (keys, budgets, failover). Langfuse observes; it does not route. Pair it with LiteLLM.

The nearest alternatives are Arize Phoenix (Elastic License 2.0, OpenInference-native), Laminar (Apache-2.0, built for long-running agents), Traceloop (commercial, now part of ServiceNow), Braintrust (commercial, evaluation-first), and Helicone, which is in maintenance mode.

Observations first. Since v4 every LLM call, tool execution and agent step is one row in a wide ClickHouse table, with the trace-level attributes (user, session, tags, release, version) copied onto each row. A trace is its root observation. Observation types are span, generation, event, agent, tool, chain, retriever, evaluator, embedding and guardrail; generations carry model, token usage and cost. Langfuse Cloud has run on this model since early 2026, and self-hosted v3 gets security patches until 31 January 2027.

SDKs are OpenTelemetry. The Python SDK v4 and the JS/TS SDK v5 create OpenTelemetry spans and export them to Langfuse. You trace with the @observe() decorator, with start_as_current_observation() context managers, or with drop-in wrappers such as from langfuse.openai import openai. Correlating attributes (user_id, session_id, tags, metadata) go through propagate_attributes(), which stamps them on every child observation. By default v4 exports only LLM-relevant spans: Langfuse's own, spans with gen_ai.* attributes and known LLM instrumentation scopes, not your HTTP and database spans.

Ingestion is queued. The web container receives batches, writes them to S3 first, and queues a reference in Redis; the worker container loads them into ClickHouse. A traffic spike fills the queue instead of failing requests, and events survive a database outage. Expect a short delay before new data appears.

Scores are NUMERIC, CATEGORICAL, BOOLEAN or TEXT, attached to a trace, an observation, a session or an experiment run. Prompts are cached in the SDK for 60 seconds by default; after that the stale version is served instantly while a fresh one loads in the background, and a fallback prompt covers a cold start with the API down. Experiments run a task over a dataset or a local list, apply your evaluators, and record each item as a trace you can compare run against run.