Langfuse alternatives for customer-facing agents

Stay on Langfuse if you need an open-source trace store with prompt management and evals: it is good, MIT-licensed at the core, and self-hosts cleanly. The honest reasons to look elsewhere are narrow. You want tracing produced by the runtime that executes the agent, you need per-tenant cost attribution and isolation as a first-class model, you are all-in on LangChain, you want one vendor for infrastructure and LLM observability, or you need a specific compliance posture.

Who should pick what: LangSmith for LangChain and LangGraph teams. Datadog's own Agent Observability for teams paying for Datadog. Braintrust when the bottleneck is evals rather than tracing, and Helicone when you mostly want a cost ledger with rate limits. Teams shipping an agent their customers use, across many tenants, should read the last two sections.

The narrow reasons to look past Langfuse

Langfuse does the core job well. It records traces as a tree of spans and generations, infers cost from token usage and a model price table, versions and labels prompts, runs LLM-as-judge evaluators over datasets, and exposes all of it through an OpenTelemetry-compatible SDK and API. If none of the five situations below describes you, the answer to "which Langfuse alternative" is probably "none".

You want tracing bundled with the runtime that executes the agent

Langfuse is a sink. Your code emits spans and Langfuse stores and renders them, so every fact in a trace is one your instrumentation remembered to record. The retry a client library performed silently, the tool call that timed out before its span closed, the cache-read token count returned in a shape your integration did not parse: each is a gap you close by hand. A runtime that executes the agent records the step because it ran the step.

You need per-tenant cost and isolation as a model, not a filter

Langfuse attaches user_id, session_id, tags and metadata and lets you filter and group cost by them. Python SDK v4 spreads those attributes to every observation in the trace through a context manager, which is a better default than the v3 update_current_trace call it replaced, and still leaves the model at "annotate, then filter":

from langfuse import observe, propagate_attributes


@observe()
def answer(tenant_id: str, end_user_id: str, question: str) -> str:
    with propagate_attributes(
        user_id=end_user_id,
        session_id=f"{tenant_id}:{end_user_id}",
        metadata={"tenant_id": tenant_id},
        tags=[f"tenant:{tenant_id}"],
    ):
        return run_agent(question)

The background job that re-summarizes a thread, the webhook handler that replays a failed turn, the eval script an engineer ran against production keys: forget the block in one and that spend lands under an empty tenant. Isolation is the second half. Every tenant's traces sit in one Langfuse project, so showing a customer their own usage, or promising that tenant A's prompts never appear in tenant B's view, means an access layer above the Langfuse API. Langfuse roles are Owner, Admin, Member and Viewer, assigned at the organization and optionally per project, which separates your teams from each other rather than your customers.

You are all-in on LangChain or LangGraph

LangSmith tracing turns on with LANGSMITH_TRACING=true and an API key, and it is the only tool that renders LangGraph's node and edge structure the way the framework models it. Langfuse's LangChain callback handler is maintained, though it follows framework releases rather than shipping with them. If your whole stack is LangChain, the vendor's own tool removes a class of "which side broke" debugging.

You want one vendor for infrastructure and LLM observability

If your pages already fire from Datadog, a second UI for LLM spans splits the on-call story in two. Datadog correlates an LLM span with the pod it ran on, the database query it triggered and the queue it waited on, in the trace view your SRE already reads. Langfuse can be linked from Datadog by trace ID and cannot be joined to it.

You need enterprise features on a vendor with a specific compliance posture

Langfuse Cloud publishes a security page and offers enterprise self-hosting; verify the current reports (SOC 2, ISO 27001, HIPAA, data residency) against your requirement rather than relying on a summary, this page included. Ownership matters to procurement too. ClickHouse acquired Langfuse in January 2026, announcing no planned licensing changes and no change to Cloud; the repository still carries an MIT core with ee/ directories under a commercial license as of September 2026. Ask every vendor the same questions and compare the written answers.

Comparison table

Every row is a product you can stand up this week. Cells describe the default offering as of September 2026, checked against each vendor's documentation.

LangSmith

