My AI agent is slow to respond. How do I find the cause?

Rius shows a slow agent in three places, and each one narrows the search. Start on Home for latency and time to first token, open the Agents page to see which agent or version slowed down, then open a slow trace and read its timeline to find the span that took the time. This follows the same path described in Monitor AI agents in production. The slow step is usually a single model call, a tool call, a retry loop, or a prompt that grows with every turn.

How it works

Each step in Rius answers a different question.

• Is it slow overall? On Home, the latency percentiles (p50, p95, p99) and the time to first token (p50 and p95) are shown for the selected window, compared with the previous one. Time to first token is how long a streamed model call waits before its first chunk arrives. The models table also gives a time to first token p95 per model, so you can see whether one model is the slow one. See Usage and cost.
• Which agent, and since when? On the Agents page, scan the list, then open the agent. The Drift charts plot TTFT p50, cost per trace and failed rate over time, so you can see the day it got slower. Versions compares two versions side by side on latency, time to first token (p50), tokens per trace and cost, which shows whether the last release caused it.
• Is the context the problem? In Context on the agent page, Peak usage shows how much of the model’s context window the largest call used. A prompt that keeps growing makes every call slower.
• Which step is slow? Open a trace from Recent traces, or from Traces. The waterfall lays the spans out as a tree on a timeline, badged by kind (chain, llm, tool), so a long bar stands out. The Map tab has a latency lens that shows where the time went at a glance. Clicking a node takes you to that node’s spans in the tree.

Latency figures count finished traces only, so a long run still in progress does not distort them.

Set it up

1. Open Home, pick the window in which the slowness started, and check the latency and time to first token panels. Then open Agents, click the agent that is slower, and look at Drift and Context.
2. Tag your runs with versions so that Versions can compare a slow release against a fast one. Set them in the environment:

RIUS_MAIN_AGENT_VERSION=prompt-v12      # the agent definition: prompt, tools, policy
RIUS_SERVICE_VERSION=2026.09.29-a41f3c  # the build or deploy

3. Open a slow trace from Recent traces. In the waterfall, find the longest bars, and select an LLM span to see its model, tokens and cost. Then switch to Map and use the latency lens to confirm where the time sits.
4. Look for the usual patterns on the trace page:
   • Retry chains. Back-to-back calls of the same tool or step collapse into one row, such as fetch_article · 3 attempts · recovered, so a retry loop that adds seconds is easy to spot.
   • Context growth. For a trace with several model calls, a strip above the tree plots input tokens per call in order. Rising bars mean an unbounded history or a runaway prompt.
   • Since previous llm call. On an LLM span’s Input / Output tab, this shows what each step added to the prompt.
   • Compare runs. Compare the slow trace with another run of the same agent to see which steps changed and where latency moved.
5. To find one kind of step across many runs, use the Spans tab. Filter by kind, such as Tool or LLM, and click the Duration header to sort. Details are in Exploring traces.
6. If a run seems stuck rather than slow, turn on partial spans with RIUS_PARTIAL_SPANS. A run then shows as running… while it is in flight, and you can filter on that status. A trace still showing running… long after the work should have finished points to a crash, a hang, or a killed process.

What you get

• A short path from the symptom to the cause: Home for the size of the problem, Agents for which agent or version, and the trace waterfall for the span.
• Time to first token for streamed calls, per agent and per model, so a slow model stands out from a slow tool.
• A way to see whether a release made things slower, with latency and time to first token compared by version.
• Evidence of context growth, with peak usage per agent and input tokens per call within a trace.
• Retry loops shown as one row with an attempt count instead of a wall of identical spans.
• Cost next to latency on every LLM span, as a list-price estimate in US dollars, so you can weigh a faster model against its price.

When something else fits

• Time to first token only exists for streamed calls. An agent that never streams shows a dash there, so rely on trace and span durations instead.
• Heartbeats show whether a process is alive, not whether it is making progress. A hung process that still sends heartbeats shows as running, so use partial spans and the running… filter to find stuck runs.

Related