Timeout Errors Across All AI Providers (2026) — Complete Directory — AI Error Hub

Category hub · Cross-provider · Timeouts

Timeout Errors Across All AI Providers — 2026 Guide

Curated by Zain Khan

Editor, AI Error Hub

Updated October 14, 2026

Timeouts fire for many different reasons — HTTP request timeouts, streaming disconnects, reasoning models exceeding their budget, tool calls hanging, cross-region latency spikes, gateway policy caps, and framework-level deadlines that trip before the provider's timeout. Each has a different fix. This page is the cross-provider directory: every timeout pattern we've documented across every provider, IDE tool, and gateway, grouped so you can find your specific error in seconds.

For backoff and retry patterns triggered by timeouts, see the backoff chapter of the Rate Limits pillar guide. For related failure modes, see the Rate Limits, Authentication, and Context Window category hubs.

Anthropic Claude OpenAI Google Gemini AWS Bedrock Azure OpenAI IDE Tools Gateway Layer Framework Layer

2026 timeout defaults at a glance

Timeout behavior varies enormously across providers and SDKs. Here's the 2026 landscape at a glance.

Provider / Layer	Default timeout	Streaming	Config parameter	Notes
Anthropic Claude (SDK)	10 minutes	Keep-alive with reconnect	timeout in Anthropic() client	Extended thinking can push toward limit
Anthropic Claude Batches API	24 hours	N/A (batch)	N/A — fixed deadline	Expires silently at 24h
OpenAI (SDK)	10 minutes	Server-sent events (SSE)	timeout parameter on request	Reasoning models can hit at high effort
OpenAI Batch API	24 hours	N/A (batch)	N/A — fixed deadline	Fails whole batch if exceeded
Google Gemini (Vertex)	60 seconds default	SSE stream	request_options.timeout	Adjustable up to model max
Google Gemini File API	Upload-size-based	N/A	Client-side chunking	Large files can hit even with slow uploads
AWS Bedrock (boto3)	60 sec connect / 60 sec read	Model-specific	read_timeout in Config	Streaming ignores read_timeout
Azure OpenAI (SDK)	60 seconds (Front Door)	SSE stream	Front Door: not configurable	Move to direct endpoint for long requests
Azure OpenAI Direct	10 minutes	SSE stream	timeout parameter	Bypasses Front Door 60s limit
IDE tools (Cursor/Copilot)	~30-60 sec per turn	N/A	Not user-configurable	Tied to subscription tier
Gateways (LiteLLM/OpenRouter/Portkey)	Configurable per route	Configurable	config.yaml / dashboard	Should be shorter than provider timeout

Anthropic Claude

Claude's default SDK timeout is 10 minutes — generous for most requests but hittable on extended thinking workloads with high budget_tokens. Streaming uses keep-alive to prevent connection drops on long-generating responses. The 529 overloaded_error is often confused with timeouts but is a separate condition — provider capacity, not client patience.

→ Claude API Pillar Guide

OpenAI

OpenAI's reasoning models (o-series, GPT-5.6 with reasoning_effort=high) can run for many minutes on hard problems — the default 10-minute timeout is often hit before the reasoning completes. Streaming responses via SSE handle mid-response reconnection. Assistants API polling has its own timeout semantics.

→ OpenAI API Pillar Guide

Google Gemini

Gemini's default 60-second request timeout is shorter than Anthropic or OpenAI — configurable up to model maximum via request_options. Long-context requests (approaching 1M tokens) can exceed default timeout during prefill alone. File API uploads use chunked transfer and can timeout on slow uploads or oversized files.

→ Gemini API Pillar Guide

AWS Bedrock

Bedrock's boto3 default is 60-second connect + 60-second read — the read timeout can be surprisingly short for long-generation Claude requests. Streaming responses use InvokeModelWithResponseStream, which handles read_timeout differently than InvokeModel. Cross-region inference profiles add regional latency variance.

→ Amazon Bedrock Pillar Guide

Azure OpenAI

Azure OpenAI has a hidden gotcha: Azure Front Door enforces a 60-second timeout on requests routed through it, regardless of your SDK timeout config. Direct-to-deployment endpoints bypass Front Door and allow the full 10-minute timeout. For long reasoning or extended thinking workloads, direct endpoints are essential.

→ Azure OpenAI Pillar Guide

Timeouts at other layers of the stack

Timeouts don't only fire at the provider layer. IDE tools have their own per-turn deadlines, gateways enforce upstream timeouts, frameworks have chain-level and node-level timeout budgets. Each layer can trip before the provider timeout does.

IDE Tools

