grok-4.5旗舰模型xAI 的旗舰模型，500K 上下文。强在 agentic 表现和 token 效率，成本明显低于同级竞品。默认会返回思维链，且思维链计入输出 token
模型与协议
配置之前，先搞清楚你面对的是什么。这一页解释常见的模型名到底指什么，以及网关的协议端点分别能驱动哪些工具。
第三方网关上常见的 Grok 模型名
grok-4.5-build不是独立模型xAI 从未发布过这个型号。Grok Build 是 CLI 工具的名字，底层驱动它的模型就是 grok-4.5。网关返回这个名字，通常说明上游对接的是 Grok Build 链路而非纯 API
grok-composer-2.5-fast编码 Agent 模型xAI 的 Composer 2.5，专用于长时程编码任务，强在长指令跟随和工具调用。响应快，不产生思维链 token，跑批量任务更省
网关的三套协议
很多中转网关会同时实现多套协议。搞清楚它支持哪些，就知道同一个密钥还能驱动什么工具。用 curl 打一下就能确认。
| 端点 | 协议 | 可驱动的工具 |
|---|---|---|
/v1/chat/completions | OpenAI Chat Completions | Grok Build、Chatbox、Cline 等绝大多数客户端 |
/v1/messages | Anthropic Messages | Claude Code（设 ANTHROPIC_BASE_URL 即可） |
/v1/responses | OpenAI Responses | Codex（config.toml 里 wire_api = "responses"） |
当模型名和实际后端对不上
这是中转网关的常态，值得单独说一说。我们实测遇到过：请求 grok-4.5，响应里的 model 字段返回 grok-4.5-build；请求某个 Composer 模型，模型自报家门却是另一个完全不同的编号。
这说明网关内部可能做了模型映射或替换。含义很直接——不要完全信任模型名与真实后端的对应关系。如果你的代码里有校验响应 model 字段的逻辑，它大概率会对不上，需要放宽。跑重要任务之前，自己抽查一下模型的真实身份。
后端可能无预警变更
我们观察到某网关在十几分钟内，把 /v1/models 返回的内容从一批 Claude 模型换成了 Grok 模型，期间推理请求全部返回 503。这类中转不受你控制，不要把关键工作流绑死在上面。
思维链会计进你的账单
grok-4.5 默认返回 reasoning 内容，并且这部分计入 completion_tokens。实测问一句「1+1 等于几」，正文只有五个字，却消耗了 131 个输出 token，其中 125 个是思维链。
跑批量任务时这个差距会被放大。如果不需要深度推理，把 default_reasoning_effort 调低，或者换用不产生思维链的模型。