How do I alert on context window usage for a single agent?

Rius lets you alert on one agent’s context window usage with a custom alert that has an Agent filter and a rule on the Context usage metric, such as p95(Context usage) > 0.8. The Agent filter limits the alert to spans from that agent. Context usage is measured per model call, so the rule looks at how full the model’s window is on each call, not at a per-trace average. You compare it against a value between 0 and 1, and the alert shows it as a percentage.

How it works

A custom alert is one or more rules, combined with AND, evaluated over one shared rolling window. Filters select which spans feed the rules before any aggregation, so the filter decides which agent you measure and the rule decides what you measure about it.

• The Agent filter. It matches the agent identity Rius derives, as each span carries it. It matches every span that carries the agent’s value, not only the root span, so all of that agent’s model calls feed the rule.
• Context usage. For one model call, it is the input tokens, prompt cache included, divided by the model’s context window. A value of 0.8 means the call filled 80% of the window.
• Per-call aggregation. Most numeric metrics, such as Cost, aggregate per trace: avg(Cost) is the average cost per trace. Context usage is an exception, along with Time to first token and LLM calls. Its aggregations run over calls. p95(Context usage) > 0.8 fires when the fullest 5% of calls in the window use more than 80% of their model’s context.
• Which calls count. Only inference calls, the spans the trace view badges as LLM, count. Agent, tool, retrieval and embedding spans never count, even when they carry a model.
• Models with no known window. A call whose model has no known context window has no context usage. It is left out of the aggregation and never counted as 0.

The aggregations available for Context usage are avg, min, max, p50, p95 and p99. Comparison operators are less than, less than or equal, >, >= and ==.

Set it up

1. Open the custom alert builder and add a filter with the field Agent, the operator =, and your agent’s name. Values are suggested from your workspace’s live data. Use in if you want one alert to cover several agents.
2. Add a rule on the Context usage metric. Pick an aggregation, an operator and a threshold between 0 and 1. Use p95 or p99 to catch the heaviest calls without being moved by a few small ones, max to fire on any single call over the line, and avg to watch the typical call.
3. Set the window, between 5 minutes and 24 hours. A short window reacts quickly. A longer one smooths out a few large calls.
4. Optionally add a second rule, since rules combine with AND. For example, add count(LLM calls) above a minimum so the alert ignores quiet windows where only a few calls ran.
5. Attach a channel (webhook, email or Slack) and set the Renotify policy, off or every N minutes.

The alert from steps 1 to 3 reads like this in the rule grammar. Replace checkout-agent with your own agent name:

FILTERS   Agent = checkout-agent
RULES     p95(Context usage) > 0.8
WINDOW    15 minutes

The builder shows a plain-language preview of exactly when the alert fires, and that sentence becomes the alert’s description on its details page. Check it against what you intended. See Custom alerts for the full rule grammar and limits.

What you get

• An alert scoped to one agent, so a heavy prompt in another agent does not trip it.
• A signal on the fullest calls, not a diluted average, when you use a high percentile or max.
• Firings that record the observed value of every rule against its threshold, so you can see which condition tripped.
• A coverage ratio on each firing. It tells you how many calls had a known context window, so you can tell a real reading from a partly covered one.
• Routing to webhook, email or Slack, with optional renotification while the alert keeps firing.

One caveat on coverage: it is attached only to firings. If low coverage holds a rule under its threshold, the alert stays quiet. If your agent uses a model with no known context window, its calls are not measured at all.

The Agent filter is the right scope here. Step, Model, Span kind and Operation filters change which spans the rules measure. Context usage lives on model calls, so a filter that selects only tool, chain or agent spans leaves the rule nothing to measure. If you narrow by Model or set Span kind to LLM, you measure only those calls, which is fine for context usage but narrower than the whole agent.

When something else fits

• If you want to watch context usage across your whole workspace, drop the Agent filter or filter by Service instead.
• If you want full context windows caught with no rule to write, the pre-defined Context rot alert flags any call that uses at least 70% of its model’s window. Use a custom alert when you need your own threshold on one agent.
• If you need either-or logic, such as context above 80% or cost above a limit, create a second alert, because rules combine with AND only.

Related