Ragmux vs Helicone: gateway or observability platform?

Helicone and Ragmux turn up in the same “AI gateway” searches, but they’re not really competing for the same job — and Helicone itself is really two different things wearing one name. The platform (Helicone/helicone) is an LLM observability dashboard; a separate, newer repository (Helicone/ai-gateway) is an actual routing proxy, and the two ship under two different open-source licenses, which matters more than a rebrand or an acquisition would. Ragmux is one binary that routes, retrieves and enforces a budget in the same request path Helicone’s platform would only ever watch from the outside.

What Helicone is today

Helicone has shipped as two separate open-source projects, under two separate licenses — a detail worth stating plainly before anything else, since it changes what each one obligates a team that forks and modifies it. The original Helicone/helicone repository is Apache-2.0 licensed: it’s the observability platform, and its self-hosted Docker stack bundles a web dashboard, an API service, PostgreSQL and ClickHouse, plus MinIO for object storage. Its own Docker docs note a change worth knowing before adopting it as a router: “Jawn no longer proxies LLM traffic: the /v1/gateway/* routes have been removed. To proxy requests through a self-hosted deployment, run the AI Gateway alongside Jawn.” That AI Gateway is a separate repository, Helicone/ai-gateway, describing itself as “The fastest, lightest, and easiest-to-integrate AI gateway on the market. Fully open-sourced.” Its own LICENSE file opens with the standard GPLv3 header — “GNU GENERAL PUBLIC LICENSE” followed by “Version 3, 29 June 2007” — and GitHub’s own license detection classifies the repository GPL-3.0, a different license family entirely from the platform’s Apache-2.0. Worth flagging for a reader who goes to verify this directly: the router’s own README still displays a license badge reading “APACHE” near the top — the LICENSE file and GitHub’s classifier are the source of record here, not the badge, and the mismatch is Helicone’s own repository’s to fix, not a gap in this page’s sourcing. Its README also documents response caching with Redis and S3 as available backends, so “no database” isn’t quite the same claim as “no optional stateful dependency” — see the concession above.

Helicone’s own blog announced in March 2026 that Mintlify had acquired the company, stating: “Helicone’s services will remain live for the foreseeable future in maintenance mode. This means security updates, new models, bug & performance fixes all keep shipping.” Both GitHub repositories remain published and unarchived at the time of writing (the platform repository’s most recent push was 2026-09-16, a week before this review), so self-hosting either one today still works. The announcement itself doesn’t say new-feature work has stopped — “maintenance mode” is Helicone’s own phrase, and a reasonable reader takes that to mean roughly what the table below says, but it’s worth being clear that’s a reading of the announcement, not a quote from it.

Feature comparison

License terms, concretely — two repositories, two different obligations

This is the detail worth getting exactly right, since getting it wrong has real consequences for a team that plans to embed either repository in its own product. Helicone/helicone, the platform, is Apache-2.0 — a permissive license with no obligation to release source, even for a modified, closed-source redistribution. Helicone/ai-gateway, the router, is a different license family: GPL-3.0, per its own LICENSE file and GitHub’s spdx_id classification. GPL-3.0 is strong copyleft — distributing a modified version, or combining it with another program in a way that creates one derivative work, obligates releasing the corresponding source under the same terms. That’s a materially different obligation than the platform’s Apache-2.0, and a team planning to fork and embed Helicone’s AI Gateway inside a closed-source product needs to read GPL-3.0’s terms before doing so, not assume the platform’s more permissive license carries over to the router, and not trust the router’s own README badge, which still says “APACHE.”

Ragmux’s own AGPL-3.0-or-later goes one step further than GPL-3.0 specifically: GPL’s copyleft obligation is triggered by distributing the software; AGPL’s is triggered by running a modified version as a network service, whether or not it’s ever distributed. That’s the gap AGPL was written to close — the same gap that lets a team run a modified GPL-3.0 program purely as an internal service, with nobody outside the organization ever receiving a copy of it, without the same source-release obligation Ragmux’s license would impose in that scenario. Apache-2.0 is the only license among these three with no source-release obligation in either case.

Complementary in practice — with a caveat about the wire format

Ragmux exports OpenTelemetry spans over OTLP/HTTP with JSON encoding for every request by default (OTLP/gRPC is opt-in) — its own observability docs name pointing that exporter at a Collector as “the supported configuration.” Helicone’s platform, on its side, can genuinely ingest OpenTelemetry-shaped trace data, but not through a generic /v1/traces OTLP receiver: its own API reference describes a dedicated POST /v1/trace/log route that accepts an OTELTrace body (resourceSpans → scopeSpans → spans), and that schema marks fields — links, events, droppedLinksCount, droppedEventsCount, droppedAttributesCount — as required that Ragmux’s own exporter never sends: Ragmux’s docs list “no span links, events or baggage” among what a minimal, dependency-free exporter gives up. Pointing a Collector’s default OTLP exporter at that route as-is would very likely fail; making the two talk needs a transformation step, not just a URL change. The complementary relationship is real — Helicone’s platform genuinely accepts OpenTelemetry-shaped data, and neither project asks the other to route through it — but “wire it up in five minutes” isn’t a claim either project’s own docs currently back.

What actually crosses that connection, on Ragmux’s side, is worth being specific about regardless of the transport details above. Ragmux’s own observability docs describe exactly eight hand-written span sites — no more — covering the request lifecycle from the incoming chat call through each upstream attempt and the provider call and, for a project with a linked store, the retrieval step, with one firm rule enforced by a dedicated test: no attribute value ever carries message content, the retrieval query, passage text, a filename or a credential. Whatever a downstream collector does with Ragmux’s spans, the spans themselves carry call-shape data — IDs, counts, durations — not a copy of what was said.

Where Ragmux is not the answer

• No trace visualization or request-level dashboards to match Helicone’s. Ragmux logs request-level facts (tokens, latency, cost, RAG use); it has nothing like Helicone’s dashboards for a production traffic volume.
• PostgreSQL with pgvector is mandatory, in every deployment shape — Helicone’s AI Gateway router runs from nothing but provider API keys by default.
• 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 neither Helicone license carries in the same form: Apache-2.0 has no source-release obligation at all, and GPL-3.0’s obligation triggers on distribution, not on running a modified version as an internal network service.
• Reference docs are in English; guides are mostly in English too, with a few in Turkish.