GPT-5.6 Sol 跑分更高了，为什么我的周额度反而更快见底？

我用了几天 GPT-5.6 Sol，感受真是喜忧参半。

在我的 Codex 会话中，显示的上下文预算比用 GPT-5.5 时要大——在我的环境下大约是 356K 对 250K。听起来像是个不错的升级。但实际上，我每周的额度消耗得快多了。Sol 也明显比 GPT-5.5 慢。在 Max 模式下，Sol 比 GPT-5.5 在 xhigh 模式下问的问题多得多，而 Ultra 到目前为止还不太对我的胃口。

Ultra 给我的感觉不像一个可控的工作台，倒像是推开一扇门，看到满屋子的智能体都在忙活些什么。我能看见各种活动，却感觉不到自己有一个清晰的控制界面来理解它们在做什么、随时叫停，或者判断哪些中间结果值得信任。

这种体验让我开始思考一个更大的问题：当模型公司或排行榜说某个模型更好时，到底是什么变得更好了？

核心要点速览

说法	通常意味着什么	没告诉我们的事
「1M 上下文窗口」	模型或产品在特定条件下能接受很大的最大 Token 预算	每个 Token 是否都能被有效利用、产品何时压缩上下文，以及我的额度消耗速度
「更高的 Intelligence Index」	在一组公开的智能体、编程、通用和科学评测中获得了更好的加权成绩	产品是否更快、更少打扰我、更容易操控，或者是否更适合我的具体工作流
「更高的 Agentic Index」	在指定测试框架中，多步骤工具任务的最终结果更好	系统是否使用了智能体群、是否展示了执行计划，或者是否验证了子智能体的输出
「更高的 Coding Index」	在该指数包含的编程基准测试中表现更好	完整的编程助手在代码库导航、代码审查、中断响应或成本控制方面是否更出色
「Ultra」	一种将适合的任务分配给多个子智能体的多智能体产品模式	更多的并行工作会自动带来更高的准确率或更强的可控性

我现在的结论很简单：基准分数是一份测量契约，而不是模型评测报告。如果我不知道具体的任务、工具、设置、评分标准和汇总规则，那个醒目的数字对我来说几乎毫无意义。

上下文窗口的数字其实并不矛盾

我首先需要理清自己对上下文窗口的理解。

OpenAI 当前的 API 页面将 GPT-5.6 Sol 和 GPT-5.5 的上下文窗口都标为 1.05M Token。但这显然和我在 Codex 中看到的约 356K 和 250K 不符。另外，在 OpenAI 的 ChatGPT Business 模型与限制页面中，GPT-5.6 Sol 的窗口又被记录为 272K。

这不一定是谁出错了，而是因为「上下文窗口」可能指代几个不同的层面：

层面	回答的问题	示例
模型上限	API 模型在公开限制下最多能接受多少内容？	OpenAI 目前将 GPT-5.6 Sol 和 GPT-5.5 都列为 1.05M
产品暴露窗口	ChatGPT、Codex 或工作区实际向用户开放了多少？	产品可以只开放 API 上限的一部分
会话预算	扣除系统指令、工具定义、文件、消息和输出预留后，还剩多少空间？	我在活跃编程会话中看到的数字
压缩阈值	智能体何时开始总结历史而不是继续扩展上下文？	用户配置的阈值可能远低于模型上限
有效上下文	模型在这类任务中能可靠利用多少信息？	取决于具体任务，通常小于宣传的最大值

这个区别很重要。我在 Claude Code 中使用支持 1M 上下文的模型，但会将 CLAUDE_CODE_AUTO_COMPACT_WINDOW 设置在约 300K。Anthropic 的 Claude Code 环境变量文档明确支持将 1M 模型当作较小窗口来处理自动压缩。Anthropic 的 平台发布说明也确认，支持的 Claude 模型已普遍提供 1M 上下文。

所以当我说 300K–400K 是个甜点区间时，并不是在否认模型无法处理更多内容。我描述的是一种操作偏好：有足够的空间进行认真的编程会话，但又能及时压缩，避免会话变成充斥着过时决策、旧错误和无关工具输出的垃圾场。

最大上下文不等于有效上下文

长上下文确实解决了实际问题。我不希望智能体忘记二十分钟前讨论的架构设计，不想让它反复读取相同的文件，也不想让它在修改进行到一半时丢失验收标准。

