How do I move my production and staging environments from Helicone to Rius?

Rius keeps each environment in its own workspace with its own API key, so you move production and staging by giving each deployment its own key and calling rius.init(). Each trace belongs to the one workspace its API key points to. Per-deployment values such as app version or region go on resource attributes, and your Helicone proxy can stay in place while you compare both tools. Caching, rate limits, retries and fallbacks have no Rius counterpart.

How it works

Helicone logs calls through a proxy and takes extra values as Helicone-* request headers. Rius works inside your process: the Rius SDK instruments your LLM client and exports spans, so nothing sits between your code and the provider. The full concept mapping is in Migrate from Helicone, and Migrate to Rius covers the general approach.

For environments, the mapping is:

• Environment (production, staging): one Rius workspace per environment, each with its own API key. A trace belongs to the workspace its API key sets, so the key your deployment uses decides where its traces go. Keep each environment in its own workspace rather than tagging it on spans.
• If you tagged requests with a Helicone-Property-* header: per-request values become span attributes on the span that wraps the work. Per-deployment values, such as app version or region, become resource attributes, which every span from the process carries.
• Sessions and users: Helicone-Session-Id becomes rius.session(id) and Helicone-User-Id becomes rius.user(id) (withSession and withUser in TypeScript).
• Hiding content: Helicone-Omit-Request and Helicone-Omit-Response map to capture_content=False, or RIUS_CAPTURE_CONTENT set to false. Prompts and completions are stripped at export and metadata still flows. You can use this on production only if you want it there.
• Cost: Rius computes it on its side from the model and token counts, as a list-price estimate in US dollars.

Set it up

1. Create one workspace per environment. Make a production workspace and a staging workspace, and create an API key in each. Keys start with ri_.

2. Give each deployment its own key. Store the key in the deployment’s environment configuration, as you did with your Helicone key. Staging gets the staging key and production gets the production key.

   export RIUS_API_KEY="ri_..."

3. Add rius.init(). Install the SDK with the integrations for the providers you call, for example pip install "glassflow-rius[openai,anthropic]". Then initialise it once at startup. The call reads RIUS_API_KEY, so the same code runs in both environments with no branching.

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

   In TypeScript, call init({ serviceName: 'my-agent' }) and await rius.ready before the first call.

4. Move per-deployment tags to resource attributes. Set values such as service.version through the standard OpenTelemetry OTEL_RESOURCE_ATTRIBUTES variable. Names like app.region are your own.

5. Start with staging. Check one call end to end: the trace appears under your service_name, the model call shows model and token counts, and cost appears. Then repeat in production.

6. Run both tools while you compare. If you still rely on the Helicone proxy or gateway, leave its base URL and headers in place and add rius.init() anyway. Rius traces the client in your process whatever base URL it uses. 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. If you use the Helicone async logger, run it and the Rius SDK in separate services or deploys, not in one process.

7. Cut over. Remove the Helicone base URL, Helicone-* headers and async logger, and revoke the Helicone key once nothing sends to it.

What you get

• Production and staging traces land in separate workspaces, chosen by the API key each deployment uses, with no environment tag to remember.
• Every model call, tool call and agent step as a trace, with model, tokens and a computed cost per call.
• Sessions and users from rius.session and rius.user, plus filterable span and resource attributes in the trace list.
• Alerts with webhook, email and Slack channels.
• No latency added to your calls. The SDK exports spans in the background, and if Rius is unreachable your calls still go through.

Some things have no counterpart in Rius:

• Gateway features: caching, rate limits, retries, fallbacks and a unified provider API.
• Prompt management, scores, feedback, datasets and evals.
• Moderation and prompt-injection detection.
• Breakdowns of cost or metrics per custom property.
• Historical data. Existing staging and production traces stay in Helicone, and Rius starts from the first span you send.

When something else fits

If caching, rate limits or fallbacks are load-bearing in production, keep the Helicone gateway in front of the provider and add Rius next to it first. Replace the gateway later as a separate project. If you depend on prompt management, scores or datasets, keep those workflows in your current tool.

Related