How do I move my sessions from Arize Phoenix to Rius?

Rius reads the same session.id attribute Phoenix uses, so your sessions move when you point your OpenInference exporter at Rius or switch using_session to rius.session. Your instrumentation keeps stamping the same attribute. Set it on every span of a trace, the root span included, so each trace lands in the right session. Sessions you already recorded in Phoenix stay there, and Rius starts from the first span you send.

How it works

A Phoenix session is a group of traces that share a session.id. Rius uses the same attribute, so the mapping is one to one:

• Session: Phoenix’s session.id, set with using_session, is a Rius session. Rius groups traces by that value.
• User: user.id, set with using_user, is read directly as the Rius user.
• Project: a Phoenix project maps to a Rius agent, named by the service.name resource attribute. Phoenix’s openinference.project.name is stored but does not group anything, so set service.name or your traces arrive as unknown_service.

The trace list shows a trace under the session and user of its root span, the top-level span of the trace, usually your request handler. That is where migrations go wrong. The using_session and using_user context managers only stamp spans created by OpenInference: the instrumentors, and the tracer from the provider that register() returns. A root span you start from a plain OpenTelemetry tracer misses them. The trace then shows up as a single-trace session with no user, even though the model call inside carries the right ids.

The Rius SDK removes this problem. rius.session and rius.user stamp every span in scope, the root and the instrumentors’ spans included.

For the full concept table and both migration paths, see Migrate from Arize Phoenix. For the general approach to moving between tools, see Migrate to Rius.

Set it up

1. Pick a path. To keep your code as it is, keep register() or your own tracer provider and re-point its exporter at Rius, as the Phoenix migration guide shows. Your using_session calls keep working. To use the Rius SDK instead, follow step 3.

2. If you keep OpenInference, make sure the root span carries the session. Start root spans from the OpenInference tracer (tracer_provider.get_tracer(__name__)), or set the attributes on the root yourself:

with tracer.start_as_current_span(
    "handle-turn",
    attributes={"session.id": conversation_id, "user.id": user_id},
):
    run_agent(message)

3. If you switch to the Rius SDK, replace the session scope. Install the SDK with the extra for your provider, then swap register() and using_session:

pip install "glassflow-rius[openai]"

# Before
from phoenix.otel import register
from openinference.instrumentation import using_session
 
register(project_name="my-agent", auto_instrument=True)
 
with using_session(conversation_id):
    run_agent(message)

# After
import rius
 
rius.init(service_name="my-agent")
 
with rius.session(conversation_id):
    run_agent(message)

Change using_user to rius.user in the same edit. Set RIUS_API_KEY in your environment. The endpoint defaults to EU ingest, so the key is usually the only setting. rius.init() instruments the supported libraries it finds installed, so your own instrumentor calls and auto_instrument=True go away.

4. Run both backends in parallel. Add Rius as a second span processor with replace_default_processor=False so your Phoenix project keeps receiving spans. The side-by-side code is in the Phoenix guide.

5. Check one traced request. Confirm the trace sits in the session you expect and under the right user. A trace that appears as its own one-trace session points to a root span without session.id.

What you get

• Traces grouped by the same session.id values you already use, with no change to the ids.
• Each trace listed under the session and user of its root span.
• Model, token and cost data on the model-call spans, because Rius reads OpenInference spans. Rius computes cost on its side, so you never send a cost value.
• With the Rius SDK, scopes that stamp every span, so you no longer depend on where the root span was created.
• With no session.id, a trace counts as its own session. With the Rius SDK, set RIUS_SESSION_ID to tag a whole process, such as a CLI run, with one session.

When something else fits

• No counterpart in Rius: annotations and feedback on spans, evals, datasets, experiments and prompt management. If your session reviews depend on them, keep Phoenix for that work and run both side by side.
• History does not move: Rius has no import of past Phoenix sessions. Keep your Phoenix instance, or an export of it, for as long as you need the history.
• Self-hosting: Rius is a managed service only, so there is no server for you to run.

Related