LangSmith Alternatives: The Best Open Source Options (2026)

TL;DR

If you are looking for LangSmith alternatives, the search is usually about lock-in rather than features. LangSmith is a closed platform, self-hosting is an Enterprise-only arrangement, and per-seat billing applies to every engineer you add. This post covers seven open source options, audits what each one's license actually says, and flags which tools you should no longer be recommended at all.

• The best overall alternative is OpenObserve. It is AGPL-3.0, self-hosts as a single binary with no license key or sales conversation, and stores LLM spans in the same OpenTelemetry-native backend as your infrastructure logs, metrics, and traces — the direct opposite of the lock-in that starts this search.
• Check that a tool is still being built before you adopt it. Helicone went into maintenance mode after Mintlify acquired it in March 2026, and it still appears in roundups as a live recommendation.
• "Open source" hides three different commitments. Clean Apache-2.0 (Opik, Laminar, MLflow, OpenLLMetry), MIT-with-enterprise-carve-outs (Langfuse), and the Elastic License 2.0 (Phoenix), which is source-available and not OSI-approved.
• LangSmith's SDK is open source. The platform is not. The distinction is the whole argument.
• Two failure modes sit in LangChain's own documentation and are easy to miss until they bite: orphaned child spans expire silently with no error returned, and ordinary production workflows move traces onto a more expensive retention tier.
• The question nobody asks is whether your data can leave. Self-hosting is not the same as portability.

Why teams look for a LangSmith alternative

LangSmith is good at what it was built for. If your application is LangChain or LangGraph, its tracing shows chains, agent steps, and tool calls as first-class concepts instead of anonymous spans, and the evaluation and dataset tooling is mature. Nothing below is an argument that it is a bad product.

The pressure comes from four places.

The platform is closed. LangChain and LangGraph are MIT, and so is the langsmith-sdk client. The platform those SDKs report into, the backend, the UI, and the storage layer, is not published anywhere. You can inspect and patch the code that emits telemetry, but not the system that stores and serves it.

Self-hosting is an Enterprise conversation. LangChain's own docs describe self-hosted LangSmith as "an add-on to the Enterprise plan designed for our largest, most security-conscious customers," and tell you to contact sales for a license key to trial it in your environment. The documented install path is Kubernetes, with platform-specific guides for AWS, GCP, and Azure. The lower tiers are cloud-only. For a team with data residency obligations, that turns an engineering decision into a procurement one.

Billing scales with headcount, not usage. Per-seat pricing applies to every seat you add, so the cost of giving the whole engineering team visibility grows linearly with the team. The free tier is capped at a single seat, which means even evaluating it properly with a colleague requires a paid plan.

Two things in the docs that nobody writes about. These are worth knowing before you scale up:

• Orphaned spans disappear silently. The OTLP endpoint is asynchronous: it accepts a batch, returns a 200, and materializes runs in the background. If a child span's parent has not arrived yet, the child is buffered and linked once it does. But as LangChain's docs put it, "if the parent span is never exported to LangSmith, the buffered child expires and never appears as a run. LangSmith will not return an error, because the 200 was sent before processing." On self-hosted deployments the buffer window is REDIS_RUNS_EXPIRY_SECONDS, defaulting to 12 hours. A partially instrumented service can look healthy while quietly dropping data.
• Ordinary workflows move traces to a more expensive tier. LangSmith's billing docs list three triggers that upgrade a trace from base to extended retention: feedback added to any run on the trace, whether by manual annotation, an online evaluator, or the SDK; an annotation queue receiving any run from the trace; or an automation rule matching any run within it. The docs are upfront that "auto upgrades can have an impact on your bill," and you can opt out of the upgrade when creating or editing an online evaluator. The other two paths have no such switch, which means the features you would naturally adopt in production are the ones that change what you pay.

Neither is a scandal, and both are documented rather than hidden. They are simply the kind of detail worth knowing before you commit.

Check that the tool is still being built

Start here, because a good chunk of published advice on this topic is out of date in a way that will cost you a migration.

Helicone is the clearest example. Mintlify acquired it and announced the outcome on March 3, 2026: "Helicone's services will remain live for the foreseeable future in maintenance mode. This means security updates, new models, bug and performance fixes all keep shipping." That is a fair deal for existing users and a poor basis for a new adoption, because maintenance mode means no new capability is coming. We wrote up migrating off Helicone when it happened.

