How do I move my historical traces from Helicone to Rius?

Rius does not import historical traces from Helicone, so your history stays in Helicone and Rius starts from the first span you send it. You add the Rius SDK, run both tools on the same traffic, and cut over when Rius shows what you need. The Helicone concepts you used for new traces (sessions, users, custom properties) map onto Rius sessions, users and span attributes.

How it works

Helicone is mainly a proxy. Your client sends each request through a Helicone base URL, and Helicone logs it on the way through. Rius works differently. The Rius SDK instruments your LLM client inside your process and exports OpenTelemetry spans, one record per step such as a model call. Rius does not accept Helicone’s request logs, so there is no import and no way to point the Helicone proxy at Rius.

Because of that, history and new data live in separate places:

• Existing traces stay in Helicone. Keep Helicone, or an export from its query API, for anything you need to look back at.
• New traces go to Rius from the moment rius.init() runs.

Here is how the concepts map for new traces:

The Migrate to Rius overview covers the general approach, and the Helicone migration guide has the full walkthrough.

Set it up

1. Create a Rius workspace and API key, then install the SDK with the integrations for the providers you call.

   pip install "glassflow-rius[openai,anthropic]"
   export RIUS_API_KEY="ri_..."

2. Call rius.init() at startup. It traces every call your provider clients make, whatever base URL they use.

   import rius
   from openai import OpenAI
   from anthropic import Anthropic
    
   rius.init(service_name="my-agent")  # reads RIUS_API_KEY
    
   openai_client = OpenAI()        # default base URL once Helicone is gone
   anthropic_client = Anthropic()  # default base URL once Helicone is gone

3. Run both tools side by side. If you use the proxy or AI Gateway, leave the Helicone base URL and headers in place and add rius.init() anyway. The Rius integrations patch the client library in your process, not the network path, so calls are traced whatever base URL the client uses. If you use Helicone’s async logger, run it in one service and the Rius SDK in another. Do not run both in one process, because both register the process-wide OpenTelemetry tracer provider and only the first registration is kept.

4. Carry over the values you send as Helicone headers, and keep the headers themselves until cutover. Wrap the work in a session and a parent span, and wrap each request in a user scope.

   with rius.session(session_id):
       with rius.start_as_current_span("support_ticket"):
           response = openai_client.chat.completions.create(
               model="gpt-4o-mini", messages=messages,
           )
    
   with rius.user(request.user_id):
       handle(request)  # every span of the request carries user.id

   Set per-request properties as attributes on the wrapping span with span.set_attribute(...). Set per-deployment values, such as app version or region, on the resource with the OTEL_RESOURCE_ATTRIBUTES variable.

5. Verify one call end to end. The trace appears under the agent named by your service_name, the generation shows model and token counts, and cost appears. Then compare request counts, token totals and cost on real traffic for a few days.

6. When Rius shows what you need, remove the Helicone base URL, the Helicone-* headers and the async logger. Revoke the Helicone API key once nothing sends to it.

Two details matter while both tools run. A response Helicone serves from its cache is still recorded by Rius as a generation priced from its token counts, so Rius cost runs higher than Helicone’s by your cache-hit share. 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.

What you get

• A clean start in Rius on the day you add the SDK, with every later call traced as a generation with model, input and output tokens, cache reads and writes, and messages.
• Traces that show the full tree of agent, tool, retrieval and model steps, not only LLM requests.
• Sessions and a Users page that lists each user with their traces, failures, error rate and cost.
• Cost per call computed by Rius from the model and token counts. These are list-price estimates in US dollars, not billed amounts.
• Alerts with webhook, email and Slack channels, and an MCP server so your coding agent can query production traces.

Your Helicone history stays where it is, readable in Helicone for as long as you keep that account.

When something else fits

• If you need old and new traces in one view, keep Helicone for the history, or keep an export from its query API, and use Rius for everything from the cutover on.
• If caching, rate limits, retries or fallbacks are load-bearing, keep the Helicone gateway and add Rius next to it. Rius is not a gateway and does not replace those features.
• If you depend on prompt management, scores, datasets or evals, keep those workflows in your current tool, because Rius does not offer them.

Related