LangSmith vs Langfuse (2026): which to pick, and where both stop

LangSmith if you build on LangChain or LangGraph. Langfuse if you don’t, or if you want open source and self-hosting. That’s the honest answer to the question, and you can stop here if all you need is a tracer. But it’s the smaller decision. Both are recorders. Neither tells you whether your agent is any good.

LangSmith vs Langfuse at a glance

Sources: LangChain pricing, LangSmith usage and billing, LangSmith data export, Langfuse pricing, ClickHouse acquires Langfuse. Checked 14 Oct 2026.

Where they’re the same

Recording a trace is close to a solved problem. Both tools capture nested spans, LLM calls, tool calls, tokens and cost. Both accept OpenTelemetry. Both manage prompts, store datasets, run LLM-as-judge evaluators and give you annotation queues. If you put the two feature lists side by side, you’ll spend an afternoon finding a difference that matters to your agent.

So don’t pick on features. Pick on the three things below.

Where they differ

Framework gravity. LangSmith is built by the LangChain team, and it shows. LangGraph traces land with their graph structure intact, and the deployment tooling sits in the same product. If your agent is a LangGraph app, LangSmith is the shortest path. If it isn’t, that advantage is worth nothing to you.

Pricing shape. LangSmith charges per seat. Langfuse charges per unit of data, with unlimited users from Core upwards. Neither is outrageous. They just punish different things: LangSmith gets dearer as more people look, Langfuse as more traffic flows.

Who keeps your history. This is the one I’d weigh most in 2026. LangSmith base traces expire after 14 days. From 14 Sep 2026, the longest retention a SaaS customer can buy is 180 days, down from 400. And if you signed up after 3 Aug 2026, bulk export is Enterprise-only. Your agent’s history ages out unless you pay, and taking it elsewhere got harder this year. Langfuse is open source and self-hostable, so the exit is always there.

One smaller point, from building integrations against both. A Langfuse API key is scoped to one project, so connecting it to anything is a single paste. A LangSmith key is scoped to a whole workspace, which means a project picker and a key that can see more than it needs to. Not a reason to choose on its own. It does tell you which one was designed to be built on.

Where both stop

Here’s the part the comparison pages leave out. You don’t buy a tracer to have traces. You buy it to make the agent better. And on that job, both tools stop at the same four places.

You can record it, but can you see it?

Three founders have told me they couldn’t see what their agent was doing. They had the traces. They couldn’t read them.

The reason is that different use cases need different views. A support conversation should read like a chat, turn by turn, with the moment it went wrong in front of you. A piece of generated marketing copy should be annotated as copy, not as a JSON blob three levels down a span tree. Langfuse lets you build those views. Configuring them is tiresome. A good product knows what you need to see in each context and shows you that by default.

Hamel Husain and Shreya Shankar make the same point in their evals course: show an email as an email. Generic trace viewers break down on exactly the traces that matter.

So recording is a commodity. Viewing isn’t yet.

You can annotate it, but what’s the method?

Both tools give you annotation queues. Neither has an opinion on how to use them. That’s like being handed a pen and paper and told to measure quality.

Annotating every trace isn’t an option. You need to know which traces to label, how many, and how to turn a few dozen labels into a number for the whole population, with error bars. That framework isn’t easy to build yourself, and it’s harder to keep up as your judges and your data drift. Without it, you have a pile of labels, not a measurement. I’ve written more on what makes a good LLM judge.

You can score it, but does the score move anything?

The outcome your agent exists for is usually not in your tracer. One customer runs a sales agent whose success is measured in sends. Sends live in their product database. None of them are in the traces.

Evals without outcomes are a fine starting point. They’ll give you a well-behaved agent. But if you want to move the number the business cares about, you need to know which evals actually predict it. That connection lives between two systems, and neither tracer reaches across.

You have the score. What do you change?

The last gap is the playbook. Say a judge tells you 18% of conversations fail. Now what? Change the prompt, swap the model, add a tool, split the agent? I’ve spoken to a team with scores on everything and no idea what to change next. The data was there. The path from a score to a tested change wasn’t.

Tracing tools were built to answer “what happened”. The question that matters by month three is “what do we change, and did it work”.

Which should you choose?

• Your agent runs on LangChain or LangGraph: LangSmith. The integration is deeper and the deployment tooling is in the same place. Budget for retention if you need history beyond 14 days.
• Any other framework, or none: Langfuse. Flat pricing with unlimited users, open source, and you own the exit.
• You need to self-host: Langfuse. It’s free to run yourself.
• You own whether the agent is any good: keep whichever tracer you have and add an eval analytics layer on top. That’s what TwoTail is. It connects to Langfuse with a pasted key and no code change, and takes OpenTelemetry from anything else.

Disclosure: I build TwoTail, so weigh the last bullet accordingly. The first three stand on their own.