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

未关闭
  • 哪里不对？
#924 3 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@a1exwang 已经在做这个了。

开始于 2026年11月3日。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
70/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
azure, javascript, vscode
领域
api, tooling

调研方向

The extension contains Responses API adapters, API capability checks, an in-memory preference cache, and a fallback from Chat Completions to Responses on OperationNotSupported. Locate the fallback handler that inspects 400 errors and the routing decision point for function tools. Done means Luna requests with tools route to /v1/responses (or reasoning_effort none) and the new 400 triggers retry, covered for streaming and non-streaming.

由索引模型根据 Issue 内容生成。

描述

needs attention

Product

Foundry Toolkit for VS Code

Environment

Foundry Toolkit: 1.6.18
OS: Windows
Host: VS Code Chat in Agent mode
Model: Microsoft Foundry deployment of gpt-6-luna

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-luna inference endpoint due to 400.
Function tools with reasoning_effort are not supported for gpt-6-luna 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

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

Actual behavior

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

Tool-calling requests for Luna 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.

Recommended fix

Prefer proactive routing rather than relying only on error text:

When the model advertises Responses API support and a request includes function tools plus non-none/default reasoning, route directly to Responses API.
Also recognize this 400 as a fallback signal and retry through Responses API for forward compatibility.
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.

主要语言
JavaScript
星标
2.1k
派生
260
平均合并
3 小时 18 分钟
30 天内合并 PR
43

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/foundry-dev-tools 的其他 Issue

查看 microsoft/foundry-dev-tools 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。