Grok 4.7 与 Claude Fable 5.1：基准测试解读、Token 成本计算与路由策略

两款前沿模型相隔三周发布。Claude Fable 5.1 于 2026 年 9 月 1 日上线，Grok 4.7 于 2026 年 9 月 21 日上线。它们瞄准的目标并不相同。Fable 5.1 围绕长程推理和能够持续运行数小时的智能体构建；Grok 4.7 则围绕编码、智能体工作及性价比构建。

核心数据差异显著：

• Grok 4.7：50 万上下文，grok-4.7，输入单价 $2/百万 token，输出单价 $6/百万 token，缓存输入 $0.50/百万 token。
• Claude Fable 5.1：100 万上下文，claude-fable-5-1，输入单价 $10/百万 token，输出单价 $50/百万 token，缓存读取 $0.25/百万 token。

在基础费率下，Grok 的输入成本低 80%，输出成本低 88%——尽管其上下文窗口仅为对方的一半，且基准测试表上的表现大致平分秋色。以下是我的解读。

规格参数表，剔除营销话术

Grok 4.7 基于比 Grok 4.6 更大、更新的基础模型运行，其强化学习（RL）训练周期更长，并侧重于需要耗时数小时的任务。发布说明还强调了更好的自我验证和长上下文管理能力——这两点在智能体循环中才能切实感受到，而在演示中往往看不出来。

Fable 5.1 旨在服务于多步研究、文档密集的专业工作以及能够在长时间会话中持续运行的智能体。

基准测试表大致平分秋色

以下所有内容均源自 xAI 发布的对比表格中的厂商报告数据。Grok 4.7 以“xhigh”级别测量；Fable 5.1 以“max effort”级别测量。xAI 单独指出 Grok 的 DeepSWE 成绩属于高努力级别。

• 由 xAI 标记为高努力级别。

编码能力

这是比较中最模糊的部分，这也正是你不应该仅凭单一数字做选择的原因。Fable 5.1 在 CursorBench 4.0 中以 5.5 分的优势胜出。Grok 4.7 在 DeepSWE v1.1 中以 1 分的优势领先。Terminal-Bench 4.0 则是悬殊差距：57.9% 对 38.0%，19.9 分的差距直接映射出模型在无监督情况下驱动终端 shell 所能花费的时间长短。

我的解读：仓库级编辑能力的胜负难分，如同抛硬币。但终端自主性并非如此。如果你的智能体每次要在 PTY（伪终端）中连续运行 45 分钟，那么这 19.9 分的差距就是两张表中最重要的决定性指标。

知识工作并非单一能力

同一份厂商表格显示，Grok 在 EEBench（工程领域，+7.6）和 Harvey Legal Agent（法律领域，+12.9）上领先，而 Fable 则在 HealthBench Professional（医疗领域，+5.4）上领先，并以 21 分的优势微弱领先 AA Briefcase v1.1。法律、医学、工程和办公自动化各自施加了不同的工具界面和不同的推理需求。不存在一个能在“专业工作”这一类别中全面获胜的模型。

Token 数学计算才是最终决定因素

计算示例——1000 万输入 token 加上 200 万输出 token，无缓存：

• Grok 4.7：输入 $20 + 输出 $12 = $32
• Fable 5.1：输入 $100 + 输出 $100 = $200
• 名义差距：每次运行相差 $168

在生产环境中，有两个需要注意的陷阱。首先，Grok 4.7 的 $2/$6 是基础费率；SpaceXAI 的文件指出，一旦请求超过 200K token，定价会更高。其次，Fable 的 $0.25/M 缓存读取费用只有在你的提示词前缀在多次调用中确实保持稳定时才相关——在你相信自己的成本估算之前，请先检查你的缓存命中率。上述计算未包含工具费用、区域溢价和缓存写入费用。

唯一值得追踪的成本指标是“每个通过验收结果的单位成本”。一个每 token 成本高 6 倍但能消除一次重试循环并减少 20 分钟人工审查时间的模型胜出，而一个从未通过你验收测试的廉价模型反而是最昂贵的选项。

