Helicone is now in maintenance mode. Here's how to switch to OpenObserve in 5 minutes.

#llm #ai #opensource #opentelemetry

If you've been using Helicone to track LLM costs and traces, you've probably noticed development has slowed down since the Mintlify acquisition in March 2026. Open issues on the self-hosted repo aren't getting picked up, and the team's focus has visibly shifted.

If you're looking for a replacement, this post walks through moving to OpenObserve — a self-hosted, Rust-based observability platform that handles LLM traces, logs, metrics, and infra monitoring in one binary.

The one thing to know before you migrate

Helicone and OpenObserve solve the same problem in different ways, and that matters for how you migrate.

Helicone is proxy-based: you point your base_url at Helicone, it sits in front of the provider, and it logs the request/response pair as it passes through.

OpenObserve is OpenTelemetry-native: instead of proxying traffic, it ingests OTLP spans. You keep calling OpenAI/Anthropic directly, and an OpenTelemetry instrumentor wraps the client to emit a span for each call — prompt, response, tokens, latency, cost — straight to OpenObserve.

That means migration isn't a one-line base_url swap. It's swapping a proxy header for a few lines of instrumentation. In practice it's still a five-minute change, and you get logs, metrics, and infra traces in the same place as your LLM traces for free — something Helicone doesn't do.

Before (Helicone)

from openai import OpenAI

client = OpenAI(
    api_key="sk-your-openai-key",
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": "Bearer hc-your-helicone-key",
    }
)

After (OpenObserve)

from opentelemetry.instrumentation.openai import OpenAIInstrumentor
from openobserve import openobserve_init

# Instrument the OpenAI client and point traces at OpenObserve
OpenAIInstrumentor().instrument()
openobserve_init()

from openai import OpenAI

# Call OpenAI as normal — no base_url or header changes needed
client = OpenAI(api_key="sk-your-openai-key")

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Hello!"}]
)

Anthropic works the same way with AnthropicInstrumentor, and LangChain has its own instrumentor too, so chain-level traces show up without extra code.

Step-by-step migration

1. Run OpenObserve

docker run -d --name openobserve \
  -v $PWD/data:/data \
  -e ZO_DATA_DIR="/data" \
  -e ZO_ROOT_USER_EMAIL="root@example.com" \
  -e ZO_ROOT_USER_PASSWORD="Complexpass#123" \
  -p 5080:5080 \
  public.ecr.aws/zinclabs/openobserve:latest

Open http://localhost:5080 and log in with the credentials above.

2. Install the SDK

pip install openobserve-telemetry-sdk openai opentelemetry-instrumentation-openai python-dotenv

3. Set your environment variables

# Base64-encode "email:password" for OPENOBSERVE_AUTH_TOKEN
OPENOBSERVE_URL="http://localhost:5080"
OPENOBSERVE_ORG="default"
OPENOBSERVE_AUTH_TOKEN="Basic <your_base64_token>"
OPENAI_API_KEY="your-openai-key"

4. Swap the Helicone client for the instrumented one

Remove the base_url and Helicone-Auth header, add the two instrumentor lines shown above, and call the OpenAI or Anthropic SDK exactly as you did before.

5. Confirm it works

Send a request, then open OpenObserve → Traces. You should see a span with the model, prompt, response, token counts, and latency.

What you gain beyond parity

Logs, metrics, and traces in one place. If you're already running Prometheus, Loki, or an ELK stack for infra, OpenObserve can absorb that too, so LLM spans sit next to the rest of your system's telemetry instead of living in a separate dashboard.
SQL-based querying over trace data instead of a fixed UI.
No proxy hop. Your requests go straight to the provider; OpenObserve only receives the telemetry, not the live traffic.
Columnar storage on Parquet/S3, which keeps costs down at higher trace volumes compared to row-based stores.

What you lose (for now)

OpenObserve isn't a drop-in AI gateway — it doesn't do request routing, caching, or fallbacks the way Helicone's gateway features do. If you're using those, you'll want to pair OpenObserve with something like LiteLLM for routing and keep OpenObserve purely as the observability backend.