Pick your LLM tracing layer with two questions: what shape is your stack, and where are your traces allowed to live. Everything else in the Langfuse vs LangSmith comparison, and both feature lists have grown long, is a tiebreaker. We picked Langfuse, and this post walks the comparison the way we actually ran it, with our reasons stated as our reasons rather than universal truths.
One disclosure before any feature talk, because it changes how you should read every section. We run Langfuse in production. We have evaluated LangSmith, but we do not operate it in production. The Langfuse half of this post comes from production scars; the LangSmith half comes from hands-on evaluation and public documentation, checked as of mid-2026. Most vendor comparisons blur that line. Keeping it sharp is the point of this one.
What the tracing layer must do in production
Both products describe themselves as LLM engineering platforms, and both cover tracing, evals, prompt management, and datasets. The production job description is narrower and harsher: sit in the seam of every request and answer questions about money and failure fast enough to matter, while holding payloads you may not be allowed to ship anywhere.
The money question first. On an analytics platform we built for an IoT product, one user question can fan out from a router to multiple specialists, and eyeballing the bill stops working the moment that fan-out exists. Langfuse traces every request end to end there with per-task cost attribution, so when spend moves we see which task class moved it and whether the router or a specialist misbehaved. The full architecture is in the anatomy of a production multi-agent platform; the tracing layer is what makes that architecture auditable.
The failure question second. The failures that hurt in production return HTTP 200, which is the whole argument of our silent-failures post. When an answer is wrong rather than absent, the trace holding the exact prompt, retrieved context, and response is the artifact you triage from. On a client platform we operate, Langfuse prompt traces are one leg of a triage stack that keeps mean time to recovery under five minutes: an alert fires, and the trace shows the exact prompt and payload that produced the bad answer.
That is the bar. Now the two candidates.
Langfuse from the production seat
Langfuse is open source and self-hostable, with OTel-based SDKs and integrations for LiteLLM, the OpenAI SDK, LangChain, and the Vercel AI SDK, among others. The cloud version is usage-priced; the self-hosted core is free to run, as of mid-2026.
Three constraints put it in our stack, and all three are about us rather than about Langfuse's brochure.
Self-hosting kept payload custody. Traces are prompts and responses, which on client work means client data. Self-hosting Langfuse keeps every payload inside infrastructure we control, which turned a data-processing conversation into a non-event on contracts where a third-party trace store would have been a negotiation.
Framework-agnostic matched our stacks. Our platforms route model calls through LiteLLM rather than through LangChain end to end. A tracing layer that assumes a specific framework would be instrumenting a layer we do not have. Langfuse's OTel-based SDKs wrap the call sites we actually own.
The open-source core removed a vendor from the seam. The tracing layer touches every request, which makes it the most expensive dependency in the system to replace. An open-source core means that if the company behind Langfuse changes direction, the code we run keeps running and a fork stays possible. We hope never to need that property. We were unwilling to bet the seam on never needing it.
The honest cost: self-hosting is paid in operations. Langfuse v3 wants Postgres, ClickHouse, Redis, and blob storage, and you own every upgrade. The zero license fee is real, and so is the pager duty for four stateful services.
LangSmith from evaluation and the docs
Restating the honesty clause where it matters most: we have evaluated LangSmith hands-on and read its documentation closely, and we have never carried it through a production incident. What follows is informed opinion without scar tissue behind it.
LangSmith is LangChain's commercial platform. It is SaaS-first, with self-hosting available as an add-on to enterprise plans, deployed on Kubernetes with a license key, as of mid-2026. The feature surface matches Langfuse's on paper: tracing, evals, datasets, prompt management with a playground.
Here is the steelman, and it is strong. If your stack is LangChain or LangGraph end to end, LangSmith's integration depth is the shortest path to full observability. Tracing turns on with environment variables, and the trace tree mirrors your graph structure. Evals plug into the same primitives your agents are built from. In that stack, choosing anything else is self-inflicted friction: you would be re-instrumenting by hand what the ecosystem hands you for free.
In our evaluation, LangSmith's rendering of LangGraph runs stood out in a way generic SDK integrations did not match, and that is precisely the coupling working as designed. The same coupling means that outside the ecosystem you fall back to generic SDKs and lose the main advantage.
The feature table
Compressed to a table, with the volatile rows qualified as of mid-2026.
| Capability | Langfuse | LangSmith |
|---|---|---|
| Tracing | End-to-end traces via OTel-based SDKs; per-task cost attribution | End-to-end traces; richest rendering on LangChain/LangGraph runs |
| Evals | LLM-as-judge and custom scorers over datasets and experiments | Evals, datasets, annotation queues, built on ecosystem primitives |
| Prompt management | Versioned prompts with deploy labels, fetched at runtime | Prompt versioning plus playground, tied into the ecosystem |
| Self-hosting | Free, open-source core; Docker Compose up to Kubernetes | Enterprise-plan add-on; Kubernetes with a license key |
| Framework coupling | Agnostic: OTel, LiteLLM, OpenAI SDK, LangChain integrations | Deepest inside LangChain/LangGraph; generic SDKs elsewhere |
| Pricing model | Usage-tiered cloud; self-hosting free (mid-2026) | Seat-based plans plus usage-based tracing (mid-2026) |
| Data residency | Your infrastructure by default when self-hosted; cloud offers EU and US regions | Your infrastructure on enterprise self-host; vendor SaaS otherwise |
Decision rules
Two rules cover most teams.
Rule one, stack shape. If LangChain or LangGraph is your framework end to end, take LangSmith and stop reading comparison posts. If your stack mixes frameworks or routes through LiteLLM and raw provider SDKs, Langfuse instruments the code you actually have.
Rule two, data residency. If prompt and response payloads must stay inside your infrastructure and an enterprise contract is out of proportion for your size, self-hosted Langfuse is the only door that opens at that budget. If SaaS custody is acceptable, or enterprise procurement is already in motion, both platforms can meet you.
When the rules disagree, decide which constraint is load-bearing. A LangGraph shop with hard residency requirements and no enterprise budget lands on self-hosted Langfuse and accepts thinner integration. A mixed-stack team with loose residency requirements could still run LangSmith, but it would pay coupling costs for depth it cannot use.
The tiebreaker is horizon. The tracing layer sits in the seam of every request, so it is the dependency you will hold longest, and the longer you expect the system to live, the more an open-source core weighs.
Where our seat sits
Our receipts are Langfuse-side and disclosed as such; the reasons were stack shape and payload custody, and yours may differ. The platforms behind those receipts are summarized in the operator brief, and the live demo runs the same tracing discipline on the smallest system we operate. Evaluate LangSmith if your stack earns it. Whichever you pick, pick it for the shape of your stack and the custody of your data, and instrument the seam before the bill or the first silent incident forces the question.