Skip to Content

Can I run Rius alongside Helicone while I migrate?

Yes, Rius runs alongside Helicone during a migration, so you can compare both on the same traffic and turn Helicone off once Rius shows what you need. With the Helicone proxy or AI Gateway, keep the Helicone base URL and add the Rius SDK. With the async logger, run each tool in a separate service. If your code already emits OpenTelemetry, a Collector can send the same traces to Rius and to your other backend.

How it works

The right setup depends on how Helicone captures your calls today.

  • Helicone proxy or AI Gateway: The Rius SDK instruments your client library inside your process, not the network path. Leave the Helicone base URL and headers in place and add rius.init(). Helicone logs each call on the network path and Rius traces it in your process, so both see the same traffic.
  • Helicone async logger: Both the logger and the Rius SDK register the process-wide OpenTelemetry tracer provider, and OpenTelemetry keeps only the first registration. Running both in one process means the instrumented calls reach only one tool. Run the logger in one service and the Rius SDK in another, or compare one deploy of each.
  • Instrumentation that already emits OpenTelemetry: An OpenTelemetry Collector can fan the same traces out to Rius and to your existing backend with one extra exporter entry and no application changes.

The Helicone proxy logs to Helicone, and Rius does not accept Helicone’s request logs. A Collector cannot forward those logs to Rius. Rius receives OpenTelemetry spans created in your process.

Set it up

  1. Create a Rius workspace and API key, install the SDK with the integrations for your providers, and call init() at startup. The Helicone migration guide covers the install lines for Python and TypeScript.

    import rius rius.init(service_name="my-agent") # reads RIUS_API_KEY
  2. Proxy or AI Gateway: Do not remove the Helicone base URL or the Helicone-Auth header yet. Use plain model names such as gpt-4o-mini, not the gateway’s gpt-4o-mini/openai form, or calls show tokens but no cost. If the gateway supplies your provider keys or credits, switch to your own provider keys before you remove it, because Rius never holds provider keys.

  3. Async logger: Keep it in its current service and add the Rius SDK to a different service or deploy.

  4. Collector: If your instrumentation already emits OpenTelemetry, add Rius as an exporter next to the existing one. Use the otlphttp exporter, not otlp, because the endpoint does not accept gRPC.

    exporters: otlphttp/glassflow: endpoint: https://ingest.eu.console.rius-glassflow.com # proto is the default encoding and the recommended one; json works too encoding: proto compression: gzip headers: authorization: Bearer ${env:RIUS_API_KEY} service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlphttp/glassflow, otlphttp/existing]

    The Collector page has the full configuration. If analytics fields come up empty, check that no Collector processor strips gen_ai.* keys.

  5. Verify one call end to end: the trace appears under your service_name, the model call shows model and token counts, and cost appears.

  6. Move your session, user and property values onto rius.session(), rius.user() and span attributes while both tools run.

What you get

  • Both tools see the same traffic, so you can compare request counts, token totals and cost before you commit.
  • Rius computes cost from the model and token counts, and shows traces, sessions and users.
  • Expect Rius cost to run higher than Helicone’s by your cache-hit share. Rius records a response served from Helicone’s cache like any other call and prices it from its tokens.
  • A clear point to turn Helicone off. Compare both backends for a few days, then decide what happens to gateway features you use. Move anything that reads from Helicone, such as dashboards and alerts, to the Rius equivalents. Then remove the Helicone base URL, the Helicone-* headers and the async logger, and revoke the Helicone API key once nothing sends to it.
  • Existing Helicone history does not move. Rius starts from the first span you send, so keep Helicone or an export from its query API if you need the past.

The Migrate to Rius overview has the same side-by-side approach for other tools.

When something else fits

  • If caching, rate limits, retries or fallbacks are load-bearing, keep the Helicone gateway after the migration. Rius is not a gateway, and it traces your calls either way.
  • If you depend on prompt management, scores, datasets or evals, keep those workflows in your current tool, because Rius does not offer them.

Still stuck? Get help

Last updated on