Hi Thimows,

Your repro looks useful. I’d make the next test isolate three things: SDK forwarding, Gateway routing, and provider-specific behavior.

First, remove Gateway caching from the minimal repro so the only variable is reasoning:

1
const result = streamText({
2
  model: 'zai/glm-5.2-fast',
3
  prompt: 'Solve a moderately complex problem and explain the answer.',
4
  reasoning: 'none',
5
})
6

Then pin one provider at a time instead of letting Gateway choose dynamically:

1
const result = streamText({
2
  model: 'zai/glm-5.2-fast',
3
  prompt: 'Solve a moderately complex problem and explain the answer.',
4
  reasoning: 'none',
5
  providerOptions: {
6
    gateway: {
7
      only: ['fireworks'],
8
    },
9
  },
10
})
11

If reasoning: 'none' is still ignored when pinned to a single provider, that points to a model/provider capability or mapping issue. If it only happens with automatic routing, then the issue is more likely Gateway selecting providers that do not handle the same reasoning control consistently.

I’d also capture the Gateway generation ID from providerMetadata.gateway.generationId for one failing request. That gives Vercel something specific to look up without needing your API key or private logs.

The concerning part is not that the model can reason internally, but that visible reasoning parts and reasoningTokens are returned while the request explicitly asks for reasoning: 'none'. If that setting is unsupported for this model/provider combo, I’d expect a warning or a rejected option rather than silent reasoning output.

Thanks for your reply @ryux1! one important clarification: this is a regression. reasoning: 'none' previously disabled visible reasoning with this same integration. It recently stopped working and is now affecting our production apps: agent steps take substantially longer and consume far more tokens than expected.

I ran the requested isolation using ai@7.0.31 and @ai-sdk/gateway@4.0.23, with Gateway caching removed:

• A mocked transport confirmed the SDK forwards both "reasoning": "none" and the Gateway only option in the outbound request.
• Automatic routing selected Fireworks and still streamed reasoning.
• Pinning Fireworks still streamed reasoning.
• Pinning Wafer still streamed reasoning.
• Both zai/glm-5.2-fast and zai/glm-5.2 are affected.
• All six tests consumed the full 768-token safety limit despite reasoning: 'none'.
• Fireworks produced only reasoning and no answer text before exhausting the limit.
• Wafer spent the tokens on reasoning and only began returning a short answer after roughly six seconds.
• No unsupported-option warnings were returned.

There is also inconsistent usage mapping: Fireworks streamed visible reasoning but reported reasoningTokens: 0, while Wafer reported 768 reasoning tokens.

Representative failing generation IDs:

• Fireworks, glm-5.2-fast: gen_01KXX3WH30VNCYBGXZFYAHEBPC
• Wafer, glm-5.2-fast: gen_01KXX3WNTDCHHQ61H37Z50SWHN
• Fireworks, glm-5.2: gen_01KXX3WVYMCXF47TR3E314FVPK

Since the SDK is forwarding the setting and the failure occurs with both providers when pinned, this appears to be a Gateway/provider reasoning-control regression rather than an automatic-routing issue. This is urgent for us because it is currently breaking the latency and cost characteristics of every agent request.

Hi Thimows,

Thanks, that narrows it down a lot. With the mocked transport confirming the SDK forwards reasoning: "none", and both pinned providers still emitting visible reasoning, I’d stop looking at caching or automatic routing. This now looks like either a Gateway provider-translation regression or a provider-side regression that Gateway is exposing for both routes.

The most useful bug report package is probably:

1
ai@7.0.31
2
@ai-sdk/gateway@4.0.23
3
model: zai/glm-5.2-fast and zai/glm-5.2
4
reasoning: "none"
5
gateway caching removed
6
gateway only: fireworks -> still streams reasoning
7
gateway only: wafer -> still streams reasoning
8
no unsupported-setting warning returned
9

And then include those generation IDs plus one small captured stream sample showing the reasoning part and the final usage object. The Fireworks mismatch is especially important: visible reasoning streamed, but reasoningTokens: 0. That suggests there may be two separate issues here: reasoning control being ignored and usage normalization being inconsistent.

For production mitigation, I would not rely on maxOutputTokens as the fix, because your test already shows it can just spend the whole cap on reasoning and return little/no answer. I’d temporarily route latency-sensitive agent steps away from zai/glm-5.2* through Gateway, or put this model behind a feature flag until reasoning: "none" is honored again.

If you know the last date/time or last package/model behavior where this worked correctly, that would probably help Vercel/provider teams bisect the regression.