Grok 3 API 已退役：2026 年迁移、价格与选型指南

现在继续调用 grok-3，并不代表 xAI 仍在运行 Grok 3。xAI 已于 2026 年 5 月 15 日退役这个 API 型号；旧 slug 仍可解析，但请求会被转到 grok-4.3，reasoning effort 设为 none，费用也按 Grok 4.3 计算。

这件事比普通的「新模型替代旧模型」更容易被忽略，因为应用不一定报错。接口返回正常、自动化继续运行，开发者却可能仍在配置、日志或成本表里把它记作 Grok 3。对于一人公司和小团队，真正需要处理的是这种静默变化：你实际用了什么模型、付了什么价格，原有提示词和结构化输出是否仍然可靠。

本文的型号、价格与产品状态均在 2026 年 10 月 10 日依据 xAI 官方文档核对。所有金额均为美元；正式上线前仍应查看控制台中的即时价格和团队限额。

先检查：你的 Grok 3 请求实际去了哪里

xAI 的 2026 年 5 月模型退役公告 明确列出 grok-3。截止时间之后，它的处理方式如下：

自动转发可以避免服务在退役当天直接中断，却会掩盖依赖已经改变。只要配置里还写着 grok-3，排查问题的人就很容易按照旧能力、旧价格和旧文档判断。

第一步不是比较新模型排行榜，而是把流量记录、发票、评测结果与应用配置对齐。确认响应中的实际模型和 usage 信息，然后显式改成当前型号。

为什么「接口还能用」不能算迁移完成

模型变化未必表现为明显的答非所问。更常见的是细小但会破坏自动化的漂移：JSON 多出解释文字、工具调用次数改变、摘要变长、引用格式变化，或某类模糊输入更容易得到武断结论。

这类问题在人工聊天中可能无伤大雅，放进无人值守流程就会积累成本。一次输出格式变化可能让下游解析失败；研究 Agent 多搜几轮，会同时增加 token 和工具费用；更长的回答也可能让月度开支缓慢抬升。

因此，即使重定向后的请求全部返回 200，也要按模型迁移重新验收：

1. 从真实工作流收集正常样本、边缘情况与已知失败案例；
2. 用明确指定的新型号和 reasoning effort 重跑；
3. 比较任务是否完成、结构是否有效、引用是否可靠、延迟和单次总成本；
4. 预先定义回退条件，不要一次性切完全部流量；
5. 更新成本看板和内部说明，确保显示的型号就是实际计费型号。

如果自动化将长期重复运行，这套验收比一次主观试聊重要得多。如何构建重复工作的 AI Agent 也强调，稳定性来自可观察的输入、结果与失败处理，而不是某个模型品牌。

旧 Grok 3 slug 现在怎么计费

xAI 当前 API 价格表 显示，Grok 4.3 支持 100 万 token 上下文，但会以 20 万输入 token 为价格分界。

这里最容易算错的是长上下文规则：当 prompt 达到 20 万 token 时，不是只有超出的部分变贵，而是该次请求的全部 token 使用长上下文费率。

纯文本任务可以先用「输入 token × 输入单价 + 输出 token × 输出单价」估算，再单独处理缓存输入。但生产环境不必只靠估算。xAI 的 成本追踪文档 说明，每次响应会在 usage 中返回 cost_in_usd_ticks，其中已经包含 token、服务端工具调用和缓存折扣后的实际计费。

对于规模不大的团队，这个字段比月末总账更有用。把它记录到具体客户、任务和定时运行上，才能知道一份合格交付物真正花了多少钱。

使用 X Search 时，成本不只是模型 token

Grok 与 X 同属一个生态，但 API 并不会默认知道实时事件。xAI 官方模型页明确说明，想获得当前网络信息，需要主动开启 Web Search 或 X Search 等服务端工具。

截至核对日期，xAI 公布的部分工具价格包括：

• Web Search：每 1,000 次调用 $5；
• Code Execution：每 1,000 次调用 $5；
• X Search：每抓取 1,000 条帖子 $5，每抓取 1,000 个用户资料 $10；
• Collections Search：每 1,000 次调用 $2.50。

X Search 的计费单位尤其值得注意。它可以按关键词、语义、用户或线程检索；同一条帖子在不同搜索中重复出现时，usage 计数不会自动去重。一次用户提问也可能触发多轮搜索，所以不能把「一次请求」等同于「一次工具费用」。

如果用它做舆情、竞品动态或账号监控，应限制日期范围、允许或排除的账号、最大轮次和返回规模，并保存引用和 usage 明细。涉及外部工具与自有函数时，还要提前回答 Browser Agent 的安全与权限问题，尤其是凭证、写入操作和人工审批边界。

现在应该换成哪一个 xAI 型号

旧 Grok 3 的所有任务不应该机械迁到同一型号。先区分任务，再选择候选：

只想用最小改动消除隐式跳转

优先测试 grok-4.3 并显式设置 none。这与 xAI 当前的自动转发行为一致，却把真实依赖写回配置。即使如此，也要重跑格式、工具调用和延迟测试，不能因为后端目标相同就跳过验收。

任务需要搜索、分析和可调推理