推理控制在不同厂商之间不可比

Grok 提供低、中、高、超高（xhigh）四个等级。Fable 使用带有努力程度控制的自适应思考。名称看似重叠，行为却截然不同。将“高”对应到“高”并不是受控实验——保持任务、工具和验收标准不变，让每个模型自行选择其努力级别，否则你测量的只是标签语义。

上下文窗口是另一个结构性差异：1M vs 500K。这对于整个代码库的工作、法律取证、科学语料库以及携带长历史记录的智能体来说很重要。但对于大多数任务而言并不重要，为那些你永远不会使用的冗余容量支付 5 倍的输入费用是一种浪费。

Grok API 的工具包括函数调用、网络搜索、X 搜索和代码执行作为原生工具。Anthropic 侧没有 X 搜索的等效功能。Fable 的工具行为取决于你在其中运行它的 Claude 环境或应用栈。

路由而非选择

这里有趣的架构不是挑选赢家，而是默认路由加上可衡量的升级路径。我将策略明确配置在配置文件中，以便从生产日志中进行审查和调整：

ROUTES = {
    "default": {
        "model": "grok-4.7",
        "reasoning": "high",
        "price": {"in": 2.0, "out": 6.0, "cached_in": 0.50},  # 每百万 token，<=200K prompt
    },
    "escalate": {
        "model": "claude-fable-5-1",
        "price": {"in": 10.0, "out": 50.0, "cache_read": 0.25},
    },
}

def escalate(task, attempt):
    # 仅基于可衡量的触发条件 —— 避免基于直觉的路由
    return (
        attempt.tokens_in > 200_000          # 超出 Grok 的基础定价层级 / 上下文压力
        or not attempt.passed_acceptance_test
        or task.needs_long_terminal_execution
        or task.cost_of_error > RETRY_BUDGET
    )

def route(task):
    attempt = call(ROUTES["default"]["model"], task)
    if escalate(task, attempt):
        attempt = call(ROUTES["escalate"]["model"], task)
    log_attempt(task, attempt)  # 是否通过？token数、延迟、重试次数、工具失败情况
    return attempt

如果你希望在一个集成层跨提供商进行整合，而不是使用两个 SDK 和两个计费仪表板，CometAPI 在后端通过单一端点同时暴露 grok-4.7 和 claude-fable-5-1 —— 当上述路由器成为实际的产品决策时，这非常有用。

记录触发条件 alongside 结果，否则策略永远无法改进。每条路由的关键指标包括：通过率、总 token 数、缓存命中率、端到端延迟、工具失败计数、重试次数、人工修正时间。

在信任任何数据之前，先确保基准测试的规范性

• 版本漂移。CursorBench 3.2.0 和 4.0 是不同的测试。不要跨版本比较。
• 努力设置。Grok 的 xhigh 与 Fable 的 max 并非相同的旋钮，且 Grok 自身的 DeepSWE 行被标记为高。
• 测试框架和工具访问权限。Terminal-Bench 的分数会随着围绕模型的脚手架、权限和安全防护配置而变化。
• 厂商报告值 vs 复现值。上述所有数字均来自某一家厂商的表格。用它来形成假设，而不是用来做出发货决策。

然后在你的代码仓库上运行这两个模型，使用你自己的工具，在你的时间预算和验收标准下，进行足够多次的重复试验，以将模型行为与任务差异区分开来。

选择 Grok 4.7 的场景：当 token 成本驱动单位经济效益时，例如高容量的编码助手、批量知识处理、后台自动化、其领域结果与你的工作负载相匹配的工程代理，以及任何受益于原生网络加 X 搜索的应用。

选择 Claude Fable 5.1 的场景：当失败代价高昂时，例如多小时的自主编码、重度依赖终端的代理、非常大的代码库或文档集、在多个步骤中保持状态的专业代理，以及重试成本高于推理成本的流程。

没有哪个模型是通用的赢家，任何声称相反的文章都是在向你推销排行榜，而不是成本模型。从默认的升级路由策略开始，测量每个被接受任务的成本，并让生产日志来推动边界的移动。

最初发布于 cometapi.com