LangSmith is LangChain's hosted observability and evaluation platform, with the deepest integration any tracing tool has with a single framework. Every LangChain runnable and LangGraph node becomes a run in the trace tree with inputs, outputs and token usage, with no code beyond environment variables. Datasets, evaluators, an online evaluator over sampled production traffic and a prompt hub sit on top, and LangSmith Deployment, renamed from LangGraph Platform, hosts the running agent, now including Google ADK and Claude Agent SDK agents.

Choose it if your agent is a LangGraph graph and stays one. The trace view matches the mental model you have, and evals run against the graph you deploy. A fuller comparison is at Langfuse vs LangSmith, and if the framework itself is under review, start with LangGraph alternatives.

The honest limitation is gravity. LangSmith is closed source, self-hosting and BYOC are Enterprise-plan features, and pricing is per trace across two retention tiers, a fourteen-day base rate and a four-hundred-day extended rate at ten times base that online evaluators and automation rules apply for you, so a chatty agent at volume needs a sampling plan. Outside LangChain its integration is ordinary OpenTelemetry, which is fine, and then the reason to prefer it over Langfuse is gone. The broader list is at LangSmith alternatives.

Arize Phoenix and Arize AX

Phoenix is Arize's tracing and evaluation tool, built on OpenTelemetry with the OpenInference semantic conventions for LLM spans. It runs as a single container, accepts OTLP from any instrumented app, and includes evaluators, datasets, experiments and a prompt playground. Arize AX is the commercial platform: the same trace and eval model with enterprise access control, larger retention and Arize's older ML monitoring alongside it.

Choose Phoenix if you already instrument with OpenTelemetry and want the LLM view without a vendor SDK; it is the natural landing spot for a team that instruments once and exports widely. Choose AX if the same organization also monitors classical ML models.

The honest limitation is the license. Phoenix ships under Elastic License 2.0, which is source-available rather than open source: you can read, run and modify it, and you cannot offer it to third parties as a hosted service, a distinction procurement treats differently from Langfuse's MIT core. Prompt management is no longer the gap it was, since Phoenix versions prompts, ships production, staging and development tags plus custom ones, and fetches a tagged version from its SDK. AX is priced separately, so starting on Phoenix and growing into AX is a migration rather than an upgrade toggle.

Braintrust

Braintrust is an evaluation platform first and a tracing tool second. Its center is the loop of dataset, prompt or agent, scorer, experiment: you version a change, run it against a dataset, and read a diff of scores against the previous run. Tracing exists so production spans become dataset rows and scores attach to live traffic. Scorers are code, LLM judges or prebuilt ones, and they run in CI.

Choose it if your bottleneck is deciding whether a change made the agent better, and you would rather have one excellent answer than a broad observability suite. Teams iterating on one high-value agent get more from it than teams operating many.

The honest limitation: the platform is closed source, though its autoevals scorer library is MIT. Braintrust calls the deployment with the data plane in your own cloud account BYOC, and both BYOC and self-hosting are Enterprise-plan features as of September 2026, with Starter and Pro on SaaS. Production operations (alerting, on-call views, infrastructure correlation) is thinner than Datadog's, and it does not run the agent, so tenant attribution is the same annotate-then-filter model as Langfuse.

Helicone

Helicone is an Apache-2.0 LLM gateway. You point your provider client's base URL at Helicone, or run the gateway yourself, and every request is logged with tokens, cost, latency and headers you attach such as Helicone-User-Id. Sitting in the request path lets it cache, rate-limit and cap spend per key or per user with no code in the application.

Choose it if what you wanted from Langfuse was a cost ledger with per-user limits enforced rather than reported. For an internal tool with many users on one company key, a gateway that says "this user hit their daily cap" is the right shape.

The honest limitation is that a gateway sees requests rather than reasoning. A multi-step agent shows up as a list of calls, and the tracing view will not tell you why the agent took a wrong turn. It is also one more hop in the request path unless you use async logging, and Helicone's own comparison is clear: async keeps custom properties, user metrics and streaming, and gives up caching, custom rate limiting (where cost caps live), retries and prompt auto-formatting. Helicone documents no OTLP ingest endpoint, so it is a destination you integrate with rather than another OpenTelemetry exporter.