但更大的窗口也会带来三种不同的失败模式，人们常常把它们都笼统地称为「上下文腐化」：

失败模式	问题所在	实际体验
中间信息丢失	相关信息因位置不同而获得的关注度不够可靠	模型记得开头的规则和最新消息，却漏掉了夹在中间的关键决策
上下文腐化	随着输入内容增加，性能反而下降，即使答案仍在提示中	会话掌握的信息更多了，但做出的决策却更糟糕
上下文拖累	每一轮都要携带更多历史、工具输出和冲突状态	延迟更高、消耗更大，也更容易遵循过时的指令

Lost in the Middle 的研究显示，长上下文的性能会因相关信息的位置不同而显著变化。Chroma 的 Context Rot 研究则测试了输入量增长时性能下降的更广泛问题。这些研究并不能证明 300K 是普适的最佳值，但确实证明了「能装下」和「能用好」是两个完全不同的概念。

即使是 Artificial Analysis 的长上下文组件 AA-LCR，每道题测试的也是大约 10 万 Token 的跨文档推理能力。这为长文档推理提供了有用的证据，但并不能证明模型在一场包含多次编辑、失败命令和意图变化的百万 Token 编程会话中，从头到尾都能保持同样可靠的性能。

为什么我的每周额度消耗得更快

仅凭我的使用体验，无法判断 Sol 变慢究竟是因为发布初期的高需求、后端负载、模型行为，还是我自己的任务特点。OpenAI 并未公开足够的遥测数据让我区分这些因素，所以「大家都在用」只能作为一个假设。

额度消耗方面则更容易解释。OpenAI 的 Codex 定价文档指出，消耗量取决于模型选择、上下文、推理、工具使用、检索和缓存；看似相似的任务可能消耗不同的额度。文档还提到可能会有额外的每周限制。

因此，即使最终答案很短，更大的保留上下文也可能让智能体会话变得更昂贵。模型可能需要处理更多历史、进行更长时间的推理、发出更多工具调用，并反复检查更多证据。缓存输入可以让重复的前缀更便宜，但并不会让长智能体循环变成免费操作。

这就是为什么我觉得「Token 高效的模型」和「我的额度消失得更快」并不矛盾。前者是模型层面的说法，讨论的是模型在基准测试中完成任务所需的输出或推理量；后者是我整个会话的产品层面结果。

我真正关心的指标不是每个回答消耗多少 Token，而是每个被接受的结果消耗多少额度。

如果 Sol 能一次性正确完成困难的重构，更高的消耗可能是值得的。但如果它消耗更多、问更多问题、运行更慢，最终仍然需要同样的审查，那么基准测试的优势就还没有真正惠及我的工作流。

Max 和 Ultra 是不同的产品

OpenAI 的 Codex 模型指南做出了一个关键区分，这也解释了我部分的感受：

控制级别	改变的内容	最适合的场景	主要风险
Extra High / xhigh	提高所选模型的推理强度	包含多个步骤、多个信息源或复杂权衡的困难任务	延迟和消耗增加，但不一定带来明显的改进
Max	给所选模型更多时间思考单个任务	深度比速度或消耗更重要的最难单一问题	长时间的单智能体运行仍可能走上错误路径
Ultra	使用子智能体并行处理不同部分	能清晰拆分为多个独立工作流的任务	活动更多、协调开销更大、输出可能冲突，且控制更不直观

同一份文档还指出，GPT-5.5 和 GPT-5.6 的推理强度没有精确的对应关系。Max 模式改变的也不仅仅是标准的推理级别选择器。这意味着我对 GPT-5.5 xhigh 与 GPT-5.6 Max 的比较是一个有效的体验报告，但不是一个受控的模型实验。

提问频率也是如此。我注意到了这个问题，但不能仅凭几天的体验就断定 GPT-5.6 总是问更多问题。提示结构、产品指令、安全检查和任务模糊性都会影响这种行为。我能确定的是，提问频率应该纳入我的评估范围，因为每一次不必要的澄清都会打断工作流。

基准分数由什么构成

现在，在查看任何排行榜之前，我都会先关注五个层面：

