编辑判断：把默认路由与难题路由分开
如果团队已经使用 GPT-6.1 Sol，Terra 更值得被视为新的日常执行选项。日常文档处理、屏幕理解和重复操作可以先交给 Terra；涉及多模块重构、隐蔽依赖和复杂调试的任务，则让 Sol 参与验收或承担首轮执行。这样的分工是基于能力与成本的编辑建议，不是官方服务等级承诺。
编码能力不能合成一个总分
站内本次读取的 Terminal-Bench 4.0 最高档公开记录为 Terra 50.3%、Sol 58.18%。然而在 Terminal-Bench-Science 0.1 的最高档记录里，Terra 为 58.3%、Sol 为 57.0%。两组结果不能相加后宣布总冠军：前者测试终端任务，后者关注科学研究中的代码工作，数据来源和代理配置也需要逐行核对。后者约 1.3 个百分点的差距，没有误差区间时不足以支持“科学研究全面领先”。
这也是我们更建议按任务类型分流的原因。修复一个测试失败与从视频中提取科学观测值，虽然都要写代码，对视觉输入、实验设计和验证方式的要求并不一样。应当对实际工作负载建立验收集，而不是用“更擅长编程”概括所有代码任务。
半价如何转化为业务价值
2026 年 10 月 28 日，标准文本上下文不超过 272K 时，Terra 为每百万输入/输出 token 1/5 美元，Sol 为 2/10 美元。相同 token 用量下 Terra 的这一部分费用为 Sol 的一半，但实际生成长度、推理 token 和重试次数可以不同。超过 272K 的输入有单独费率，不能把短上下文示例直接套到百万上下文任务上。
如果日常任务在 Terra 上一次通过，它很适合作为规模化默认选项；如果大量任务最终都要转给 Sol 重做，两次执行的费用会叠加。因此路由阈值应该依赖失败特征，例如连续工具错误、无法通过单元验收或缺失关键事实，而不是让模型反复自称有信心。
推荐执行方式
选择一批有确定输出的常规任务，让两款模型在相同工具和时间限制下完成，比较合格率、耗时中位数与尾部耗时。复杂代码任务另建一组，不与文档抽取混算。我们倾向于 Terra 承担可自动检查的高频执行，Sol 承担确实能用更高完成质量抵消差价的难题；最终比例由团队自己的样本决定。
读数口径与资料
本文编辑日期为 2026 年 10 月 28 日。表格会随新来源更新，正文是这一日期的选型判断。文中公开评测保留各自的推理档与工具条件，不将厂商自报等同于独立复测，也不把未公开成绩当作零分。实际成本应包含所有尝试、工具费用与必要的人工复核。