Datadog LLM Observability

Datadog renamed this product Agent Observability in 2026, though the docs still sit under the llm_observability path. The ddtrace library auto-instruments the major provider SDKs and frameworks, OpenTelemetry traces can arrive agentless, and spans land in the same backend as APM and infrastructure traces. Two evaluations are managed for you, language mismatch and sensitive data scanning; nine judge templates cover failure to answer, hallucination, prompt injection, tool selection and toxicity; and your own scores go in through the API.

Choose it if Datadog already pages your team. An LLM span linking to the pod, the Postgres query and the queue depth at the moment of failure beats a prettier trace view in a separate tab, and your SREs know the query language.

The honest limitation: billing counts LLM spans, the calls to the model rather than the tool, workflow and retrieval spans around them, so forecast on model calls. Datasets, experiments and prompt tracking have since landed, narrowing the old gap against Braintrust and Langfuse; what stays absent is any path to self-host. If you are not already a Datadog customer, it is not the place to start.

The question none of them answer

Every tool above, Langfuse included, assumes the agent is something your team runs: one company, one set of engineers reading the traces, one bill. That assumption sets the data model. Tenant and end user are strings on a span, cost is a number you group by later, and access control decides which of your engineers sees which project.

An agent your customers use breaks the assumption in two places first. Attribution has to be produced at execution time, because the surfaces reaching the agent multiply: web chat, Slack, an API key a customer's backend calls, a scheduled job, each able to forget the tenant. Isolation has to be a property of the store, because a customer asking "show me my usage" or "prove tenant B never saw our prompts" is asking about the data rather than the UI.

Cost per tenant then stops being a report and becomes a control. The question changes from "what did tenant A cost last month" to "tenant A's agent has called the same search tool eleven times in one turn because it returns an empty array the model reads as failure; stop it before the turn ends". A trace sink shows you that pattern the next morning. Only the thing running the agent caps it at call ten.

Per-tenant memory is the same problem from the other side. If the agent remembers, memory has to be keyed by tenant and end user, and recall for one must be impossible for another. Tracing is downstream of execution, so no tracing product touches this. A survey of platforms that do run the agent is at best AI agent platforms.

Where Runtype fits

Runtype is where the agent runs when the trace has to be produced by the runtime instead of annotated by your code. The first way in changes nothing: any OpenTelemetry-instrumented agent, LangChain, the Vercel AI SDK, a custom loop or Flue, exports to https://api.runtype.com/v1/otel and gets the Runs view, the trace tree, token usage and a display-only cost estimate; your provider still bills you. Point exactly one instrumentation at it; two doubles tokens and cost.

export OTEL_EXPORTER_OTLP_ENDPOINT="https://api.runtype.com/v1/otel"
export OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer ${RUNTYPE_API_KEY},x-runtype-agent-id=${RUNTYPE_AGENT_ID}"

Three more ways in.

• Register the agent. An external agent whose endpoint speaks Runtype's unified stream or A2A embeds in the open-source Persona chat widget and sits behind web chat, Slack, SMS, MCP, A2A and schedules, with tool calls and cost recorded per run.
• Serve it tools. An MCP surface exposes a product's flows, agents, records and tools, so your loop stays the orchestrator.
• Rebuild when it earns it. Port one capability once a suite harvested from real runs proves parity; runtype eval run exits non-zero 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 rather than filtered from a dashboard afterward. Every trace and cost figure carries the tenant and end user the request ran under, and long-term memory is keyed per end user under the same strategy (end-user identity).

A tool the model calls eleven times in one turn is bounded by maxToolCalls per turn (default 10) and maxTurns per run, and a tool that needs a human is gated by an approval with a five-minute default timeout. Cost is recorded per execution, record and batch.

Where a competitor is the better choice it is the better choice: LangSmith for a LangGraph team, Datadog for a Datadog shop, Braintrust when evals are the whole problem, and Langfuse for an open-source trace store you run yourself. Runtype runs managed or self-hosted on your own infrastructure.