Langfuse vs LangSmith, and the third question neither answers

Pick Langfuse if you want to self-host, need the source, or run agents on more than one framework. Pick LangSmith if your stack is LangChain or LangGraph and you want tracing, evals, and deployment from one vendor. The two overlap on most features; the decision is license, hosting, and framework fit, not tracing depth.

Both products stop at the same line: they trace an agent your team runs. When the agent is a feature your customers use, and each account has its own cost, data boundary, and definition of a good answer, the trace is where the problem starts. The first five sections are the comparison you came for; the last two are that question.

Comparison table

Every row decides this choice for at least one team. Plan names, allowances and prices are as of September 2026, and both vendors revise them, so price your own volume against the current pages before committing.

What Langfuse does best

Langfuse is the observability platform you can read, fork, and run. The application ships from one public repository under the MIT license, and the same build runs Langfuse Cloud and your cluster. Nine features need a commercial license key when you self-host, and as of September 2026 they are project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the organization management API with SCIM, and the instance management API. Nothing in the tracing, evals, or prompt path is held back.

Tracing on any framework

The tracing model is a tree of observations under a trace: spans for arbitrary work, generations for model calls with token counts and computed cost, and events for point-in-time markers. Traces carry a user_id, a session_id, tags, and free-form metadata, each a filter in the UI and a dimension in the metrics API. The Python v3 SDK is built on OpenTelemetry, so a span from the OTel API and a span from the @observe decorator land in the same tree.

from langfuse import observe, get_client

@observe()
def answer_ticket(question: str, tenant_id: str) -> str:
    langfuse = get_client()
    langfuse.update_current_trace(
        user_id=tenant_id,
        tags=["support"],
        metadata={"tenant_id": tenant_id, "plan": "team"},
    )
    return call_model(question)

Framework coverage is the widest of the two, and a framework with no integration sends OTLP to the public OTel endpoint, where Langfuse maps the GenAI semantic conventions to generations.

Evals and prompt management

Datasets are inputs with optional expected outputs; experiments run your application over a dataset and score every row. LLM-as-judge evaluators run against sampled production traces or dataset runs, and human annotation queues route individual traces to a reviewer whose score lands beside the judge's. Every score, managed or custom, goes through one scores API.

Prompt management stores versioned prompts with labels like production and staging. The SDK fetches by label and caches locally, so a prompt change ships without a deploy and a Langfuse outage does not take your application down. Prompt experiments run a prompt version over a dataset and compare scores, closing the loop between the editor and the eval results.

Who should choose Langfuse

Choose Langfuse when security or procurement requires self-hosting, when you want the source for what you depend on, or when you run more than one framework and want one trace format across them. Choose it when cost is dominated by volume rather than seats, because self-hosting removes the ingestion bill entirely.

The honest limitation

Langfuse does not run your agent. There is no deployment product, no agent server, and no managed runtime; it observes whatever you run elsewhere. Self-hosting v3 means operating four services (Postgres, ClickHouse, Redis, and object storage), which is a real platform commitment. For tools that go further, see Langfuse alternatives.

What LangSmith does best

LangSmith is LangChain's platform for tracing, evaluating, and deploying LLM applications, and it is at its best when the application is a LangGraph graph. Every chain, tool call, and graph node reports automatically with LANGSMITH_TRACING=true and an API key, with no decorator and no wrapper.

The tightest LangGraph integration there is

A LangGraph run in LangSmith is a run tree that mirrors the graph: the state at each node, the branch taken at each conditional edge, the tool calls and their outputs, and the tokens spent at each step. LangSmith Studio opens the same graph as an interactive canvas, lets you edit state mid-run, and replays from any node. No other tracer knows what a LangGraph checkpoint or interrupt is; if those are the words your team uses, this is the tool that speaks them.

from langsmith import traceable

@traceable(run_type="chain")
def answer_ticket(question: str) -> str:
    return call_model(question)

answer_ticket(
    "Why was I billed twice?",
    langsmith_extra={"metadata": {"tenant_id": "acme", "plan": "team"}},
)

For code outside LangChain, @traceable builds the same run tree by hand, wrap_openai and the Anthropic wrapper capture model calls with token counts, and langsmith_extra attaches metadata and tags at call time. LangSmith also accepts OpenTelemetry traces at its OTLP endpoint from LangChain, LangGraph, or any OTel-compatible application, so an agent instrumented with GenAI semantic conventions reports in without the SDK.

Evals with the LangChain vocabulary

LangSmith's eval loop is datasets, experiments, and evaluators, with two primitives Langfuse lacks in the same shape. Pairwise evaluators compare two experiments row by row and record a preference, which answers "is the new prompt better" rather than "does it score above 0.8". Online evaluators score a filtered sample of production traces continuously, and the results feed monitoring dashboards and alerts on the same dimensions.

Prompt management is the Prompt Hub: prompts with commits, tags, and a playground that runs a prompt against any dataset row. Prompts pull into code with client.pull_prompt("name:tag") and return LangChain prompt objects, so the path from hub to graph is one call.

Who should choose LangSmith

Choose LangSmith when your agents are LangGraph graphs and you want tracing, evals, prompts, Studio, and deployment from one vendor with one login. Choose it when your team is small in seats and moderate in volume, because the per-seat plans are priced for that shape, and when you want a managed agent server rather than a container you run. Teams weighing whether the graph library itself is the right bet should read LangGraph alternatives first.

The honest limitation

LangSmith is closed source and, below the Enterprise plan, cloud only. Self-hosting exists, but it is a procurement conversation rather than a docker compose up. The deepest features assume LangChain objects: pulled prompts are LangChain templates, Studio needs a LangGraph graph, and automatic tracing fires only inside LangChain code paths. A team on Pydantic AI or the OpenAI Agents SDK gets a good tracer and not much of the rest; compare LangSmith alternatives before committing.

