OPENAI_TIMEOUT, to cap how long each request on the native OpenAI client path may take.
Quick Start
1
Set the env var (zero code change)
2
Build a client — it reads the env var
OPENAI_TIMEOUT mid-process rebuilds the cached SDK client on the next get_openai_client() call.3
Pair it with OPENAI_MAX_RETRIES
max_retries. See OpenAI Client Retries.How It Works
OpenAIClient reads OPENAI_TIMEOUT when it is built and passes it to both the sync OpenAI and async AsyncOpenAI SDK clients.
Configuration Options
Precedence:
OPENAI_TIMEOUT env var > SDK default (600s). There is no constructor argument for the timeout on OpenAIClient — the env var is the only lever.
Which Approach to Use
See LLM Timeouts for the agent-level and registry layers.Common Patterns
Fail fast while learning — a short bound surfaces a stuck provider quickly.Best Practices
Start with 60–120 seconds
Start with 60–120 seconds
Long enough for normal chat calls, short enough that a stuck request retries quickly.
Keep the 600s default for reasoning models
Keep the 600s default for reasoning models
Lowering the bound can cut off slow but healthy reasoning calls.
Don't double-stack timeouts
Don't double-stack timeouts
OPENAI_TIMEOUT covers only the native client path. For agent llm calls use Agent(llm={"timeout": N}) — set the one that matches your path.Retry-on-timeout is automatic
Retry-on-timeout is automatic
The SDK retries timed-out requests on its own. Combine with
OPENAI_MAX_RETRIES to control how many times.Related
OpenAI Client Retries
Retry transient errors on the same client.
LLM Timeouts
Agent-level and registry timeout layers.
Agent Retry
Retry the agent loop with backoff.
OpenAI
Configure the OpenAI provider.

