LangSmith alternatives without the LangChain lock-in

Most teams searching for LangSmith alternatives want out of the LangChain ecosystem, not out of tracing, and the two are separable: LangSmith accepts OpenTelemetry traces from any framework. If you are leaving anyway, Langfuse is the closest like-for-like move, Arize Phoenix suits a team already on OpenTelemetry, Braintrust fits an eval-first workflow, and Helicone fits a team that mainly wants cost and request logs through a proxy. A customer-facing, multi-tenant agent needs more than a trace sink, and that case is covered at the end.

What LangSmith stores, and what leaves with you

LangSmith holds five kinds of state, and a migration is mostly a question of which ones travel with you. Traces are the bulk of the volume: every run tree with inputs, outputs, token counts, latency and feedback, grouped into projects. Datasets hold examples (inputs, expected outputs, metadata) that experiments run against. Prompts live in a versioned hub with commits, evaluators are either code you wrote or LLM-as-judge configurations set up in the UI, and annotation queues hold the human review work and its feedback records.

The portability of each is different:

Bulk export writes Parquet to an S3-compatible bucket, and its gating tightened during 2026: workspaces created after 3 August 2026 need Enterprise, while older Plus workspaces keep it until 1 February 2027. Feedback statistics travel with the runs by default; feedback comments are opt-in.

The practical reading: datasets, prompts and code evaluators can be committed to your repository this week whether or not you migrate. Most teams leave historical traces behind, keeping LangSmith read-only through its retention window. UI-configured evaluators and queue workflows are the real re-implementation cost.

What a migration actually involves

A LangSmith migration has four separable steps, and the order matters because the first two are useful even if you stop there. Decouple tracing from the SDK with OpenTelemetry, run the old and new sinks in parallel, move the durable assets into files, then cut over.

Step 1: decouple tracing from the SDK

If LangSmith traces reach the backend through @traceable, wrap_openai or the LangChain callback handler, the coupling is in your code. OpenTelemetry is the way out. LangSmith already ingests OTLP, so the first move is to make your application emit OpenTelemetry spans and point them at LangSmith. Nothing changes in the UI, but you now own the exporter configuration.

For a LangChain or LangGraph application, the vendor-neutral route is the OpenInference instrumentor, which turns every chain, LLM and tool invocation into OpenTelemetry spans against whatever tracer provider you configure. LangSmith's own SDK offers an OpenTelemetry mode behind LANGSMITH_OTEL_ENABLED, with LANGSMITH_OTEL_ONLY narrowing delivery to your OTLP destination alone, which is the less invasive route if you want to keep the LangSmith SDK for now.

pip install opentelemetry-sdk opentelemetry-exporter-otlp-proto-http openinference-instrumentation-langchain

import os

from openinference.instrumentation.langchain import LangChainInstrumentor
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

provider = TracerProvider(
    resource=Resource.create({"service.name": "support-agent"})
)

langsmith_exporter = OTLPSpanExporter(
    endpoint="https://api.smith.langchain.com/otel/v1/traces",
    headers={
        "x-api-key": os.environ["LANGSMITH_API_KEY"],
        "Langsmith-Project": "support-agent",
    },
)
provider.add_span_processor(BatchSpanProcessor(langsmith_exporter))

trace.set_tracer_provider(provider)
LangChainInstrumentor().instrument(tracer_provider=provider)

Once this runs, LangSmith is receiving the same spans it always did, but through a standard exporter you control. Swapping or adding a backend is now a configuration change, not a code change.

Step 2: run both sinks in parallel

Add a second span processor with a second exporter. OpenTelemetry fans every span out to each processor independently, so a failure or slowdown in one backend does not affect the other, and you can compare the two side by side for a few weeks before removing the LangSmith exporter.

new_backend_exporter = OTLPSpanExporter(
    endpoint=os.environ["NEW_OTLP_TRACES_ENDPOINT"],
    headers={"Authorization": f"Bearer {os.environ['NEW_BACKEND_API_KEY']}"},
)
provider.add_span_processor(BatchSpanProcessor(new_backend_exporter))