One acquisition went the other way. Langfuse was acquired by ClickHouse in January 2026, and the outcome so far has been unremarkable in the best sense: the MIT core license is intact, self-hosting still works at production scale, and the Cloud endpoints are unchanged. We covered what that acquisition changed in detail. Treat it as context worth knowing, not a reason to avoid the tool.

The practical lesson is that project health belongs in your evaluation criteria next to features, and it is cheap to check. Open the GitHub repository and look at the date of the most recent push. Every tool recommended in this post was pushed to within the last week, checked in July 2026. A tool that is technically excellent and no longer being built is a migration you have already scheduled without realizing it.

What "open source" actually means in this category

Every comparison table in this space puts a green checkmark in an "open source" column. That column is close to meaningless, because it flattens three genuinely different commitments.

Clean permissive licensing. Comet Opik, Laminar, MLflow, and OpenLLMetry are Apache-2.0 across the repository, including an explicit patent grant. There is no second license hiding in a subdirectory.

Open core. Langfuse's README states it plainly: "This repository is MIT licensed, except for the ee folders." That is a normal and honest business model, and the core genuinely runs at production scale, but it means the answer to "is it MIT" is "mostly." GitHub reports the repository license as NOASSERTION for exactly this reason. The same pattern applies to several other tools in the category.

Source-available. Arize Phoenix's LICENSE file opens with "Elastic License 2.0 (ELv2)." You can read the code, run it, and self-host it with no usage caps, but you cannot offer it as a competing hosted service. ELv2 is not an OSI-approved open source license, and comparison tables in this space routinely place it in the same column as MIT and Apache-2.0 without noting the difference.

None of these is disqualifying, and our wider open source LLM observability tools guide covers the category in more depth. The point is that "open source" is the answer to a question you probably were not asking. The questions that matter are narrower: can I run the whole product myself, are SSO and RBAC and audit logging in the build I can run or behind an enterprise wall, and what am I allowed to do with it afterwards. For teams with compliance obligations, pair that with how each tool handles PII in LLM telemetry.

The 7 LangSmith alternatives

1. OpenObserve

Our pick for the top spot, and full disclosure, our product, so weigh this section accordingly. It leads this list because it answers the lock-in problem most directly: no proprietary SDK, no per-seat billing, and no separate silo for LLM data. OpenObserve is a general-purpose observability backend rather than an LLM-specific platform. It ingests OTLP and stores gen_ai.* spans in the same columnar store as your application traces, infrastructure logs, metrics, and RUM data.

Where it beats LangSmith: your LLM spans are not in a separate product from the rest of your system, so "was that slow response the model or the vector database" is one query rather than a cross-tool investigation. Instrumentation is standard OpenTelemetry with no proprietary SDK, which is covered in the OpenTelemetry for LLMs guide. Per-model input and output pricing is configurable, so cost tracking reflects your actual billing agreement rather than a generic table. AGPL-3.0 and self-hostable as a single binary.

Where it does not: there is no prompt management, no playground, and no dataset management, so the build-and-iterate half of LangSmith has no equivalent here. Evaluation exists but is an enterprise feature, and it is narrower than what a dedicated eval platform gives you. Teams that need both commonly run a development-focused tool alongside a general observability backend.

License: AGPL-3.0 for the open source edition.

Pick it if: you already run infrastructure and application observability somewhere, and you do not want LLM telemetry to be the one exception.

2. Langfuse

The most widely adopted open source option in the category, at roughly 31.5k GitHub stars, and the most direct like-for-like replacement: tracing, prompt management, datasets, and evaluations in one product, with self-hosting that genuinely works at scale.

Where it beats LangSmith: you can run the whole thing yourself without a sales conversation, on Docker Compose or Kubernetes. It is framework-agnostic by design rather than by accommodation, and it accepts OpenTelemetry natively. Billing is usage-based rather than per-seat, so adding engineers does not change the bill.

Where it does not: it is open core, MIT apart from its enterprise directories, so confirm the features your deployment needs are in the build you can run. If your application is deeply LangGraph-shaped, LangSmith's native rendering of that structure is still better. And it is now owned by ClickHouse, which is worth factoring into a long-horizon decision even though nothing has changed operationally.

License: MIT for the core, separate enterprise license for the ee directories.

