Grok 模型退役了怎么迁移：官方给的重定向路径怎么读
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
Grok 这次的模型退役有个反直觉的设计：退役之后旧的模型 slug 并不会失效，请求也不会因为模型不存在而失败，而是被平台自动重定向到新模型上继续服务。官方公告里明确说「slug 本身继续解析，你不需要改代码来避免中断」。这意味着代码不改照样能跑——但也意味着如果你没有主动迁移，你现在已经在按新模型的价目在付费，而且推理档位是平台替你选的，不是你选的。真正需要动手的不是「让它别报错」，而是「让它按你想要的模型和档位跑」。退役日期是 2026 年 5 月 15 日 12:00 PM PT，按本文写作时间算，这个时间点已经过去了，所以下面所有内容对你都不是「将要发生」，而是「已经生效」。
先确认你有没有被这次退役覆盖
xAI 迁移指南里列出的退役 slug 是一份明确的清单，去官方 migration 页面对照即可（以官方文档当前版本为准）：grok-4-1-fast-reasoning、grok-4-1-fast-non-reasoning、grok-4-fast-reasoning、grok-4-fast-non-reasoning、grok-4-0709、grok-code-fast-1、grok-3，以及图像侧的 grok-imagine-image-pro。
排查动作很简单：在你的代码库里全局搜一遍 model= 或者 "model":，把出现过的字符串都收集起来，和上面这份清单比对。别只查主服务，容易漏的地方是这三类：一是离线脚本和定时任务，这些没人天天看日志；二是配置中心或者环境变量里写死的模型名，代码里搜不到；三是 Batch 提交的 JSONL 文件模板，按官方说明，文件里每一行是一个带 custom_id、method、url、body 四个字段的 JSON 对象，模型名在 body 里面而不是行的顶层，扫配置的时候很容易被跳过去。
这里有个和你的直觉不一样的点值得强调：大多数人对「模型下线」的预期是请求直接失败、监控当天就炸、被迫立刻处理。而按官方这份迁移指南的说法，退役后的 slug 仍然继续解析，请求照常返回结果——监控上一片安静，变化只发生在你调用的模型和账单口径上。安静恰恰是最危险的形态：没有任何信号提醒你去做这件事，全靠你自己想起来。
重定向到底落在哪个模型上
官方给出的映射规则是按「推理 / 非推理」两类分的，这一条决定了你现在实际在调用什么：
- 清单里所有推理型模型的请求，由
grok-4.3以low推理档位承接； - 清单里所有非推理型模型的请求，由
grok-4.3以none推理档位承接； grok-code-fast-1走的是另一条路，重定向到grok-build-0.1；grok-imagine-image-pro重定向到grok-imagine-image-quality。
注意后两条不是「统一归到 grok-4.3」的例外情况，而是官方按工作负载类型分开安排的：代码类负载给了专门的编码模型，图像类负载给了对应的 Imagine 模型。所以如果你同时在跑对话和代码两条线，迁移后你会同时落到两个不同的模型上，成本口径要分开算。
关于 grok-4.3，官方在这份迁移指南里给出的结构性参数是：上下文窗口 100 万 token，推理档位有 none、low、medium、high 四档（以官方文档为准）。这里出现了一个文档之间的细微不一致，值得你自己回源确认一次：迁移指南说 grok-4.3 支持包括 none 在内的四档推理档位，但 reasoning 参数那份文档的汇总表里只列了 grok-4.6、grok-4.5 和 grok-4.20-multi-agent 三行，没有 grok-4.3 这一行。两份文档更新节奏不一样很正常，但你在写代码显式指定档位之前，最好按目标模型的模型页再核一遍取值范围，别照着一份文档写死。
「不用改代码」这句话的代价
官方在迁移指南开头的 CAUTION 提示框里点了一句：grok-4.3 与它所替代的那些模型定价不同。正文的「Pricing impact」一节说得更直接：退役日之后继续往废弃 slug 发请求，会按 grok-4.3 的价目计费，而不是原模型的价目；官方给出的建议是在退役日之前就为每类负载显式挑好替换模型，以避免成本意外上涨。具体差多少这里不写，因为价目随时可能调整，去官方定价页看当前值才有意义。
真正要你理解的是机制上的两个变化：
第一，计价基准换成了另一个模型。 你的账单从此按 grok-4.3 的价目结算，而不是按你代码里写的那个旧 slug 原本的价目——两者具体差在哪，去官方定价页看当前值，这里不复述。更麻烦的是长上下文分档：官方定价表下方注明，部分模型采用长上下文计价，即当一次请求的 prompt token 数（官方特别说明这个统计包含缓存命中的部分）达到该模型的长上下文阈值之后，这次请求的全部 token 都按更高的那一档计价，不是只有超出的部分；缓存和非缓存 token 在这种情况下各自走自己的长上下文档位。关键是这个阈值按模型定，不是全局常量，所以换模型之后你不能假设它没变。查法是现成的：官方 GET /v1/language-models 接口返回的每个模型对象里都带一个 long_context_threshold 字段，文档对它的定义是「达到或超过该 token 数时长上下文价格生效」，取值为 0 表示这个模型没有长上下文计价档；同一个返回里的价格字段也成对出现，带 _long_context 后缀的那一组就是对应的高档价。迁移之前拉一次这个接口，按目标模型的实际取值重新估一遍你有多大比例的请求会踩进高档，比翻定价页截图靠谱。
第二，推理档位被平台替你选了。 重定向给推理型负载配的是 low，给非推理型负载配的是 none。官方明确写了这一点的用意——「主动迁移可以让你自己控制为哪一档推理付费，而不是接受重定向应用的默认档位」。推理 token 是计入总消耗的，官方 reasoning 文档里写得很直白：使用推理模型时，推理 token 作为总消耗的一部分计费。所以档位选择直接落在账单上。这一块的参数细节可以看 Grok 推理强度怎么控制。
主动迁移的具体动作
官方说法是「大多数情况下，迁移就是改一下 API 请求里的 model 字段」。但只改 model 字段等于把档位选择也交出去了，完整的动作是两步：
第一步，把 model 换成你选定的目标模型。 官方的推荐替换关系是：原来用 grok-4-1-fast-reasoning、grok-4-fast-reasoning、grok-4-0709 的，迁到 grok-4.3；原来用两个 non-reasoning 变体的，迁到 grok-4.3 并显式指定 none 档位，对延迟不那么敏感的负载可以考虑改用 low；原来用 grok-code-fast-1 的，迁到 grok-build-0.1。
第二步，显式写上推理档位。 参数名是 reasoning_effort（Responses API 上的形态是 reasoning: {"effort": ...}）。这里有几条来自官方 reasoning 文档的硬约束要提前知道：
- 不指定时，
reasoning_effort取默认值high，且推理不能被关闭（这条是针对grok-4.6和grok-4.5写的，以官方文档当前版本为准）； presencePenalty、frequencyPenalty和stop三个参数不能和推理模型一起用，请求里带了会直接返回错误。如果你的旧代码里为了控制输出长度设了stop，迁移时这行就得删掉，否则会是你迁移当天第一个报错；xhigh档位在不支持它的模型上会被当作high处理，不会报错——又是一个「安静地不按你预期跑」的行为。
第三步不算迁移动作，但强烈建议做：把改动放在灰度里跑一段，因为换模型不只是换价目，输出风格、工具调用行为、对系统提示词的遵循程度都可能变化。跨厂商换模型的通用检查项可以对着 换模型/换厂商迁移清单 过一遍，同厂商跨版本迁移里大部分条目同样适用。
迁移之后怎么核账单口径
Grok 这边核账单有个比较省事的机制：每一次推理响应的 usage 对象里都带一个 cost_in_usd_ticks 字段，chat completions、Responses API、图像生成和视频生成都有。官方说明写得很清楚，这个值是该次请求实际被计费的金额，已经把所有适用的优惠（包括提示缓存带来的减免）算进去了，也包含服务端工具调用的费用，不需要事后再去查账单做对账。
字段单位是 ticks 而不是货币单位，官方给出了 ticks 与货币金额之间的固定换算系数，具体系数写在成本追踪文档里。用整数 ticks 而不是浮点金额的理由官方也解释了：请求量上去之后，浮点数累加会有舍入误差，总数对不上，整数 ticks 能精确到远小于一分钱的粒度。xAI SDK 另外提供了一个 cost_usd 便捷属性做自动换算，原始整数值仍然可以从 usage.cost_in_usd_ticks 拿到。
所以验证迁移效果的做法就有了：迁移前后各采样一批同类请求，把 cost_in_usd_ticks 按模型名分组累加，直接看单位业务量的成本变化，而不是等月底账单出来再猜是哪个环节涨的。按维度拆成本的做法可以看 Grok 的成本追踪怎么做，长期的监控口径可以参考 API 成本监控怎么做。
用别名还是用固定版本，这次退役给了答案
官方模型文档里写了三种 slug 形态的语义：<modelname> 指向该模型的最新稳定版本，<modelname>-latest 指向最新版本（适合想自动拿到新特性的人），<modelname>-<date> 指向某一次具体发布、不会被更新，适合对一致性有硬要求的工作流。
这次退役正好把这个选择的代价摊开了看：这批被退役的 slug 里，grok-4-0709 这种带日期的固定版本也在其中。也就是说，钉死版本能让你的行为稳定，但并不能让你免于退役——到期了照样被重定向走。反过来，用别名的人平时会跟着版本自动往前走，退役这件事对他们冲击更小，但代价是模型行为可能在某次更新后悄悄变化。
实用的取舍：对输出格式敏感、下游有严格解析的链路用固定版本，同时把「盯官方 release notes」列成一项固定的运维动作；对格式不敏感的探索型、内部工具型链路用别名，省心。两种都不是免检的。
怎么持续盯住下一次退役
官方的 release notes 是按月倒序组织的，每条更新带一个小标题和指向具体文档的链接，新模型上线、新参数可用、新 API 能力都在里面。翻这份页面的时候有两类条目要特别留意：一类是新模型发布，因为新模型上线通常意味着旧模型的退役在排期上；另一类是区域开放条目，release notes 里出现过「某个模型在欧盟区的控制台可用」这样的单独条目，说明模型的区域开放是分批推进的。做迁移排期时，务必按官方的区域可用性说明确认目标模型在你账号所属的区域是否已经开放，别在代码都改完之后才发现目标模型在你的区域还调不通。境外模型服务的可用区域一律以官方说明和官方给出的企业采购路径为准。
官方在迁移指南结尾给的支持方式只有一条：发邮件到 support 邮箱，具体地址写在那一页的结尾。迁移过程里拿不准的问题——目标模型在你的账号和区域下能不能调、某个参数组合报错是不是预期行为——按这个官方渠道提，比在别处找二手答案稳妥。
最后，这次最容易栽的坑
按坑的隐蔽程度排序，第一是你以为没事：没有报错、没有告警、监控全绿，但计价模型和推理档位都已经变了。第二是只改了 model 字段就收工：档位仍然是重定向给你的那个默认值，你既没享受到主动选档的成本优化，也可能在需要深度推理的场景上拿到了 low 档的结果。第三是忘了删旧参数：stop、presencePenalty、frequencyPenalty 这些和推理模型互斥的参数留在请求里会直接报错，而这些参数往往藏在很久以前写的公共封装层里，改 model 的人根本不知道它们的存在。
今天就能做的一件事：搜一遍代码库里的模型名，把清单上的旧 slug 都换成显式的目标模型加显式的推理档位，然后用 cost_in_usd_ticks 采样对比一周。这件事拖着不做没有任何惩罚信号，正因为如此才更容易被无限期拖下去。