Skip to Content

How do I move my cost tracking from Arize Phoenix to Rius?

Rius computes cost on the server from the model name and token counts on each LLM span, so moving cost tracking from Arize Phoenix means pointing the spans you already send at Rius. Phoenix and Rius both read OpenInference spans, so your instrumentors stay and you change the exporter endpoint, the API key and a service name. You send tokens, never a cost value. The Migrate from Arize Phoenix guide has the full walkthrough.

How it works

Phoenix prices calls from its own model pricing table. Rius prices them itself, so there is no cost field to map across.

  • Inputs: the OpenInference span for a model call carries llm.model_name and llm.token_count.*. Rius reads that span as a generation and gives it model, token and cost analytics.
  • Pricing: Rius prices each call from the model and token counts using LiteLLM’s public model-price catalog, in US dollars. Cache reads and writes are priced at their own rates.
  • Estimates: costs are list-price estimates, not billed amounts. If your Phoenix numbers came from custom prices, expect differences.
  • Unknown models: a model Rius does not know gets an empty cost, not $0. A blank cost on a span means the model is unpriced, so check the model name.
  • Grouping: Rius groups traces by agent name, which defaults to the service.name resource attribute. Phoenix’s project name (openinference.project.name) is stored but does not drive grouping.
  • Sessions and users: session.id and user.id are the same attributes in both tools, so your using_session and using_user calls keep working. The Users page shows each user’s traces, failures, cost and time to first token, and traces are grouped into sessions by session.id.

For a wider view of how the tools map, see Migrate to Rius.

Set it up

  1. Create a workspace and an API key in Rius. Each trace belongs to the workspace its key belongs to, so use a separate workspace and key for production and staging if you used separate Phoenix projects for them.
  2. Re-point register(). Pass the full traces URL, the protocol and your Rius key in code, and give the agent a service.name. Without a service.name, traces arrive as unknown_service. Setting only PHOENIX_COLLECTOR_ENDPOINT to the Rius URL sends spans to the wrong port.
import os
 
from opentelemetry.sdk.resources import Resource
from phoenix.otel import register
 
tracer_provider = register(
    endpoint="https://ingest.eu.console.rius-glassflow.com/v1/traces",
    protocol="http/protobuf",
    api_key=os.environ["RIUS_API_KEY"],
    batch=True,
    resource=Resource.create({"service.name": "my-agent"}),
    auto_instrument=True,
)
  1. Raise the span attribute limit if you do not use the Rius SDK. OpenInference writes one attribute per message and tool field, and OpenTelemetry keeps 128 per span by default. On a long agent loop, later turns can lose the model or token usage, and that leaves those calls without cost. Set OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT=4096.
  2. Or switch to the Rius SDK if you want fewer moving parts. rius.init() replaces register(), wires the same OpenInference instrumentors and sets the 4096 limit for you.
import rius
 
rius.init(service_name="my-agent")
 
with rius.session(conversation_id):
    run_agent(message)
  1. Set session and user on the root span too. Use rius.session and rius.user, or set session.id and user.id yourself, so per-user cost lands under the right user. OpenInference’s using_session and using_user only stamp spans OpenInference creates, so a root span from a plain OpenTelemetry tracer misses them.
  2. Run both backends in parallel. Add Rius as a second span processor with replace_default_processor=False, then compare token totals and cost on the same traffic for a few days. Your Phoenix numbers and Rius’s can differ if you used custom prices there. The trial lasts 30 days or 500,000 spans, whichever comes first, and needs no card.
  3. Cut over. Remove the Phoenix exporter once the numbers match what you need.

What you get

  • Cost per model call, computed by Rius from model and token counts, with nothing to send or maintain.
  • A usage and cost view with traces, tokens, cost by model and error rate over 15 minutes to 30 days or a custom range.
  • Per-user cost, traces and failures on the Users page, from the user.id you already set.
  • Traces grouped into sessions by session.id.
  • Cost next to alerts: custom alert rules can watch cost, so a spend spike can notify you.
  • No Phoenix server or database to run, because Rius is a managed service.

When something else fits

  • Rius has no custom or overridden model prices, and it does not apply negotiated, batch or other discounts. If your cost reporting depends on those, keep that reporting in Phoenix or another place.
  • Existing Phoenix traces stay in Phoenix. Rius starts from the first span you send, so keep your Phoenix instance for historical cost.
  • Evals, datasets, experiments, annotations and prompt management have no counterpart in Rius. Keep those workflows in Phoenix while Rius handles tracing and cost.

Still stuck? Get help

Last updated on
Quickstart