层面	关键问题	为何会影响结果
工作负载	实际测试的是什么任务？	物理问题、银行客服流程和代码库补丁衡量的是完全不同的能力
测试框架	模型获得了哪些工具、提示、沙盒、记忆和轮次限制？	同一个模型在 Claude Code、Codex、Cursor 或中立框架中的表现可能不同
推理设置	使用了哪个模型快照、推理强度、温度和 Token 预算？	high 和 Max 模式下的「GPT-5.6 Sol」并不是相同的测试条件
评分标准	谁或什么来判断结果是否正确？	单元测试、数据库状态、精确匹配、评分细则和 LLM 评委都有不同的失败模式
汇总方式	任务分数如何变成headline数字？	加权平均可能会用其他方面的优势掩盖重大弱点

这通常就是那种「信我就对了」式基准测试让人不舒服的原因。基准测试本身可能是正规的，但问题在于headline图表隐藏了测量契约。

Artificial Analysis 当前所有 LLM 指数：按实用热度排序

Artificial Analysis 并未公开每个排行榜的访问量，因此无法做出精确的热度排名。以下是我截至 2026 年 7 月的实用排序：先列出网站位置最显眼、适用范围最广的综合指数；然后是跨领域的专项指数；最后的专业指数则按照 Artificial Analysis 能力导航中的顺序排列。这里涵盖了当前 12 个文本模型和编程智能体指数——不包括其独立的图像、视频、语音、音乐或硬件排行榜。

1–6：大多数人应该先了解的指数

排序	指数及构成	具体场景	高分不能证明什么
1	Intelligence Index v4.1 智能体 34%、编程 24%、科学推理 24%、通用能力 18%	创建电子表格和备忘录、解决需要工具的银行业务、完成终端任务、回答研究级科学问题，并从长文档中寻找证据	模型在每个组件中都领先、运行速度快、额度消耗少，或在我的产品中表现良好
2	Coding Index Terminal-Bench v2.1 和 SciCode 各占 50%	通过终端修复损坏的环境，或将科学算法描述转换为能通过测试的 Python 代码	完整的编程产品能理解我的代码库、审查自己的补丁，或易于中断
3	Agentic Index GDPval-AA v2 和 τ³-Banking 各占 50%	使用沙盒和网络工具制作专业交付物，或搜索政策并执行正确的多步骤账户工作流	产品使用了智能体群、委派效果好，或验证了子智能体的输出
4	Coding Agent Index v1.1 DeepSWE、Terminal-Bench v2 和 SWE-Atlas-QnA 的等权平均	阅读代码库、实施长期变更、操作终端，并回答有关代码库架构的问题	底层模型单独获得了这个成绩；智能体框架、模型和设置都是被测变体的一部分
5	Multilingual Index 覆盖 16 种语言的 Global-MMLU-Lite	不仅用英语，还能用中文、印地语、阿拉伯语、约鲁巴语或缅甸语回答等价的通识和推理问题	高质量翻译、本地化语调、长文写作、文化安全建议或多语言工具使用
6	Openness Index 模型访问和授权的 0–100 分评分，加上训练数据和方法透明度	判断我能否下载权重、商业使用、检查披露的数据，并复现或审计训练方法	智能程度、安全性、事实准确性，或「开放权重」意味着完全开放的数据和训练代码

7–12：专业领域指数

这些行业指数重复使用了许多相同的底层基准测试，然后根据类似 O*NET 的职业能力图谱，按各项能力在该领域中的出现频率进行加权。它们是有用的筛选信号，而非专业认证。

