Skip to main content
Set one env var, 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

The value is part of the client cache key, so changing OPENAI_TIMEOUT mid-process rebuilds the cached SDK client on the next get_openai_client() call.
3

Pair it with OPENAI_MAX_RETRIES

The OpenAI SDK retries timed-out requests automatically, up to 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.
Leave it unset for reasoning models — long non-streaming reasoning calls can legitimately run for minutes; the 600s SDK default covers them.

Best Practices

Long enough for normal chat calls, short enough that a stuck request retries quickly.
Lowering the bound can cut off slow but healthy reasoning calls.
OPENAI_TIMEOUT covers only the native client path. For agent llm calls use Agent(llm={"timeout": N}) — set the one that matches your path.
The SDK retries timed-out requests on its own. Combine with OPENAI_MAX_RETRIES to control how many times.

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.