[Bug] reasoningSummary injected for Azure/openai-compatible providers — should be guarded like textVerbosity

[Dulani]

[Authorship: 80% AI, 20% human]

Description

In transform.ts, reasoningSummary = "auto" is set for all gpt-5 models (line ~829) with no Azure guard. The textVerbosity parameter has an Azure guard (input.model.providerID !== "azure" on line ~838), but reasoningSummary does not.

Impact

Azure OpenAI rejects reasoningSummary as an unknown parameter. This is currently masked when using useResponses: true (which routes through the copilot Responses SDK), but will break if that path changes.

Evidence

// transform.ts ~line 826
if (input.model.api.id.includes("gpt-5") && !input.model.api.id.includes("gpt-5-chat")) {
  if (!input.model.api.id.includes("gpt-5-pro")) {
    result["reasoningEffort"] = "medium"
    result["reasoningSummary"] = "auto"   // ← NO Azure guard here
  }
  if (
    input.model.api.id.includes("gpt-5.") &&
    !input.model.api.id.includes("codex") &&
    !input.model.api.id.includes("-chat") &&
    input.model.providerID !== "azure"    // ← textVerbosity IS guarded
  ) {
    result["textVerbosity"] = "low"
  }
}

Proposed Fix

Add && input.model.providerID !== "azure" to the reasoningSummary block (lines 827-830), or use input.model.api.npm !== "@ai-sdk/openai-compatible" to match existing patterns elsewhere in the codebase.

Related

• Azure models fail due to reasoning_effort being sent even with --variant none #12113 (Azure models fail due to reasoning_effort — same root cause for a different parameter)

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [Bug] Custom OpenAI-compatible provider errors with "Unknown parameter: 'reasoningSummary'" for GPT-5 series models #13546: Same error — Unknown parameter: 'reasoningSummary' for custom OpenAI-compatible providers with GPT-5 models (closed)
• Bug: gpt-5 defaults + @ai-sdk/openai-compatible path sends incompatible reasoning params #16154: Same root cause — gpt-5 defaults send incompatible reasoning params via @ai-sdk/openai-compatible path (closed)

Both of those issues were resolved. If the problem has regressed or your scenario is meaningfully different (e.g., specific to Azure rather than generic openai-compatible providers), please describe how your case differs from those.

[daitmaamar4-png]

Confirmed: This is the same root cause affecting @ai-sdk/openai providers with LiteLLM proxies (like our issue #21346). The
easoningSummary = 'auto' injection without provider guards breaks any non-OpenAI endpoint that doesn't recognize this parameter, causing response parsing crashes. The fix should extend the existing Azure guard pattern to cover custom providers via input.model.api.npm !== '@ai-sdk/openai' or similar checks. Applying the same guard used for extVerbosity to the
easoningSummary block should resolve both scenarios.

[Dulani]

Thanks for the links. Those issues (#13546, #16154) addressed reasoningSummary being sent to unsupported providers generally. This issue is different: it's a code-level asymmetry in transform.ts — textVerbosity has && input.model.providerID !== "azure" on line ~838 but reasoningSummary in the same block (lines 827–830) does not. The bug is the inconsistent guard, not the general injection problem those PRs fixed.