Deciding between LangSmith vs Langfuse for agent observability is not just a matter of brand preference; the two tools diverge sharply on deployment model, cost structure, and how they handle the messy reality of multi-step LLM workflows. Both capture traces, spans, and token counts, but the ergonomics of wiring them into a production agent and the long-term bill you’ll pay are different enough that the choice shapes your architecture.
Capabilities
Trace capture and span modeling
LangSmith treats every run as a node in a tree of runs; nested chains, tools, and retrievers become child runs with automatic token streaming and exception capture. For non-LangChain code you decorate functions with @traceable and the client builds the hierarchy from context variables. Langfuse models the same reality as “observations” — spans, generations, and events — with explicit session and user IDs attached at the root. Its @observe decorator populates the parent link via contextvars, so async loops and thread pools stay correct.
Both tools show latency waterfalls and per-step I/O, but LangSmith’s run object carries LangChain-specific metadata (e.g., prompt template hashes) that Langfuse does not infer unless you add it.
Evaluations and datasets
LangSmith has first-class datasets and an evaluate() runner that scores traces with custom functions or LLM judges offline:
from langsmith import evaluate
evaluate(dataset_name="qa_pairs", pred_fn=my_agent, evaluators=[exact_match])
Langfuse mirrors this with datasets and scorecards, plus a UI for annotating production traces. Its eval SDK is younger; you typically push scores via langfuse.score() rather than a single built-in runner. The difference is maturity, not coverage.
Feedback and prompt management
LangSmith’s feedback API lets end users send a thumbs-up that lands on the exact run:
client.create_feedback(run_id, "user_score", value=1)
Langfuse exposes /feedback with similar semantics. On prompts, LangSmith’s hub pulls versioned prompts by name at runtime; Langfuse prompts are versioned and fetchable via SDK, but collaboration (comments, staged rollouts) is lighter.
Self-hosting and data residency
Langfuse is MIT-licensed and runs from a docker-compose with Postgres or ClickHouse; your traces never leave your VPC. LangSmith is closed-source SaaS with no self-hosted edition. Enterprise contracts can mandate data residency, but the default is LangChain’s cloud.
Price / Cost Model
LangSmith meters on traced runs plus seat licenses. A single agent turn that calls a retriever, three tools, and a final LLM easily generates 10–20 runs; each is a billable unit on lower tiers. Free allowances exist but evaporate at production volume.
Langfuse is free if you self-host — you pay only for your own compute and storage. Its managed cloud bills on ingested events (spans/generations) with a free tier and usage caps you set. Because you control sampling, you can drop low-value spans to zero cost. In the LangSmith vs Langfuse debate, the cost wedge is granular instrumentation: LangSmith penalizes fine spans, Langfuse lets you throttle them.
Neither publishes flat per-token rates; both meter on trace objects, so the real lever is instrumentation depth.
Latency / Throughput
Instrumentation overhead is non-blocking in both. Langfuse’s Python SDK batches observations and flushes on a background thread; misconfigured flush intervals delay visibility but never block the request path. LangSmith’s client sends runs over a similar background worker.
Per span, batched overhead is sub-millisecond. The throughput ceiling is usually the ingestion endpoint: Langfuse self-hosted on a single Postgres node will drop or queue spans past a few thousand writes/sec unless you scale the DB. LangSmith’s cloud absorbs bursts but applies per-project rate limits. No vendor benchmark survives contact with a 50-tool agent loop — your span count per turn is the only number that matters.
Ergonomics
SDK footprint
LangSmith:
from langsmith import traceable
@traceable(name="retrieve_docs")
def retrieve(query: str):
return vector_store.search(query)
Langfuse:
from langfuse.decorators import observe
@observe(name="retrieve_docs")
def retrieve(query: str):
return vector_store.search(query)
Langfuse ships TypeScript decorators with identical semantics, which matters if your agent runs on Node. LangSmith supports JS but its Python story is deeper.
Setup friction
LangSmith needs LANGCHAIN_API_KEY and LANGCHAIN_TRACING_V2=true; on LangChain it’s zero code. Langfuse needs LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY, and an SDK init. Self-hosting adds a docker stack and a migration step.
UI debugging
LangSmith’s trace view embeds a playground to re-run a prompt inline with edited variables. Langfuse shows clean session groups and token costs but requires copying I/O into its prompt editor to iterate. For quick root-causing, LangSmith is faster; for audit trails, Langfuse’s session view is clearer.
Ecosystem
LangSmith is natively coupled to LangChain but exports OpenTelemetry, so you can ship runs to Grafana. Langfuse was OTel-native from day one and accepts OTLP from any service without its SDK.
If you route model calls through a gateway like n4n.ai, both tracers can ingest the forwarded provider cache-control hints as span attributes, letting you see cache hits versus misses per LLM call without custom plumbing.
Langfuse’s open-source community ships integrations for LlamaIndex, Haystack, and LiteLLM quickly; LangSmith’s official LangGraph debugging (state snapshots, node timing) is deeper and closed-source.
Limits
LangSmith’s hard limit is deployment: no self-host, export bounded by API rate caps, and indexed metadata fields cost money. High-cardinality tags are fine but billed. Langfuse’s limit is operational — self-hosting ClickHouse is not free in engineer time, and its cloud restricts SSO on lower plans.
Both cap retention by plan; LangSmith defaults to 30 days on cheap tiers, Langfuse lets you set TTL in self-host config. Neither treats binary payloads (images, audio) as first-class — they store URLs or base64 that bloat spans. Query latency over millions of traces degrades on both unless you archive.
Head-to-Head Comparison
| Dimension | LangSmith | Langfuse |
|---|---|---|
| Deployment | Closed SaaS, no self-host | Open-source, self-host or cloud |
| Cost model | Seat + per-trace usage | Free self-host; per-event cloud billing |
| Trace model | Nested runs, auto token stream | Observations (span/gen/event) + sessions |
| Evaluations | Datasets, judges, prompt hub | Datasets, scores, lighter prompt UI |
| Latency overhead | Background thread, sub-ms batched | Async batch, sub-ms batched |
| SDK languages | Python, JS | Python, JS, OTel-native |
| Data residency | Enterprise tiers only | Your VPC if self-hosted |
| Limits | No self-host, export rate caps | Ops burden, SSO paywalled on cloud |
Which to Choose
LangChain-first teams shipping fast
If you already use LangChain/LangGraph and need evaluations this week, LangSmith vs Langfuse isn’t a contest. Zero-config tracing and the inline playground win. Accept SaaS lock-in and watch per-trace spend by coalescing spans.
Privacy-regulated or on-prem shops
Choose Langfuse and self-host. Full trace ownership, aggressive sampling, no third-party prompt leakage. Budget one engineer to maintain ClickHouse and upgrades.
High-volume, cost-sensitive agents
Langfuse cloud with sampled spans is cheaper at scale because you control ingestion. LangSmith’s per-run metering punishes fine-grained instrumentation; you’ll either reduce span depth or pay steeply.
Hybrid or multi-framework services
If you run LangGraph plus a Go planner, Langfuse’s OTel-native design unifies them without a LangChain dependency. Use LangSmith only if you stay inside its ecosystem.
Pick the deployment constraint first; UI differences are survivable, data residency and billing model are not.