The Mintlify acquisition put Helicone into maintenance mode. Here is what changed, what to evaluate in a replacement, and how to migrate without losing the trace history you spent a year accumulating. Honest about every alternative, including ours.
On 3 March 2026, Mintlify acquired Helicone. The team relocated to San Francisco, and the stated rationale was integrating Helicone's routing and observability into Mintlify's documentation infrastructure. The official messaging was steady: services will remain live for the foreseeable future, in maintenance mode.
The scale at the time was not small. Helicone had processed 14.2 trillion tokens, served around 16,000 organisations, and tracked roughly 33 million users. This was a serious piece of infrastructure with a large installed base, not a side project quietly winding down.
What maintenance mode means in practice is narrow: security patches, new model support, and bug fixes only. No new features. Open issues on the self-hosted version are reportedly not being addressed. There is no public roadmap and no timeline for a full shutdown. The Helicone founders are personally helping customers with migrations, which is generous, and which also tells you everything you need to know about where the team's attention has moved.
The honest read: Helicone is not end of life today, but it is on a glidepath. If you are evaluating it for a new production deployment in 2026, you should not be.
The honest answer is not in a panic, but yes. Maintenance mode is not the same as a forced shutdown. Your existing Helicone deployment will keep working for the foreseeable future, and nothing about your traffic stops the day you read this.
What changed is the risk profile. New provider API features, prompt caching on Anthropic, structured outputs on OpenAI, new models as they ship, will lag in support. Your compliance team will flag the maintenance-mode dependency on the next audit. The product still does what it did; it just stops growing into what you will need next.
Three triggers make migration genuinely urgent:
The realistic window for an unhurried migration is around six to twelve months. Use it. Do not wait until you have an outage.
Migration on your timeline is much cheaper than migration on someone else's.
It is worth being clear-eyed about what Helicone built well, because the migration story is more useful when it is honest.
The single-URL-change integration was the headline. Most observability tools require an SDK installation; Helicone needed one config change to a base URL. That insight was genuinely influential, and the execution was solid enough to process 14 trillion tokens through it.
The multi-provider gateway was part of the observability product, not a separate thing you bolted on. Routing, caching, and fallback handling sat alongside logging. Most alternatives picked one or the other; Helicone shipped both.
The Apache 2.0 license made the self-hostable path real, and serious teams ran it in production. Cost-per-request tracking and per-user tagging worked from day one, with no eval team or data pipeline required to get a useful dashboard.
What Helicone never quite owned was the production operator's set of questions: cost per customer, cost per feature, was the scheduled run actually fresh, did the output quality just drift. Helicone watched the request. The next generation of tools watches the agent.
Six criteria, useful regardless of which tool you end up picking.
Proxies are simpler to install but add a network hop on your critical path. SDKs require code changes but never sit between your code and the provider. Helicone customers who were rattled by the maintenance-mode realisation often prefer SDK approaches now, because the failure mode is telemetry stops rather than all LLM calls stop.
Per-request is table stakes. Per-user is fine. Per-customer and per-feature is where finance teams stop asking awkward questions. Look at the default data model, not just what is theoretically possible with enough custom tagging.
If your agents run on schedules (cron, n8n, GitHub Actions), missed runs are a primary failure mode. The tool should page you when a scheduled run does not arrive in its window, not only when something throws.
A 200 OK with hallucinated output is a failure that no traditional observability stack catches. Look for deterministic checks, LLM-as-judge with calibration anchors, and drift detection on the production score distribution.
Per-seat is the structural enemy at small scale: you pay more for adding teammates. Per-trace is the structural enemy at large scale: overage costs come to dominate. A flat tier with named limits is the only model that does not punish you for either growth axis, and many of the post-Helicone alternatives have not figured this out yet.
Maintenance mode happened to Helicone after acquisition. ClickHouse acquired Langfuse in January 2026. Cisco acquired Galileo in May 2026. The independent observability vendors are being absorbed. If you are picking a tool to depend on for the next three years, ask who owns it and whether they have a parent company with a different strategic priority.
Different teams weight these six criteria differently. There is no single correct answer; there is only a correct answer for your stack and your roadmap.
Production observability with cost attribution per agent, per customer, and per feature as the default. Schedule freshness, drift detection, and LLM-as-judge with calibration anchors. Flat tier with named limits, no per-seat, no per-trace, no overage. Best for AI-focused B2B SaaS running production agents that touch paying customers. Worst fit if your primary workflow is offline batch evaluation on curated datasets (use Braintrust) or if you need a drop-in proxy with one config change (use Portkey).
Apache 2.0 gateway, the closest architectural replacement for Helicone's gateway-first model. Lightweight, fast to install, with observability through the Maxim platform. A good pick if you used Helicone primarily as a routing gateway with logging as a nice-to-have.
Full-stack open source that combines gateway, observability, evals, and guardrails in one platform. The most ambitious feature set in this list. Worth evaluating if you want to consolidate onto one tool rather than stitch a stack together.
Open source and self-hostable under MIT, plus a hosted cloud option. Strong tracing, mature prompt management, broad framework coverage; the default open-source choice. Note that ClickHouse acquired Langfuse in January 2026; the product is unchanged, but the acquisition introduces some vendor-direction uncertainty. Best for teams with the operational capacity to self-host and a preference for OSS.
LangChain's commercial platform, with first-class instrumentation for LangChain and LangGraph. Per-seat plus per-trace pricing means it gets expensive quickly at production scale. Best for teams deep in the LangChain ecosystem whose primary workflow is prompt iteration and offline eval at development time.
A read-only-API-key approach: no proxy, no SDK, no code changes, set up in around thirty seconds, with a free tier. Best for teams who used Helicone primarily for cost visibility and want a near-zero-effort replacement. The trade-off is that you only get what the provider's billing API exposes; deep request-level tracing is out of scope.
Open source, OpenTelemetry-native, ELv2 licensed. Best for teams already on Arize for ML observability, or who have made OpenTelemetry a hard requirement.
Open-source AI gateway with a hosted plane. Architecturally the closest to Helicone: routing, caching, automatic fallback, and a prompt library. If you used Helicone for the gateway features and you want a like-for-like replacement that is being actively developed, Portkey is the obvious pick.
A self-hosted Docker container designed as a near-drop-in Helicone replacement. Same proxy-header model, and it aliases Helicone's custom headers. Best for teams who want to keep the Helicone integration pattern and host it themselves.
Most teams will not pick exactly one tool. A common pattern in 2026 is gateway tool plus observability tool: Portkey or Bifrost for routing, paired with AgentPing or Langfuse for the per-agent observability layer. The two have different jobs and the SDKs do not conflict. Pick the architectural bet that matches your traces, not the marketing page that matches your mood.
The first step is removing Helicone from the hot path. For most teams that is a base-URL change back to the native client:
# Before: proxied through Helicone
client = OpenAI(
api_key="sk-...",
base_url="https://oai.helicone.ai/v1",
default_headers={"Helicone-Auth": "Bearer hc-..."},
)
# After: direct to provider
client = OpenAI(api_key="sk-...")
The same applies to Anthropic and any other provider you proxied. Any Helicone-specific headers (Helicone-Property-*, Helicone-Session-Id, and the rest) need to be migrated to whatever replacement you pick, rather than dropped.
| Helicone concept | AgentPing equivalent |
|---|---|
| Request | Run (one agent invocation, may contain many LLM calls) |
| Property | Run metadata (customer_id, feature, and so on) |
| User ID | Customer ID (per-customer cost rollup is the default) |
| Session ID | Parent run ID (multi-step agents become parent/child run trees) |
| Custom header tagging | Fields set at run start via the SDK |
| Scores | Self-reported scores plus deterministic checks plus LLM-as-judge |
This captures the same data Helicone would have, plus the things Helicone did not:
import agentping
from anthropic import Anthropic
agentping.init(api_key="apk_...")
client = Anthropic()
with agentping.run("ticket-triage",
customer_id="acme-corp",
feature="support-routing") as run:
response = client.messages.create(...)
run.score("confidence", 0.92)
run.log(f"Routed to {department}")
That is the entire migration for one workflow. The proxy is removed from your hot path. The cost attribution moves from per-request to per-agent and per-customer. The schedule freshness checks and the quality scoring become available as soon as you point AgentPing at your scheduler.
AgentPing is what we are building. Production observability with cost attribution per agent, per customer, and per feature as the default, plus schedule freshness for cron-driven agents and quality scoring on the production stream. SDK-based, independently owned, not in maintenance mode. If the production-focused angle in this guide describes your situation, we built AgentPing for you. The first cost spike it catches typically pays for the next year of subscription.
If the production observability angle in this guide matches what you need, we would love to have you. The free plan includes 100k events per month and needs no card.
Context: what the acquisition means for the market → AgentPing vs Helicone →