You don't choose between LangSmith and Langfuse. Your stack chooses for you.

Automation Engineering · By Caleb Sakala · April 16, 2026

Support ticket classifier in production. Three weeks live, accuracy has dropped from 94% to 71%. The engineer opens LangSmith, runs a trace session, spends 45 minutes identifying that the model is tokenizing a specific vendor name inconsistently across runs. The fix is prompt-level. They push the change and two days later are back in LangSmith for a different failure. It is now two hours a day.

That is the pattern, not the exception. LangSmith and Langfuse are both useful tools. But how much time a team spends in them, and which one they actually need, tells you something more specific than most comparison posts acknowledge.

The short version: if a team is deep in LangChain or LangGraph, LangSmith is the right default. If the stack is anything else (raw OpenAI or Anthropic API calls, LlamaIndex, Haystack, custom pipelines), Langfuse is the right default. That decision settles about 80% of the comparison. The rest comes down to cost and compliance.

What LangSmith gets right

LangSmith is developed by the LangChain team, and this is its primary strength: the integration is native and deep. When running a LangGraph agent, LangSmith renders the full execution graph as a run tree, showing each node, its inputs, its outputs, and its latency. Debugging an agent that misfired on step 4 of a 7-step chain is a 5-minute task in LangSmith. Without it, the same task requires reconstructing execution order from scattered logs.

The evaluation layer is also mature. LangSmith lets teams build datasets from production traces, capturing the real inputs that caused failures, annotating them, and adding them to an eval set. Teams can then run LLM-as-judge or human-annotation scoring, and integrate eval runs into a CI/CD pipeline so that a regression blocks a deploy. As of 2026, that capability is non-trivial. Most teams running evals are still working from ad hoc scripts against a static spreadsheet.

Where LangSmith breaks

Two failure modes matter in practice.

Vendor lock-in compounds over time. LangSmith's native tracing uses LangChain's run tree model. If a team later migrates off LangChain to a raw API approach or a different orchestration framework, the observability stack gets rebuilt from scratch. Teams that moved from LangChain to custom tooling consistently report this as a two-to-four-week migration cost. The monitoring layer stays coupled to the framework choice long after the framework itself becomes optional.

Pricing scales poorly at high volume. The free tier gives 5,000 root traces per month, roughly 5,000 LLM calls if running single-step chains, or 500 to 700 agent runs on a multi-step workflow. The Plus plan runs $39 per seat per month with expanded limits, but volume overages push a 10-person team past $400/month at scale. Teams running more than 50,000 agent runs monthly should model the cost before the lock-in accumulates.

What Langfuse gets right

Langfuse is framework-agnostic. It uses an OpenTelemetry-compatible tracing model that works with any stack: LangChain, LlamaIndex, direct OpenAI calls, Anthropic calls, or custom pipelines. The integration is a drop-in wrapper around an existing API client:

from langfuse.openai import openai # drop-in wrapper, no other changes needed response = openai.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}] ) # Langfuse captures: model, token counts, latency, cost per trace # gpt-4o-mini costs $0.15/M input tokens, $0.60/M output tokens

No decorator changes. No framework rewrite. For teams not using LangChain, this is the entire argument.

