TL;DR
I went looking for Langfuse alternatives after living with a proprietary tracer for eight months and then paying to migrate off it.
I compared six options:
- Helicone
- Arize Phoenix
- LangSmith
- Braintrust
- Laminar
- Future AGI traceAI
They all trace LLM calls.
The axis that actually mattered was OpenTelemetry-native (OTel) vs proprietary tracing, because that's what determines whether you can leave without re-instrumenting everything.
Four of the six are open-source, ranging from roughly 200 to 10,000 GitHub stars (June 2026). That spread turned out to predict almost nothing about what I actually cared about: portability.
The Axis That Bites You in Month Eight: Whose Traces Are These?
Every tracer captures:
- LLM calls
- Prompts
- Tokens
- Retrieval events
The question nobody asks on day one and everybody regrets on day 200:
Is the trace format OpenTelemetry (portable) or the vendor's own schema (locked to their dashboard)?
If it's proprietary, switching tools later often means:
- Re-instrumenting your application
- Rebuilding integrations
- Losing historical trace data
I learned this the expensive way.
So today I sort observability tools by lock-in first and features second.
The Six Tools, Sorted by Lock-In
1. Helicone
The gateway-first open-source pick.
Often the first Langfuse alternative people mention.
You proxy model calls through Helicone and get:
- Logging
- Cost tracking
- Analytics
with very little code change.
Highlights
- Open-source (Apache-2.0)
- Self-hostable
- ~5,800 GitHub stars (June 2026)
Best for: teams that want a fast observability layer with minimal engineering effort.
2. Arize Phoenix
The open-source OTel pick.
Phoenix combines:
- OTel-based tracing
- Evaluations
- Self-hosted deployment
The core project is free and open-source.
Arize's commercial offering (AX) adds:
- Enterprise capabilities
- Advanced ML monitoring
Highlights
- Open-source
- OTel-native
- Self-hosted
- ~10,000 GitHub stars (June 2026)
Best for: teams that want portable tracing and full ownership.
3. LangSmith
The LangChain-native pick.
If you're already using LangChain or LangGraph, LangSmith provides:
- Automatic instrumentation
- Deep framework integration
- Strong developer experience
The tradeoff is coupling.
Highlights
- Proprietary
- Closed-source
- Closely tied to the LangChain ecosystem
Best for: teams fully committed to LangChain.
Most lock-in of the group.
4. Braintrust
The polished SaaS pick.
Braintrust has one of the strongest experiences for:
- Evaluations
- Observability
- Cross-functional visibility
Non-technical stakeholders tend to like the UI.
Highlights
- Proprietary trace schema
- Closed-source
- Managed SaaS by default
- Enterprise deployment options available
Even in enterprise deployments, you're still operating within their trace format.
Best for: organizations that prioritize product polish over portability.
5. Future AGI traceAI
The no-lock-in instrumentation pick.
traceAI is different from the others.
It is not an observability platform.
It is an Apache-2.0 OpenTelemetry instrumentation layer that captures:
- LLM calls
- Prompts
- Tokens
- Retrieval
- Agent steps
and exports them to any OTel-compatible backend:
- Datadog
- Grafana
- Jaeger
- Vendor platforms
In other words:
It handles instrumentation, not dashboards.
If you want a polished product out of the box, tools like Langfuse or Helicone are more complete.
If you want portable traces that you own, this is the lightest approach I found.
Highlights
- Apache-2.0
- OTel-native
- Backend-agnostic
- ~200 GitHub stars (June 2026)
Best for: teams optimizing for long-term portability.
It's also the youngest project here, so think of it as a bet on the instrumentation-first approach rather than a mature platform.
6. Laminar
The newer open-source pick.
Laminar combines:
- OTel-based observability
- Evaluations
- Modern architecture
It is newer than Phoenix but worth evaluating.
Highlights
- Apache-2.0
- OTel-native
- ~3,000 GitHub stars (June 2026)
Best for: teams looking for a modern open-source observability stack.
My Take
I'm not crowning a winner.
Different tools optimize for different priorities.
| If you want... | Look at... |
|---|---|
| Fastest onboarding | Helicone |
| Self-hosted OTel observability | Phoenix or Laminar |
| Deep LangChain integration | LangSmith |
| Polished SaaS workflows | Braintrust |
| Pure OTel instrumentation | traceAI |
The proprietary tools are completely reasonable choices.
Until the day you want to leave.
What I Would Do Differently
I would choose OTel-native instrumentation from day one.
Not because proprietary tools are bad.
In many cases they're actually easier and more pleasant to use.
But the cost of switching is paid later through:
- Re-instrumentation
- Migration effort
- Lost historical context
And on day one, you have no idea whether you'll outgrow the tool.
The argument is simple:
Instrument once with OpenTelemetry. Point it at whatever backend you want. Change backends without changing application code.
That's the entire case for OTel.
And it's the one strong opinion I came away with.
FAQ
Is Langfuse bad?
No.
Langfuse is genuinely good.
It's self-hostable, widely adopted, and has roughly 29,000 GitHub stars as of June 2026.
This post is about alternatives and tradeoffs, not criticism.
If I'm OTel-native, does that mean I don't get a dashboard?
No.
You still need somewhere to view traces.
Examples include:
- Grafana
- Datadog
- Jaeger
- Vendor platforms
OTel-native simply means you can change the backend later without changing instrumentation.
Should I self-host or use a managed service?
Self-host if you need:
- Data residency
- Infrastructure control
- Lower long-term platform dependency
Managed if you want:
- Faster setup
- Less operational burden
- A more polished experience
Open Question
Lock-in is easy to reason about.
What I still struggle to quantify is the value difference between:
- A polished proprietary platform
- A portable-but-rawer OTel stack
The proprietary tools genuinely save time every day.
The portability benefits only pay off if you actually switch.
I don't have a clean framework for valuing that optionality.
If you've found a useful way to think about that tradeoff, I'd love to hear it.
Top comments (0)