Skip to main content
Autonomy applications have multiple timeout layers that work together to ensure reliable execution. Understanding how these layers interact is essential for building robust agents, especially for long-running tasks like research or batch processing.

Understanding Timeout Layers

When a request flows through an Autonomy application, it passes through several timeout boundaries:
Each layer has its own timeout configuration. The outermost timeout (HTTP API) acts as the ultimate limit—if inner operations exceed it, the entire request fails.

The Multi-Iteration Challenge

Agents don’t make single requests—they iterate through a loop of thinking, acting, and gathering responses. A typical agent conversation involves multiple model calls:
Time compounds across iterations. A 10-iteration agent with 30-second iterations needs 300 seconds total—but the default HTTP timeout is only 180 seconds.

Quick Reference


Layer 1: HTTP API Timeout

The HTTP layer is the outermost timeout boundary. Configure it when making requests to the built-in agent endpoints:
curl
For custom FastAPI endpoints, handle timeouts explicitly:
images/main/main.py
The HTTP timeout must be greater than max_execution_time plus overhead for startup and teardown (typically 60 seconds buffer).

Layer 2: Agent Execution Limits

Control how long an agent can run and how many iterations it can perform:
images/main/main.py

Configuration Options

Estimating Execution Time

Use this formula to estimate the time budget:

Layer 3: Agent Lifecycle Timeouts

Separate from execution, agent lifecycle operations have their own timeouts:
images/main/main.py

Lifecycle Timeout Guidelines


Layer 4: Model Configuration

Each model call has its own timeout settings:
images/main/main.py

Model Timeout Guidelines

These are per-call timeouts. A 10-iteration agent makes 10+ model calls, so total time can be iterations × request_timeout.

Layer 5: Throttle Configuration

When throttle=True, requests queue when rate limits are approached. This prevents 429 errors but adds latency:
images/main/main.py

Throttle Timing Impact

With throttling enabled, each iteration can wait in the queue:
Worst case for 3 iterations:
  • Queue waits: 3 × 60s = 180s
  • Model calls: 3 × 120s = 360s
  • Total: 540s
When using throttling, ensure your HTTP timeout accounts for queue wait time multiplied by expected iterations.

Throttle Configuration by Use Case


Layer 6: Subagent Timeouts

Subagents have their own execution time that counts against the parent’s budget:
images/main/main.py

Subagent Timeout Guidelines

  1. Subagent time counts against parent time:
  2. For parallel subagents, the slowest determines wait time:
  3. Rule of thumb:

Configuration Examples

Interactive Chat Application

Fast responses for conversational AI:
images/main/main.py
HTTP timeout: 90 seconds

Research Agent

Deep work with many iterations:
images/main/main.py
HTTP timeout: 1860 seconds (31 minutes), or use streaming

Batch Processing

High throughput with rate limiting:
images/main/main.py

Voice Interface

Ultra-low latency for real-time:
images/main/main.py
HTTP timeout: 45 seconds

Timeout Hierarchy

For consistent behavior, configure timeouts from outermost to innermost:
Key rule: Each outer layer’s timeout must be greater than the sum of all possible inner timeouts.

Streaming for Long Tasks

For tasks that may exceed HTTP timeout limits, use streaming to keep the connection alive:
images/main/main.py
Streaming keeps the connection alive with periodic chunks, avoiding HTTP timeout issues for long-running research tasks.

Troubleshooting

”Request timed out” at HTTP layer

Symptom: Agent task fails with HTTP timeout, even though agent should have more time. Cause: HTTP timeout (default 180s) < max_execution_time (default 600s) Solution: Increase HTTP timeout or use streaming:
curl

Agent stops mid-task

Symptom: Agent stops before completing complex reasoning. Cause: max_execution_time too short for the number of iterations needed. Solution: Increase max_execution_time and max_iterations:

Subagent timeouts

Symptom: Subagent tasks fail with timeout errors. Cause: Default subagent timeout (60s) too short for multi-step work. Solution: Increase subagent max_execution_time:

Throttle queue timeouts under load

Symptom: Many requests fail with queue timeout when system is busy. Cause: throttle_max_seconds_to_wait_in_queue too short for the load. Solution: Increase queue timeout or reduce concurrency:

Best Practices

Start Conservative

Begin with shorter timeouts and increase based on observed behavior. Long timeouts can mask performance issues.

Use Streaming

For tasks over 3 minutes, use streaming to avoid HTTP timeout issues and provide progress to users.

Match Layers

Ensure outer timeouts are always greater than inner timeouts plus overhead.

Monitor Iterations

Track how many iterations your agents typically use to right-size timeouts.