Grok API 模型：价格、上下文与工具调用

Grok API 型号怎么选

先选择最有可能满足任务的最小型号，再用同一批任务与一个更高能力候选比较，最后根据通过结果质量、延迟、可靠性和总成本决定。

• 编码、知识工作和需要大上下文的工具型 Agent 可优先测试 Grok 4.6。
• 交互任务先用 low 或 medium；只有质量提升足以覆盖延迟和输出成本时才使用 high 或 xhigh。
• 简单分类或抽取若测试无明显收益，应选择更轻量的路由。

Grok API 支持哪些能力

• 通过 Responses 与 Chat Completions API 接收文本和图片，并输出文本。
• 500K 上下文适合大型代码库、长文档和较长的 Agent 历史。
• 公开工具包括函数调用、网页搜索、X 搜索与代码执行。
• 推理强度支持 low、medium、high、xhigh，文档默认值为 high。

Grok 价格与上下文应该怎么看

不要只比较输入单价。还应计入输出、缓存读写、长上下文档位、推理 Token、工具调用、重试，以及每轮重复发送的历史内容。

• 长时间 Agent 循环可使用 prompt_cache_key 或 Chat Completions 会话 Header 提升缓存命中稳定性。
• 接近 500K 前应压缩或总结上下文，不要持续重发无限增长的完整历史。
• 实时互联网或 X 信息必须启用对应搜索工具；基础模型本身不是实时数据源。

Grok 适合哪些工作负载

• 多文件编码、调试和仓库分析。
• 结合网页搜索、X 搜索与结构化工具的研究 Agent。
• 跨大量资料的长篇知识工作。
• 需要代码执行与函数调用的多步骤流程。

Grok API 限制与迁移风险

• 达到厂商长上下文阈值后，请求价格会翻倍；需确认所选路由如何计费。
• 图片输入受格式和大小限制，上线前应验证预处理流程。
• 新版 Grok 并不支持所有旧采样参数，包括 log probabilities。

从型号研究进入实际调用

先打开上方具体型号页查看厂商模型 ID，再到模型广场确认当前 API Key 可用的模型 ID。把 ID 保存在配置中，方便审查、测试和回滚，而不必重写应用。