Timeouts are the deadlines your client imposes on a request, and they come in flavors worth distinguishing before you tune any of them. A connection timeout caps how long to wait for the TCP/TLS handshake to complete. A read timeout caps how long to wait for response data. An idle timeout (relevant to streaming) caps the silence between chunks of a response that is otherwise flowing. Conflating them is the root of most timeout misconfiguration: each protects against a different failure, and each deserves a different value for LLM traffic.
Why Claude calls need generous read timeouts
Current Claude models can produce up to 128,000 output tokens in a single synchronous response (64,000 on Haiku 4.5), and requests can carry up to a million tokens of input context. Generating a long response takes real time — far longer than the single-digit-second read timeouts common in enterprise HTTP client configs. Connection timeouts, by contrast, can stay short: establishing a connection to a healthy endpoint is fast, and failing fast there lets your retry logic act quickly. The asymmetry is the whole game — short to connect, patient to read.
Where the settings live
Each official SDK exposes timeout configuration on its client; the exact option names and defaults are documented per language in the SDK repositories, and they can change between releases, so treat the README of the version you've pinned as the source of truth. The clients you'd configure are, for the three languages this article's title names: Python's Anthropic client from the anthropic package (Python 3.9+), TypeScript's Anthropic client from @anthropic-ai/sdk (Node.js 20 LTS+, plus Deno, Bun, and edge runtimes), and Java's AnthropicOkHttpClient from com.anthropic:anthropic-java, whose builder pattern (AnthropicOkHttpClient.builder()...build()) is where client-wide configuration is applied. Java's client is built on OkHttp, so its networking behavior follows that HTTP stack. In all three, prefer setting timeouts once at client construction so every call site inherits the policy, and override per request only for genuinely unusual calls.
Streaming changes the calculation
The cleanest fix for long generations is usually not a longer read timeout but streaming. With server-sent events (SSE) — supported as a core capability on all four Claude platforms — the model delivers output incrementally, so your client is never waiting minutes for one giant response body. The timeout that matters shifts from "total response time" to "time between events": an idle timeout of modest length will catch a genuinely stalled stream quickly, while an actively streaming response can run as long as it needs. This is why streaming is the default recommendation for anything long-running; see the streaming basics article for the mechanics.
A tuning checklist
First, measure: log the real latency distribution of your Claude calls per model and per use case — a Haiku 4.5 classification and an Opus 4.8 agentic run live in different worlds. Second, set the connection timeout short and the read timeout from your observed tail latency plus comfortable headroom, not from a generic corporate default. Third, switch anything user-facing and long to streaming, and tune the idle timeout instead. Fourth, remember that timeouts and retries multiply: a request that times out and retries several times occupies a caller for the sum of those deadlines, so cap total elapsed time where a human is waiting. Finally, re-verify after model migrations — output lengths and thinking behavior differ across model generations, and yesterday's comfortable timeout can become today's flaky one.
Where to go next
Read configuring retries and handling 429s for the two policies that interact with timeouts most, or streaming for better UX and fewer timeouts for the user-experience side of the same story.