Helicone is in maintenance mode. An honest map of where to go

What happened, without the drama

Somewhere in your codebase there is one config line that swaps your OpenAI or Anthropic base URL for Helicone’s, and it has been quietly earning its keep since the day you shipped. In 2026 the Helicone team was acquired by Mintlify and the hosted product moved into maintenance mode. Let’s be clear about the register of this piece: that is a success story, not a cautionary tale. Helicone was open-source, genuinely good, and widely loved - the kind of tool people recommended to each other unprompted - and acquisition is what happens to teams that build something thousands of AI apps depend on. But maintenance mode means no new features, an uncertain horizon, and a migration on your roadmap whether you scheduled one or not. The useful way to spend that migration is not to hunt for "the Helicone alternative." It is to notice how many distinct jobs that single base-URL swap was doing for you, because the honest answer to "what replaces Helicone" is "it depends which Helicone you were using."

Helicone was never one job

Because Helicone sat as a proxy in front of every AI call, it could do unrelated jobs with zero marginal integration cost - everything flowed through it anyway. Unbundle what you were actually getting and there are four: request logging and tracing, so you could debug why a prompt misbehaved last Tuesday; cost visibility, so you could see what you were spending per model and per user; response caching, so repeated prompts didn’t bill you twice; and rate limiting, including per-user limits, so one user couldn’t drain your provider budget. One product, one URL swap, four jobs. The replacements are different tools for different jobs, and that is fine - arguably healthier, since each lane now has specialists that go deeper than a proxy ever could. The mistake to avoid is replacing the job you stare at most (the dashboard) and silently dropping the jobs that ran in the background (the limits). Walk the four lanes one at a time.

Tracing and debugging: the observability lane

If your Helicone habit was opening the request log to figure out why an agent looped or which prompt version produced the bad output, you need an LLM observability tool, and this lane has clear residents. Langfuse is the natural first stop: open-source like Helicone was, self-hostable if that mattered to you, SDK-based rather than proxy-based, with tracing that handles multi-step agent chains well. Lunary plays in the same lane with observability plus analytics. When choosing, check three things honestly. First, integration model: these are SDK tools, so unlike the proxy you instrument your code - more setup, but your provider call stays direct. Second, self-hosting: if part of Helicone’s appeal was running it yourself, confirm the self-hosted tier actually includes what you use, not just the core. Third, framework fit: if you are on LangChain, LlamaIndex, or the Vercel AI SDK, the quality of the official integration will dominate your day-to-day far more than any feature matrix. This is the lane most migration guides cover, so we will not belabor it - it is also the lane you are least likely to forget.

Caching: the job that moved into the stack

Helicone’s response caching was a real money-saver in 2023, when providers billed every token of every identical request at full price. That world is gone. Anthropic and OpenAI both ship provider-side prompt caching now - repeated prefixes (system prompts, few-shot examples, long documents) are billed at a fraction of the normal input rate, handled inside the provider with no middleman. For exact-duplicate full responses, a thin application-level cache - a hash of the request body in Redis or even your existing database - covers the remainder in an afternoon. This is the rare migration lane where the honest advice is that you probably do not need a vendor anymore: the job did not move to a different tool, it moved into the stack you already run. Check your Helicone cache-hit rate before deciding; if it was low single digits, you can drop the job entirely and nobody will notice.

Cost-per-user and limits: the job teams under-replace

Here is the trap. Observability tools will show you cost per user - Langfuse and Lunary both have the dashboard where you discover that user X spent $80 this month. What they will not do is stop user X at $5. Visibility and enforcement look adjacent on a feature list and are entirely different machinery underneath: one is a query over logs, the other is an atomic check that has to run before the AI call and hold up under concurrent requests. Helicone blurred this line because the proxy could do both - it saw every request, so it could count and it could block. Its observability-lane successors inherit the counting, not the blocking. So audit your old setup honestly: if you had per-user rate limits configured, or if you stared at the per-user cost page before deciding whom to invoice or cut off, you were using Helicone as a metering and enforcement layer, and a tracing dashboard does not replace that. This is the lane Vevee lives in: per-end-user metering, plan limits defined in a dashboard, and an SDK that gates the call before it runs - enforcement as the product, not a side effect of logging. Whatever you pick for this lane, pick something, because this is the job whose absence your users will find before you do.

Proxy versus SDK: the architectural fork

Helicone’s magic was the integration cost: change one base URL, get everything. It is worth being honest about what that swap cost you in exchange - a vendor in the hot path of every AI call. Every request paid the proxy’s latency, and every request shared the proxy’s availability: if it degraded, your AI features degraded with it, which is precisely the property that makes maintenance mode uncomfortable. The replacements in both lanes - Langfuse for tracing, Vevee for metering - are SDK-based, and that is not an accident. Your provider call stays direct: you call OpenAI or Anthropic yourself, and the tool is consulted beside the call (a gate before, a track after) rather than sitting inside it. If the metering layer has a bad day, your calls still complete; the failure mode is a missed log line or a fail-open gate, not a down product. The honest trade-off in the other direction: the URL swap was genuinely easier. An SDK means two extra calls around each AI request and an afternoon of integration instead of a one-line diff. You are trading a few hours of setup for getting a third party out of your request path - a trade most teams would have taken anyway once they noticed they were making it.

The migration checklist

The migration is mechanical once you know which jobs you were actually using. Do it in this order - the ordering is the part that matters, because one step has a failure mode the others do not.

• Inventory the four jobs. Open your Helicone config and dashboard usage, and write down which of tracing, cost visibility, caching, and limits you actually relied on - not which features exist.
• Export your historical data while the hosted product is still up. Request logs and cost history are cheap to export today and impossible to reconstruct later.
• Pick a replacement per job, not one tool for everything: observability lane for tracing, provider-side caching plus a thin app cache, a metering layer for per-user costs and limits.
• Stand up the new limits BEFORE removing the proxy. The day the base URL changes back, every rate limit configured in Helicone stops existing - and unlike a missing dashboard, missing limits announce themselves as a provider bill, found by exactly the users who were being limited.
• Re-point the base URL back to your provider last, once tracing is capturing and limits are enforcing in the new setup.

Where this leaves you

Helicone earned its place by making four jobs feel like one, and the right way to honor that is to replace it deliberately rather than nostalgically. Tracing goes to the observability lane - Langfuse if you want open-source and self-hostable, Lunary in the same orbit. Caching goes into your stack, mostly via your provider. And the per-user cost and limits job - the one that was protecting your margin while you looked at the tracing tab - goes to a metering layer built for enforcement. That last lane is what Vevee is for: per-end-user metering, plan limits you define in a dashboard, race-safe reserve/commit gating before the call runs, with a free tier and a $15/mo Pro that you can evaluate against your real traffic in an afternoon. Whichever tools you land on, the unbundling itself is the win: each job now has an owner that treats it as the whole product, instead of one proxy treating all four as features.