Helicone was acquired by Mintlify. Here is a migration checklist if you are moving off.

On March 3, 2026, Helicone announced it was joining Mintlify. If you run Helicone in production, the practical question is not whether the acquisition is good or bad. It is what changes for you, and whether you need to do anything about it.

Here is the honest version, and a checklist if you decide to move.

What actually changed

Helicone’s founders joined Mintlify, and active feature development on the standalone product has wound down. The team has said security patches, bug fixes, and new model support will continue. New features and roadmap work are the part that stopped.

For a lot of teams that is fine for a while. A logging proxy that already works does not stop working the day the roadmap freezes. But two situations make people start looking. You are on Helicone Cloud and you want to know the plan is still moving forward, not just being kept alive. Or you self-host and you were counting on features that are now unlikely to ship.

Helicone was one of three observability tools acquired in a few months. ClickHouse bought Langfuse and Cisco bought Galileo in the same window. If you are picking a replacement, that pattern is worth keeping in mind. More on that at the end.

Do you even need to move right now

Worth saying plainly. If you self-host Helicone, you are happy with it, and you do not need anything new from it, there is no fire. The code keeps running. You can migrate on your own schedule instead of someone else’s.

The case for moving sooner is stronger if you are on the hosted product, if you depend on the gateway staying current with new providers and models, or if you would rather switch once now than watch and decide later. If that is you, the rest of this is for you.

The migration checklist

Helicone and Spanlens are both drop in proxies, so the mechanical part is short. The work is mostly finding every place your code sets a base URL and updating headers.

1. Swap the base URL

This is the one required change.

// Before, Helicone
const openai = new OpenAI({
  baseURL: 'https://ai-gateway.helicone.ai',
  apiKey: process.env.HELICONE_API_KEY,
})
// After, Spanlens
const openai = new OpenAI({
  baseURL: 'https://server.spanlens.io/proxy/openai/v1',
  apiKey: process.env.SPANLENS_API_KEY,
})

2. Map your metadata headers

If you tagged requests with user, session, or prompt identifiers, those headers have direct equivalents.

3. Move your provider key server side

Helicone had you pass both keys. Spanlens registers your real OpenAI or Anthropic key once in the dashboard and keeps it server side, so your application only ever sends the Spanlens key. One less secret in your request path.

4. Update the other providers

If you route Anthropic, Gemini, or Azure through the proxy too, each has its own base URL. The full list and the copy paste version of every step is in the Helicone to Spanlens migration guide.

5. Verify before you delete anything

Send one day of real traffic through the new path and reconcile the cost and token numbers against your provider invoice before you tear out Helicone. Keep both running in parallel for a day. This is the step people skip and regret.

Before you pick any replacement, not just this one

Three observability tools got acquired in one quarter. Whatever you move to, the useful question is what happens to your data if the same thing happens again.

Two things worth checking on any tool you evaluate. Can you export your raw trace data without a support ticket. And can you self host the whole thing, so that a change of ownership is your decision to act on rather than something that happens to you. Spanlens is MIT licensed and self hostable with one Docker command for exactly this reason, but the point stands no matter what you choose. Own your exit before you need it.

If you want to compare the two side by side first, the Spanlens vs Helicone breakdown goes through pricing, hosting, and instrumentation in detail.