可以评估 grok-4.3 的 low、medium 或 high。推理强度不是越高越好：分类、抽取和固定格式生成通常更看重速度和一致性；复杂研究或多约束判断才可能从更高强度获益。

需要 xAI 当前旗舰通用模型

xAI 将 grok-4.7 列为当前旗舰，用于通用任务和代码，支持 50 万 token 上下文。价格表显示，在 20 万 token 以下，它的输入为 $2/百万、输出为 $6/百万；长上下文价格为输入 $4、输出 $12。只有评测证明它带来的质量提升值得这部分差价，才需要升级。

核心是 Agent 编码

可以把 grok-build-0.1 纳入候选。xAI 将它作为代码工作流选项，当前短上下文价格为输入 $1、输出 $2/百万 token。但型号标签不能代替仓库测试，仍要用真实代码库、工具权限和验收命令判断。

哪些场景值得接入 xAI API

对小团队而言，增加一家模型供应商只有在带来明确能力时才合理。

需要把 X 当作一手信息面。 X Search 能限制账号与日期，读取帖子、用户和线程，并返回引用。监控指定创始人、品牌账号或行业讨论时，这比普通网页搜索更直接。

需要联合检索 Web 与 X。 同一研究流程可以同时调用网页与 X 搜索，再把来源带回结果。适合有清晰来源要求的市场简报，而不是随意生成热点内容。

已有兼容 OpenAI SDK 的应用。 xAI 的 快速入门 展示了使用 OpenAI SDK、更换 base URL 与 API key 的接入方式。它能减少初始改造，但不保证所有字段和模型行为完全相同，回归测试仍不可省。

需要按请求核算费用。 cost_in_usd_ticks 能把费用落到一次具体任务，而不是只看团队月度总额。

希望用预付额度控制试验损失。 xAI 支持预付 credits；只开启预付、不启用额外月结额度，可以为早期测试建立更明确的预算边界。

这些理由都比「Grok 更便宜」具体。正确的接入理由应该是：某项能力解决了现有流程的问题，而且评测后的总成本可以接受。

哪些情况不值得再加一个 API

如果当前模型已经稳定完成任务，仅仅为了增加模型数量接入 xAI，通常得不偿失。新供应商意味着新的密钥、账单、限流、错误处理、政策检查和迁移周期。

出现以下情况时，先不要切换：

• 任务并不依赖 X 数据或 xAI 的特定工具；
• 没有评测集，无法定义什么叫「更好」；
• 系统无法接受型号别名和自动跳转带来的行为变化；
• prompt 经常超过 20 万 token，却从未评估检索或裁剪方案；
• 没有人监控工具调用、重试次数和每个成功任务的实际费用；
• 真正欠缺的是文件、审批、排程与交付物管理，而不是模型端点。

特别是对不写代码的用户，API key 本身不会提供任务队列、失败重试、权限审批和成果审阅。Agentic AI 工具 与裸 API 解决的是不同层次的问题。

用一条真实工作流完成迁移评估

不要只丢几个通用提示词比较回答。挑一项会真正投入使用的任务，例如「每天根据指定 X 账号与官网来源生成带引用的竞品简报」，再完成下面的闭环。

明确合格结果

写清输入来源、输出格式、必须包含的引用、最大耗时以及哪些错误必须交给人工。没有验收条件，就无法判断更高价格是否带来价值。

固定实际型号

测试配置中删除 grok-3 和不必要的移动别名，明确写出型号与 reasoning effort。只有这样，之后的结果与价格才可复现。

准备包含失败样本的评测集

除常见任务外，还要加入来源不足、帖子冲突、输出应为空和必须拒绝执行的情况。只测试顺利样本，会低估无人值守时的风险。

记录一次成功交付的总成本

保存实际计费字段、抓取的帖子与账号数量、重试、失败输出和人工返工。便宜的 token 可能被过多搜索或重复执行抵消。

专门测试 20 万 token 分界

如果真实 prompt 可能接近阈值，就分别测试两侧的费用与质量。能用检索、分段或上下文压缩解决时，不要默认把全部历史都塞进一次请求。

建立预算与行动边界

使用预付额度或明确的账单上限，限制搜索轮次和范围。任何会写入 CRM、发布内容或修改外部数据的函数，都应定义人工审批点。

把维护时间算进选择

记录接入、监控、迁移和提示词复测所需时间。如果节省的推理费用抵不过新增维护路径，切换就没有降低总成本。

对 Grok 3 搜索结果的最终答案

Grok 3 API 曾经可用，但现在已经是历史型号。继续发送 grok-3 只是在借用旧名字调用 Grok 4.3，不应据此引用旧价格、旧上下文或旧能力说明。

已有集成应尽快改成明确的当前型号，按真实样本重新测试，并把搜索工具费用纳入单次任务成本。新项目则应从 xAI 当前的 模型目录 开始选择，而不是从过时教程复制 Grok 3 配置。

如果目标是开发软件、自己掌控请求与工具循环，直接 API 很合适。如果目标只是选择合适模型完成工作，维护多家接口未必值得。Floatboat 把已支持模型放在同一个 Agent Workspace 中，文件、审阅与交付仍留在完整流程里；它减少的是集成负担，而不是假设所有模型都没有差异。