How do I move my cost tracking from Helicone to Rius?

Add the Rius SDK with rius.init() and Rius computes cost on the server from each call’s model and token counts, so there is no cost header or value to migrate. Calls are traced inside your process, with or without the Helicone gateway in front of the provider. Move your user ids onto rius.user() to see cost per user. The full walkthrough is in Migrate from Helicone, and the wider picture is in Migrate to Rius.

How it works

Helicone is mainly a proxy. Your client sends requests through a Helicone base URL, and Helicone logs them on the way through. Rius works differently: the Rius SDK instruments your LLM client inside your process and exports one span per step, so nothing sits between your code and the provider.

Here is how cost maps across:

• Cost per call: Helicone’s cost maps to Rius’s cost. Rius computes it server-side from the model and the token counts on each model-call span. You never send a cost value.
• Pricing basis: Rius prices calls with LiteLLM’s public model-price catalog, in US dollars, with cache reads and writes at their own rates. Costs are list-price estimates, not billed amounts.
• Unknown models: a model the catalog does not know gets an empty cost, not zero.
• Per user: Helicone-User-Id maps to rius.user(id), which stamps user.id on every span in scope. The Users page lists each user with their traces, failures, error rate and cost.
• Per session: Helicone-Session-Id maps to rius.session(id), which stamps session.id so traces group by session.
• Per custom property: Helicone-Property-* headers become span or resource attributes. You can filter traces on them, but Rius has no cost breakdown per custom property.
• Omitting content: Helicone-Omit-Request and Helicone-Omit-Response map to capture_content=False. It strips prompts and completions at export, and metadata, including tokens and cost, still flows.

Set it up

1. Install the SDK with the integrations for the providers you call, then call rius.init() at startup. This is all cost tracking needs. Each provider call becomes a generation with model and token counts, and Rius prices it.

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

   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

2. Decide about the gateway. If you rely on caching, rate limits or fallbacks, leave the Helicone base URL and headers in place. The Rius integrations patch the client library in your process, so calls are traced whatever base URL the client uses. If you only used Helicone for logging, still keep the base URL and headers until cutover, so you can compare both tools on the same traffic. If you use the Helicone AI Gateway with Helicone-managed provider keys or credits, switch to your own provider keys first, because Rius never holds provider keys.

3. Use plain model names such as gpt-4o-mini, not the gateway’s gpt-4o-mini/openai form. The gateway form gives you tokens but no cost.

4. Add a user scope where you set the user header. Every span of the request then carries user.id:

   with rius.user(request.user_id):
       handle(request)  # every span of the request carries user.id

5. Add rius.session(session_id) where you set Helicone-Session-Id, and copy Helicone-Property-* values onto span attributes or resource attributes. If you used Helicone’s async logger, remove it rather than running both in one process, because both register the process-wide OpenTelemetry tracer provider and only the first registration is kept.

6. 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 both backends on the same traffic for a few days, as the Helicone migration guide describes. At cutover, remove the Helicone base URL and Helicone-* headers, and revoke the Helicone key once nothing sends to it.

What you get

• Cost per call on every model-call span, computed by Rius from the model and tokens, with cache reads and writes priced at their own rates.
• Cost per user on the Users page, next to each user’s traces, failures and error rate.
• Cost by model, error rate and time to first token over ranges from 15 minutes to 30 days, in the usage and cost view.
• Alerts on cost, with webhook, email and Slack channels.

Expect these differences from Helicone:

• Cache hits: if you keep the gateway during a side-by-side run, a response Helicone serves from its cache is recorded in Rius like any other call, with the token counts the response carries, priced at the provider’s rates. Rius cost then reads higher than Helicone’s by your cache-hit share.
• No custom prices: Rius has no custom model prices and no negotiated, batch, flex, priority or long-context discounts. Costs are list-price estimates.
• No per-property cost: attributes are filterable, but there is no cost breakdown per custom property.
• No history import: existing traces stay in Helicone. Rius starts from the first span you send it.
• No gateway: Rius has no caching, rate limits, retries or fallbacks, and Rius is a managed service only.

When something else fits

• If caching, rate limits or fallbacks are load-bearing in production, keep the Helicone gateway and add Rius next to it first. Replace the gateway later as a separate project.
• If you need negotiated-rate or custom-price cost accounting, or cost per custom property, Rius’s list-price estimates do not cover that, so keep that reporting where it is today.

Related