Claude Platform on AWS in Practice

Streaming Responses on Claude Platform on AWS

Users judge latency by the first word, not the last. Streaming turns a long wait into an immediate flow — and on this platform it works exactly like the first-party Claude API.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Streaming delivers a model response incrementally as it is generated, instead of making the caller wait for the whole thing. Claude Platform on AWS uses server-sent events (SSE) — the same plain-HTTP streaming format as the first-party Claude API — not AWS EventStream, the binary framing Bedrock's native APIs use. That is a genuine migration convenience: any SSE-consuming code you wrote against the first-party API works unchanged, and full SSE streaming (including fine-grained tool streaming) is supported.

Streaming with the SDK

The AnthropicAWS client is used exactly like Anthropic(), so the SDK's streaming helper carries over. The context-manager form handles connection setup and teardown, and text_stream yields text as it arrives:

from anthropic import AnthropicAWS

client = AnthropicAWS()  # AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID set

with client.messages.stream(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Explain SSE in one paragraph."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

final = stream.get_final_message()  # assembled Message with usage totals

Under the SSE surface, a response arrives as typed events: the stream opens, content blocks start, a series of content_block_delta events each carry a small fragment of a block (text, or partial JSON for tool use), blocks stop, and the stream closes with the final usage accounting. Two handling rules keep consumers robust. First, deltas are fragments, not units: a content_block_delta can split words, sentences, or a JSON value mid-token, so accumulate deltas per block and only parse the result once the block completes — this matters most for tool-use input, where partial JSON is not valid JSON until the block ends. Second, dispatch on event type and ignore types you don't recognize, so new event types added later don't break you. The SDK's higher-level iterators do the accumulation for you; drop to the raw event stream only when you need it.

Back-pressure for slow consumers

Back-pressure is what happens when the party reading the stream is slower than the party producing it. If you relay Claude's stream to a browser over your own connection, a slow client can stall your relay. Practical defenses:

Decouple with a bounded buffer. Read from the model stream on one task, write to the client on another, with a size-limited queue between them. When the queue fills, decide the policy explicitly — pause reads, or disconnect the slow client — rather than letting memory grow unbounded.

Don't hold streams open for absent readers. If the end client disconnects, cancel the upstream request promptly rather than draining it into the void.

Batch UI updates. Deltas can arrive faster than a UI usefully repaints; coalescing fragments every few tens of milliseconds costs nothing perceptible and reduces downstream churn.

Testing timeout resilience

Streams traverse your proxies, load balancers, and VPC path (AWS PrivateLink is supported for private connectivity), and every hop has an idle-timeout opinion. Before production, test the failure modes you will actually see:

Long thinking gaps. Requests with extended reasoning can have quiet periods before visible output; verify intermediaries don't kill the connection during them, and set client read timeouts per-chunk rather than for the whole response.

Mid-stream termination. Kill the connection partway and confirm your application treats the partial output correctly — either discarding it or clearly marking it incomplete, never persisting it as a finished answer.

Retry semantics. A stream that dies mid-response cannot be resumed; a retry is a new request that regenerates from the start. Make sure retry logic doesn't duplicate side effects your handlers performed on the partial stream.

Rule of thumb: log the response's x-amzn-requestid (for AWS support) and request-id (for Anthropic support) as soon as the stream opens, not when it ends — a stream that dies mid-flight is precisely the case where you'll want the IDs.

Where to go next

Pair this with error codes and retries for the failure-handling half, and tool use on Claude Platform on AWS for streaming tool calls. The quickstart covers first-call setup.

Sources

← All articles