The self-hosting option is real and practical: Postgres, ClickHouse, and Redis, documented clearly in the public repo. Langfuse has 23,100 GitHub stars and ships under MIT license (per Cekura's April 2026 tracking). For teams with GDPR or HIPAA requirements, this matters: LLM inputs and outputs that include personal data cannot route through third-party SaaS without compliance overhead. Self-hosted Langfuse removes that problem entirely.

Cost tracking is also more granular than LangSmith. Langfuse surfaces token cost per trace, per user, per session, and aggregated by model. For a team managing several LLM API accounts and trying to understand which workflows are expensive, Langfuse's cost attribution is noticeably more actionable.

Where Langfuse breaks

The evaluation tooling requires more configuration. LangSmith's eval framework is prescriptive: follow a pattern and it works. Langfuse's scoring system is flexible but demands manual setup, including defining scoring functions, wiring up SDK calls, and building the feedback loop. Teams that want evaluations running immediately after setup will find LangSmith faster. Teams that need to customize their eval pipeline will find Langfuse more tractable long-term.

Alerting is also thinner. LangSmith has built-in monitoring alerts for latency spikes and error rate changes. Langfuse surfaces the data, but the alerting layer is largely left to existing infrastructure (Datadog, PagerDuty, or similar). If no alerting setup exists already, this creates extra work before the monitoring is actually operational.

The actual decision

The framework dependency is the deciding variable.

Running LangChain or LangGraph as the primary orchestration layer? Start with LangSmith. The run tree visualization alone is worth it, and the native eval integration pays for itself within the first regression incident.

Running anything else: raw API calls, LlamaIndex, custom step-by-step pipelines, or workflows built on platforms like Chase Agents where each step declares explicit inputs and outputs? Use Langfuse. The drop-in wrapper works in 10 minutes, self-hosting is viable, and there is no accumulating dependency on LangChain through the monitoring stack.

For compliance-sensitive environments (healthcare, fintech, any team where LLM inputs could contain PII), Langfuse's self-hosting is the deciding factor regardless of framework. Routing LLM calls with patient data through a third-party SaaS is a compliance review waiting to happen.

Cost math at 100,000 calls per month

The numbers diverge at scale.

Langfuse's free tier covers 50,000 units per month. One unit roughly equals one observation; a single LLM call generates two to three units. At 100,000 calls, the volume is approximately 200,000 to 300,000 units. Cloud Pro runs $59/month at that volume. Self-hosted is $0 beyond existing server costs.

LangSmith's free tier provides 5,000 root traces per month. At 100,000 calls, a team is on the Plus plan at $39/seat/month. For a team of five that is $195/month; for a team of ten, $390/month before volume overages. The ZenML engineering team benchmarked heavy eval workloads for a 10-person team at $400 to $600/month.

Self-hosted Langfuse at 100,000 calls per month versus LangSmith at the same volume is $0 versus $195 to $600+. That differential changes procurement conversations.

What observability debt is actually signaling

Here is what most comparison posts skip: the amount of time a team spends in observability tooling is a signal about AI architecture, not just monitoring quality.

When an AI workflow is non-deterministic, where the model makes judgment calls that vary with context, deep trace debugging is unavoidable. Open-ended research agents, complex multi-step reasoning chains, content generation with fuzzy quality criteria: these workflows are hard to predict by design, and observability tooling is the right investment.

A large fraction of production AI workflows are deterministic in disguise. "Route this support ticket to billing, engineering, or general" has a finite decision space. "Extract line items from this invoice PDF" is an extraction task with a clear success criterion. "Send a Slack message when a GitHub action fails" is a trigger with no ambiguity. These workflows often run as LLM calls inside an agent loop, then fail unexpectedly, and teams spend debugging cycles in LangSmith or Langfuse trying to understand behavior that should have been constrained by the architecture.

A support ticket classifier with a 23-point accuracy drop almost always has an architecture fix, not a monitoring fix. Observability tools surface the symptom. Fixing it requires going upstream.

Chase Agents workflows handle this at the structural level: each automation step declares its inputs, its outputs, and the specific tools it can call. For a support ticket routing workflow, the classification model runs once per ticket with a constrained output schema, and the routing logic is an explicit rule downstream of it. When the routing misfires, the trace is two lines (the model's input and output) rather than a 45-minute debugging session through an agent run tree.

That architecture still benefits from observability tooling. Cost tracking, latency monitoring, and regression testing matter even when workflows are deterministic. But the shape of the problem is different: the team is instrumenting for measurement and auditing, not for understanding why the model behaved unexpectedly. Langfuse handles that use case well, integrating cleanly with the step-level logging that comes naturally from an explicit-input, explicit-output workflow design.

Closing

Back to the support ticket classifier. After two weeks of daily LangSmith debugging sessions, the team rebuilt the classification step with a constrained output schema and a fallback rule for vendor names appearing more than 10 times in recent history. Accuracy went to 97% and stayed there. LangSmith is still part of the stack. But the debugging time dropped from two hours a day to 20 minutes a week.

The tool worked exactly as designed. LangSmith produced accurate traces for every single run. It took two weeks to recognize that what the team needed was not more visibility: it was a tighter prompt and a constraint layer. The observability tool told them what was happening. The architecture question was what to do about it.