Foundry Toolkit: GPT-6 Astra tool calls fail in VS Code Chat because Chat Completions is used with reasoning

[ErikSeiter]

Product

Foundry Toolkit for VS Code

Environment

• Foundry Toolkit: 1.6.13
• OS: Windows
• Host: VS Code Chat in Agent mode
• Model: Microsoft Foundry deployment of gpt-6-astra

Problem

The model works in the Foundry Toolkit chat/playground, but fails when selected as the model in VS Code Chat Agent mode. Requests without function tools are not the problematic case; the failure occurs when VS Code Chat supplies function tools.

Error

Unable to call the gpt-6-astra inference endpoint due to 400.
Function tools with reasoning_effort are not supported for gpt-6-astra in /v1/chat/completions.
To use function tools, use /v1/responses or set reasoning_effort to 'none'.

Project/resource identifiers and client request IDs have been omitted.

Steps to reproduce

1. Connect a Microsoft Foundry project containing a gpt-6-astra deployment in Foundry Toolkit 1.6.13.
2. Select that deployment as the model in VS Code Chat.
3. Use Agent mode so VS Code sends function tools.
4. Submit a request that allows tool use.

Actual behavior

Foundry Toolkit routes the request to /v1/chat/completions. Because Astra has reasoning enabled by default, the service rejects the combination of function tools and reasoning with HTTP 400.

Expected behavior

Tool-calling requests for Astra should use /v1/responses, preserving reasoning and tool-calling support. As a compatibility fallback, Chat Completions could explicitly set reasoning_effort: "none", but Responses API is the preferred path.

Investigation

The installed extension already contains:

• Responses API request/stream adapters;
• API capability checks;
• an in-memory API preference cache keyed by endpoint host and deployment;
• fallback from Chat Completions to Responses API when an error is recognized as OperationNotSupported.

However, this newer HTTP 400 message is not recognized by the existing fallback condition, so no retry occurs.

Verified workaround

A local test expanded the existing unsupported-operation detection to also recognize:

Function tools with reasoning_effort are not supported

The existing caller then cached responses for the deployment and retried through the Responses API. The modified bundle passed JavaScript syntax validation and produced no VS Code diagnostics.

Recommended fix

Prefer proactive routing rather than relying only on error text:

1. When the model advertises Responses API support and a request includes function tools plus non-none/default reasoning, route directly to Responses API.
2. Also recognize this 400 as a fallback signal and retry through Responses API for forward compatibility.
3. Add coverage for both streaming and non-streaming VS Code Language Model API requests.

Relevant Microsoft guidance: https://learn.microsoft.com/azure/foundry/openai/how-to/reasoning#tool-calling-with-reasoning-models

That guidance recommends Responses API when reasoning is combined with function/custom tools.

[microsoft-github-policy-service]

Thank you for contacting us! Any issue or feedback from you is quite important to us. We will do our best to fully respond to your issue as soon as possible. Sometimes additional investigations may be needed, we will usually get back to you within 2 days by adding comments to this issue. Please stay tuned.