Can I keep my OpenTelemetry instrumentation when I leave Helicone?

Yes, Rius takes OpenTelemetry traces, so you keep your OpenTelemetry instrumentation and re-point its OTLP exporter or your Collector at Rius. Rius reads models, token counts, sessions, users and tool names from the standard attributes on your spans and computes cost itself. Helicone’s own request logging is separate: the proxy logs to Helicone, and Rius does not accept Helicone’s request logs. Migrating is usually a routing change, as the Migrate to Rius guide describes.

How it works

Rius is convention-native OpenTelemetry, so the spans your instrumentation already emits are what it reads. See Interoperability for every sender path.

What can stay

• Instrumentation from OpenLLMetry or OpenInference.
• Any instrumentation that follows the OTel GenAI conventions.
• An OpenTelemetry Collector or any other OTLP sender. Only the exporter or Collector destination changes.

What Rius reads from those spans

• The model, from gen_ai.request.model.
• Token counts from gen_ai.usage.input_tokens and gen_ai.usage.output_tokens, plus cache read, cache write and reasoning tokens when you send them.
• The kind of step, from gen_ai.operation.name or openinference.span.kind.
• Agent and tool names from gen_ai.agent.name and gen_ai.tool.name, and failures from error.type.
• Sessions and users from session.id and user.id. A trace with no session.id is its own session, and a span with no user.id counts as anonymous.
• Prompts and replies from the GenAI message attributes, unless content capture is off.
• Resource attributes such as service.name and service.version.

OpenInference, OpenLLMetry and Traceloop, Laminar, Vercel AI SDK 5 and 6, and Pydantic AI usage details are normalized when they arrive, so models and tokens appear without code changes. Rius computes cost and time to first token from the spans. Never send a cost value.

What Helicone-specific pieces do

The Helicone-* headers (Helicone-Session-Id, Helicone-User-Id, Helicone-Property-*) are request headers read by the Helicone gateway, not span attributes. Rius reads the equivalents from span attributes, so you move those values onto session.id, user.id and your own attributes. If you rely on the gateway for caching, rate limits or fallbacks, leave it in place. Rius traces the calls whichever base URL the client uses.

Set it up

1. Create a Rius workspace and an API key. Keys start with ri_.
2. In your exporter or Collector, set the traces endpoint to https://ingest.eu.console.rius-glassflow.com/v1/traces. Use OTLP over HTTP (http/protobuf is recommended, http/json also works) and send the key in an Authorization Bearer header. There is no gRPC endpoint, and Rius ingests traces only, not OTLP metrics or logs. For a vanilla OpenTelemetry SDK in your language, follow that SDK’s own documentation to register a tracer provider with this exporter. If a Helicone async logger is running in the process, remove it. It registers the process-wide tracer provider, OpenTelemetry keeps only the first registration, and your calls would reach only one tool.
3. If you would rather not wire the exporter yourself, call rius.init() instead. The Rius SDK instruments your client in the process and sends the traces for you. Remove your existing OpenTelemetry instrumentation and tracer provider setup first, because running both produces duplicate LLM spans:

import rius
 
client = rius.init(
    api_key="ri_...",
    service_name="my-agent",
)

4. Move per-deployment properties, such as an app version or region, onto the resource with the standard OpenTelemetry variable:

export OTEL_RESOURCE_ATTRIBUTES="service.version=1.4.2,app.region=eu"

5. Set session.id and user.id on every span, root included, in place of the Helicone session and user headers. The Python SDK offers rius.session and rius.user, and the TypeScript SDK offers withSession and withUser.
6. While you evaluate, send the same traces to both backends. Cut over when Rius shows what you need, then remove the Helicone base URL and headers if you no longer need the gateway. The Migrate from Helicone guide has the full checklist.

What you get

• Your existing instrumentation keeps producing spans, and Rius shows them with models, tokens and cost per call.
• Sessions and users appear once your spans carry session.id and user.id.
• Cost is a list-price estimate in US dollars, computed by Rius from the model and token counts.
• You can run Rius next to Helicone on the same traffic and compare request counts, token totals and cost before you cut over.
• Rius starts from the first span you send. Existing traces stay in Helicone, and there is no import.

When something else fits

• Rius is not a gateway, so caching, rate limits, retries and fallbacks stay with the Helicone gateway or whatever serves them today.
• Rius has no prompt management, scores, datasets or evals, so keep those workflows in your current tool.

Related