Where the endpoint points depends on the backend:

Langfuse builds its Basic credential by base64-encoding public_key:secret_key, and Braintrust expects x-bt-parent: project_id:<your project id>.

What to compare during the parallel run: root-span counts per day (they should match exactly), token and cost totals (they should match if both backends price from the same model table), and whether nested tool calls render as children of the LLM span rather than as siblings. Instrumentors differ most on that last point, and it decides how the new backend's UI feels day to day.

Step 3: move datasets, prompts and evaluators into the repo

Datasets are the asset most worth keeping, and they should live in version control regardless of which backend you pick. Export each one to JSONL:

import json
from pathlib import Path

from langsmith import Client

client = Client()
out = Path("evals/datasets")
out.mkdir(parents=True, exist_ok=True)

for dataset in client.list_datasets():
    with (out / f"{dataset.name}.jsonl").open("w") as f:
        for example in client.list_examples(dataset_id=dataset.id):
            f.write(json.dumps({
                "id": str(example.id),
                "inputs": example.inputs,
                "outputs": example.outputs,
                "metadata": example.metadata or {},
            }) + "\n")

Every backend in the comparison table imports JSONL of this shape, and a file in the repo can be diffed in a pull request, which a hosted dataset cannot. Prompts follow the same pattern: pull each one and write the template text to a file, accepting that the hub's commit history stays behind. The remaining work is re-implementing the UI-configured evaluators, typically an LLM-as-judge with a rubric, as a scoring function that reads the JSONL and returns a number.

Annotation queue output is feedback records you can list and store beside the dataset they scored. The queue itself is workflow, modelled differently by every backend, so plan to rebuild it.

Step 4: cut over

Cutover is removing the LangSmith span processor and updating the environment variables that pointed at it. Because OpenTelemetry carried the traffic, no application code changes here. Keep the LangSmith project readable until its retention window closes, since old trace links in tickets and pull requests keep resolving there.

Comparison table

Pricing shapes are as of September 2026.

The two rows at the bottom are not observability features, and no tracing product should be faulted for lacking them. They are there because a team leaving LangSmith for a customer-facing agent tends to discover it needs them next.

Staying on LangSmith

LangSmith is the right choice for a team that keeps LangGraph. Its trace view understands LangGraph's node and edge model, the Studio debugger attaches to a running graph, and the LangSmith Deployment story (formerly LangGraph Platform) assumes LangSmith is the observability layer. Nothing else here renders a LangGraph state machine as well.

The under-appreciated point is that LangSmith does not require LangChain. The @traceable decorator instruments plain Python and TypeScript, and the OTLP endpoint accepts spans from the Vercel AI SDK, Pydantic AI, or a custom loop. A team whose real complaint is "we want to stop writing LangChain code" can do exactly that and keep LangSmith, at the cost of losing the LangGraph-specific views.

Its honest limitation is the pricing model. Per-seat plus per-trace billing means a customer-facing agent with high request volume pays for observability in proportion to product usage, and the base retention window is short enough that extended retention becomes a second line item. Self-hosting exists only at the enterprise tier.

Langfuse

Langfuse is the closest feature-for-feature alternative: traces with sessions and user attribution, prompt management with versions and labels, datasets, LLM-as-judge evaluators, annotation queues and a public API for all of it. It is open source under an MIT license for the core, self-hosts from a container image with Postgres and ClickHouse behind it, and ingests OTLP as well as its own SDKs. A like-for-like migration finds a home for every row in the table above.

ClickHouse acquired Langfuse in January 2026. Langfuse's announcement says the project stays open source and self-hostable with no planned licensing changes, and that Langfuse Cloud keeps running on the same endpoints.

Choose Langfuse if you want LangSmith's shape without LangSmith's billing, or if self-hosting is a requirement. Its limitation is that the self-hosted footprint is real: ClickHouse, Postgres, Redis and object storage are all part of a production deployment, so a small team that wanted to avoid running infrastructure should weigh the hosted option. For a deeper head-to-head, see Langfuse vs LangSmith and Langfuse alternatives.

Arize Phoenix