排序	指数及权重	具体场景	高分不能证明什么
7	Finance & Accounting 商业知识 30%、智能体工作 30%、推理 20%、客户互动 10%、长上下文 5%、非幻觉 5%	阅读财务文件、建立估值和敏感性模型、核对数据，并制作投资或管理备忘录	每个公式都经过审计、市场数据是最新的，或工作符合我的司法管辖区和内部控制要求
8	Strategy & Ops 商业知识 30%、智能体工作 30%、客户互动 30%、指令遵循 5%、长上下文 5%	将运营数据、政策文件和利益相关者需求转化为人员配置计划、流程变更和完整的办公室工作流	良好的组织判断力、政治可行性、员工采纳度，或在我系统中的可靠执行
9	Legal 法律知识 35%、智能体工作 25%、推理 15%、长上下文 10%、非幻觉 10%、客户互动 5%	审查合同和判例资料包、识别冲突的权威、起草备忘录，并避免编造引用	掌握我所在司法管辖区的现行法律、保护特权信息、引用有效性，或无需律师即可安全提交的工作
10	Healthcare & Medical 医学知识 35%、智能体工作 25%、非幻觉 15%、推理 15%、客户互动 10%	结合症状、病史、药物和指南形成临床推理摘要，然后协调电子病历或药房工作流	诊断、安全的个体化治疗、监管批准，或替代临床审查
11	Engineering 工程知识 35%、推理 35%、智能体工作 25%、终端使用 5%	根据疲劳和极端载荷设计风力涡轮机支撑结构、论证安全裕度，并自动化计算	设计经过仿真、独立检查、符合规范、可制造，或可签字批准
12	Economics 经济学知识 35%、推理 35%、智能体工作 15%、长上下文 15%	估算关税的归宿和弹性效应、量化福利权衡，并综合相互冲突的研究	数据、因果假设、预测或最终政策建议对现实经济有效

有一个历史细节值得一提。Artificial Analysis Data API 页面仍然提到了 Math Index 字段，但当前的 Intelligence 方法说明 MATH-500 和 AIME 2025 已退出主动报告。除非 Artificial Analysis 恢复实时的方法论和排行榜，否则我会将 Math 视为遗留/API 字段，而不是第十三个当前的公开指数。

Artificial Analysis Intelligence Index：一个组合，而非单一测试

截至 2026 年 7 月，Artificial Analysis Intelligence Index v4.1 结合了九项评测。类别权重为：智能体 34%、编程 24%、科学推理 24%、通用能力 18%。

因此，Intelligence Index 分数既不是「对一个难题的深度推理」，也不是「智能体群的编排」。它是一个组合：

类别	包含内容	通俗场景
智能体 — 34%	GDPval-AA v2 和 τ³-Banking	根据提供的材料创建专业文件，或通过查找政策并进行正确的工具介导账户变更来解决银行业务
编程 — 24%	Terminal-Bench v2.1 和 SciCode	完成多步骤终端任务，或编写能通过测试的科学 Python 代码
科学推理 — 24%	Humanity's Last Exam、GPQA Diamond 和 CritPt	解决科学和研究物理领域的困难专家级问题
通用能力 — 18%	AA-LCR 和 AA-Omniscience	跨长文档推理、回答事实问题，并在不确定时不胡猜

这比单一的学术选择题分数有用得多。但这也是一个编辑选择。Artificial Analysis 在 v4.1 中增加了智能体任务的权重。一个模型可以在headline指数上有所提升，主要是因为它在工具使用任务上表现更好，即使它在最难的单一科学问题上的改进较小。

底层基准测试的实际体验

基准测试	通俗解释	如何验证成功
GDPval-AA v2	完成 44 个职业中的一个现实专业任务并提交可用文件	盲测评分，转换为以人类专家工作为基准的 Elo 评分
τ³-Banking	搜索大型银行政策库、与模拟用户对话，并执行正确的账户工作流	最终后端数据库状态，多次尝试的平均值
Terminal-Bench v2.1	操作真实终端完成软件、系统管理、数据、训练或安全工作	任务特定测试，通过或失败
SciCode	将科学问题描述转换为可工作的 Python 代码	代码执行和单元测试
AA-LCR	从约 10 万 Token 的长文档中寻找并组合分散的证据	答案等效性评分器
AA-Omniscience	回答 42 个知识主题的问题，但在不确定时选择放弃而非编造	准确率加上独立的非幻觉组件
Humanity's Last Exam	回答横跨科学、数学和人文学科的困难专家编写问题	答案相等性，pass@1
GPQA Diamond	解决非专家通常会错过的研究生级生物、物理和化学问题	四选项选择题，pass@1
CritPt	解决未发表的研究级物理挑战	通过官方服务器进行数值、符号或 Python 函数评分

现在，headline Intelligence Index 有了具体的形状。如果我的工作是合同审查、客户支持、代码库维护或科学研究，我就不应该同等重视每个组件。

Coding Index 不等于 Coding Agent Index

这种命名确实容易让人困惑，这是完全可以理解的。

