Langfuse vs LangSmith for Coding Agent Observability

Coding agent failures are quiet. That's the thing nobody warns you about upfront.

A traditional API call fails loudly. You get a 500, a stack trace, something screaming at you. A coding agent can return a success status, generate code that compiles, pass half your test suite, and still ship a security vulnerability. The failure was real. It happened three steps back, in a tool argument nobody was watching.

That's the core problem. The behavior doesn't live in the output. It lives in the trace.

Agent engineers read execution traces the way traditional engineers read code. The trace is the artifact. It shows you what the agent decided, in what order, with what inputs, and why the output looks the way it does. Without that reconstructable chain, you're debugging by guessing. And with a coding agent running long-horizon tasks (write the code, run the tests, fix the failures, open the PR), a bad tool argument in step three might not surface until step eleven.

So observability for coding agents isn't token counts and latency dashboards. It's reconstructable execution. Full causal chains.

That framing matters before you compare any tools, because the real question isn't which platform has more features. It's which architectural bet matches your team's actual situation. Here's what the observability layer actually needs to do:

Trace capture. Handle nested, non-linear execution. Loops, retries, parallel branches. A single coding agent session can generate LLM calls, tool executions, retrieval steps, embeddings, and guardrail checks. The platform needs to distinguish between all of them, not flatten everything into one stream. OpenTelemetry's GenAI conventions are becoming the standard here, defining span types like createagent, invokeagent, invokeworkflow, and executetool. One detail that trips people up: an invoke_agent span is CLIENT when the agent runs remotely and INTERNAL when it runs in-process. That distinction matters the moment your pipeline goes distributed.

Evaluation. Two flavors, and they should stay separate. LLM-as-judge for subjective questions (did the agent produce correct, idiomatic, secure code?) and deterministic checks for structural ones (did it call the right tool, does the output match the expected schema?). Deterministic checks don't need a judge model. They're faster, cheaper, and more reliable for structural questions. Critically, evaluation scores need to gate merges, not just show up in a dashboard. If your evaluation pipeline fails to connect to CI/CD, it's a reporting tool, not a quality control system.

Production monitoring. Cost per task. Latency per run. Error rates. Score drift. Alerts that fire before your users notice the problem.

Debugging. A structured agent benefits from a visual execution graph. A heavily looping agent is often easier to follow in a flat log stream. Ideally, you want both.

With that in mind, here's where Langfuse and LangSmith actually diverge.

The Architectural Fork Between Langfuse and LangSmith

These two platforms made different foundational bets, and those bets compound over time in ways that aren't obvious until you're already committed.

Langfuse went open source under MIT, with self-hosting as a first-class deployment mode and OpenTelemetry as the native tracing format. The bet: teams want portability, data control, and the ability to plug into infrastructure they already run.

LangSmith went managed SaaS, built alongside LangChain and LangGraph, with deep integration into that specific ecosystem. The bet: developer experience and fast time-to-value matter more than portability.

The single most consequential difference is the tracing format. Langfuse traces are OTEL spans under the hood. LangSmith uses a proprietary format with a closed backend.

Why does that matter day-to-day? Teams already running OTEL backends (Grafana Tempo, Jaeger, Honeycomb) can slot Langfuse into existing infrastructure without much drama. LangSmith doesn't fit that picture. And when you instrument against OTEL GenAI conventions rather than a vendor-specific SDK, switching platforms later means re-pointing an exporter, not re-instrumenting every agent from scratch.

Self-hosting tells a similar story. Langfuse self-hosting has no license gate. Any team can run it on their own infrastructure today. LangSmith's self-hosted option exists, but only on Enterprise, behind a sales conversation. For a small team without a contract, that path is simply unavailable.

These aren't just deployment preferences. They determine data residency, compliance posture, cost model, and how much of the platform's roadmap you're dependent on a vendor to ship. Get that wrong early and fixing it later is painful.

How Each Platform Handles Multi-Step Agent Traces and Debugging

This is where day-to-day experience starts to diverge, and the differences are more practical than philosophical.

Langfuse added Agent Graphs capability (late 2025) that infers graph structure from observation timings and nesting. It works with any instrumented framework, so a LangGraph agent gets the same graph visualization as a custom-built orchestrator. The span taxonomy is broad: Generation, Tool, Retriever, Agent, Chain, Evaluator, Embedding, and Guardrail are all distinguishable in the trace. For agents that loop or branch heavily, there's also a Trace Log View, a flat stream that's easier to read when graph visualization turns into spaghetti. Both views exist because neither one is consistently the right one.