Self-hosting compared

Self-hosting is the sharpest difference. Langfuse self-hosting is the default open-source path: a Docker Compose file for one machine, a Helm chart for Kubernetes, and a documented list of the four backing services. There is no license key, and the same version ships to Langfuse Cloud and to your cluster on the same schedule. ClickHouse acquired Langfuse in January 2026, and as of September 2026 the licensing and the self-hosting path are unchanged.

LangSmith self-hosting is an Enterprise feature delivered as Kubernetes manifests or a Docker setup, run inside your own cloud account under a license key. LangSmith Deployment adds a hybrid mode in which LangChain hosts the control plane and your infrastructure runs the data plane where agents execute and traces are stored. Langfuse has no equivalent, because Langfuse has no deployment product.

Price compared

Figures below are as of September 2026 and both vendors revise them. The shape of each bill is the durable part.

Langfuse Cloud bills on ingested units per month, where a unit is roughly one observation (a span, generation, or event), with a free Hobby tier at 50,000 units, Core at $29 and Pro at $199 per month for 100,000 units each, and $8 per additional 100,000. Volume is the whole story: an agent that emits forty spans per turn consumes forty units per turn. Self-hosting replaces that line with infrastructure cost, dominated for most teams by ClickHouse storage and the object store.

LangSmith bills on two axes: $39 per seat per month on the Plus plan, and traces beyond the plan allowance at $0.0005 each for the 14-day base tier, with the 400-day extended tier at ten times that rate. A five-person team with a high-volume agent pays mostly for traces; a twenty-person team with a low-volume agent pays mostly for seats. A trace is a whole run rather than a span, so a forty-span turn is one trace, which makes the bill easier to forecast.

The question neither of them asks

Every section above assumes the agent is something your team runs: an internal copilot, a back-office workflow, a triage bot your own staff use. A tracer is the right center of gravity there, because the person reading the trace is the person who can fix the prompt.

The situation changes when the agent is a feature inside your product and your customers are the ones using it. Three things that were global facts become per-account facts.

Cost stops being a monthly bill and becomes a margin line on every customer, and one tenant's runaway loop is your loss until you can prove which account caused it. Isolation stops being an infrastructure property and becomes a contractual promise: tenant A's documents, memory, and tool credentials must be unreachable from tenant B's run, not just filtered out of a dashboard. Quality stops being one eval suite and becomes a per-tenant question, because tenant A configured the agent for refunds and tenant B for onboarding, and a prompt change that helps one can break the other.

Both tools give you attribution for the first of those, and only after the fact. Put a tenant_id in trace metadata, as both snippets on this page do, and you can group cost by tenant in Langfuse's metrics API or filter runs by tenant in LangSmith. That answers "which account spent the money last month". It does not stop the run before the money is spent, refuse a request that cannot prove which tenant it belongs to, or keep tenant A's documents out of a trace an engineer is reading for tenant B.

The second and third are outside a tracer's scope entirely. A trace is descriptive; isolation has to be prescriptive, enforced where the agent executes, before the model sees a token. Per-tenant evals need a per-tenant record of what the agent was configured to do and what it did, captured from production runs, not a shared dataset that averages every customer into one score. Neither product frames this because neither product runs the agent; the runtime is where the answer has to live.

Where Runtype fits

Runtype is what answers the third question, the one about what happens after the trace. Four ways in, and the first is the tracer question you came for.

• Send traces. Point the same OTLP exporter at https://api.runtype.com/v1/otel, from LangChain, the Vercel AI SDK or a custom loop, alongside or instead of Langfuse and LangSmith. You get the Runs view, the trace tree, token usage and a display-only cost estimate; your provider still bills you. Spans carrying the GenAI content attributes have a transcript you can capture as an eval case (external telemetry).
• Register the agent. An external agent whose endpoint speaks Runtype's unified stream or A2A is embedded in the open-source Persona chat widget, added to a product as a capability behind web chat, Slack, REST, SMS, iMessage, MCP and A2A, and put on schedules. The run then happens under Runtype's identity check, limits and approvals.
• Serve it tools. An MCP surface exposes a product's flows, agents, records and tools, so the loop you already have stays the orchestrator.
• Rebuild when it earns it. Port one capability to a flow or hosted agent once a suite harvested from real runs proves parity; runtype eval run returns a non-zero exit code on a regression.

Identity is a declared property of each resource: a tenancy strategy of internal, tenant-isolated or end-user-isolated with an assurance floor of asserted or verified, evaluated before execution, so a request that cannot prove which tenant it belongs to never runs. Cost is recorded per execution, record and batch with cached and uncached token counts, and each figure carries the tenant and end user the run belonged to, so the per-customer margin line is a sum over that account's executions. Long-term memory, when enabled, is keyed per end user and scoped under the same strategy.

A production failure is captured as a regression case from its recorded execution, LLM-judge scores are reviewed by a human and roll up into a judge-agreement figure, and a suite runs against a candidate model before a change ships. Approval gates cover all tools or a named list with a five-minute default timeout, and secrets referenced as {{secret:NAME}} are resolved server-side at the outbound request and never reach the model.

The decision:

• Internal agent, LangGraph, one vendor: LangSmith.
• Internal agent, self-hosted or open source or mixed frameworks: Langfuse.
• Customer-facing and multi-tenant, where cost, isolation and evals are per account: run it on Runtype, and keep whichever tracer your team already reads.

A tracer describes the run; the runtime is where a per-account promise is kept.