Retry storms and hidden LLM spend
5 Jul 2026 · 6 min read
Agent retries can quietly turn small failures into runaway model and tool costs.
A retry storm starts when the system treats every failure as transient. Agent platforms need typed failures and attempt budgets.
AstraRunner treats this as an execution-platform concern: the run needs durable state, traceable decisions, cost visibility, and enough structure for teams to review what happened after the agent finishes.
Patterns that work
- Retry rate limits differently from validation failures.
- Stop after repeated equivalent model outputs.
- Escalate blocked tool calls instead of looping.
- Track spend per retry chain.
Implementation checklist
- Classify failure reasons.
- Set max attempts per step.
- Add jitter and backoff for external tools.
- Expose retry history in run detail.
Watch outs
- LLM self-repair loops can repeat the same mistake.
- Tool retries can hit vendor rate limits harder.
- Retries without new information rarely improve quality.
Related reading
How this fits the Astra stack
AstraRunner owns the operational path for agent work: orchestration, scheduling, approval gates, traces, costs, and role-agent handoffs. AstraMemory owns durable context and retrieval. AstraGenie turns those capabilities into product workflows for teams that want automation without rebuilding the platform layer.