Artificial Analysis Coding Index 是一个模型能力指数。它将 Terminal-Bench v2.1 和 SciCode 等权重结合。通俗地说：模型能否在终端中操作，能否生成正确的科学代码？

而独立的 Artificial Analysis Coding Agent Index 则评估编程智能体变体在 DeepSWE、Terminal-Bench v2 和 SWE-Atlas-QnA 上的表现。其场景包括长期代码库变更、终端执行，以及需要理解代码库才能回答的问题。Artificial Analysis 甚至会展示在固定模型的情况下，比较 Claude Code、Cursor CLI 和 OpenCode 等产品的测试框架差异。

如果我想知道……	应该看……
原始模型能否解决终端和科学编程问题？	Coding Index 及其两个组件
配置好的编程智能体能否制作补丁、使用终端并理解代码库？	Coding Agent Index 和各基准测试的详细分解
Codex 在我的订阅中是否会感觉快速、可控且经济？	仅靠这两个指数都不够；我需要产品和工作负载的实际测量数据

Coding Agent Index 更接近我的日常体验，但它仍然无法衡量我能否干净地中止智能体群、UI 是否解释每个工作者在做什么，或者我多久会达到每周限额。

Agentic Index 不意味着 Swarm Index

Artificial Analysis Agentic Index 是 GDPval-AA v2 和 τ³-Banking 的等权重组合。它衡量规划、工具使用、自主性、专业交付物、知识检索、客户互动和最终任务完成。

这些都是智能体技能，但并不需要智能体群。

Artificial Analysis 通过其开源 Stirrup 测试框架运行 GDPval-AA。一个模型获得工具和沙盒，在任务中工作，并提交交付物。该基准测试可以告诉我，某个模型加测试框架在完成这类工作方面是否更好。但它并不能告诉我该模型是否是一个强大的多智能体编排器。

智能体群的好坏取决于其控制循环

我对编排问题的回答是肯定的：工作者模型的选择确实重要。但它只是系统中的一个因素。

阶段	可能的失败点	良好的控制表现
任务分解	编排器沿错误边界分割任务	独立的作用域、明确的输入、明确的验收标准
工作者执行	工作者误解其任务或缺乏能力	适合任务的模型选择和有限的工具
结果聚合	父智能体在未注意到的情况下合并了不兼容的答案	冲突检测、来源追踪和结构化交接
验证	系统将自信的工作者输出视为证据	测试、模式、独立审查、源检查和可重现的命令
恢复	一个失败的分支污染最终答案或导致无限重试	可见的失败状态、重试限制、取消和回滚
人工控制	用户无法看到成本、进度，或不知道智能体群为何选择某个方向	预算、检查点、暂停/停止控制和可审查的产物

父智能体总结五个工作者的响应并不是验证。父智能体通过测试、证据、模式或独立审查来检查这些响应才是验证。

基准测试在这里又增加了混淆。Terminal-Bench 的测试、τ³-Banking 的数据库检查和 GDPval-AA 的评委小组验证的是基准测试结果。它们并不能证明智能体或智能体群在提交前内部验证了自己的工作。

这个区别对我很重要。我不仅希望最终答案在外部评委检查后通过。我还希望操作系统能展示足够的证据，让我在运行过程中就能信任、中断和修复它。

那些热门但不是指数的排名

模型页面还按速度、延迟、价格、上下文和效率对模型进行排名。这些列与我的 Sol 体验相关，但它们并没有将多个能力基准测试组合成一个指数。

