BYOK: unrequested easoning_effort and snippy params sent to non-reasoning OpenAI deployments (400)
还没有人认领这个 Issue。
- 主要语言
- Java
- 星标
- 10.5k
- 派生
- 1.5k
- 平均合并
- 1 天 14 小时
- 30 天内合并 PR
- 129
描述
What happened
Using the SDK in BYOK mode against an Azure AI Foundry account, every request to a non-reasoning OpenAI deployment (gpt-4.1-mini) fails at the provider with:
400 Unrecognized request arguments supplied: reasoning_effort, snippy
Anthropic deployments on the same account, same credentials, same code path work fine (claude-haiku-4-5, claude-sonnet-4-6 — 14/14 successful calls in the same run).
Why this looks like an SDK-side issue
Two parameters are reaching the provider that the calling application never set:
-
snippy— this string does not appear anywhere in our codebase. We grep for it across our entire application source and find zero occurrences. We have no API through which we could set it. -
reasoning_effort— we do pass areasoningEfforttocreateSession, but only after checkingcapabilities.supports.reasoningEffortfromlistModels()and dropping it when the model doesn't advertise support:const supported = new Set( (await sdk.listModels()) .filter((m) => m.capabilities?.supports?.reasoningEffort) .map((m) => m.id), ); const effort = supported.has(model) ? requested : undefined; await sdk.createSession({ model, ...(effort ? { reasoningEffort: effort } : {}), // ... });For a BYOK deployment name like
gpt-4.1-minithis resolves toundefinedand the key is omitted from the object entirely — yetreasoning_effortstill appears on the wire.
So both parameters appear to be injected below the SDK surface, inside the bundled CLI binary.
Impact
Non-reasoning OpenAI deployments are unusable through the BYOK path. This isn't only an inconvenience for model comparison — it removes the non-Anthropic fallback from a deployment whose only other models are Anthropic, so an Anthropic quota problem in-region would leave no working model at all.
Environment
@github/copilot-sdk1.0.13 (bundled CLI 1.0.83)- Provider: BYOK / custom endpoint,
type: "openai", Azure AI Foundry - Failing deployment:
gpt-4.1-mini(OpenAI2025-04-14) - Working deployments (same account/credentials):
claude-haiku-4-5,claude-sonnet-4-6
Expected
Neither snippy nor reasoning_effort should be sent to a provider/model that doesn't accept them — particularly reasoning_effort when the caller explicitly omitted it and the model catalog doesn't report reasoning support.
Questions
- Is
snippyintended to be sent to custom/BYOK providers at all? It looks like an internal parameter that should be scoped to the first-party backend. - For BYOK deployments absent from the model catalog, what's the intended way to guarantee no reasoning parameters are attached? Is there a supported opt-out?
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 BYOK createSession 和 listModels 路径开始,然后检查面向 Azure AI Foundry OpenAI 部署的捆绑 CLI 请求处理。使用 gpt-4.1-mini 进行复现,并将发出的请求与 Anthropic 路径进行比较。当非推理部署既不接收 reasoning_effort 也不接收 snippy,而受支持的推理模型保留其参数时,即表示完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- azure, typescript
- 领域
- api, backend, cloud
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 活跃
- 描述清晰度
- 基本清楚
- 新手友好度
- 52/100