Quick Start
Execution Presets
How It Works
| Phase | What happens |
|---|---|
| 1. Budget check | Execution tracks iterations against max_iter |
| 2. Rate limit | Enforces max_rpm requests-per-minute |
| 3. Time limit | Stops if max_execution_time seconds elapsed |
| 4. Retry | Retries failed steps up to max_retry_limit times |
| 5. Step-limit wrap-up | On the final permitted step (max_steps, or max_iter when unset), the agent injects a wrap-up instruction so the model produces a coherent final answer summarising progress instead of being hard-cut. Detect truncation with agent.last_stop_reason == "max_steps". See Step Budget. |
Configuration Options
Full list of options, types, and defaults —
ExecutionConfigPrefer
max_steps for the tool-use budget — it’s the unified knob honoured by both execution loops, and you can detect truncation with agent.last_stop_reason. See Step Budget.| Option | Type | Default | Description |
|---|---|---|---|
max_steps | int | None | None | Unified outer-loop step budget honoured by both tool-execution loops (OpenAI-native and LiteLLM). None falls back to max_iter. Must be >= 1 when set. See Step Budget. |
max_iter | int | 20 | Legacy per-loop iteration cap, used when max_steps is unset. On the final step the agent receives a graceful wrap-up instruction and returns a coherent summary — not the old canned "Task completed." placeholder. |
max_tool_calls_per_turn | int | 10 | Cap on tool calls within a single LLM response (parallel-tool guardrail). Independent of max_steps. |
max_rpm | int | None | None | Max requests per minute |
max_execution_time | int | None | None | Max seconds per run |
max_retry_limit | int | 2 | Max retries on failure |
code_execution | bool | False | Enable code execution (code_mode="safe" by default) |
max_budget | float | None | None | Hard USD spend limit per run |
Common Patterns
Pattern 1 — Budget-capped agent
Pattern 2 — Code execution agent
Pattern 3 — Parallel tool calls for speed
Pattern 4 — Code that calls your tools
Best Practices
Use presets as a starting point
Use presets as a starting point
execution="thorough" works well for most research and multi-step tasks. Only switch to custom ExecutionConfig when you need specific limits like budget caps or code execution.Set max_budget for cost control
Set max_budget for cost control
For any agent making many API calls, set
max_budget=0.50 to cap spend at 50 cents per run. Use on_budget_exceeded="warn" in development and "stop" in production.Enable parallel_tool_calls for speed
Enable parallel_tool_calls for speed
When your agent calls multiple independent tools per turn (e.g., search + fetch + calculate), enable
parallel_tool_calls=True to run them concurrently and cut latency.Code execution safety
Code execution safety
Always use
code_mode="safe" and code_sandbox_mode="sandbox" when enabling code execution. Only switch to "unsafe" or "direct" in fully isolated environments you control.Scope code_tools with an explicit allow-list
Scope code_tools with an explicit allow-list
When
code_tools=True, always set code_tools_allow to the exact tool names code may call. Leaving it None exposes no tools (the safe default), so name only what the task needs — never grant blanket access.Detecting truncated runs
Detecting truncated runs
Set
max_steps and check agent.last_stop_reason == "max_steps" to detect truncation — no string-matching needed. The returned text is a real LLM-authored wrap-up (“Here’s what I accomplished… here’s what remains…”), not a placeholder. See Step Budget.Related
Step Budget — cap tool-use steps and detect truncation
Output — control verbosity and response format
Step Budget — cap tool-use steps and detect truncation
Caching — avoid redundant LLM API calls

