DEV Community

julian-ros
julian-ros

Posted on

Helicone is in maintenance mode. Here's what to do about it.

#ai #devops #observability #llm

Helicone is in maintenance mode. Here's what to do about it.

Last updated: 2026-09-25

TL;DR

Helicone, the open-source LLM observability platform, was acquired by Mintlify in early March 2026 and is now in maintenance mode. If you're using it, nothing breaks today, but the dashboard (alerts, cost dashboards) and the gateway (proxying, caching, routing) have very different futures. Your migration decision depends almost entirely on which half you actually use. This article gives you a decision tree, a concrete migration diff, and an honest "stay for 90 days" option.

Why this matters now

Helicone isn't a niche tool. It's one of the most-starred open-source LLM observability projects on GitHub, and its proxy gateway sits in front of production LLM traffic at a lot of companies. When a project at this scale goes into maintenance mode, the question isn't "should I care" — it's "which half of my setup is about to become a liability."

The short answer: nothing breaks today. The gateway still proxies. The dashboard still shows data. But the roadmap is frozen, and the two halves of the product are diverging in usefulness in opposite directions.

What "maintenance mode" actually means here

Helicone was acquired by Mintlify in early March 2026. The public status page and the community threads make the situation clear: the gateway remains open-source and functional, but active development has stopped. No new features. Bug fixes only, at the maintainers' discretion. The hosted dashboard is the part most affected — it still works, but it's not getting meaningful investment.

There's no sunset date published. There's no EOL notice. That ambiguity is exactly why this article exists: you need to make a call without a deadline being handed to you.

The dashboard vs. the gateway: different futures

This is the load-bearing distinction of the whole piece, so let's be precise about it.

Component What it does Status going forward Your risk
Dashboard Cost tracking, request logs, alerts, session replays Frozen; hosted version still runs but isn't improving Medium — data keeps flowing, but alerts and dashboards rot
Gateway/proxy Sits in front of LLM providers; caching, routing, retries, fallbacks Open-source, functional, no active development Low today, growing — no bug fixes for new provider APIs

If you only use the dashboard, you have more time than you think. If you use the gateway in front of production traffic, you have a real problem, and the problem compounds every time OpenAI, Anthropic, or Google ships a new API surface the proxy doesn't know about.

Decision tree: what to do based on how you use it 

Are you using Helicone's gateway in front of production traffic?
│
├─ YES → Do you depend on caching, routing, or fallbacks?
│        │
│        ├─ YES → Migrate the gateway now. LiteLLM is the closest
│        │         open-source equivalent. See migration diff below.
│        │
│        └─ NO  → You're proxying for logging only. You can switch the
│                  logging layer without touching the gateway. Lower urgency.
│
└─ NO (dashboard only) → Do you have active alerts or cost dashboards
                         you check weekly?
         │
         ├─ YES → Plan a migration within 90 days. Export your data
         │        before you need it.
         │
         └─ NO  → You're fine for now. Revisit in a quarter.
Enter fullscreen mode Exit fullscreen mode

The abandonment-risk screen

Before you pick a replacement, ask one question: how much of your Helicone setup is custom code you wrote against Helicone's specific API or SDK?

  • If the answer is "almost none" — you're calling helicone.init() and reading the dashboard — migration is a config change plus a data export. Days, not weeks.
  • If the answer is "we built custom routing rules, custom session logic, or custom alerting on top of Helicone's API" — budget real engineering time. This is where migrations stall.

Most teams overestimate how customized their setup is. Audit before you panic.

The LiteLLM security caveat (don't skip this)

If you're evaluating LiteLLM as the gateway replacement, be aware of a real, documented security issue: the Wiz Research "Off Guard" report (March 2025) disclosed vulnerabilities in LiteLLM's default setup, including SSRF and authentication bypass paths in the proxy when exposed improperly.

This doesn't mean "don't use LiteLLM." It means: if you deploy it, don't expose the proxy publicly without authentication, and keep it patched. The vulnerabilities were disclosed and fixed; the lesson is about deployment hygiene, not about the project being unsafe. Read the Wiz writeup and LiteLLM's own security docs before you deploy.

The migration diff

Here's what actually changes in your code when you move from Helicone's proxy to LiteLLM's proxy. This is the honest version — what you keep, what you lose, what you rewrite.

# BEFORE — Helicone proxy
import openai

client = openai.OpenAI(
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": f"Bearer {HELICONE_API_KEY}",
        "Helicone-User-Id": user_id,
    },
)
Enter fullscreen mode Exit fullscreen mode 
# AFTER — LiteLLM proxy
import openai

client = openai.OpenAI(
    base_url="http://localhost:4000",  # your LiteLLM proxy
    api_key=LITELLM_VIRTUAL_KEY,        # LiteLLM-issued key, not the provider's
)
Enter fullscreen mode Exit fullscreen mode

What you keep: the OpenAI-compatible interface, request/response logging, cost tracking.

What you lose: Helicone's session replay UI, its specific alerting rules, its dashboard UX. You'll rebuild equivalents in whatever you replace the dashboard with.

What you rewrite: any custom headers, custom routing rules, or SDK-specific session logic. This is the part that takes real time.

The "stay for 90 days" option

This is a legitimate choice, and it's underdiscussed.

If you're dashboard-only, or gateway-only with no custom logic, staying on Helicone for another quarter is rational. The gateway still works. The data still flows. Nothing is on fire.

But set a calendar reminder. The failure mode here isn't a hard outage — it's waking up in eight months to a broken integration with no migration plan and no one on the team who remembers how the proxy was configured. Maintenance mode doesn't kill you fast; it kills you by attrition.

What I actually did (and didn't) test

Full disclosure, because this topic deserves it: I tested the migration path above in a single-tenant environment with low throughput and OpenAI-compatible endpoints only. I did not test multi-tenant setups, high-volume routing, or Anthropic/Google-specific gateway features. Your mileage will vary, and the LiteLLM docs are the source of truth for anything I haven't touched.

Bottom line

  • Gateway in production with custom logic: migrate now, budget real time.
  • Gateway for logging only: switch the logging layer, keep the gateway until it breaks.
  • Dashboard only with active alerts: migrate within 90 days, export data first.
  • Dashboard only, no alerts: stay, set a quarterly reminder.

Nothing breaks today. That's not a reason to do nothing — it's the window to do it calmly.

Sources

Researched and drafted with AI assistance, checked against primary sources.

Top comments (0)