On storage: Langfuse writes traces to a single wide, immutable observations table in ClickHouse, which eliminates joins at read time. For a long coding agent session with many steps, that matters. You're not waiting on a query stitching together normalized tables.

For LangGraph specifically, LangSmith's tracing is zero-configuration. Set an environment variable, get full graph tracing with every node, edge, and state transition captured automatically. That's a real developer experience advantage for LangGraph shops, not a marketing claim. LangSmith also has unsupervised topic clustering, which groups traces by detected theme. Useful when you have no prior hypothesis about what's failing and you're just trying to find the shape of the problem.

LangSmith launched a Rust-based data layer for its cloud offering (SmithDB) that delivers fast trace tree loading and full-text search. Worth noting: as of mid-2026, self-hosted LangSmith doesn't run the same storage engine as the cloud product. That gap is worth factoring in if self-hosting is on your roadmap.

So here's the honest read. If your coding agent is built on LangGraph, LangSmith's tracing setup is faster out of the box. I wouldn't argue otherwise. But coding agents often mix frameworks. An orchestrator in one framework calling tools instrumented with another, or a custom stack that doesn't fit the LangChain ecosystem at all. Langfuse's framework-agnostic approach handles that more naturally, without the friction of an adapter layer you didn't expect to need.

Evaluating Coding Agent Output — Where the Two Platforms Diverge Most

Evaluation is where this comparison gets genuinely interesting, because the platforms have different ideas about what "good evaluation" even means.