Phoenix is OpenTelemetry-native from the ground up. It defines the OpenInference semantic conventions, ships instrumentors for LangChain, LlamaIndex, OpenAI, Anthropic and others, and runs locally with a single pip install for development. Its evaluation library covers hallucination, relevance and toxicity judges, and experiments run datasets against a task with those scorers attached.

Choose Phoenix if your platform team already runs an OpenTelemetry collector and wants LLM traces to flow through the same pipeline as everything else. The Elastic License 2.0 allows self-hosting freely but is not OSI-approved open source, which matters to some legal teams. Prompt management and human annotation are lighter than in Langfuse or LangSmith, and the hosted path leads to Arize AX, a separate managed product with its own pricing.

Braintrust

Braintrust is built around evaluation rather than tracing. The Eval() function takes a dataset, a task and a list of scorers and produces an experiment with a diff against the previous run, and logging comes from the same SDK so production traces can be pulled into datasets with one click. It is closed source, with a hybrid deployment where the data plane runs in your cloud account and the control plane stays hosted.

Choose Braintrust if your team ships changes gated on eval scores and wants the tightest loop between a failing production trace and a regression case. Its limitation is the mirror image of its strength: as a pure observability tool for high-volume production traffic it is more expensive and less flexible than the open-source options, and the closed-source model rules out any team that needs the full stack on its own infrastructure.

Helicone

Helicone sits at the HTTP layer. Point your OpenAI-compatible client at its gateway, add an auth header, and every request is logged with cost, latency and cache status without touching application code. It is open source under Apache 2.0, self-hostable, and inexpensive at volume because the unit is a request, not a seat.

Check its ownership before committing. Mintlify acquired Helicone in March 2026, and Helicone's announcement says the services stay live in maintenance mode, which it defines as continuing security updates, new models, and bug and performance fixes.

Choose Helicone if the question you actually need answered is "what are we spending, per model, per customer, per feature" and the tracing depth of a nested agent run matters less. Its limitation is exactly that depth: a gateway sees LLM calls, not the tool executions, retrieval steps and control flow between them, so an agent loop shows up as a sequence of unrelated requests unless you add properties by hand. Prompts, experiments and scoring exist but are thinner than in the tools above.

The question none of them answer

Every product in this comparison assumes the agent is something your team runs: an internal tool, a batch job, a backend automation, or a single-tenant application whose operator and user are one organization. The trace view shows one run, the dataset holds one team's examples, and the cost dashboard totals one bill.

A customer-facing agent breaks that assumption in three places. First, identity: a trace needs to say which tenant and which end user a run belonged to, and the backend has to keep tenant A's support engineer out of tenant B's transcript. Second, control: when the agent is about to issue a refund or send an email on a customer's behalf, someone approves it before it happens rather than reading about it afterward. Third, cost: "what did we spend on model calls" has to become "what did this tenant cost us this month," or pricing the product is guesswork.

None of the five tools above claim to do these things, and that is not a criticism: tracing, datasets and evaluators are the right scope for an observability product. A team whose agent is customer-facing gets identity, approvals and per-tenant accounting somewhere else, from an application layer it builds or a runtime that has them built in.

Where Runtype fits

Runtype is a trace destination that also owns the runtime around the agent. For a plain trace, dataset and prompt store, Langfuse is the closer like-for-like move. Four ways in, and stopping after the first is a normal outcome.

• Send traces. The parallel-run exporter above points at https://api.runtype.com/v1/otel with a bearer key, from a custom loop, LangChain, the Vercel AI SDK, Flue or Cloudflare Agents. 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 can be tested from the dashboard, embedded in the open-source Persona chat widget, put behind web chat, Slack, SMS, MCP and A2A surfaces, and scheduled.
• 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 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. Every trace and cost figure is filed under the tenant and end user the run belonged to.

Approval gates require sign-off for all tools or a named list, with a five-minute default timeout and persistent grants, and the run resumes when the approver answers. Cost is reported per execution, record and batch, and LLM-judge scores get human review. Identity, approvals and accounting sit in the runtime rather than in code around a trace store.