IDE tools have their own per-turn timeout budgets that aren't user-configurable. Cursor Agent mode tool calls have hard time limits. Claude Code tool execution can hang without clean error recovery. GitHub Copilot's extension has a shorter timeout budget than the underlying API.

→ IDE Tool Comparison Post

Gateway Layer

Gateways add configurable timeouts that should be shorter than the underlying provider's timeout — otherwise you get the worst of both worlds. LiteLLM has request_timeout and stream_timeout separately. OpenRouter enforces upstream timeouts even when the underlying provider would wait longer. Portkey timeout policies live in Gateway configs.

→ AI Gateway Comparison Post

Framework Layer

Framework timeouts stack on top of provider timeouts and often trip first if not configured carefully. LangChain has both chain-level and per-tool timeouts. LangGraph node execution has its own timeout at the state machine level. LlamaIndex workflow steps enforce timeouts per step, not per workflow.

→ LangChain Pillar Guide

Frequently asked questions

Why do reasoning models timeout more often?

Reasoning models generate hidden 'thinking' tokens before their visible response. On hard problems with high reasoning_effort or large budget_tokens, this thinking phase alone can take 5-10+ minutes. The default 10-minute SDK timeout was designed for non-reasoning models; reasoning workloads often need explicit timeout=1200 (20 min) or higher configuration.

What's the difference between HTTP timeout and streaming timeout?

HTTP timeout applies to the total request-response cycle for non-streaming requests. Streaming timeout is a per-chunk read timeout — how long the client waits between server-sent event chunks before considering the connection dead. Non-streaming requests can time out even with fast servers if the response is long. Streaming requests can time out even mid-response if the provider goes silent between tokens.

Why does Azure OpenAI time out at exactly 60 seconds?

Azure Front Door has a hard 60-second timeout on any request routed through it. This applies to Azure OpenAI's default endpoint URLs. For requests that need longer than 60 seconds (long-context, high reasoning_effort, extended thinking), use direct-to-deployment endpoints that bypass Front Door. The endpoint URL structure is different — check the Azure OpenAI direct endpoint documentation.

How should I set my request timeout in production?

For chat/completion workloads: 2-5x your p99 response latency. For reasoning workloads: 15-30 minutes if using high reasoning_effort. For streaming: separate per-chunk read timeout (~30 seconds) from total request timeout (larger). Instrument p99 latency and adjust; don't rely on defaults.

Why does the same request sometimes time out and sometimes not?

Multiple causes. (1) Provider-side load — the same request under peak load can be 3-5x slower than off-peak. (2) Model routing — some providers route to different backend clusters with different capacity. (3) Cache hits vs misses — a cached-prefix request completes 5x faster than a cold one. Instrument request timing broken down by cache status, time of day, and model to see which is the dominant factor.

Should I retry on timeout?

Almost always yes, with exponential backoff and full jitter. Timeouts are typically transient (network glitch, brief provider overload). Retries usually succeed. Caveats: (1) use idempotency keys where the provider supports them to avoid double-billing on server-successful-but-client-timed-out requests. (2) Don't retry indefinitely — cap retries at 3-5 for interactive workloads, more for batch. See our rate limits pillar for backoff patterns.

What causes 'InvokeModelWithResponseStream hangs indefinitely' on Bedrock?

boto3's read_timeout in the Config is NOT respected for streaming responses. The stream can hang forever if the server stops sending events without closing the connection. Fix: implement your own client-side timeout using threading or asyncio.wait_for around the streaming iterator. Alternatively, add socket-level SO_KEEPALIVE settings.

How do I handle timeouts in agent workloads with many tool calls?

Two levels of timeout: per-tool-call timeout (individual tool executions should have short deadlines, 30-60 seconds) and per-turn timeout (the full agent turn including all tool calls should have a longer deadline). Cap the number of tool calls per turn (recursion_limit in LangChain/LangGraph). Cache tool results so retries after timeout don't re-execute successful tools.

Why does my Batch API job fail after 24 hours?

Batch APIs on Claude, OpenAI, and Bedrock have a 24-hour completion deadline. Jobs not completed within 24 hours are marked expired and the whole batch fails (or partially completes). This isn't a timeout in the network sense — it's a workflow deadline. Don't submit batches expecting >24-hour completion; split into smaller chunks or use synchronous API for time-sensitive work.

What's a good default timeout value if I have to pick one?

For interactive chat: 60-120 seconds. For non-reasoning batch processing: 5 minutes. For reasoning workloads at medium effort: 5-10 minutes. For reasoning workloads at high effort: 15-30 minutes. For extended thinking with high budget_tokens: 20 minutes. Never use a client library's default without checking — some default to values that are too short for your workload class.