Langfuse vs Helicone vs 5 More: The Gateway Row Decides
A vendor-authored grid self-hosted all seven platforms. Gateway or ingest-only is the one row that fixes what a tool can ever do about cost.
You have more prompts, models and provider bills in production than you can follow by reading logs. So you open seven tabs of self-hostable LLM ops platforms, and every one of them claims to do everything.
A roundup published this month self-hosted all seven into one eleven-row grid. Read one row first and the shortlist collapses to two or three names.
Read the disclosure before the table
The grid comes from the team behind AcruxCore, which is one of the seven platforms in it. They say so up front: "Disclosure: we build AcruxCore, one of the seven. Columns are alphabetical, every row AcruxCore fails is in the table, and each claim below links to the other project's own documentation so you can check it without taking our word."
Treat what follows as that roundup's own scoring, not an independent audit — usable because the rows are checkable against each project's docs, and the author's own product loses several of them.
The method: "We self-hosted all seven and built the same prompt on each: a support triage agent that changes its instructions for VIP customers and lists their open tickets." Figures were "Checked August to September 2026", star counts as of 7 September 2026.
Row 3 decides more than the other ten
The roundup's central claim is that one row predicts most of what a platform can ever do about cost. Two different shapes hide under the same category name.
Beside your request path: your code calls the provider, an SDK wraps the call and ships a trace afterwards. Per the roundup, "Langfuse, Laminar, Opik and Phoenix work this way."
In your request path: your code calls the platform and the platform calls the provider. That group is "Helicone, MLflow's AI Gateway and AcruxCore."
Why it matters, in the author's framing: "A trace ingested afterwards is a record. A request passing through a gateway is a decision point. Only a decision point can swap in a cheaper model, return a cached response instead of paying for a new one, refuse a key that has passed its monthly budget, or hand your team a virtual key that never exposes the real provider key."
And the part that makes this a buying decision rather than a preference: "You can't add those four later from beside the path. By the time an ingest-only tool sees the call, the money is spent and the response exists. That's architecture, not roadmap."
The trade runs both ways. A beside-the-path tool "works with any provider, any SDK and any framework, with nothing new in front of production traffic that can fail" — and the roundup credits Laminar with auto-instrumenting fifteen-plus agent frameworks from one line of setup. The author also concedes the row can be irrelevant: "If you already enforce budgets in your own code, or you run a separate proxy, the gateway row may not matter to you at all."
The grid as published
| Row | AcruxCore | Helicone | Langfuse | Laminar | MLflow | Opik | Phoenix |
|---|---|---|---|---|---|---|---|
| License | Apache 2.0 | Apache 2.0 | MIT, some parts paid-only | Apache 2.0 | Apache 2.0 | Apache 2.0 | Elastic 2.0 |
| Self-host | ✅ 1 command | ✅ 1 command | ✅ 1 command | ✅ 1 command | ✅ 1 command | ✅ 1 command | ✅ 1 command |
| Gateway in the request path | ✅ | ✅ | ❌ ingest-only | ❌ ingest-only | ✅ + guardrails | ❌ ingest-only | ❌ ingest-only |
| Versioned, executed tool catalog | ✅ | ❌ | ⚠️ schema only | ⚠️ schema only | ⚠️ MCP servers | ❌ | ❌ |
| {% if %} / {% for %} in prompts | ✅ | ❌ substitution | ❌ substitution | ❌ no registry | ✅ full Jinja2 | ⚠️ SDK only | ❌ substitution |
| Audit log without paying | ✅ | ❌ | ❌ Enterprise | ❌ | ❌ | ❌ | ❌ |
| Built-in guardrails (PII / safety) | ❌ | ✅ | ⚠️ SDK hook | ✅ PII only | ✅ | ✅ | ❌ 3rd-party |
| Alerts to Slack or webhooks | ❌ email only | ✅ | ✅ | ✅ | ✅ spend only | ✅ | ❌ paid AX only |
| Human labeling queue | ❌ | ❌ | ✅ | ✅ | ❌ paid host only | ✅ | ⚠️ no queue |
| Organization → project hierarchy | ❌ single team | ⚠️ org only | ✅ | ✅ workspace | ❌ | ❌ | ❌ |
| GitHub stars | new project | 6.1k | 34.3k | 3.2k | 27.8k | 21.8k | 11.3k |
The roundup's own summary: "If you need a spend cap or a cached response, three of the seven can do it and four can't, by architecture. If you need a human labeling queue, the list flips: three have one, four don't."
Prompt templating is not a formality
Row 5 caught the author out. Their test prompt needs a branch and a loop, and only two of the seven render that logic server-side from the stored template: MLflow and AcruxCore. The other five leave it to application code, with plain substitution or no prompt registry at all.
Check your own templates before installing anything. If they branch, a platform that only substitutes variables pushes that logic into code it can no longer version.
Labeling queues flip the shortlist
Row 9 is where the gateway group loses. A human labeling queue exists on Langfuse, Laminar and Opik. Phoenix is marked "⚠️ no queue", MLflow "❌ paid host only", and neither Helicone nor AcruxCore has one. If your evaluation loop depends on humans grading production traffic, the two in-path options are the ones that fail you.
Licensing splits too: five of the seven are Apache 2.0, Langfuse is "MIT, some parts paid-only", and Phoenix ships under Elastic 2.0 — read that one closely if you plan to resell the tool.
What row 11 is for
Star counts run from Langfuse's 34.3k down to Laminar's 3.2k in that snapshot, with AcruxCore listed as a new project. They speak to hiring and answered issues, not to whether row 3 matches your architecture — do not let them override a row you cannot ship without.
Know what you need to see first
A separate write-up on agent monitoring makes the case for defining the questions before the tool. Its framing: "Most agent monitoring is 'log everything and grep later.' That's not monitoring — that's archaeology."
The four things it says you need are a live execution view, state inspection, failure forensics, and per-agent metrics — "Per-agent latency, token usage, error rate." Its example trace carries latency_ms and tokens per agent alongside a run status.
Analysis: that list maps onto the grid unevenly. All seven ingest traces, so per-agent latency and token counts fall out of any of them. Acting on those numbers mid-request is what row 3 gates.
How to use the grid
- Write down the one capability you cannot ship without. Spend caps and response caching point at the in-path group; human labeling points away from it.
- Check whether your prompts branch. If they do, row 5 cuts five of the seven.
- Read the license against your distribution plans, not just your internal use.
- Verify any cell that decides your choice against that project's current docs. The grid is dated August-to-September 2026 and written by a competitor.
Worth watching: the in-path group is small, and the roundup argues the capability gap it creates cannot be closed later from beside the path. If that holds, the gateway row is the one to settle before the pilot, not after it.
More from DangMua