Helicone: product and architecture
This Helicone review covers a product that sits in two categories at once, and understanding which one you are buying decides whether it is a good deal. Helicone is an LLM observability platform whose integration path is a gateway: you point the OpenAI SDK at its endpoint and requests are logged without changing your code. That makes adoption unusually cheap and the product boundary unusually wide. It is Apache-2.0 and self-hostable, with a free tier and paid plans. We evaluated it against its documentation, its published pricing, its GitHub repository, and the adoption signals we collect weekly.
Overview
Helicone was a YC W23 company and describes itself as an open-source LLM observability platform. Our 14 September 2026 snapshot recorded about 6,200 GitHub stars on Helicone/helicone, roughly 3,800 weekly npm downloads of @helicone/helpers, and 803 votes on its Product Hunt launch. The repository is Apache-2.0 and TypeScript, and was last pushed on 16 September 2026.
Worth stating plainly: the last tagged release we can see is v2025.08.21-1, while the repository is committed to weekly. A project that ships continuously without cutting tags is a normal pattern for a hosted product, but it means version pinning is not straightforward if you self-host.
Its market position is the lowest-friction entry to LLM observability. The documentation's own framing has moved toward "AI Gateway" — an OpenAI-compatible unified API across 100-plus models with automatic fallbacks and unified billing — which places it between a pure observability tool and a gateway such as LiteLLM.
The audience is teams who want request visibility and cost tracking today, without an instrumentation project.
Key Features and Architecture
The defining choice is the proxy integration. You change a base URL to https://ai-gateway.helicone.ai, keep the OpenAI SDK you already use, and every request is logged. There is no span instrumentation to write and no framework integration to maintain. That is the single biggest reason teams adopt it, and it is also the architectural commitment: your traffic goes through Helicone's infrastructure.
For teams that will not route production traffic through a third party, there is an async SDK that logs out of band. It is the right answer for latency-critical or compliance-constrained paths, and it is a genuinely different integration rather than a flag.
As a gateway it offers an OpenAI-compatible unified API across 100-plus models, with support named for OpenAI, Anthropic, Google, Vertex, and Groq among others; automatic fallbacks when a provider is down; and unified billing with 0% markup, so you pay provider list price. Switching model is a parameter change.
As an observability tool it records requests and responses, tracks cost, and supports evaluation and experimentation — the vendor's own summary is "one line of code to monitor, evaluate, and experiment".
The self-hosted option matters and is unusual in this shape: the repository is Apache-2.0 throughout, not an open core with a commercial directory, so running it yourself is genuinely the same software. Enterprise adds an on-prem deployment with vendor support on top.
Ideal Use Cases
Four situations favour Helicone. The first is getting visibility today. If you have an application in production with no observability and limited appetite for an instrumentation project, a base-URL change is as cheap as adoption gets, and something running now beats something better next quarter.
The second is cost attribution as the first question. Teams usually reach for observability because a bill surprised them, and request-level cost tracking with 0% markup on the underlying providers answers that directly.
The third is wanting a gateway and observability from one product. Running LiteLLM for routing and Langfuse for tracing is two services; Helicone is one, and for a small team that is a real saving in operational surface.
The fourth is an Apache-2.0 requirement. Of the mainstream LLM observability tools, Helicone is the one whose whole repository carries a single OSI-approved licence — Langfuse's is a split GitHub cannot resolve, Phoenix's is Elastic Licence 2.0, and Braintrust is proprietary.
Do not adopt the proxy path if a third party may not sit in your request path — use the async SDK, and weigh whether you would then rather instrument with OpenTelemetry into a tool built for it. It is also the wrong pick if prompt management with deployment and rollback, or versioned datasets and CI gating, are what you need: Langfuse and Braintrust are built around those and this is not. And a gateway comparison here should be made carefully, because per-team budgets, virtual keys, and RPM and TPM governance are LiteLLM's territory rather than Helicone's.
Pricing and Licensing
Hobby is free with 10,000 requests and 1 GB of storage, which is enough to answer whether the integration suits you. Pro is $79/month and Team is $799/month, both adding usage-based charges above the same 10,000 free requests and 1 GB. Enterprise is quoted and is the only tier offering an on-prem deployment with vendor support.
The gateway takes 0% markup: you pay each provider exactly what they charge, and Helicone earns on the platform subscription rather than on your tokens. That is a cleaner arrangement than a percentage spread, and it means the cost of the gateway does not grow with your model spend — a meaningful difference from a hosted gateway that charges a fee on credit purchases.
Self-hosting is free, and the licence is the reason it is credible: the repository is Apache-2.0 throughout rather than an open core with a commercially licensed directory, so the self-hosted build is not a reduced edition.
The jump from $79 to $799 is the decision point, and it is a large one. Before committing to Team, check which specific capability you need from it against what the usage-based charges on Pro would cost at your volume — for many teams the answer is that Pro plus overage is cheaper than the next tier, and for others the seat and governance features decide it.
Strengths & Trade-offs
Pros
- A base-URL change is the entire integration, which is the cheapest adoption path in the category.
- Apache-2.0 across the whole repository, so an open-source-only requirement is satisfied and the self-hosted build is the same software.
- 0% markup on provider costs, so the gateway's price does not scale with your token spend.
- Gateway and observability in one product, which is one service to run instead of two.
- An async SDK for teams that will not route production traffic through a third party.
Cons
- The proxy puts a third party in your request path, which is an availability and compliance question before it is a technical one.
- The last tagged release is from August 2025 while the repository is committed to weekly, so self-hosted version pinning is awkward.
- Prompt management with deployment and rollback is not the focus, and neither is versioned-dataset evaluation with CI gating.
- Not a governance gateway: no per-team budgets, virtual keys, or RPM and TPM limits of the kind LiteLLM provides.
- The gap between Pro and Team is an order of magnitude, with little in between.