n4nAI

LangSmith vs Langfuse: comparing agent tracing tools

A pragmatic engineering comparison of LangSmith vs Langfuse for agent tracing: capabilities, cost, latency, ergonomics, ecosystem, and limits.

n4n Team5 min read1,089 words

Audio narration

Coming soon — every post will get a voice note here.

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.

Tagslangsmithlangfusetracingobservability

Written by

n4n Team

The team building n4n — a single OpenAI-compatible API in front of 240+ models, with automatic fallback, load balancing and pay-per-token metering.

More from n4n Team →

All agent observability & tracing posts →