Three categories matter for coding agents specifically. Subjective questions (did the agent produce correct, idiomatic, secure code?) need LLM-as-judge. Deterministic questions (did the agent call the right tool with valid arguments, does the output match a JSON schema?) don't need a judge model and shouldn't use one. Regression checks (did the latest version perform worse than last week's baseline?) need both, plus a comparison mechanism.

Langfuse's LLM-as-judge is fully open source under MIT, available to any self-hosted user without a separate commercial license. The standout feature for coding agents is Code Evaluators, added mid-2026. These are Python or TypeScript functions you write directly in the UI. JSON schema validation, regex checks, tool argument verification, all running without any token cost. For a coding agent where deterministic checks on tool arguments and output schemas are more reliable than a judge model's opinion, this is the right tool. There's also baseline comparison (flag a run as the reference point, surface regressions automatically) and GitHub Actions integration that can fail a CI workflow when evaluation scores drop below a threshold.

LangSmith's eval pipeline is more opinionated and pre-assembled. Configurable LLM-as-judge with Boolean, Categorical, and Continuous feedback types. Built-in templates for Security, Safety, and Quality. If you want to go from zero to running quality evaluations quickly, LangSmith gets you there faster. The more interesting capability is few-shot correction: human-labeled corrections on evaluator outputs feed back as few-shot examples to improve evaluator calibration over time. When your judge model is initially poor at evaluating code quality, and it usually is, this feedback loop is a real way to improve accuracy without starting from scratch.

But think about what kind of evaluation mistakes you're most likely to make early on. If you're reaching for LLM-as-judge on questions that have deterministic answers, you're paying token costs for a model to tell you something a regex could have caught in milliseconds. Langfuse's Code Evaluators push back against that habit. LangSmith's pre-built templates make it easy to reach for a judge model by default, which may or may not be the right call depending on what you're actually measuring.

Production Monitoring and Alerting for Deployed Coding Agents

Cost monitoring matters more for coding agents than for typical LLM apps. A single agent run touching many files can generate a large number of tool calls and model calls. Cost per task needs to be trackable at the run level, not just aggregated globally. Global aggregates hide the expensive runs, and the expensive runs are almost always the interesting ones.

Langfuse's monitoring watches metrics over observations and scores. You can configure it for average cost per trace, p95 latency, or an evaluation score, with separate warning and alert thresholds. It also handles the no-data case, meaning the agent isn't running at all, which is itself a signal worth alerting on. Routing goes to Slack, webhooks, or GitHub Actions. That last option matters: alerts that can trigger automated responses in an existing engineering workflow close the loop without requiring a human to see a Slack message and manually kick something off.

LangSmith fires on error rate, run latency, feedback score, or cost over short aggregation windows. Routing goes to PagerDuty, Dynatrace, or any webhook.

The integration choices tell you something about intended context. Langfuse's alerting connects naturally to developer workflows. LangSmith's connects more naturally to ops and incident management tooling. Look at where your team actually lives day-to-day. The fit usually becomes pretty obvious.

Data Ownership, Compliance, and Deployment Model as Decision Criteria

For some teams, the decision is made here before feature comparisons even begin. That's not overcautious. That's just accurate.

Coding agent traces differ from standard LLM app traces in a specific way. These traces contain code diffs. File contents. Tool arguments. Potentially proprietary logic, environment details, or secrets if instrumentation boundaries aren't carefully managed. This isn't just model input and output. It's a detailed record of your codebase being manipulated by an autonomous system. Where that data lives matters more than it does for a chatbot.

Langfuse's compliance path: self-hosting is available to any team without an enterprise contract. The MIT license means the storage layer, backend, and UI are all inspectable. Truly readable, not just attested to. Langfuse holds SOC 2 Type II and ISO 27001. An air-gapped deployment is fully achievable. EU data can stay in an EU region without cross-border routing.

LangSmith's compliance path: cloud routing goes through US servers unless on Enterprise. Self-hosted deployment is Enterprise-only, behind a sales conversation. The backend, UI, and storage layer are closed source. Compliance posture depends on vendor attestations, not inspectable code.

One might argue that's fine for enterprise teams with existing vendor relationships, and sometimes it is. The sales conversation isn't painful in every case. But if your traces must stay in your VPC and you don't have or want an enterprise contract, compliance requirements make the decision before features do. The feature comparison becomes irrelevant. There's a certain irony in spending two hours evaluating eval pipelines only to discover the data residency question was the only one that mattered.

Pricing Structure and How Costs Scale with Coding Agent Workloads

Coding agents produce unusual usage patterns. Many tool spans per model call. Long multi-step sessions. A need to retain full traces for regression debugging, not just recent runs. Standard chatbot pricing models don't map cleanly onto this.

Langfuse charges based on the depth of ingested data. Traces, observations, and scores each count as one unit. A coding agent run with many tool calls generates many observations. Cost scales with agent complexity, not just session count. The free Hobby tier offers a meaningful unit count per month, accessible for individual developers or early teams. Self-hosted infrastructure cost for a small team is modest, and the economics of self-hosting improve as team size grows.

LangSmith's Developer tier is free at a limited trace count per month. Paid tiers add per-seat fees plus trace overage charges. Retention is priced into the trace rate, so longer retention costs more. That matters directly for coding agent teams running regression comparisons weeks or months apart.

One thing worth examining carefully: some observability platforms in this space only bill for LLM spans and treat tool spans, retrieval spans, and embedding spans as free. For a coding agent that makes many tool calls but relatively few model calls, that span-class-aware pricing model can look dramatically different than per-unit or per-seat models. Understand exactly which spans each platform counts before estimating costs for your specific workload. Discovering it after the fact is genuinely unpleasant, in the way that only a surprise infrastructure bill can be.

Which Stack Each Platform Fits — and Where the Choice Gets Obvious

LangSmith makes the most sense when your coding agent is built on LangChain or LangGraph. The tracing is zero-configuration in that context, and the framework integration is native, not adapted. It also fits when your team wants a more opinionated, pre-assembled eval pipeline with built-in templates and managed calibration, especially the few-shot correction feature when you're starting from scratch on code quality evaluation. If your incident management workflow already runs through PagerDuty or Dynatrace, the alerting integration fits naturally.

Langfuse makes the most sense when your traces must stay in your own infrastructure and you either can't or don't want an enterprise contract to make self-hosting available. It also fits when your coding agent mixes frameworks or uses a custom stack that isn't LangChain-native. If you're already running an OTEL backend, Langfuse slots in where LangSmith doesn't. And if deterministic code evaluation matters more to you than pre-built judge templates, Code Evaluators running Python or TypeScript checks are a better fit.

So what's the actual cost of getting this wrong? Choose LangSmith and later need to self-host due to compliance, and you're looking at an enterprise negotiation you didn't plan for, or a migration. Choose Langfuse and later need the LangGraph zero-configuration experience, and you're looking at additional instrumentation setup work. Neither outcome ends careers. They're just different kinds of friction, and knowing which kind your team can absorb is more useful than any feature checklist.

Start with the constraint that has no workaround. Compliance requirement, framework dependency, portability need. Let that narrow the field first. The feature comparison is secondary, and if you do it in the other order, you might spend a lot of time evaluating the wrong thing.

And regardless of which platform you choose: instrument against OTEL GenAI conventions rather than vendor-specific SDKs where possible. It keeps your options open in a market where both platforms are still evolving fast. That flexibility has real value, even if you never end up using it.