Helicone in maintenance mode, what next

Helicone in maintenance mode, what next

Helicone is an observability layer for language model calls that works as a proxy: you change the base URL in your client and every request starts being recorded along with cost, token count, and response time. No function wrapping, no decorators, no code changes.

On the third of March 2026 the company was acquired by Mintlify and the product moved into maintenance mode. If you are considering it for a new project, that one fact matters more than everything else in this text, so let us start there.

What maintenance mode actually means

Worth breaking apart, since the phrase sounds either more or less alarming than reality depending on what you read into it.

What still works: the service is maintained and receives security patches, bug fixes, and support for new models. That last part matters practically, since a proxy that does not recognise a new model name stops computing costs correctly.

What will not come: new features. The product stopped where it stood in March 2026 and will stay there. The acquirer announced support for customers migrating to another platform, which is an honest statement of the position and equally a clear signal of the direction.

The team, founders included, moved to the acquirer and works on something else. That is the part which in practice decides this project's future more than any declaration.

The scale it ran at when acquired is striking: trillions of tokens processed, around sixteen thousand organisations. This was not a project abandoned for lack of interest but a product whose team went to build something different.

What that means for you

The answer depends on where you stand, and three situations deserve separating.

A new project: do not start here. An observability layer is a decision for years, and picking a product that by design will receive nothing new means writing a migration into the plan from day one. The alternatives described below do the same job and are being developed.

A running project on the hosted version: you have time, though not unlimited. The service runs, the data is available, and the acquirer promises help with the transition. The sensible route is planning a migration calmly, in a quarter where there is room, rather than waiting for a shutdown notice.

A running project on your own server: the best possible position. The code ships under Apache 2.0, so nothing disappears and nobody switches your service off. The risk reduces to the code ageing and gaining nothing new, and that risk spreads over years rather than months.

The proxy approach and why it was good

Worth describing, since the idea outlives the product and helps judge the alternatives.

Most tools in this category require instrumentation: you wrap calls, apply decorators, import a separate client. Here you change one line of configuration.

from openai import OpenAI

client = OpenAI(
    base_url="https://oai.helicone.ai/v1",
    default_headers={"Helicone-Auth": f"Bearer {HELICONE_KEY}"},
)

The rest of the code stays untouched. Requests travel through the proxy, which records input, output, model, token count, cost, and timing, then forwards them to the real provider.

The advantages of that arrangement are concrete. It works regardless of language and library, since it operates at the protocol level. It attaches in minutes and detaches just as fast. It needs no code change, so it needs no review and no deployment either.

The drawbacks are equally concrete and worth knowing, since they apply to other tools built on the same idea. A proxy sees the model call and nothing else, so document retrieval, tool calls on your side, and the logic between steps stay invisible. With an agent taking several steps you see several unconnected calls rather than one tree. And: every request takes an extra network hop, through somebody else's infrastructure on the hosted version.

Caching and limiting, the rest of the value

Beyond recording, a proxy can do things an ordinary observability tool cannot, because it stands in the request path.

Response caching works on the principle that an identical request within a set time window receives a stored answer instead of reaching the model. In applications where users ask similar questions the saving can be substantial, and in automated tests run repeatedly larger still.

Know when not to want it, though. A cached answer is identical, so the natural variability that some uses depend on disappears. With data that changes over time a cached answer is simply stale.

Rate and budget limiting is the second such thing. Setting a per user limit protects against one account generating a month's bill. That is a safeguard hard to build well inside an application and natural in a proxying layer.

The third is spreading traffic across providers and failing over. A model that is unavailable or answering slowly can be worked around by routing requests elsewhere, with no application change.

Self hosting and its limits

Since the self hosted route is the safest for current users, it pays to know what it involves.

This is not a single process. You need a relational database for metadata, storage for request and response bodies, and an analytical layer that can sum across millions of rows. Running the whole thing through a container set is documented, while maintaining it under production traffic is work for somebody who understands each of those pieces.

The biggest surprise is usually volume growth. Recording full prompt and response text for an application serving a thousand requests a day produces a set counted in hundreds of gigabytes after a year, especially where prompts carry retrieved document chunks. A retention policy here is mandatory rather than optional.

The second thing is that a proxy sits in the request path, so its failure stops the application rather than merely stopping data collection. That is a fundamental difference from instrumentation based tools, where trace shipping happens alongside and can fail with no consequence for the user. A self hosted deployment has to plan for it: a timeout, a bypass when unavailable, and a deliberate decision about whether traffic continues or halts on failure.