Pick it if: you want the closest thing to LangSmith that you can actually run yourself.

3. Comet Opik

The most permissively licensed full platform here, and the most overlooked. At roughly 20.7k stars it is one of the largest open source projects in this category, yet it is missing from most comparison posts on this topic.

Where it beats LangSmith: GitHub reports the repository license as Apache-2.0 with no secondary license detected, and the project describes the self-hostable build as the full platform: backend, web application, tracing, datasets, experiments, evaluations, prompt management, and online evaluation. The evaluation tooling is deep, with LLM-as-judge metrics for hallucination, relevance, and moderation available without writing them yourself.

Where it does not: Opik sits inside Comet's broader ML experiment-tracking platform, so some of the framing assumes an ML lifecycle you may not have. Comet does sell an Enterprise tier with SSO and compliance certifications, so confirm which security features your deployment needs rather than assuming the self-hosted build covers all of them.

License: Apache-2.0.

Pick it if: legal review is your tightest constraint, or you want serious evaluation tooling without a per-seat bill.

4. Arize Phoenix

The strongest option if OpenTelemetry portability is the priority and the license permits it. Phoenix is free to self-host with no usage caps or feature gates, and can run fully air-gapped with nothing reported back to Arize.

Where it beats LangSmith: no caps, no license key, no sales call. Prompt management is a first-class feature, with versioning, deployment, a playground, span replay, and SDKs to sync prompts into code. Instrumentation uses the OpenInference conventions, which are themselves Apache-2.0 and supported by several other backends.

Where it does not: the Elastic License 2.0 is source-available, not OSI open source, which some legal teams treat as a hard no. Choosing OpenInference is still choosing a convention, so portability is real but not unconditional.

License: Elastic License 2.0 (source-available).

Pick it if: you need uncapped self-hosting with strong evaluation and prompt tooling, and ELv2 clears your bar.

5. Laminar

Built specifically for agent workloads, on the argument that agent traces are a different shape from prompt-and-completion logging: deeper, longer-running, and much larger per interaction.

Where it beats LangSmith: billing is based on ingested data volume rather than seats or traces, so a large team costs no more than a small one. You get raw SQL access over trace data instead of a fixed query UI, and the debugger records and replays runs against a cache, which matters when you are iterating on an agent loop. Apache-2.0 and free to self-host.

Where it does not: at roughly 3.1k stars it is the youngest project here, with a correspondingly smaller ecosystem and fewer third-party integration guides. Prompt management is limited to playground-style span replay rather than the versioning and deployment workflow Langfuse and Phoenix provide.

License: Apache-2.0.

Pick it if: you run agents, and per-seat or per-trace billing has stopped being predictable.

6. MLflow

The option to consider if your organization already has an ML practice. MLflow is Apache-2.0 and, at roughly 27.1k stars, the largest project covered here.

Where it beats LangSmith: vendor-neutral foundation governance rather than a single company's roadmap. The site footer reads "MLflow Project, a Series of LF Projects, LLC," which is a materially different ownership story from every venture-backed tool on this list. It also spans classical ML and generative AI in one system, so experiment tracking and LLM tracing share a home rather than living in separate products.

Where it does not: if you have no existing MLflow footprint, it is heavier to adopt than a purpose-built LLM tool, and its centre of gravity is still the ML lifecycle rather than LLM application debugging.

License: Apache-2.0.

Pick it if: MLflow is already running in your organization, or foundation governance matters more to you than category focus.

7. Traceloop / OpenLLMetry

Not a backend, which is the entire point. OpenLLMetry is a set of OpenTelemetry instrumentation libraries that patch the OpenAI, Anthropic, LangChain, and LlamaIndex clients and emit standard gen_ai.* spans to any OTLP endpoint. Traceloop is the commercial platform built on top.

Where it beats LangSmith: it separates instrumentation from storage, which is the only durable answer to lock-in. Instrument once, then send spans to Langfuse, Phoenix, OpenObserve, or several backends at once, and changing your mind later never means touching application code. It is also the layer that makes tracing LangChain and LlamaIndex apps portable across backends.

Where it does not: on its own it stores nothing, queries nothing, and evaluates nothing. Treating it as a LangSmith replacement means you still have a backend to choose.

License: Apache-2.0.

Pick it if: you have not committed to a backend, or you want the freedom to switch without a rewrite.

