You've done the hard part — you know you need to see what your agent actually did, and you've narrowed the field to two tools. Now you're stuck, because LangSmith and Langfuse look like they do the same things. They do: tracing, evals, prompt management, datasets, cost tracking. Staring at the feature grid won't break the tie, because the tie isn't about features.

It's about ownership. LangSmith asks you to rent the convenience; Langfuse lets you own the data. And here's the fact that makes the whole decision lower-stakes than it feels: both now ingest OpenTelemetry, so the instrumentation in your code is portable. You are not choosing a spouse. You're choosing which backend to point your spans at first.

LangSmith: rent the convenience#

LangSmith is the proprietary, hosted SaaS from the LangChain team, and its superpower is that you run nothing. If your app is already on LangChain or LangGraph, tracing lights up with zero config — every chain, tool call, and token, captured automatically — and the hosted evals, prompt hub, and datasets are polished and managed for you. It's no longer LangChain-only, either: it added OTLP ingestion (OpenLLMetry convention) plus its own exporter, so a non-LangChain app can send traces too.

The trade-offs are the flip side of "you run nothing." It's closed-source — self-hosting is an Enterprise-only option — so your trace data lives in the vendor's cloud. And it prices per seat with trace-volume tiers: a free Developer tier (reported ~5k traces/month, 14-day retention), then a Plus tier reported around $39/seat/month as of mid-2026 (verify — pricing moves). That per-seat model is friction-free at three people and a real line item at thirty.

Rent LangSmith when you live in the LangChain ecosystem, value the least possible ops, and are comfortable with your observability data sitting in someone else's cloud.

Langfuse: own the data#

Langfuse is the open-source counterweight, and it's the one to reach for when ownership is a constraint rather than a preference. Its core is MIT-licensed (~32.6k GitHub stars) — the only genuinely OSI-open-source option in this pair — and you can self-host the entire platform for free, with unlimited events and users. It does the full job (tracing, evals, prompt management, datasets, dashboards, cost tracking) and exposes a native OpenTelemetry endpoint that ingests OpenLLMetry, OpenInference, and OpenLIT spans, so it's framework-neutral by design.

The cost is operational, not licensing: at scale you're running ClickHouse yourself, and that's real work. If you'd rather not, Langfuse's managed cloud starts on a free Hobby tier and steps up (a Core tier reported around $29/month, mid-2026 — verify). Notice the cost shape differs from LangSmith's: you're paying for infrastructure or usage, not per head, which is why cost-sensitive teams tend to pull ahead here as they grow.

Own Langfuse when data residency, an OSI-open license, or per-seat-free scaling is the deciding factor — and you have (or don't mind renting) a little ops muscle.

Both tools speak OpenTelemetry now, so your instrumentation is portable. The lock-in that remains lives above tracing — in evals, prompts, and dashboards — which is exactly the layer you'd have to rebuild if you switched. So standardize the instrumentation, and the backend becomes swappable.

How to actually decide#

Answer three questions in order and the tie breaks itself:

Whichever you pick, do one thing first: standardize your instrumentation on an OpenTelemetry convention now. That single move turns this from a high-stakes marriage into a reversible bet — because once your spans are portable, changing your mind later is a config change, not a rewrite.

And if your real shortlist is all open-source — no proprietary SaaS on the table — this isn't quite the right pair. We compared the three OSS options head-to-head in Langfuse vs Laminar vs Arize Phoenix; start there instead. Either way, observability is the half of shipping an agent that tells you whether it's actually working — which pairs naturally with deciding where the agent itself should run.