We are using zai/glm-5.2-fast through Vercel AI Gateway with the Vercel AI SDK.
Despite explicitly setting reasoning: "none", the model still generates and streams reasoning content. Reasoning tokens are also reported in usage, increasing both latency and cost.
Environment
Model: zai/glm-5.2-fast
AI SDK: ai@7.0.31
Gateway package: @ai-sdk/gateway@4.0.23
Node.js: 20+
Providers observed through Gateway: Wafer AI and Fireworks AI
Minimal reproduction
import { streamText } from 'ai'
const result = streamText({
model: 'zai/glm-5.2-fast',
prompt: 'Solve a moderately complex problem and explain the answer.',
reasoning: 'none',
providerOptions: {
gateway: {
caching: 'auto',
},
},
})
for await (const part of result.fullStream) {
console.log(part)
}
console.log(await result.usage)
Expected behavior
With reasoning: "none":
The model should run with thinking/reasoning disabled.
No reasoning parts or reasoning deltas should be returned.
reasoningTokens should be zero or absent.
Latency and billing should reflect non-reasoning generation.
Actual behavior
Reasoning parts are streamed.
The model visibly performs an extended reasoning phase before answering.
Usage reports reasoning tokens.
The behavior occurs when Gateway routes the model through both Wafer AI and Fireworks AI.
The option appears to be silently ignored rather than rejected as unsupported.
Impact
This makes it impossible to control the latency and cost of agent requests. These agents perform many tool-calling steps, so unexpected reasoning substantially increases response time and token usage.
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:
const result = streamText({
model: 'zai/glm-5.2-fast',
prompt: 'Solve a moderately complex problem and explain the answer.',
reasoning: 'none',
})
Then pin one provider at a time instead of letting Gateway choose dynamically:
const result = streamText({
model: 'zai/glm-5.2-fast',
prompt: 'Solve a moderately complex problem and explain the answer.',
reasoning: 'none',
providerOptions: {
gateway: {
only: ['fireworks'],
},
},
})
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.
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.
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:
ai@7.0.31
@ai-sdk/gateway@4.0.23
model: zai/glm-5.2-fast and zai/glm-5.2
reasoning: "none"
gateway caching removed
gateway only: fireworks -> still streams reasoning
gateway only: wafer -> still streams reasoning
no unsupported-setting warning returned
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.