Ragmux vs Langfuse: gateway or LLM engineering platform?

Langfuse and Ragmux turn up in the same “LLM observability” and “AI gateway” searches, but only one of them makes the call to a model provider. Langfuse is an evaluation and tracing platform — prompt comparison, datasets, experiment tracking — built to instrument a request an application already sent, not to send it. Ragmux is one binary that routes that request, grounds it in retrieved documents and enforces a token budget on it, all before Langfuse (or anything like it) would ever see the trace.

What Langfuse is

Langfuse’s own README describes it plainly: “Langfuse is an open source LLM engineering platform. It helps teams collaboratively develop, monitor, evaluate, and debug AI applications.” Nothing in that description or its surrounding docs describes routing a request to a provider — Langfuse instruments calls an application already makes, elsewhere, and turns them into traces, evaluations and datasets. Its core is MIT-licensed, with a stated exception: “This repository is MIT licensed, except for the ee folders,” which carry Langfuse’s enterprise-edition license instead. Self-hosting it is a heavier stack than Ragmux’s: per its own self-hosting docs, Langfuse “consists of two application containers (Langfuse Web, Langfuse Worker), storage components (Postgres, Clickhouse, Redis/Valkey, S3/Blob Store), and an optional LLM API/Gateway” — six pieces against Ragmux’s one PostgreSQL database.

An acquisition worth naming, in the same neutral terms as Helicone’s

Langfuse’s own README states plainly: “since January 2026 we’re part of ClickHouse, we’re hiring engineering hybrid across the EU.” That’s the same category of fact this site gives real estate to for Helicone’s acquisition by Mintlify — a table row, an FAQ entry, and a paragraph of context — so it belongs here too, in the same tone: neither celebratory nor alarmist, just a fact worth a prospective adopter knowing before they commit infrastructure to either project. Unlike Helicone’s own post-acquisition announcement, nothing in Langfuse’s README describes a shift to maintenance mode: its repository (langfuse/langfuse) remains unarchived and was last pushed 2026-09-22, the day before this review, and the README’s own language (“we’re hiring”) reads as expansion rather than wind-down.

Feature comparison

Complementary in practice — wire-compatible, but not Ragmux’s supported path

Ragmux exports OpenTelemetry spans over OTLP/HTTP with JSON encoding for every request by default (OTLP/gRPC is an opt-in setting, and Langfuse does not accept it), and Langfuse’s own docs describe exactly that encoding as accepted on its ingestion endpoint: “Langfuse currently supports OTLP over HTTP with both HTTP/JSON and HTTP/protobuf. gRPC is not supported yet.” That’s a genuine match at the wire level — pointing Ragmux’s exporter straight at Langfuse’s /api/public/otel endpoint is protocol-compatible, unlike Helicone’s platform, whose own ingestion endpoint isn’t a standard OTLP receiver at all (see Ragmux vs Helicone). Ragmux’s own docs still name an OpenTelemetry Collector as “the supported configuration” rather than a vendor endpoint directly — mainly because most other vendors expect protobuf-only and a Collector adds retries, tail sampling and resource detection Ragmux’s minimal exporter skips on its own — not because Langfuse specifically requires one. A team that wants the simplest path can point Ragmux directly at Langfuse; a team that wants the Collector’s extra features keeps it in between either way.

Langfuse’s own docs describe that OTLP endpoint as designed to extend compatibility “beyond the SDKs and native integrations”: third-party OpenTelemetry libraries such as OpenLLMetry and OpenLIT extend Langfuse tracing specifically to Java and Go, covering frameworks like AutoGen and Semantic Kernel — broader than Langfuse’s own native Python and JS/TS SDKs, but a named, specific extension rather than “every language with an OTel SDK.”

That data-shape detail matters more here than it would for a pure dashboard, because evaluation is exactly the job that benefits most from content. Ragmux’s own observability docs describe a fixed set of eight hand-written span sites — the incoming chat call, each upstream attempt of the retry and fallback walk, the provider call and, for a project with a linked store, the retrieval step — with one rule a dedicated test enforces: no attribute ever carries message content, the retrieval query, passage text, a filename or a credential. So a trace that reaches Langfuse over this path carries call shape — durations, counts, status — not the prompts or completions Langfuse’s evaluation tooling would actually want to score. A team that wants prompt-level evaluation in Langfuse needs to instrument that at the application layer, alongside Ragmux, not expect it to arrive through Ragmux’s own OTLP export.

A worked example: adding evaluation without replacing the gateway

Take a team already running Ragmux in production for a support bot: retrieval is working, budgets are enforced, and the open question becomes “which of two system prompts answers better.” That’s not a question Ragmux is built to answer — it has no prompt-versioning or evaluation UI — and it’s exactly what Langfuse is for. Adding Langfuse’s own SDK at the application layer, or pointing a Collector fed by Ragmux’s OTLP export at Langfuse’s endpoint for the call-shape side of the picture, adds that evaluation layer without touching how the gateway routes or retrieves anything; nothing about that integration asks Ragmux to give up the position in front of the provider, because Langfuse never asked for that position in the first place.

License terms, concretely

Ragmux’s AGPL-3.0-or-later carries a network-use clause: modify it and run that modification as a service your users interact with, and you owe them the corresponding source of your change. Langfuse’s MIT core carries no such obligation — it can be forked, modified and embedded in a closed-source product without releasing anything back. Langfuse’s carve-out for its ee/ directory is the one detail worth double-checking before relying on a specific feature: code there is licensed separately from the MIT-covered core, the same split pattern LiteLLM uses for its enterprise/ directory and Portkey uses for its hosted tier’s governance features.

Where Ragmux is not the answer

• No trace visualization, prompt evaluation or experiment tracking. Ragmux logs request-level facts (tokens, latency, cost, RAG use); it has nothing like Langfuse’s evaluation datasets.
• PostgreSQL with pgvector is mandatory, in every deployment shape, against Langfuse’s six-piece stack — neither is a small operational footprint, but they’re different kinds of heavy.
• Ragmux is pre-1.0. The current release is 0.5.0; SSO/OIDC login and dollar-denominated budgets are listed on the roadmap as not scheduled, not shipped.
• AGPL-3.0-or-later carries a network-use clause that Langfuse’s MIT core does not.
• Reference docs are in English; guides are mostly in English too, with a few in Turkish.