How do I alert on LLM cost per model?

Yes, Rius lets you alert on LLM cost for a single model by adding a Model filter to a custom alert on the Cost metric. The alert measures cost per trace (for example the p95), not total spend for that model. To cover several models with their own thresholds, create one alert per model. To see total spend per model, use the cost by model breakdown on Usage and cost.

How it works

A custom alert is one or more rules evaluated over a rolling window, and filters decide which spans feed those rules before anything is aggregated. One of the filters is Model, which matches gen_ai.request.model. Cost is a metric in custom alerts, so the two combine.

• What the rule measures. Cost is aggregated per trace, with avg, min, max, p50, p95 and p99. avg(Cost) is the average cost per trace in the window, not the workspace total.
• What the Model filter does. It narrows the spans feeding the rule to the model you name. Text filters offer =, ≠, in and not_in, and the values are suggested from your workspace’s live data.
• Several models in one alert. An in filter with a list of models feeds all of them into one rule, so you get one reading across the group, not one per model.
• Window. Between 5 minutes and 24 hours.

This catches a model whose runs got expensive, such as a prompt that grew or an agent stuck retrying on that model. It does not alert on a spend total or budget for a model. A total-spend threshold is not an alert metric today.

Cost is priced from the requested model and its token counts, using list prices from LiteLLM’s public catalog in US dollars. A model with no known price carries no cost, so a rule on it has nothing to measure. See Track LLM and agent cost for how each call is priced.

Set it up

1. Open the custom alert builder and add a filter: Model = the model you want to watch. Pick it from the suggested values so the spelling matches your data.
2. Add a rule on the Cost metric with an aggregation and a threshold. A high percentile such as p95 shows the expensive runs without being pulled around by a few cheap ones.
3. Set the window. A shorter window reacts faster, a longer one smooths out noise.
4. Attach a channel (webhook, email or Slack) so the firing reaches you.
5. Repeat for each model you want its own threshold on. Different models have different prices, so a threshold that suits one rarely suits another.

The rule for one model looks like this:

FILTERS   Model = gpt-4o
RULES     p95(Cost) > $2.00
WINDOW    1 hour

To narrow further, add a Service or Agent filter. Filters combine, so you can watch one model inside one service. The full builder, filters and metrics are in Custom alerts.

You can also ask an MCP client to set the rule up for you. It calls create_alert_rule, and you review the rule in the console afterwards.

What you get

• A per-model cost alert. It fires when the cost per trace for the model you chose crosses your threshold in the window.
• A record of what tripped. Each firing records the observed value of every rule against its threshold.
• A coverage reading. Firings on cost show the share of the window that was priced, so you can tell a real high reading from a partly priced one.

One caveat matters here. Coverage is attached only to firings. If most calls on the model are unpriced, the rule can stay under its threshold and never fire. Before you rely on the alert, check on Usage and cost that the model is priced in the cost by model breakdown.

When something else fits

• If you want total spend for a model, or a budget across the workspace, read the cost by model chart and models table on Usage and cost. Those are views, not alert triggers.
• If the model has no known price, a cost alert cannot see it. Alert on tokens or duration with the same Model filter instead.
• If you want one alert that reports each model separately, that does not exist. Create one alert per model.

Related