How do I move my alerts from Helicone to Rius?

Rius has rule-based alerts that send to webhook, email and Slack, so you rebuild each Helicone alert as a Rius rule once your calls are traced by the Rius SDK. Nothing is imported: you add the SDK, create the rules, and compare both tools on the same traffic before you switch off the Helicone alerts. Rius alerts watch traced agent runs, so anything that depends on gateway behavior has no counterpart.

How it works

Helicone logs calls as they pass through its proxy. Rius works differently: the SDK instruments your LLM client inside your process and exports spans, and Rius alerts evaluate those spans. That means an alert only sees what the SDK traces, so tracing comes first and alert rules second.

How the concept maps:

• Alerts to alerts. Rius has custom rules on cost, input, output and reasoning tokens, duration, time to first token, context usage, error rate, LLM error rate, errors, traces and LLM calls.
• Filters. A rule can be narrowed by service, agent, step, model, span kind, operation, session or instance.
• Channels. Webhook, email and Slack.
• Pre-defined alerts. Rius also has four of its own: Consistent Error Pattern, Swallowed Error, Tool Loop and Context rot. You can turn them off but not delete them.
• Cost. Rius computes it from the model and token counts, as a list-price estimate in US dollars. You never send a cost value.

A rule measures only the spans it matches. Tokens and cost live on model-call spans (LLM, embedding, reranker), so a rule that filters only tool, chain or agent spans measures no tokens and no cost. To alert on model spend, filter by Model, or set Span kind to LLM. To measure whole runs, filter by Service or Agent.

Set it up

1. Trace your calls with Rius first. Add the SDK and call rius.init(). Keep the Helicone base URL and headers in place if you rely on the gateway, because Rius traces the call whatever base URL the client uses. The Helicone migration guide covers the proxy, AI Gateway and async logger paths in full.

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

2. Check one call end to end. Confirm the trace appears under the agent named by your service_name, and that the model call shows model, token counts and cost. 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 and a cost rule has nothing to measure.

3. List your Helicone alerts and recreate each as a custom rule. For each one, pick the matching Rius metric, set the threshold, add the filter (for spend, filter Model or Span kind LLM), and attach a webhook, email or Slack channel.

4. Set cost thresholds from Rius numbers. While Helicone’s cache sits in front of the provider, Rius records a cached response like any other call, priced from its tokens. Rius cost runs higher than Helicone’s by your cache-hit share, so a threshold copied across unchanged can fire early.

5. Review the four pre-defined alerts. Tool Loop counts only spans of the Tool kind. If you trace a tool function yourself with a bare observe, it makes a CHAIN span that Tool Loop never counts, so use kind=SpanKind.TOOL for those.

6. Run both tools side by side, then retire the Helicone alerts. This is the step in the cutover checklist in the migration guide for anything that reads from Helicone. Revoke the Helicone API key once nothing sends to it.

The overall routing options for any tool are in Migrate to Rius.

What you get

• Alert rules on traced agent runs, with cost computed server-side, delivered to webhook, email or Slack.
• Four pre-defined alerts for repeated errors, swallowed errors, tool loops and context rot, without writing rules.
• An optional root-cause analysis of a firing alert, run against a monthly analysis budget, at most once per service every 5 minutes.
• A side-by-side period on the same traffic, so you can confirm the Rius rules fire where you expect before you remove the Helicone ones.
• If your coding agent uses the Rius MCP server, tools such as list_alert_rules and create_alert_rule let it read and manage rules.

What has no counterpart:

• Gateway features. Rius is not a gateway, so caching, rate limits, retries and fallbacks stay with whatever serves them today.
• Scores, feedback, datasets and evals. Rius has none of these objects, so a rule cannot be built on them.
• Per-property breakdowns. Custom properties become span attributes you can filter in the trace list, but Rius has no cost or metric breakdown per custom property, and the alert filters are the ones listed above.
• Alert history. Existing history stays in Helicone. Rius starts from the first span you send.

When something else fits

If an alert depends on gateway behavior, keep it where the gateway runs, and do not remove the gateway as part of this migration. Add Rius next to it first. If you need scores, feedback or eval results to drive alerts, keep that workflow in your current tool, since Rius does not offer them.

Related