Skip to main content
A ready-to-run example is available here!
Experimental Feature: Parallel tool execution is still experimental. By default, tool_concurrency_limit is set to 1 (sequential execution). Increasing this value may improve runtime performance, but use at your own risk. Concurrent execution can lead to race conditions or unexpected behavior for tools that share state.

Overview

When an LLM requests multiple tool calls in a single response, the SDK can execute them concurrently rather than sequentially. This is controlled by the tool_concurrency_limit parameter on the Agent class. Benefits:
  • Faster execution when tools are independent (e.g., reading multiple files)
  • Better utilization of I/O-bound operations
  • Enables parallel sub-agent delegation
When to use:
  • Running multiple read-only operations simultaneously
  • Delegating to multiple sub-agents at once
  • Executing independent API calls or file operations

Configuration

Setting the Concurrency Limit

Configure tool_concurrency_limit when creating an Agent:

Concurrency Limit Values

ValueBehavior
1 (default)Sequential execution—tools run one at a time
2-8Moderate parallelism—good for most use cases
>8High parallelism—only for I/O-heavy workloads with independent tools. Risk of resource exhaustion.
The optimal value depends on your workload. Start with a lower value (e.g., 4) and increase if needed.

Use Cases

Parallel File Operations

When reading multiple independent files:

Parallel Sub-Agent Delegation

Combine with TaskToolSet for parallel task processing:

Sub-Agents with Their Own Parallelism

Each sub-agent can have its own concurrency limit:

Considerations

Thread Safety

Not all tools are safe to run concurrently. Be careful with:
  • Tools that modify shared state
  • Tools that write to the same files
  • Tools with external side effects that depend on execution order
  • Deadlocks when tools wait on resources held by other concurrent tools
  • Resource exhaustion (file handles, memory, network connections)

When NOT to Use

  • Tools that must execute in a specific order
  • Operations that modify the same files
  • Workflows where one tool’s output feeds into another

Ready-to-run Example

This example demonstrates parallel tool execution with an orchestrator agent that delegates to multiple sub-agents, each running their own tools concurrently.
examples/01_standalone_sdk/45_parallel_tool_execution.py
You can run the example code as-is.
The model name should follow the LiteLLM convention: provider/model_name (e.g., anthropic/claude-sonnet-4-5-20250929, openai/gpt-4o). The LLM_API_KEY should be the API key for your chosen provider.
ChatGPT Plus/Pro subscribers: You can use LLM.subscription_login() to authenticate with your ChatGPT account and access Codex models without consuming API credits. See the LLM Subscriptions guide for details.

Understanding the Example

The example demonstrates a two-level parallel execution pattern:
  1. Orchestrator Level: The main agent has tool_concurrency_limit=8, allowing it to delegate to all three sub-agents simultaneously
  2. Sub-Agent Level: Each sub-agent has tool_concurrency_limit=4, allowing them to run their own tools (terminal commands, file reads) in parallel
  3. Verification: The example includes a parallelism report that analyzes persisted events to confirm tools actually ran concurrently

Next Steps