Comparison table

Star counts are a rough proxy for ecosystem size, not quality, and were checked in July 2026. The column worth reading twice is the enterprise carve-out one, because it is the gap between what a tool is licensed as and what you can actually run.

Can you get your data out?

Every comparison post in this category asks whether you can self-host. Almost none asks the question that matters more when things go wrong: if you leave, do your traces come with you?

Three things to check before you commit to any tool here, including ours.

Is your instrumentation portable? If you instrumented with a vendor's SDK, your application code encodes that vendor's data model, and leaving means rewriting instrumentation. If you instrumented with OpenTelemetry, leaving is mostly an endpoint change. This is the strongest practical argument for the OpenLLMetry approach even if you never use Traceloop's platform.

Is there a bulk export? Reading traces back through a UI or a rate-limited API is not an export. Check whether there is a documented way to pull historical data out in bulk, and in what format.

What happens to history when you stop paying? Retention is finite everywhere, and on hosted plans access typically ends with the subscription. Export before you cancel, not after.

One caveat on portability generally. The OpenTelemetry GenAI semantic conventions have moved out of the main semantic-conventions repository into a dedicated one, and the old pages now carry a relocation notice saying they are no longer maintained there. Meanwhile several attribute families are live in production at once. LangSmith's own mapping documentation lists gen_ai.*, OpenInference, Traceloop, llm.*, retriever, tool, and Logfire attributes, all converted into LangSmith's internal fields. "OpenTelemetry-native" is doing a lot of work in this category's marketing. It means your transport is standard. It does not mean your semantics survive a move intact.

Which one to pick

• You want LLM spans in the same backend as your infrastructure telemetry. OpenObserve. Escaping the separate-silo model is the strongest structural answer to the lock-in that starts this search.
• You want the closest self-hostable equivalent to LangSmith. Langfuse.
• Legal review is the tightest constraint. Comet Opik, clean Apache-2.0 with no carve-outs.
• You need uncapped self-hosting with strong prompt and eval tooling. Arize Phoenix, if the Elastic License clears your bar.
• You run agents and billing has stopped being predictable. Laminar.
• You already have an ML practice, or foundation governance matters. MLflow.
• You have not decided. Instrument with OpenLLMetry first and keep the choice open.
• Stay on LangSmith if your stack is LangChain or LangGraph, cloud hosting is acceptable, and your team is small enough that per-seat billing is not yet the problem. It is a good product inside those boundaries. The reason to leave is structural, not a feature gap.

Send LLM traces to OpenObserve

If OpenObserve is on your shortlist, setup is standard OpenTelemetry with no product-specific SDK. Install OpenLLMetry, which patches your model clients and emits gen_ai.* spans:

pip install traceloop-sdk

from traceloop.sdk import Traceloop

Traceloop.init(app_name="my-llm-app")

Then point the SDK at your OpenObserve instance:

export TRACELOOP_BASE_URL="https://api.openobserve.ai/api/<your_org>"
export TRACELOOP_HEADERS="Authorization=Basic%20<your_base64_token>,stream-name=default"

Two details that will cost you an afternoon otherwise. The Traceloop SDK does not read the generic OTEL_EXPORTER_OTLP_ENDPOINT variable, so set TRACELOOP_BASE_URL or it will default to Traceloop's own cloud and fail asking for an API key. And header values must be URL-encoded per the OTLP specification, so the space in Basic <token> has to be written as %20. Get that wrong and the Authorization header is dropped silently: exports appear to succeed and nothing arrives.

The base endpoint is enough, since the SDK appends /v1/traces itself. Grab the org slug and token from Data Sources → Custom → Traces in the UI. For self-hosted OpenObserve, swap the base URL for your instance, for example http://localhost:5080/api/default.

Because this is plain OTLP underneath, the same spans can go to two backends at once. That is the low-risk way to evaluate anything on this list: dual-ship alongside LangSmith for a couple of weeks, compare what each shows you, then decide.

Try OpenObserve Cloud

If the argument that landed was "I do not want my LLM traces in a separate product from the rest of my system," that is what OpenObserve is built for: LLM spans, application traces, infrastructure logs, metrics, and RUM in one columnar store you query with SQL. Start on OpenObserve Cloud, or run the self-hosted single binary for free under AGPL-3.0.