排名	衡量内容	回答的具体问题示例	常见误解
输出速度	生成开始后每秒接收的答案 Token 数；当前默认性能工作负载使用约 1 万输入 Token	Sol 开始回答后，可见文本出现的速度有多快？	快速输出并不意味着答案开始前的等待时间短
首 Token 时间	从 API 请求到第一个流式 Token 的秒数	多久能看到任何活动？	对于推理模型，第一个 Token 可能是思考过程而非答案
首答案 Token 时间	输入处理时间加上隐藏或可见推理，直到第一个答案 Token	多久能收到有用的答案文本？	它仍然不包括完成响应或智能体工作流的时间
端到端响应时间	接收 500 Token 答案的估计秒数，包括输入、推理和生成时间	哪个 API 能更快返回中等长度的答案？	它不是十分钟编码任务从提示到审查结果的总时间
每百万 Token 价格	公布的 API Token 价格，通常显示为缓存/输入/输出的混合费率	在指定的 Token 组合下，原始 API 流量的成本是多少？	它不是订阅的每周额度或每个成功结果的成本
每项指数任务成本	观察到的基准测试 Token 使用量乘以相关的输入、缓存、推理和答案价格	模型的平均基准测试工作负载有多昂贵？	「平均任务」可能与我的代码库或提示完全不同
每项指数任务时间	每项任务的加权输出 Token 除以输出速度；不包括 TTFT 和测试框架开销	解码指数典型输出需要多长时间？	它不是真实的墙钟完成时间
每项指数任务输出 Token	平均每项指数任务产生的加权推理和答案 Token	哪个模型花费更多生成的 Token 来达到其分数？	更少的 Token 并不自动意味着更便宜、更快或更好
上下文窗口	模型报告的最大输入和输出 Token 限制	这个请求能否容纳？	它不衡量有效回忆、上下文腐化、产品压缩或额度使用

我应该关注哪个数字？

我的工作负载	有用的公开信号	我仍需自行测试的内容
一个非常困难的科学或推理问题	HLE、GPQA Diamond、CritPt，加上所选的推理设置	我的领域的准确性、延迟，以及引用是否能通过审查
科学或算法代码生成	Coding Index，特别是 SciCode	我的语言、库、测试和可维护性
大型代码库变更	Coding Agent Index，特别是 DeepSWE 和 Terminal-Bench	代码库约定、回归率、审查时间，以及从失败命令中恢复的能力
客户支持自动化	Agentic Index，特别是 τ³-Banking	我的政策、防护措施、升级规则和真实后端状态
长篇报告、财务文件或法律包	AA-LCR 和相关专业指数	在我的文档长度下的证据回忆能力和引用准确性
必须承认不确定性的事实助手	AA-Omniscience 的准确性和非幻觉性	我的权威来源和弃权政策
多智能体编码智能体群	没有单一的 headline 指数	任务分割、重复工作、冲突、验证器覆盖率、停止行为、总成本和接受结果率

我真正想要的 Sol 评分卡

经过几天的使用，我还没有足够的数据来宣布 GPT-5.6 Sol 在我的工作中比 GPT-5.5 更好或更差。但我对应该记录什么有了更好的想法：

• 接受结果率：我无需重大修复就能接受工作的频率。
• 端到端时间：从提示到审查结果的时间，而不是每秒输出 Token 数。
• 每个接受结果的额度消耗：任务消耗了多少五小时和每周额度。
• 干预负担：澄清问题、权限暂停、纠正和重启的次数。
• 上下文持久性：早期约束和决策是否仍能影响后期工作。
• 控制能力：我能否看到进度、限制范围、停止分支，并理解发生了什么。
• 验证能力：系统是否产生了测试、证据和可审查的产物，而不是自信的总结。

这张评分卡可能与公开排行榜不一致。这没关系。排行榜在回答它的问题，我在回答我的问题。

我认为 LLM 的发展方向

我不认为方向仅仅是「让单一模型更聪明」。三个方向正在同时演进：

1. 单一模型在推理、编程、工具使用和判断重要性方面变得更好。
2. 运行时在上下文管理、缓存、压缩、权限和恢复方面变得更好。
3. 产品在编排方面变得更好：子智能体、专家、并行工作、评委和验证器。

基准测试也在朝同一方向发展。Artificial Analysis v4.1 在其 Intelligence Index 中给予智能体工作最大的类别权重。编程智能体排行榜越来越多地比较测试框架，而不仅仅是模型名称。这是合理的，因为有用的单元正变得越来越像一个系统。

但行业仍然过于急切地将系统重新压缩成一个数字。

我目前对上下文的看法仍然是，300K–400K 是长时间编码会话的舒适操作范围。我目前对 Ultra 的看法是，在获得更清晰的控制循环之前，我不想要更多的智能体。而我目前对 GPT-5.6 Sol 的看法是复杂的：我能看到能力的发展方向，但速度、限制、问题数量和可控性也是能力的一部分。

当基准测试说一个模型更强时，它并没有撒谎。它只是在回答一个比大多数人以为自己在问的更窄的问题。