GPT-5.6 on Azure OpenAI buffers full completion into a single output_text.delta instead of incremental streaming

Question

Hi, I've beeen testing the new GPT-5.6 on Azure OpenAI, but I am facing some issues: it returns the full completion as a single output_text.delta instead of streaming token-by-token via the Responses API. A GPT-5.4 deployment on the same resource, same client, same code path, streams normally. The same code path emits ~1,300+ deltas for GPT-5.4 vs 1 for GPT-5.6.

I even tried to switch output filter to Asynchronous Filter, but changed nothing.

Environment:

• Azure OpenAI, /openai/v1/ (Responses API), OpenAI Python SDK v1, streaming enabled
• Both deployments: reasoning.effort = "low", identical content-filter policy

Repro (only the model differs):

• GPT-5.4: ~1,300–1,800 incremental deltas (1–16 chars each), first delta ~1.8s
• GPT-5.6: exactly 1 delta with the entire response, arriving at end of generation

Is incremental streaming expected to be unavailable for this GPT-5.6 deployment (as it is day-one GA), or is there a config setting I'm missing? If it's a known gap, is there an ETA?
Thank you in advance!

Answer 1

streaming with gpt-5.6 seems to be working again here -

Answer 2

Same issue here with GPT-5.6. The Chat Completions API streams fine on the exact same deployment - only the Responses API buffers everything into a single output_text.delta. Same resource, same code, and a GPT-5.4 deployment streams normally via Responses.

Since completions streams correctly, this rules out the content filter and any client/proxy buffering on our end - looks like a Microsoft-side gap for the 5.6 Responses API. Can anyone from Microsoft confirm, or share an ETA?

Answer 3

Hello Andrew Sá,

Greetings! Thanks for raising this question in the Q&A forum.

Since GPT-5.4 streams normally on the same resource and code path, this is not a client bug. What you are seeing is a known pattern with day-one GA model rollouts on Azure OpenAI: full token-by-token streaming support for a brand new model is sometimes enabled a few days after the model itself goes GA, so the backend temporarily falls back to returning the whole completion as a single output_text.delta even though stream is set to true. A few other things can also collapse streaming into one chunk, so it's worth ruling those out first.

1. Confirm the api-version you are pinned to

If you are calling a dated preview api-version rather than the newest /openai/v1/ path for the Responses API, the older version may not yet understand GPT-5.6's streaming event schema and can silently buffer. Test the same request against the latest GA api-version and, separately, against the most recent preview api-version, and compare delta counts.

1. Verify Asynchronous Filter is actually bound to this deployment

Switching the output filter mode in the request body only works if the deployment itself is associated with a content filtering policy that has Asynchronous Filter selected. Go to Azure AI Foundry portal, open the GPT-5.6 deployment, and confirm under its content filter policy that Asynchronous Filter is the active mode for that specific deployment rather than just the default policy. Default (synchronous) filtering buffers output in sentence-sized windows, but it does not normally reduce a full response to exactly one delta, so this is unlikely to be the sole cause, but it is worth eliminating.

1. Test in a different region or a fresh deployment

Day-one capacity rollout for new models is uneven across regions. Deploy GPT-5.6 in a second region (or redeploy in the same region) and rerun the repro. If incremental streaming works there, it confirms this is a rollout gap tied to your specific deployment rather than a model-wide limitation.

1. Try both Chat Completions and the Responses API

Since you are on /openai/v1/ with the Responses API, also test the same prompt through the chat/completions endpoint with stream: true. If one endpoint streams token-by-token and the other does not, include that detail when you escalate, since it narrows down whether the gap is in the Responses API event handling specifically.

1. Capture the apim-request-id and open an Azure Support ticket

Since GPT-5.4 on the same resource streams correctly, capture the apim-request-id response header from a failing GPT-5.6 call and open a support case through the Azure Portal (Help + Support > New support request). Reference that this is a day-one GA gap for incremental streaming, since it will need engineering visibility on the model rollout rather than a documentation-based fix. There is currently no published ETA for full streaming parity on GPT-5.6 deployments.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Answer 4

Any idea when this is going to be fixed ? The behavior is still the same as of now. No streaming even though stream is set to true