Streaming means the API returns the response incrementally over a single long-lived HTTP connection, using server-sent events (SSE) — a simple standard where the server pushes small text events down the wire as they become ready. On Microsoft Foundry, the Messages endpoint (POST /v1/messages) supports streaming for both hosting versions of Claude, and it is GA. Microsoft documents streaming and fine-grained tool streaming for both the "Hosted on Azure" and "Hosted on Anthropic infrastructure" deployment options.
Streaming with the Python SDK
The anthropic Python package includes a Foundry-aware client, AnthropicFoundry, which builds the endpoint URL from your resource name (https://<resource>.services.ai.azure.com/anthropic/) and handles the SSE plumbing. The SDK also auto-reads the ANTHROPIC_FOUNDRY_API_KEY and ANTHROPIC_FOUNDRY_RESOURCE environment variables, so the client can be constructed with no arguments in configured environments.
from anthropic import AnthropicFoundry
client = AnthropicFoundry(api_key="...", resource="example-resource")
with client.messages.stream(
model="claude-sonnet-5", # your deployment name
max_tokens=2048,
messages=[{"role": "user", "content": "Draft a project status update."}],
) as stream:
for text in stream.text_stream:
print(text, end="", flush=True)
final = stream.get_final_message()
print("\n", final.usage)The stream helper yields text deltas as they arrive and assembles the complete message at the end, so you still get the full usage object for cost and cache accounting. If you call the REST endpoint directly instead of using an SDK, set "stream": true in the request body and include the anthropic-version: 2023-06-01 header.
Timeouts: why streaming is the default for long outputs
Long generations — big max_tokens values, extended reasoning, large structured documents — can take minutes of wall-clock time. A non-streaming request holds the connection silently for the entire generation, which is exactly the condition that trips client-side timeouts, corporate proxies, and load balancer idle limits. A streaming request, by contrast, receives events continuously, keeping intermediaries convinced the connection is alive. Practical guidance:
- Stream anything user-facing or long. Current 1M-context models on Foundry support up to 128K output tokens; you do not want that arriving as one blocking response.
- Set generous read timeouts, short connect timeouts. A connect failure is worth retrying quickly; a slow-but-flowing stream is healthy and should not be killed.
- Watch for the terminal event. Treat a stream that ends without a final message-stop event as a failed request, not a short answer.
Retry considerations specific to Foundry
Two Foundry-specific facts shape your retry logic. First, Foundry does not return Anthropic's anthropic-ratelimit-* response headers, so you cannot read remaining quota off the response and preemptively slow down. Anthropic's guidance for Foundry is to use Azure monitoring tools and implement exponential backoff on HTTP 429 responses. Second, Foundry rate limits count requests per minute and uncached input tokens per minute at the subscription level, shared across deployments of the same model and version — so an aggressive retry loop in one service can throttle a neighboring service using the same model.
For failures you escalate to Microsoft or Anthropic support, capture the request-id and apim-request-id response headers — Anthropic's Foundry documentation asks for both so the request can be traced across Azure and Anthropic systems. Log them for every request, not just failures; you rarely know in advance which request you will need to investigate.
When not to stream
Streaming is not free complexity. Batch-style backends that classify tickets or extract fields from documents gain nothing from partial output — they need the complete, parsed result before doing anything, so a plain messages.create call with a sensible timeout is simpler to write, log, and retry. A reasonable rule: stream when a human is watching or when expected generation time is long enough to threaten a timeout; block when a machine is the consumer and responses are short. Also note what is missing on Foundry: Anthropic's Message Batches API is not available there at all, so high-volume asynchronous workloads are built from ordinary synchronous calls — streamed or not — under your own queue and concurrency control.
Where to go next
Pair this with handling rate limits and throttling on Foundry for the backoff details, and using Claude tool use on Foundry if your streams include tool calls. For general UX patterns, see streaming UX and timeouts.