在 astra、sol、terra 和 luna 之间怎么选

五个模型、一个端点、一份预算。一个新账号真正要问的，不是它们里哪个最强，而是手上每一部分活该走哪一个——而这个答案从来不会是单独一个名字。它是一个路由决定：每一类请求做一次，然后拿你自己控制台里逐条的用量去对。下面就是这个决定，按该做的顺序排好。

先从 terra 开始

terra 是默认项，不是将就的折中。它公布的定位是快速、高效的日常工作 — agent、工具调用、编程、电脑操作和视觉任务 — 而这已经覆盖了一个产品实际发出去的大部分请求：普通对话、按既定结构做抽取、那种敲字多过思考的编码辅助，以及读懂屏幕再动手的 agent 步骤。它的输入是 0.55，输出是 2.75，每一项都是 sol-6.1、sol-6 的一半。

所以新的一类请求先放在那里跑，然后对结果诚实一点。如果 terra 给出的答案就是你本来会发布的那个，你已经找到了对的模型，每个输入 token 算 0.55 个积分。往上换是要有能指出来的证据才做的决定——一次你能拿给别人看的失败——而不是为了保险先换上去。

什么时候把一类请求提到 sol

sol-6.1 是整张费率表的锚：一个 sol-6.1 输入 token 就是 1.1 个积分，本页其他每一个数字都是相对它的比例。sol 公布的定位是深度推理、高难度编程、agent 类任务和研究——这句话本身也就是换过去的判据。当推理深度明显值回票价时，就把那一类请求提到 sol：terra 一直绕不出来的难 bug；中间步骤必须对、结论才可能对的多步分析；必须把整个文件同时装在脑子里才能改的那种改动。提供方自己对 terra 所运行模型的说明也是这样：最复杂的编程任务，sol-6.1 和 astra 仍是更强的选择。

换到 sol-6.1 或 sol-6，这一类请求的花费会翻一倍：输入是 1.1，terra 是 0.55；输出是 5.5，terra 是 2.75。对一类原本做不成、现在做得成的请求，这个价钱值得；对一类本来就没问题的请求，这个价钱很不划算。要换的是那一类，不是整个应用——这五个模型没有哪一个是全局开关，而本页上最便宜的东西，是你根本没有往上换的那些请求。

astra 是留给什么活的

astra 是在 1M token 的上下文窗口上做前沿级推理，专为最难的那一类活准备，而它的定价就是要你有意识地花：输入 5.5、输出 27.5，每一类都是 sol-6.1 的五倍。请把这当成一条用法说明，而不是一句警告。astra 是留给发布前的最后一遍复核、留给会有人照着行动的那份分析、留给没人会再读第二遍的一次性任务——也就是答错的代价高过所花 token 的那些活。

有一件事不在这个决定里：长度。这里没有任何模型对长上下文另外加价。每个模型的长上下文费率跟它自己的短上下文费率一行一行完全相同，所以一份长文档并不会改变它该发给哪个模型。按活有多难来选，输入有多大就让它是多大。

luna 扛后台的量

不是产品发出去的每一条都值得动用推理模型。分类、打标、短摘要、判断一条记录该进哪个队列——那些在每一条记录上都跑一遍、又没有人会单独去读的处理——是 luna 的活，它公布的定位是快速草稿、分类、摘要和大批量对话。luna-6 输入 0.055、输出 0.275，两者都比 sol-6.1 便宜二十倍。

不过要把它的提示词保持精简，否则省下来的会原样还回去。一个后台任务并不需要你的全部上下文：让你的主力助手表现好的那段长 system prompt，放进一个分类器里通常只是死重量；而单价上便宜二十倍这件事，会被你多发二十倍的 token 一笔抹平。把要处理的那条、要用的标签发过去，别的什么都不要发。

sol-6.1、sol-6 与 luna-6：GPT-6 世代

Sol 的 GPT-6.1 模型，系列中最新的一款，每个输入 token 计 1.1 个 AI 积分。 Sol 的 GPT-6 世代，每个输入 token 计 1.1 个 AI 积分。 Luna 的 GPT-6 世代，本站公示的最低费率。 为兼容已有集成，sol 和 luna 这两个模型名继续可用：它们现在运行 sol-6.1 和 luna-6，并按这两个模型的费率计费。点名 GPT-5.6 Terra 的请求由 terra 提供服务，terra 运行 GPT-6.1。自己写 sol-6.1 或 luna-6，和本文其他调整一样只改一个词，控制台的逐笔明细会告诉你每一笔花了多少。

五个混着用，然后核对账单

每个 token 多少积分，按模型和按类别列出，直接取自本站给其他一切定价所用的那份 catalogue——上面几段里的比例，说的就是这五行：

以上这些都不是选一次就固定下来的设置。五个模型共用一个端点、一个 key，而模型只是你本来就在发的那个 body 里的一个字段——该便宜的请求上改一个词，必须做对的请求上改一个词。

POST /v1/chat/completions

{
  "model": "terra",
  "messages": [
    {"role": "user", "content": "用一句话概括这个工单。"}
  ]
}

如果你的代码里写的是 OpenAI 风格的模型名，它会被读成所属的那一档，所以在你还没想好要改成什么之前，现成的配置照样能跑。正是这一点让混着用的试验很便宜：你不需要迁移任何东西，就能让一类请求先换个地方跑一个星期。

跑循环的 agent 还有两件事要做对。第一，每一轮开头保持一段稳定的前缀——system prompt、工具定义、轮与轮之间不变的那些指令——因为从缓存前缀里读回来的 token，只按它自己模型输入费率的一半计费；而每一轮都重新拼提示词的循环，等于每一圈都为同样的字付全价。第二，分层路由要有意为之，而不是照着习惯来：决定下一步做什么的 planner 通常值得用 sol-6.1 或 astra，执行它每一步的 worker 是 terra，事后把结果归置整理的那一遍是 luna-6。一个 agent，三个模型，是故意这么排的。

然后去核对。每一个请求都会按上表的费率在你的控制台里逐条列出来——哪个模型、哪一类 token、多少积分——所以你以为自己在跑的那套搭配，是可以核实的东西，而不是靠猜的。这一点才把上面所有内容从一种看法变成一套流程：把这页上的路由拿去用，让你自己一个星期的真实流量走一遍，然后回头读那份明细。