Helicone

💰 Pricing & Plans

🔧 API & Developer Experience

• •Drop-in OpenAI-compatible proxy: Point your existing OpenAI/Anthropic SDK at Helicone's baseURL and every call is automatically logged, costed, and traced — no new SDK to learn.
• •AI Gateway with 100+ providers: Route requests across OpenAI, Anthropic, Google Vertex, Groq, Mistral and more with provider failover, fallbacks, and unified observability through one API surface.
• •Apache-2.0 self-host: Helicone's proxy and observability backend are Apache-2.0 licensed and deployable in your own VPC — full data residency, no external telemetry.
• •HQL query language: SQL-like syntax for slicing request logs: token cost per user, latency percentiles by model, error rates by prompt template — without writing custom pipelines.
• •Prompt caching & custom rate limits: Exact and semantic cache hits return cached responses at near-zero cost; per-user/per-key rate limits are configured declaratively, not via infrastructure code.
• •LLM security & moderation: Built-in prompts for prompt-injection detection, PII redaction, and OpenAI moderation routing — guardrails sit on the same proxy that logs the calls.
• •First-class Python & TypeScript SDKs: Native SDKs for Python and TypeScript plus a generic manual logger for any HTTP client; LangChain, LlamaIndex, and Semantic Kernel integrations ship out of the box.

🛰️ AI Gateway + Observability in One Proxy

Helicone's defining move is collapsing the LLM gateway and the observability backend into a single OpenAI-compatible proxy. Teams point the OpenAI or Anthropic SDK at Helicone's baseURL and immediately get request logging, cost attribution, retries, and provider failover against 100+ upstream models — no extra SDK, no separate trace pipeline. The same proxy that routes calls to OpenAI, Anthropic, Vertex, and Groq is the one that records them and enforces custom rate limits and caching. Because the proxy is open source (Apache-2.0) and the observability layer is the same binary, teams needing full data residency can self-host the whole stack on a domestic cloud and keep every prompt and completion inside their VPC. HQL then turns the captured request log into a queryable dataset — token spend by user, latency by model, error rates by prompt version — without exporting to a warehouse. Combining a unified routing surface, an open-source self-host path, and SQL-queryable logs is what differentiates Helicone from pure observability tools (Phoenix, LangSmith) and pure gateways (Portkey, OpenRouter) in the same category.

🌐 China Access & Latency

Helicone has a notably China-friendly deployment model because the proxy and observability backend are both Apache-2.0 open source. Mainland teams can self-host the entire Helicone stack on a domestic cloud such as Aliyun or Tencent Cloud, or run it on-premises, and never touch an overseas SaaS endpoint — every prompt, completion, and trace stays inside the Chinese network boundary, which suits data-residency and compliance-sensitive workloads. Because the proxy sits next to the application, there is no per-token egress cost or Chinese-specific rate-limiting at any provider edge. The managed SaaS side (Helicone Cloud) is hosted overseas and reachable from mainland China only via VPN or an overseas relay, which typically adds a few hundred milliseconds of latency — not practical for production traffic. The standard pattern is still self-hosting the open-source build on a domestic cloud and pointing clients at the local proxy — the trade-off is operational responsibility for PostgreSQL/Redis, but latency and access experience are effectively equivalent to running in-region. Helicone does not impose per-call geographic throttling the way many Western observability vendors do.