The third is the licence itself. Apache 2.0 grants the right to modify and continue developing, so if the product matters to you and the team can maintain it, that is a real option. Rarely chosen and rarely considered, and worth one meeting with a tool in maintenance mode.

Headers, sessions, and order in the data

This is the part easiest to skip during deployment and most painful later.

Recorded traffic with no description is a list of calls you cannot navigate. At a thousand requests a day you need a way to find the ones belonging to a particular user, a particular feature, or a particular prompt version.

With the proxy approach that happens through headers attached to the request. A user identifier lets you answer one person's report. A session identifier ties together calls from one conversation. A prompt version label lets you compare behaviour before and after a change, and that is the only way to tell whether the change helped.

Settle that set at the start, since adding it a year later means historical data stays undescribed and cannot be compared with the new. Three headers written into one place in the client cost fifteen minutes and pay back on the first serious report.

Think separately about what not to record. A user identifier in the form of an email address or a phone number turns a trace set into a set of personal data, with everything that follows. A hash or an internal identifier achieves the same without that problem.

Helicone against the alternatives

When migrating, decide deliberately whether to stay with the proxy approach or move to instrumentation.

A proxy is easier to deploy and thinner in what it sees. Instrumentation requires code changes and gives a full call tree including retrieval and tools. In a simple application calling a model once per request the difference is small. With an agent it is fundamental, and that is usually the moment teams move to instrumentation regardless of any particular product's fate.

If you choose instrumentation, reach for a tool built on OpenTelemetry. That standard means the next tool change will not mean another pass through the whole codebase, and as this example shows, changes happen more often than assumed.

How to run the migration

A few things save time once the decision to move has been taken.

Start with historical data. Decide whether you need to carry past records across or whether a fresh start suffices. The answer is usually that a fresh start suffices, since traces from six months ago concern an application that has changed since, and exporting and importing them costs more than they are worth.

Then run both tools in parallel for a week. The new observability layer then shows whether it records what you need, against a working reference point. Switching the old one off only after that week removes the risk of discovering gaps afterwards.

If you used caching or limits, plan those separately. They are features of a proxying layer rather than of observability, so an instrumentation based tool will not replace them. They have to move into a gateway or into your own code, and that is usually the largest part of the work in such a migration.

The last item is headers. With a proxy you typically attach user, session, and prompt version identifiers to requests as headers. After moving to instrumentation the same information has to travel as span attributes, and it pays to do that immediately, since without it the console shows traffic with no way to filter.

Common mistakes

The first is choosing this tool for a new project in 2026. Maintenance mode means no new features, so a migration is written into the plan from the start.

The second is assuming a proxy sees the whole application. It sees model calls, while document retrieval, tool calls, and the logic between steps stay out of reach.

The third is ignoring the extra network hop. On the hosted version traffic passes through somebody else's infrastructure, which matters both for latency and for where prompts land.

The fourth is caching responses where freshness matters. A cached answer is identical and can be stale, and noticing that usually takes several days.

The fifth is migrating with no parallel period. Switching over from one day to the next reveals gaps only once the old layer has stopped.

The sixth is moving observability without moving limits and caching. Those are separate features and a new tool will not reproduce them.

FAQ

Does Helicone still work?

Yes, in maintenance mode since March 2026. The service receives security patches, bug fixes, and support for new models, while no new features will come, and the acquirer announced help for customers moving to another platform.

Who acquired Helicone?

Mintlify, on the third of March 2026. The team, founders included, moved to the acquirer and works on a different product, which in practice decides this project's future more than any declaration.

Can I keep using the version running on my own server?

Yes, and that is the safest possible position. The code ships under Apache 2.0, so nothing disappears and nobody switches your service off. The remaining risk is the code ageing, spread over years rather than months.

What should I migrate to?

It depends on whether you want to stay with the proxy approach or move to instrumentation. For simple applications both routes are equivalent; with agents instrumentation gives a full call tree. Actively developed alternatives include Langfuse and Arize Phoenix.

How does a proxy differ from instrumentation?

In what it can see and what deployment costs. A proxy attaches through a base URL change and sees model calls alone. Instrumentation requires code changes and shows the whole flow including retrieval, tools, and the logic between steps.

The acquisition notice sits on the Helicone blog, and the acquirer's position in the Mintlify announcement.