GPT-6.1 Sol 只卖旗舰五分之一，开发者该算清哪几笔账

OpenAI 在 9 月 29 日的 DevDay 上发布了 GPT-6.1 Sol。据多家媒体报道，它把标准 API 价格定在每百万输入 token 2 美元、输出 10 美元，缓存输入 0.10 美元——大约是其旗舰 GPT-6 Astra 的五分之一。Astra 的定价是输入 10 美元、输出 50 美元。同时，谷歌在 9 月 30 日发布了主打编程与网络安全的 Gemini 4 Argon。一周之内，头部厂商把"前沿能力"和"低价"这两件事摆上了同一张桌子。

对我来说，这轮发布的重点不是又多了几个跑分，而是大模型的计价方式在变，而这直接决定普通团队能不能把 Agent 跑起来。

变的是什么：计价从"按量"走向"按缓存"

先把事实摆清楚。据报道，GPT-6.1 Sol 的 API 模型 ID 是gpt-6.1-sol，上下文窗口约 105 万 token，单次最大输出 12.8 万 token。几种模式的单价大致如下（单位：美元/百万 token）：

最值得注意的是缓存输入只要 0.10 美元，比标准输入便宜 95%。对单轮问答这点差别不大，但对 Agent 这种"一个任务里反复带上同一大段上下文"的用法，差别是数量级的。另外据报道，单次请求输入超过 27.2 万 token 时，整次请求按 2 倍输入、1.5 倍输出计费；这轮促销价至少持续到 2026 年 11 月 21 日。

没变的是什么？模型能力的上限依然由旗舰模型把持。据报道，在最难的研究任务上，OpenAI 仍推荐用 Astra；Sol 的定位是"接近旗舰、但便宜得多"。它的价值不在登顶，而在把可用的智能压到能规模化的价位。

算一笔真实的账

不要被"每百万 token 两美元"这种数字骗了，Agent 的成本是乘出来的。下面这段代码可以直接跑，按官方单价估算一轮任务的成本：

# 按公布单价估算单次调用成本（单位：美元）PRICE={"sol":{"in":2.00,"cached_in":0.10,"out":10.00},"astra":{"in":10.00,"cached_in":1.00,"out":50.00},"opus_5_5":{"in":4.00,"cached_in":0.20,"out":20.00},}defcost(model,in_tok,cached_tok,out_tok):p=PRICE[model]return(in_tok/1e6)*p["in"]\+(cached_tok/1e6)*p["cached_in"]\++(out_tok/1e6)*p["out"]# 假设一轮 Agent：10 万输入，其中 9 万命中缓存，1 万输出print("sol :",round(cost("sol",100_000,90_000,10_000),4))print("astra :",round(cost("astra",100_000,90_000,10_000),4))print("opus :",round(cost("opus_5_5",100_000,90_000,10_000),4))

跑一遍就能看到，同样一轮任务，缓存命中和不命中之间差着一大截。据报道，在 Terminal-Bench Science 0.1 这类科研评测上，Sol 单任务平均成本约 5.47 美元，而 Opus 5.5 约 23.21 美元、Astra 约 23.80 美元。差距主要就来自单价和缓存的组合。

对从业者意味着什么

第一，先分清"能力需求"和"成本需求"。复杂架构设计、跨模块调试，仍然该用能扛住的模型；批量生成、跑测试、写文档这种重复劳动，完全可以用便宜档位。用同一个贵模型跑完整个流水线，是最容易烧钱的用法。

第二，缓存要主动设计。把系统提示、代码库摘要、工具定义这些不变的部分放在前面并固定下来，让它们命中缓存，成本能掉一个台阶。这是工程问题，不是模型问题。

第三，注意"长上下文罚金"。超过阈值后按倍率计费，意味着把整个仓库塞进去未必划算，分块检索可能比一次性长输入更省。

第四，别只看价格表。据报道，Sol 目前只在 ChatGPT Work 和 Codex 中对 Plus 及以上付费用户开放，普通 Chat 用不了；是否存在限速、并发限制，要看具体账户条款。开通前先用小额流量实测，再决定是否迁移。

收尾

这一轮的价格战，本质是把"能用得起"这件事往前推了一大步。但便宜的模型不等于省钱，计价模式越复杂，越考验工程上的取舍。你的项目现在是按能力选模型，还是按成本选模型？评论区聊聊。