Understanding Timeout Layers
When a request flows through an Autonomy application, it passes through several timeout boundaries: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:Quick Reference
| Use Case | HTTP Timeout | max_execution_time | Throttle | Notes |
|---|---|---|---|---|
| Simple Chat | 60s | 60s | No | Quick Q&A, 1-3 iterations |
| Tool-Augmented Chat | 120s | 120s | No | Tool calls, 3-5 iterations |
| Research Agent | 660s+ | 600s | Yes | Deep work, many iterations |
| Batch Processing | 180s | 120s | Yes | Per-item timeout |
| Voice Interface | 30s | 30s | No | Low latency critical |
| Subagent Workflows | 660s | 600s | Yes | Parent + child time |
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
images/main/main.py
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
| Parameter | Default | Description |
|---|---|---|
max_execution_time | 600s (10 min) | Total time allowed for agent execution |
max_iterations | 1000 | Maximum number of think-act loops |
Estimating Execution Time
Use this formula to estimate the time budget:| Task Type | Expected Iterations | Avg Time/Iteration | Recommended max_execution_time |
|---|---|---|---|
| Simple Q&A | 1-2 | 5s | 30s |
| Tool usage | 3-5 | 20s | 120s |
| Research | 10-20 | 30s | 600s |
| Complex analysis | 20-50 | 30s | 1800s |
Layer 3: Agent Lifecycle Timeouts
Separate from execution, agent lifecycle operations have their own timeouts:images/main/main.py
Lifecycle Timeout Guidelines
| Operation | Recommended Timeout | Rationale |
|---|---|---|
Agent.start() | 30s | Registration should be quick |
agent.send() | max_execution_time + 60s | Full execution plus buffer |
Agent.stop() | 10s | Cleanup should be fast |
Layer 4: Model Configuration
Each model call has its own timeout settings:images/main/main.py
Model Timeout Guidelines
| Parameter | Default | When to Adjust |
|---|---|---|
request_timeout | 120s | Increase for reasoning models (o1, o3) that think longer |
connect_timeout | 10s | Increase if network latency is high |
stream_timeout | 300s | Increase for very long streaming responses |
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
Whenthrottle=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:- Queue waits: 3 × 60s = 180s
- Model calls: 3 × 120s = 360s
- Total: 540s
Throttle Configuration by Use Case
| Use Case | throttle_max_seconds_to_wait_in_queue | Rationale |
|---|---|---|
| Interactive | 30s | Fast feedback on overload |
| Research | 60s | Balance iterations and timeout |
| Batch | 120s+ | Allow queue absorption |
Layer 6: Subagent Timeouts
Subagents have their own execution time that counts against the parent’s budget:images/main/main.py
Subagent Timeout Guidelines
-
Subagent time counts against parent time:
-
For parallel subagents, the slowest determines wait time:
-
Rule of thumb:
Configuration Examples
Interactive Chat Application
Fast responses for conversational AI:images/main/main.py
Research Agent
Deep work with many iterations:images/main/main.py
Batch Processing
High throughput with rate limiting:images/main/main.py
Voice Interface
Ultra-low latency for real-time:images/main/main.py
Timeout Hierarchy
For consistent behavior, configure timeouts from outermost to innermost:Streaming for Long Tasks
For tasks that may exceed HTTP timeout limits, use streaming to keep the connection alive:images/main/main.py
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 subagentmax_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.

