Azure OpenAI Responses API: reasoning stops at 516 tokens before tool calls: configuration, continuation, and bug status

We are following up on a repeatable reasoning-boundary issue with the following configuration:

• Model: gpt-6-astra (gpt-6-astra-2026-09-03)
• Region: East US 2
• Endpoint: Responses API
• Reasoning effort: xhigh
• max_output_tokens: 65536
• Tools enabled; no explicit reasoning-length limit configured

Observed behavior

Each reasoning item caps at exactly 516 tokens. After reaching this boundary, the model either continues in a new reasoning item or exits mid-sentence and goes straight to a tool call. The response remains status: "completed", with no truncation indicator.

We have not observed the same behavior with the same model through Chat Completions.

From noon on September 20 to noon on September 21, 2026, Eastern Daylight Time (EDT), approximately 36% of Responses API requests with 400+ reasoning tokens ended at exactly 516 reasoning tokens. This pattern was consistent across all hours.

Explanation received previously

A previous reply attributed this behavior to an internal orchestration and token-buffering boundary in the Responses API: 512 reasoning tokens plus 4 protocol/framing tokens. According to that reply, the runtime evaluates tool dispatch at this boundary and may end reasoning to emit a tool call. The response is marked completed because a valid tool call was produced.

Could the product team confirm whether this explanation is accurate? We can confirm the observed 516-token pattern, but we cannot independently verify its internal cause.

Why this matters

1. Reasoning stops at a fixed token boundary, often mid-sentence, rather than at a natural stopping point.
2. Emitting a tool call at that point raises concerns about decision quality, especially for tools with side effects.
3. There is no signal indicating that reasoning was interrupted, so callers cannot reliably detect affected requests.

Questions

1. Configuration: Is there a request parameter or deployment setting to disable this checkpoint or increase the 512-token interval described in the previous reply?
2. Continuation and detection: After a cut, is the model expected to resume the unfinished reasoning in the next turn? Is there any field or header that marks a reasoning item as cut?
3. Bug status: Is this tracked as a bug? Is there an ETA for a fix, or a model/API version without this behavior?
4. Scope: Does this apply to all regions and deployments of gpt-6-astra-2026-09-03, or only to certain regions or deployment configurations?

The previously suggested two-turn workaround—first requesting a response with tools disabled, then enabling tools in a second request—requires two calls instead of one and adds latency. A configuration-level option would be much preferred.

Reference requests

All requests below were made in East US 2 on September 20, 2026. All times are in EDT.

Requests with a single 516-token reasoning item followed immediately by a tool call:

Time (EDT)

apim-request-id

15:03:24

3751d57b-b192-4ff3-b433-80b58970ea7c

15:01:20

3d9f6c92-3b51-466c-a14c-dc98a1c01b69

15:02:31

86edaee2-b3e9-4b27-97f3-bc87368d78bd

15:04:24

4b346982-dedb-496f-bdf2-31cfd2e9ffe3

Comparison request that continued into a second reasoning item, with total reasoning_tokens=553:

Time (EDT)

apim-request-id

15:08:48

9fe438fc-8ef9-4391-9eca-d83a78fa8704

We will also open an Azure Portal support ticket with these request IDs. If the applicable diagnostic retention period is 30 days, the September 20 traces may expire around October 20. Please preserve the relevant traces for investigation if possible.

Thank you.We are following up on a repeatable reasoning-boundary issue with the following configuration:

• Model: gpt-6-astra (gpt-6-astra-2026-09-03)
• Region: East US 2
• Endpoint: Responses API
• Reasoning effort: xhigh
• max_output_tokens: 65536
• Tools enabled; no explicit reasoning-length limit configured

Observed behavior

Each reasoning item caps at exactly 516 tokens. After reaching this boundary, the model either continues in a new reasoning item or exits mid-sentence and goes straight to a tool call. The response remains status: "completed", with no truncation indicator.

We have not observed the same behavior with the same model through Chat Completions.

From noon on September 20 to noon on September 21, 2026, Eastern Daylight Time (EDT), approximately 36% of Responses API requests with 400+ reasoning tokens ended at exactly 516 reasoning tokens. This pattern was consistent across all hours.

Explanation received previously

A previous reply attributed this behavior to an internal orchestration and token-buffering boundary in the Responses API: 512 reasoning tokens plus 4 protocol/framing tokens. According to that reply, the runtime evaluates tool dispatch at this boundary and may end reasoning to emit a tool call. The response is marked completed because a valid tool call was produced.

Could the product team confirm whether this explanation is accurate? We can confirm the observed 516-token pattern, but we cannot independently verify its internal cause.

Why this matters

1. Reasoning stops at a fixed token boundary, often mid-sentence, rather than at a natural stopping point.
2. Emitting a tool call at that point raises concerns about decision quality, especially for tools with side effects.
3. There is no signal indicating that reasoning was interrupted, so callers cannot reliably detect affected requests.

Questions

1. Configuration: Is there a request parameter or deployment setting to disable this checkpoint or increase the 512-token interval described in the previous reply?
2. Continuation and detection: After a cut, is the model expected to resume the unfinished reasoning in the next turn? Is there any field or header that marks a reasoning item as cut?
3. Bug status: Is this tracked as a bug? Is there an ETA for a fix, or a model/API version without this behavior?
4. Scope: Does this apply to all regions and deployments of gpt-6-astra-2026-09-03, or only to certain regions or deployment configurations?

The previously suggested two-turn workaround—first requesting a response with tools disabled, then enabling tools in a second request—requires two calls instead of one and adds latency. A configuration-level option would be much preferred.

Reference requests

All requests below were made in East US 2 on September 20, 2026. All times are in EDT.

Requests with a single 516-token reasoning item followed immediately by a tool call:

Time (EDT)

apim-request-id

15:03:24

3751d57b-b192-4ff3-b433-80b58970ea7c

15:01:20

3d9f6c92-3b51-466c-a14c-dc98a1c01b69

15:02:31

86edaee2-b3e9-4b27-97f3-bc87368d78bd

15:04:24

4b346982-dedb-496f-bdf2-31cfd2e9ffe3

Comparison request that continued into a second reasoning item, with total reasoning_tokens=553:

Time (EDT)

apim-request-id

15:08:48

9fe438fc-8ef9-4391-9eca-d83a78fa8704

We will also open an Azure Portal support ticket with these request IDs. If the applicable diagnostic retention period is 30 days, the September 20 traces may expire around October 20. Please preserve the relevant traces for investigation if possible.

Thank you.