Grok 4.5 是 xAI 面向编码、Agent 和知识工作的模型,模型名为 grok-4.5。如果你的项目已经使用 OpenAI SDK,可以通过把 baseURL 指向 https://api.x.ai/v1 来调用它;新项目则可选择 xAI SDK、OpenAI SDK 兼容方式或直接请求 REST API。
这篇文章只讨论 API 接入。Grok Build、Cursor 和 Office 插件中的模型可用性,与 API Console 的地区、账号和计费状态并不完全等同,排错时不要混为一谈。
接入前先确认三件事
开始前需要:
- 在 xAI API Console 创建 API key,并将其保存在环境变量
XAI_API_KEY中。 - 确认目标账号可以使用 API Console;截至官方文档更新时,EU 用户尚不能在 API Console 中使用 Grok 4.5,官方预计在当月稍后提供。
- 明确你要用的是 Responses API 还是 Chat Completions。新接入优先用 Responses API;已有基于
chat.completions的项目可以先保持现有接口,再单独加入缓存路由设置。
不要把 API key 写进前端 JavaScript、客户端应用或 Git 仓库。浏览器、移动端和桌面客户端应先请求自己的后端,再由后端调用 xAI API。
Grok 4.5 的价格与能力范围
官方文档列出的基础文本价格如下:
| 项目 | Grok 4.5 |
|---|---|
| 输入价格 | $2.00 / 1M tokens |
| 输出价格 | $6.00 / 1M tokens |
| 推理强度 | Low、Medium、High,默认 High |
| 支持接口 | Responses API、Chat Completions |
| 可搭配工具 | Function Calling、Web Search、X Search、Code Execution |
价格表不是最终账单。实际成本还会受到输入长度、输出长度、推理强度、工具调用、缓存命中、速率限制和团队定价的影响。先用小流量记录输入、输出与缓存 token,再决定是否提高推理强度或扩大并发。
用 OpenAI SDK 调用 Responses API
如果项目已安装官方 openai Python SDK,可以按下面方式接入。关键是保留 base_url="https://api.x.ai/v1",并将模型名写成 grok-4.5:
|
|
等效的 HTTP 请求是:
|
|
请求返回错误时,先检查 API key、base_url、模型名和账号地区,再检查限额或组织级策略。不要因为模型不可用就把密钥改写到代码文件中反复测试。
为什么要设置 prompt_cache_key
长对话、代码库分析和 Agent 循环经常重复发送系统提示词、工具说明和历史上下文。xAI 的缓存按服务器保存;如果同一会话请求没有稳定地路由到同一台服务器,就可能落到缓存冷的服务器并按完整输入计费。
在 Responses API 中,应把 prompt_cache_key 作为请求体字段传入。对于同一段连续会话,使用稳定、不可预测且不含敏感原文的标识,例如服务端生成的 UUID:
|
|
这个键的作用是让同一会话更稳定地路由到同一服务器,从而提高缓存复用机会;它不是把所有请求强行合并成一个对话,也不能代替你保存自己的会话状态。需要隔离的用户、项目、租户或任务,应使用不同的键。
Chat Completions 不是同一个字段
已有项目如果继续使用 Chat Completions,不要把 prompt_cache_key 直接照搬过去。该接口使用 HTTP 请求头 x-grok-conv-id:
|
|
两种接口的目的一样:让同一会话尽量命中同一服务器缓存。字段位置不同是常见错误来源:Responses API 用请求体 prompt_cache_key,Chat Completions 用 x-grok-conv-id 请求头。
缓存键怎样设计才不会失效
可以把缓存键视为“同一可复用上下文”的服务端路由标签。推荐策略:
- 一个用户在一个明确会话中的连续请求共用同一个键;
- 更换项目、模型、系统提示词版本或权限范围时生成新键;
- 用数据库 ID、随机 UUID 或经过哈希处理的内部会话 ID,不直接拼接邮箱、提示词原文或客户数据;
- 在应用日志中记录键的短摘要和缓存 token,而不是记录完整密钥或完整用户输入;
- 观察
cached_tokens,用真实命中情况判断设计是否有效。
如果每一轮都生成新 UUID,或把同一用户所有不相关任务都塞进一个键,都会削弱缓存策略的价值。前者很难复用,后者则会让调试、隔离和成本归因变得混乱。
EU 与多地区部署怎么处理
官方文档说明,Grok 4.5 在 API Console 对 EU 用户仍未开放,预计在当月稍后推出。因此,面向多地区用户的产品应把地区可用性作为启动检查的一部分:
- 在后端创建调用前确认账号和部署地区是否具备访问资格。
- 对不具备资格的地区返回清晰的功能不可用提示,而不是无限重试。
- 不要通过代理、共享账号或伪造地区信息绕过服务限制。
- 为关键流程准备已获授权的替代模型或人工处理路径,并在上线前测试降级行为。
EU 是否已经开放、具体价格和限额都可能变化。发布到生产环境前,应以 API Console、模型详情页和最新定价页为准,而不是只依据本文的发布时间。
常见接入问题
返回 401 或 403
优先检查 XAI_API_KEY 是否真正注入运行环境、请求是否发往 https://api.x.ai/v1,以及账号是否具备 API Console 和地区访问资格。不要在错误日志里打印 Authorization 头。
缓存 token 一直是 0
确认连续请求使用相同的 prompt_cache_key,并且字段放在 Responses API 请求体中;若使用 Chat Completions,则检查 x-grok-conv-id 头。缓存命中也受上下文与服务端路由影响,不能只通过一次短请求判断策略失败。
成本比预期高
先拆分输入、输出和缓存 token,检查是否默认使用了 High 推理强度、是否重复发送长上下文、是否工具调用过多,再调整提示词、会话切分和缓存键。不要仅凭总账单猜测是模型单价问题。
总结
接入 Grok 4.5 的最短路径是:在后端保存 XAI_API_KEY,将 OpenAI SDK 的 base_url 指向 https://api.x.ai/v1,用 grok-4.5 调用 Responses API,并为同一连续会话设置稳定的 prompt_cache_key。对已有 Chat Completions 项目,则使用 x-grok-conv-id。上线前再核对 EU 可用性、实时价格、限额与缓存 token,才能把示例调用变成可控的生产工作流。
官方资料: