This is one of the most common "it works in testing, fails in production" traps for teams running Claude on Amazon Bedrock. AWS's documentation for the Anthropic Claude Messages API on Bedrock states two numbers side by side: the inference timeout for Claude 3.7 Sonnet and Claude 4 models is 60 minutes, while AWS SDK clients default to a 1-minute read timeout. A "read timeout" is the maximum time the client will wait for the server to send data before it abandons the connection. On a non-streaming InvokeModel call, the server sends nothing until the entire response is ready — so any completion that takes longer than a minute to generate gets killed client-side, even though Bedrock is still working on it and would have delivered a perfectly good answer.
Why it looks like a service failure (but isn't)
The symptom is a read-timeout exception from your HTTP layer after almost exactly 60 seconds, typically on your longest prompts: big documents, extended thinking, large max_tokens. Short requests sail through, so the bug hides during development and appears only when real workloads arrive. Nothing useful shows up as a Bedrock error, because from Bedrock's perspective the client simply disconnected. AWS's own recommendation is to raise the SDK read timeout to at least the inference ceiling — for botocore (the engine under boto3, AWS's Python SDK), that means read_timeout of 3600 seconds or more.
import boto3
from botocore.config import Config
config = Config(read_timeout=3600) # AWS recommends >= 3600 for Claude 4
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1",
config=config)
# long InvokeModel calls now survive past the 1-minute defaultEvery AWS SDK has an equivalent knob; the Python names are shown here because the AWS docs use botocore as their example. If you build clients in several services (a Lambda here, a container there), audit all of them — the default is per-client, and one unpatched client is enough to reintroduce the bug.
Which Bedrock surface are you on?
Bedrock has two surfaces for Claude, and the advice lands differently on each. The 60-minute-versus-1-minute mismatch is documented for the legacy surface — the InvokeModel and InvokeModelWithResponseStream operations on the bedrock-runtime endpoint, which is where boto3-based integrations live. The current surface, "Claude in Amazon Bedrock," serves the standard Anthropic Messages API at the bedrock-mantle endpoint through Anthropic's own SDK (AnthropicBedrockMantle in Python). Anthropic's SDKs carry their own long-request discipline — they validate that non-streaming requests won't exceed a roughly 10-minute timeout and push you toward streaming for anything longer, as covered in the 10-minute rule article. Either way, the underlying principle is the same on both surfaces: the client's patience, not the model's, is usually the binding constraint.
Streaming makes the whole problem smaller
Raising the read timeout keeps a blocking call alive, but it also means your application sits silent for potentially many minutes with no way to distinguish "still generating" from "something is wedged." The stronger fix for long completions is streaming — InvokeModelWithResponseStream on the legacy surface, or standard SSE streaming on the current surface. With a stream, data starts flowing as soon as generation starts, each read resets the clock on idle timeouts, and you can show progress or checkpoint partial output. Long-running agentic work on Bedrock generally wants both belts: streaming as the primary pattern, and a generous read timeout as insurance for the quiet stretches within a stream.
max_tokens or extended thinking, grep your codebase for client construction and confirm every Bedrock client sets an explicit read timeout. The default is 60 seconds; your longest request defines the number you actually need, up to the 60-minute inference ceiling.Where to go next
For streaming mechanics on the legacy surface see Bedrock streaming with InvokeModel; for other Bedrock-specific failure modes see common Bedrock errors. Client-side timeout knobs in Anthropic's own SDKs are covered in SDK timeout tuning.