把请求里的 model 改成 glm-5.3 以后，旧习惯里用来关思考的 thinking.type: "disabled" 一送上去，整段会被拒。智谱文档《GLM-5.3》写得很死：这个型号会始终启用思考，不再支持禁用。迁模型 ID 之前如果参数还按旧习惯传，很容易卡在这一步。
文档里的参数表
《GLM-5.3》页的功能变更一段写明：目前只处理文本，支持 1M 上下文窗口，最大输出 Tokens 为 128K。思考相关参数如下：
thinking.type：只接受enabled，默认也是enabled，不支持禁用。reasoning_effort：low、high、max，默认max。文档对三档的说明是轻量 / 增强 / 深度推理。
页面上的迁移提示原文大意是：若应用里还在用 thinking.type: "disabled"，请在把模型 ID 更新为 glm-5.3 之前，先改成 enabled，并把 reasoning_effort 设为 low。否则请求会失败。复杂 Coding 任务文档建议用 max。
最小请求形态可以按文档示例收成：
{
"model": "glm-5.3",
"messages": [{"role": "user", "content": "…"}],
"thinking": { "type": "enabled" },
"reasoning_effort": "max"
}
日常想省一点思考开销，把 reasoning_effort 调成 low 即可，不要再传 disabled。需要更深推理时再用 high 或 max。三档怎么选没有统一公式，文档只给了 Coding 等复杂任务偏 max 的建议。延迟和费用体感要自己用同一条提示对比，这篇不引用任何竞品分数表。
迁的时候先改哪一步
容易踩坑的顺序是：先改 model，请求一发就失败，再回头翻文档。按迁移提示，应先改客户端或网关里的 thinking / reasoning_effort，确认不再出现 disabled，再切模型 ID。代理层、SDK 封装、提示词模板、CI 里的 fixture 如果还写着旧字段，也会在切模型后一起爆。
有的封装会把「关闭思考」做成布尔开关，内部仍序列化成 thinking.type: "disabled"。开关在旧模型上能用，不代表新模型还认。切 glm-5.3 前，把序列化结果抓一条出来看字段，比只改 UI 开关更靠谱。流式和非流式示例在文档里都要求带上 thinking.type: "enabled"，别只改了非流式路径。
接入端点文档列了 OpenAI Chat Completions、OpenAI Response、Anthropic Message 几类 Base URL。若曾经订阅过 GLM Coding Plan（含已过期），文档备注暂时只能走 OpenAI Chat Completions 协议调模型 API，其余协议的开放进度以页面后续更新为准。这篇只核思考参数。套餐积分、Flash / FlashX 进不进 Coding Plan 另说，不在这里展开价目。
排错时先看返回体里是不是明确抱怨 thinking / disabled，再查本地配置。有的网关会把未知字段丢掉，表面上看请求「成功了」，实际上思考强度一直停在默认 max，账单和延迟都会和预期不一致。另一类相反：网关把旧的 disabled 原样转发给新模型，于是整段失败。两种都要在代理日志里把 outbound JSON 打出来对一下。
文档里的能力列表还提到流式输出、Function Calling、上下文缓存、结构化输出等，这些和「能不能关思考」不是同一件事。思考被迫开启之后，工具调用轮次里还要不要回传思维链字段，以智谱深度思考专题文档为准，这篇不把旧模型的习惯直接搬过来。基准评测数字、和其他型号的对比表一律不抄，避免写成跑分帖。
如果业务上必须「完全不思考」的短链路，按当前文档做不到，只能继续留在仍支持 disabled 的旧模型 ID，或接受 reasoning_effort: "low" 作为最轻的一档。把模型名先改掉再指望参数兼容，是这次迁移里最常见的顺序错误。团队若有统一的模型路由配置，把 glm-5.3 的默认思考参数写进同一处，比让每个业务服务自己猜字段名省事。
已经切到 glm-5.3 的，你们是统一把 reasoning_effort 钉在 low，还是按任务在 low / high / max 之间切换？