How do I move my metadata and tags from Helicone to Rius?

Rius carries your Helicone metadata and tags over as span attributes, sessions and users. Replace each Helicone-Property header with an attribute on the span that wraps the work, or on the resource for values that describe the whole process. Session and user headers become rius.session and rius.user scopes, which stamp session.id and user.id on every span in scope.

How it works

Helicone attaches metadata to a request through headers that its proxy reads. Rius has no proxy. The Rius SDK runs in your process and exports spans, so metadata becomes attributes on those spans. This is the mapping:

• Helicone-Property- (custom properties)* becomes a span attribute for a value that belongs to one request, such as a ticket id or a feature name. It becomes a resource attribute for a value that belongs to the deployment, such as an app version or a region.
• Helicone-Session-Id becomes rius.session(id) in Python or withSession in TypeScript. It stamps session.id on every span inside the scope, including the auto-instrumented model call.
• Helicone-User-Id becomes rius.user(id) in Python or withUser in TypeScript. It stamps user.id and feeds the Users page and the user filter on the trace list.
• Helicone-Session-Path has no path string in Rius. The tree comes from how your spans nest, so a ticket span with an answer span started inside it keeps the same structure.
• Helicone-Session-Name has no separate field. Name the span that wraps the work, or set an attribute.
• Environment tags such as production and staging belong in separate workspaces, each with its own API key, not in an attribute.

If you used the Helicone async logger, replace logger.set_properties(...) (withProperties in TypeScript) with the scopes and attributes above. Remove the logger instead of running both in one process, because only one tool receives the instrumented calls. The full path for each Helicone setup is in Migrate from Helicone, and the wider approach is in Migrate to Rius.

Set it up

1. Start Rius in your process, and remove the Helicone base URL and Helicone-Auth header, or the async logger. Calls then go straight to the provider, and the SDK traces them. The key is read from RIUS_API_KEY.

   import rius
    
   rius.init(service_name="my-agent")  # reads RIUS_API_KEY

2. Replace the session and user headers with scopes. Every span started inside carries session.id and user.id.

   with rius.session(session_id):
       with rius.user(request.user_id):
           handle(request)

   In TypeScript, use withSession and withUser, both imported from @glassflow-ai/rius.

3. Move each per-request property onto the span that wraps the work. Wrap the call in a span and set one attribute per property. The names app.ticket_id and app.feature are examples of your own names, so pick the keys you used as Helicone property names.

   with rius.start_as_current_span("support_ticket") as span:
       span.set_attribute("app.ticket_id", ticket_id)
       span.set_attribute("app.feature", "auto-reply")
       response = openai_client.chat.completions.create(
           model="gpt-4o-mini", messages=messages,
       )

4. Move per-deployment properties onto the resource. Set them with the standard OpenTelemetry OTEL_RESOURCE_ATTRIBUTES variable as comma-separated key=value pairs, for example service.version and your own app.region. Every span from the process then carries them.

5. Check one trace in Rius. Open it and confirm the session, the user and your attributes show on it. Then filter on them with Add filter in the trace list.

What you get

• Your properties are filterable in the trace list. A trace matches when any of its spans carries the value.
• You can declare an attribute with a type in the workspace settings, so you can filter it numerically.
• Sessions group related traces, and each user appears on the Users page with their traces, failures, error rate and cost.
• Cost is computed by Rius from the model and token counts, so you never send it as metadata. It is a list-price estimate in US dollars.
• The trace shows the full tree of agent, tool, retrieval and model steps, so structure that Helicone expressed with a session path comes from your code’s nesting.

Two things have no counterpart. Rius gives no cost or metric breakdown per custom property, and it has no active-user, retention or cohort analytics. Attributes are for finding and filtering traces. Existing Helicone data also stays in Helicone, because Rius starts from the first span you send.

When something else fits

• If you need cost broken down by a custom property, or product analytics such as retention and cohorts, keep that reporting where it is today, because Rius filters on attributes but does not aggregate by them.
• If caching, rate limits or fallbacks are part of how you use Helicone, keep the gateway in place and add the Rius SDK next to it, since Rius traces the calls either way.

Related