Best LLM Observability Tool 2026: Langfuse vs LangSmith vs Helicone

The structural question is whether you instrument your code or put a proxy in front of it, and that decides what you can see. Read down and stop at the first line that describes you.

LLM observability captures and stores traces of your model calls — prompts, completions, latency, token usage and cost — so you can debug failures, spot quality regressions and watch spend in production. It is ordinary application observability extended to behaviour that is non-deterministic, where the same input can produce a different output and "it broke" often means "the output got worse", not "it threw".

That is a different job from evaluation. Observability watches what your system does after it ships; evaluation tells you whether a change is safe to ship in the first place. Many teams run both, and several of these tools do both, but the questions are distinct. For the pre-release half, see the best LLM evaluation tools.

Each tool optimises a different point in the stack rather than competing feature for feature. Prices were read from each vendor's own pricing page on 28 August 2026, and repository figures from the GitHub API the same day.

Langfuse is the default recommendation because it has the broadest integration list, a genuinely free self-hosted core, and the lowest switching cost if you change your mind. It is also the one with the most caveats, and they are worth knowing before you commit.

If your application is built on LangChain or LangGraph, LangSmith traces it with no configuration at all, and nothing else matches that. Outside that ecosystem the argument weakens considerably.

Helicone is structurally different from the other three: it sits in front of your API call as a proxy rather than inside your code as an SDK. That single decision explains both its biggest advantage and its main limitation.

PromptLayer is narrower than the other three, and that is the point rather than a flaw. It does prompt versioning and request logging, and it does not pretend to be a full observability platform.

ClickHouse, Inc. acquired Langfuse on 16 January 2026, announced alongside ClickHouse's $400 million Series D led by Dragoneer. The acquisition was reported at the time by SiliconANGLE and confirmed on ClickHouse's own blog, in a Langfuse GitHub discussion, and by the law firm that advised on the deal.

The clearest evidence is in the repository itself: the LICENSE file now opens with "Copyright (c) 2023-2026 ClickHouse, Inc." The project remains actively developed and was pushed the day this page was checked.

There is a coherent logic to it. Langfuse already stored traces in ClickHouse, so the acquirer owns the database underneath the product rather than being an unrelated buyer. That is a better setup than most acquisitions in this category. The consideration is still worth naming: roadmap priorities after an acquisition follow the acquirer's commercial interest, and Langfuse self-hosted now depends on a company that also sells ClickHouse Cloud. The Enterprise self-hosted tier is explicitly bundled with ClickHouse Cloud or BYOC, with those costs additive.

Langfuse is the only one of the four that documents and supports a free self-hosted deployment — but the widely repeated claim that there is no feature gate between free and paid is wrong. Langfuse's own self-host page lists nine capabilities as Enterprise-only: server-side data masking, project-level RBAC, data retention management, SCIM user provisioning, organization creators, UI customisation, audit logs, admin and instance management APIs, and protected deployment labels.

Read that list against who self-hosting is usually for. Teams choose to self-host because of data residency or regulatory pressure, and RBAC, audit logs and data masking are exactly what a regulated team needs. The free tier genuinely covers observability, evals, prompt management, datasets, tracing and cost tracking with unlimited usage. It does not cover governance.

The other three are more straightforward. LangSmith restricts self-hosting to Enterprise with custom pricing. PromptLayer offers single-tenant self-hosting on GCP, AWS or Azure at Enterprise only. Helicone is the interesting case: the code is Apache-2.0 and public, but the pricing page sells on-prem only at Enterprise and documents no supported free self-host path, so open source and supported self-hosting are not the same thing here.

All four bill on a hybrid model — a seat or platform fee plus metered usage beyond an included quota — so two teams on the same tier can get very different invoices. Volume drives the bill more than headcount does, with LangSmith the clearest example.

Helicone is built around cost visibility, and the proxy architecture is why. Because every call passes through it, cost and token data are captured by default on every request without anyone deciding what to instrument — so there are no blind spots from a service someone forgot to wrap.

Langfuse and LangSmith both track token usage and cost per trace as part of their broader observability data, which is sufficient for most teams. Neither presents cost management as a standalone product surface the way Helicone does. PromptLayer records cost per request but reports it through its logging views rather than a dedicated cost dashboard.

The honest framing is that this is a difference of emphasis, not capability. If you want to answer "which model and which key is burning our budget across twelve services", Helicone answers it fastest. If you want to answer "why did this agent run cost eleven dollars", an SDK tracer that sees the individual steps will serve you better.

Stack, data-residency requirements and team size decide this. Six profiles cover most readers.

Observability traces contain the full prompt and completion, which means they contain whatever your users typed. That makes the hosted-versus-self-hosted decision a data-protection question in three major markets.

If you are still prototyping — a few dozen manual calls a day, no production traffic, nobody else who needs to see the traces — skip all four and use the provider dashboards. The OpenAI usage page and the Anthropic console already show you spend and request volume, and print statements cover the rest at that scale.

The threshold worth waiting for is concrete: real users generating traffic you did not personally trigger, or a second person who needs to answer "what did it do" without asking you. Both are visibility problems, and that is what these tools sell. Adopting one before then means configuring a platform against usage patterns you have not discovered yet, and most teams reconfigure it once real traffic arrives anyway.