The short version: on March 3, 2026, Mintlify acquired Helicone and its founders, and the open-source LLM observability tool moved to maintenance mode — security patches, bug fixes, and new-model support keep shipping, but new features, new integrations, and the roadmap have stopped. Helicone is Apache-2.0 and self-hostable, so nothing turns off on a deadline. The decision isn't "is it broken." It's "do I want my cost tracking and agent debugging on a tool that will never ship another feature." For most founders the answer is migrate — calmly, on your own schedule. Here's the map.

What "maintenance mode" means, exactly#

It means the lights stay on and the roadmap goes dark. Per Helicone's own announcement, the team — Justin Torre and Cole Gottdank — joined Mintlify, and the product now gets security fixes, bug fixes, and support for newly released models, but no new analytics, no new integrations, no net-new development. At acquisition Helicone had processed 14.2 trillion tokens for roughly 16,000 organizations — this is real infrastructure, which is exactly why you want an orderly exit rather than a scramble.

So: your dashboards keep working with today's providers. What you lose is the thing a live competitor gives you for free — the drip of new features every month, and confidence that next year's models and frameworks will be first-class.

The trick to deciding: Helicone was two products#

Most write-ups miss this. Helicone bundled two separable things behind one base-URL swap:

  1. An observability backend — traces, token counts, cost per request, request logs, evals.
  2. An AI gateway — caching, rate-limiting, provider routing, failover.

Your migration depends on which one you actually leaned on. Split the decision along that seam and it gets simple.

If you used it as a cost + trace dashboard#

Move to an actively developed, open-source, OpenTelemetry-native platform. In practice that's Langfuse or Arize Phoenix.

Langfuse is the safe default: MIT-licensed core, free to self-host, tracing + cost tracking + evals + prompt management, and — the part that matters here — it was acquired by ClickHouse in January, so it's the opposite trajectory to Helicone: better-funded and shipping harder. Phoenix is the other solid open-source pick if you want trace-and-eval tooling you run yourself. Both are framework-agnostic, so you're not trading one lock-in for another. If you're weighing them, we've already put them head to head for a solo founder and as self-host options.

The bundling that made Helicone a one-line install is exactly what makes leaving it a two-tool job. That's not a tax — it's the fix.

If you relied on the gateway#

If what you loved was the caching, the rate limits, the routing across providers, and the failover — that's the gateway, and there are dedicated ones still shipping: LiteLLM, Portkey, and Bifrost. We compared the three recently; any of them replaces the gateway half of Helicone without dragging your observability along for the ride.

Yes, you now run a gateway and an observability backend where you had one box. Keep them separate anyway — it's why your next migration will be a config change instead of a project.

The real lesson: the proxy was the trap#

Helicone's best feature was that you swapped api.openai.com for oai.helicone.ai and were done — no SDK, no code change. That convenience is also what welded a third party onto your critical request path. When that party stops shipping, you're stuck moving the thing every request flows through.

The durable move is to stop instrumenting on a proxy and start emitting OpenTelemetry GenAI traces from your app. Do that and the observability backend becomes a destination — any tool that speaks OTLP (Langfuse, Phoenix, and most of the field) is one OTEL_EXPORTER_OTLP_ENDPOINT away. The trace is the new log; own the trace, rent the dashboard. While you're re-plumbing, it's also the right moment to redact PII before traces leave your perimeter and to tail-sample so the observability bill doesn't scale with traffic.

The one-line decision#

Helicone isn't a cautionary tale — it's a genuinely good tool that got acquired, which happens. The cautionary tale is putting a single vendor on the path every one of your requests takes. Fix that once, and the next acquisition is somebody else's fire drill.