GPT-6 Astra API：模型 ID、端点，以及长周期任务的实际成本

The short version: GPT-6 Astra is callable today at https://api.openai.com/v1 under a single model id, gpt-6-astra, at $10.00 per million input tokens, $1.00 cached input and $50.00 output — the figures Ope​nAI's own pricing page carried on September 16, 2026. The model itself is from September 3, 2026, thirteen days before this page was written, so nothing here is launch coverage and nothing here is framed as an announcement. This is the reference page for the developer question that comes after availability: what string to pass, which endpoint takes it, what the 1,050,000-token window really buys, what the account has to look like first, and what one genuine long-horizon agent run costs on a rate card that quietly reprices itself above 272,000 input tokens. GPT-5.6 Sol appears throughout only as the price baseline it is sold above, never as the subject.

一个发布仅十三天的模型之所以本周值得单独写上一页，是因为进入它的路径在发布之后发生了变化，而 API 这条路径如今已成为常规渠道。OpenAI 于 9 月 3 日发布 Astra 时，说的是分阶段推出，而非全面可用；到 9 月 8 日，它表示该模型已在 Codex 和 ChatGPT Work 中向 Plus、Pro、Business 和 Enterprise 用户全面推出；而到 9 月 14 日那一周，AWS 已将其列入 Bedrock，Microsoft Foundry 也已将其列为正式可用。对 API 调用方而言，这一先后顺序并没有听起来那么重要——该端点自始至终都在线且有文档可查——但这确实意味着围绕它的采购问题如今有了发布当天所没有的答案。下文所有内容均于 2026 年 9 月 16 日读取自 OpenAI 自家的模型文档、定价页面和数据控制页面；凡来自其他来源的内容，都会在承载它的那句话中加以说明。

模型 ID，以及如实回答的快照问题

需要传入的字符串是 gpt-6-astra——全小写、用连字符连接、不带厂商前缀。这是 Ope​nAI 为该模型记录的唯一 id。

如果你在寻找一个带日期、可供固定（pin）的快照，那根本找不到，我们也不会编造一个看起来合理的后缀。Ope​nAI 的 GPT-6 Astra 模型页面在 Snapshots 下只列出了一项，就是裸的 gpt-6-astra。没有 -2026-09-03 这种带日期的形式，也没有 -latest 这个供应商侧的别名。我们在调研期间，在一个路由器列表上看到了形如 ~openai/gpt-astra-latest 的动态别名；那是在供应商 id 之上构建的网关构造，不是 Ope​nAI 发布的内容，也不应该把它当作那样的东西写进你的配置。

实际影响很小，但值得说明。你可以获取模型对象，以确认你正在与之交互的是什么：

curl https://api.openai.com/v1/models/gpt-6-astra -H "Authorization: Bearer $OPENAI_API_KEY"

把裸 ID 固定到一个配置值里，而不是把它敲进十几个调用点。如果 OpenAI 之后添加了带日期的快照，裸 ID 就会变成移动靶，你固定下来的值也会在不知不觉中开始变化——只改一个地方，就是两分钟的改动和花一下午时间 grep 之间的区别。

端点：基础 URL、兼容性，以及一个可运行的请求

The base URL is https://api.openai.com/v1. Per Ope​nAI's model documentation, GPT-6 Astra is supported on Responses (/v1/responses), Chat Completions (/v1/chat/completions) and Batch (/v1/batch). It is explicitly not supported on Realtime, Assistants, Fine-tuning, Embeddings, image generation and editing, video, audio, moderation, or the legacy Completions endpoint — and those absences matter as much as the presence list, because a team that planned around the Assistants API or a fine-tuned variant has to replan rather than rewrite.

关于兼容性：这是 OpenAI 自家的第一方 API，也是所有兼容 OpenAI 的 SDK 和客户端编写时所依据的线格式。任何能使用该格式的东西，都能无需兼容层直接与 gpt-6-astra 通信——你只需更改模型字符串；如果你是从较旧的 OpenAI 模型迁移而来，还要更改下面的参数名称。新项目应使用 Responses API：OpenAI 正是在这个接口上说明该模型的推理控制，内置工具也位于这里，而且对于最新模型，Chat Completions 的支持历来是两者中较薄弱的那一个。

一个最小的流式调用，并设置了推理努力程度：

curl https://api.openai.com/v1/responses \

-H "Authorization: Bearer $OPENAI_API_KEY" \

-H "Content-Type: application/json" \

-d '{"model": "gpt-6-astra", "input": "列出若要将此服务从旧版认证 API 迁移出来，你需要修改哪些文件。", "reasoning": {"effort": "high"}, "max_output_tokens": 16000, "stream": true}'

同样的东西用 Python 来写，而大多数读者实际上就生活在 Python 里：

from openai import OpenAI

client = OpenAI()

stream = client.responses.create(model="gpt-6-astra", input="列出你会为了将这项服务从旧版认证 API 迁移出去而修改的文件。", reasoning={"effort": "high"}, max_output_tokens=16000, stream=True)

for event in stream:

if event.type == "response.output_text.delta": print(event.delta, end="")

那个请求中有三点是此模型所特有的，而不是从通用快速入门中照搬而来的。

• 推理力度是一个成本调节旋钮，而不只是质量调节旋钮。 OpenAI 的模型页面列出的支持取值为 low、medium、high、xhigh 和 max。请注意这份列表的起点：GPT-6 Astra 没有 none 或 minimal，也就是说下限被抬高了。推理 token 按输出 token 计费，价格为每百万 50.00 美元，这意味着把力度从 high 调到 max 是一项附带价格的决策，而不是免费的质量升级。

• 支持流式传输，而这也是运行长回合的可靠方式。对该模型的单次请求最多可输出 128,000 个 token。若等待它一次性落入一个响应体中，又无法知晓它是否在推进，最终就只能靠猜超时时间。

• 这里的提示缓存是显式的。Responses API 在文本、图像和文件内容上记录了 prompt_cache_breakpoint，其模式为 explicit，用于标记“可复用提示前缀的确切结束位置”，并从请求的 prompt_cache_options.ttl 继承其 TTL。在缓存输入费率为未缓存费率十分之一的模型上，你把这条边界放在哪里，就是请求中杠杆作用最大的一行。

1,050,000 token 窗口究竟意味着什么

文档记录的参数为：1,050,000 token 的上下文窗口、922,000 token 的最大输入、128,000 token 的最大输出，以及 2026 年 4 月 30 日的知识截止日期。

从人们常忽略的算术开始：922,000 加上 128,000 等于 1,050,000。上下文窗口由你发送的内容和模型可能返回的内容共享，而输出上限从中预留。你不能发送 1,050,000 个 token 的输入；单次请求的实际上限是 922,000，如果你想给真正的回答留出空间，还得比这更少。

一百万 tokens 换成你实际工作中使用的单位，能换来什么？token 与文本之间的换算只是近似值，而且这些数字是我们的估算，不是 OpenAI 的，但量级是对的：按每个 token 大约四个字符计算，1,050,000 个 token 大约相当于 750,000 个词，或者大约十万行代码。那是一个完整的中型代码仓库，还为智能体工作时生成的工具输出留有余地。这款模型所主打的长时程场景正是如此：一个智能体一小时前读过某个文件，现在仍能看到它当时写了什么，而不是一个已经把一上午压缩成一段摘要的智能体。

接下来是更适合放在成本页面而非规格页面的部分。Ope​nAI 的模型文档指出，对于输入超过 272,000 个输入令牌 的提示词，其定价为 整个请求的输入与缓存费率均为 2 倍，输出为 1.5 倍。定价页面将其列为第二行：GPT-6 Astra 的长上下文为输入 $20.00、缓存输入 $2.00、输出 $75.00。因此，该窗口顶部四分之三是一个价格区间，而不仅仅是余量。一次运行的记录若超过 272,000 个令牌，整个请求的每个输入令牌——包括缓存令牌——都要支付双倍费用，而这是该模型经济账中最大的单项波动。下文将完整说明。

还有一个值得了解的机制，因为这是厂商自己承认一个窗口并不能解决所有问题。对于 Codex，OpenAI 描述了一种随 Astra 推出的实验性上下文方案，其中笔记会跨上下文窗口持久保留，而不是反复压缩成单一摘要，较早的窗口保持可搜索，因此早期消息和工具输出中的需求与测试结果仍然可以找到。OpenAI 称其为实验性功能，表示它在 Codex 的 config.toml 中启用，并称它将成为 Astra 的默认设置。如果你要在 API 上自己构建等效方案，这就是应该效仿的形态：持久化笔记加上可检索的历史记录，而不是依赖一个万能提示。

而极限还在于数字本身：大窗口是一种容量，而非在整个窗口内都保持注意力的保证。厂商报告的长时程数据，比 token 数更能说明其实际行为——Ope​nAI 报告 OSWorld 2.0 在每任务约 40 分钟时为 72.6%，Terminal-Bench 4.0 为 57.9%，而 GPT-5.6 Sol 为 37.3%。这些是 Ope​nAI 自家的数字，我们并未复现；独立视角的图景与之接近但并不完全相同：Artificial Analysis 测得 Astra 在 Terminal-Bench v4.0 上为 59.1%，Claude Fable 5.1 为 52.0%，GPT-5.6 Sol 为 39.9%。两者都认同，相较于上一代，长时程能力上的差距确实存在；但两者都不能代替你自己跑一遍任务。

输入模态，以及坦诚留待解决的文件问题

OpenAI 的模型页面列出的输入模态为 文本和图像，输出为文本。此模型不支持音频、视频，也不支持图像生成。

图像输入作为用户消息中的一个内容部分传入。该部分类型为 input_image，图像可以通过 image_url 以完全限定 URL 或 base64 数据 URL 的形式提供，也可以通过 Files API 中的 file_id 提供。还有一个可选的 detail，取值为 auto、low、high 或 original，默认为 auto。其结构如下：

{"model": "gpt-6-astra", "input": [{"role": "user", "content": [{"type": "input_text", "text": "这张截图里有什么变化？"}, {"type": "input_image", "image_url": "data:image/png;base64,...", "detail": "high"}]}]}

OpenAI 的视觉文档列出 PNG、JPEG、WEBP 和非动画 GIF 为可接受格式，每次请求的总负载最高 512 MB，每次请求最多 1,500 张图像，超过 30,000 个图像块的图像会被拒绝，而不是被缩小。这些是平台的一般视觉限制，而不是 Astra 特有的限制，图像就像任何其他输入一样按 token 计费。

现在来说读者真正带着来的那个问题，以及诚实的答案。你能发送文件或 PDF 吗？ 我们无法在 Ope​nAI 的文档中确认该模型是否支持文档输入，也不会暗示它可以。Responses API 确实定义了 input_file 内容部分，因此这套基础通路在 API 层面总体上是存在的；但 Ope​nAI 关于 GPT-6 Astra 的页面把文本和图像列为其输入模态，并未列出 file，而且我们也没有找到 Ope​nAI 有任何记载该端点支持 PDF 输入的声明。同一模型的某个路由器列表确实把 file 与文本、图像并列显示——但请把它视为路由器方面的说法，即路由器对某条路由的记录，而非厂商的保证。如果文档摄取对你的工作负载至关重要，那么在基于它进行开发之前，先针对真实端点进行测试，并准备好 OCR 转文本的备用方案。这就是花一个下午测试与推倒重来之间的差别。

完整价格线，以及一次长期运行的成本核算

本节中的每一个数字都读取自 Ope​nAI 自己的定价页面，时间为 2026年9月16日，且除非该行另有说明，所有数字均为每百万 token 在 Standard 层级的价格。

• 短上下文，最高 272K 输入 — 输入 $10.00，缓存输入 $1.00，缓存写入 $12.50，输出 $50.00。

• 长上下文，输入超过 272K — 输入 $20.00，缓存输入 $2.00，缓存写入 $25.00，输出 $75.00，按整个请求计费。

• Batch 和 Flex —— 标准版的一半：短上下文 $5.00 / $0.50 / $6.25 / $25.00，长上下文 $10.00 / $1.00 / $12.50 / $37.50。

• 快速模式 — 标准模式的两倍：短上下文为 $20.00 / $2.00 / $25.00 / $100.00，长上下文为 $40.00 / $4.00 / $50.00 / $150.00。OpenAI 指出，快速模式不适用于具有欧盟数据驻留的 GPT-6 Astra。

• 数据驻留 — 使用该功能的端点，对于 2026 年 3 月 5 日及之后发布的模型需加收 10% 的费用。GPT-6 Astra 符合该条件，因此数据驻留部署的价格比上述所有数字高出 10%。

要内化的一点是缓存输入费率。1.00 美元对 10.00 美元，意味着你再次发送的那部分提示词享受 90% 折扣——而在智能体工作负载中，这部分几乎就是整个提示词。缓存写入按 12.50 美元计费，也就是未缓存输入费率的 1.25 倍，因此盈亏平衡点很简单：100,000 个 token 以未缓存方式发送两次花费 2.00 美元，而将该前缀写入一次再读回一次花费 1.35 美元。从第二次复用开始，缓存就划算了，而一个智能体在同一个对话记录上运行一百轮，就会将它复用一百次。

这就把我们带到了真正决定这个模型是否用得起的算术上，因为标称费率并不是最终落在账单上的那个数字。下面是一次模拟运行——是我们自己的模拟，基于 Ope​nAI 公布的费率，而非实测账单——针对的是该模型所面向的那类任务：一个自主编程智能体在几个小时内完成一次仓库级迁移，进行 120 次模型调用，随着工作记录不断累积，每次调用平均约有 500,000 个输入 token，其中 80% 的输入由缓存提供，整个运行过程中包含推理在内共产生 400,000 个输出 token。

按短上下文标准费率：

• 未缓存输入 — 12M tokens × $10.00 = $120.00

• 缓存输入 — 48M tokens × $1.00 = $48.00

• 输出 — 0.4M tokens × $50.00 = $20.00

• 本次运行总计 ≈ $188.00

同一次运行在长上下文档位，也就是每次调用超过 272,000 个 token 的转录实际所处的档位：

• 未缓存输入 — 12M tokens × $20.00 = $240.00

• 缓存输入 — 4800 万个 token × $2.00 = $96.00

• 输出 — 0.4M tokens × $75.00 = $30.00

• 本次运行总计 ≈ $366.00

由此得出两个结论，而这两个结论都无法从标称费率中看出来。首先，你的转录文本存放在哪里，和选择哪个模型同样重要——同一个任务大致会翻倍，取决于它是否跨过 272K 阈值，这使得上下文纪律（检索合适的 100K，而不是携带 600K）在这个模型上成为一种成本控制手段，而不仅仅是性能手段。其次，缓存的价值比折扣所暗示的更大：如果完全没有缓存命中，第一个场景会携带 $600.00 的输入，而不是 $168.00，并且该次运行的成本约为 $620，而不是 $188。在你调高推理投入之前，先开启缓存。

对于基线而言，GPT-5.6 Sol 上同样的 token 组合，按 Ope​nAI 定价页在 9 月 16 日显示的价格——短上下文下输入 $4.00、缓存输入 $0.40、输出 $20.00——算下来约为 $75.20，而在 Sol 的长上下文档位（$8.00 / $0.80 / $30.00）下约为 $146.40。这样一来，本次运行在两个档位上都是约 2.5x。关于这个倍数有两点需要说明，因为它已经在别处引起了混淆：Sol 的数字是促销价——Ope​nAI 称该促销至少持续到 2026 年 11 月 21 日——而 Astra 的是标价，所以这个倍数衡量的是当下这两张价目表，而不是关于这些模型的稳定事实，一旦促销到期它就会收窄。另外，流传的关于 Astra 的较早的“2.5x”，有时是拿 Sol 促销前的标价 $5.00/$30.00 算出来的，那样输入是 2x，输出约为 1.67x。要说清你指的是 Sol 的哪个价格，否则这个数字毫无价值。

还有一点：Batch 层级会将所有费用减半，使首次运行成本降至约 $94。你能否使用它取决于下一节的内容。

零数据保留，以及那个自我取消资格的折扣

OpenAI 表示，符合条件的 API 客户可在受支持的端点上使用零数据保留，但需经批准——而这句话的两部分都各有其实际作用。它不是自助开关：资格需经 OpenAI 事先批准并接受附加要求，且需联系销售才能启用。获批后，可在“设置 → 组织 → 数据控制”的“数据保留”选项卡下，按组织或项目层级进行配置；项目可以继承组织默认设置、明确启用 ZDR、选择 Modified Abuse Monitoring，或将两者都禁用。

实际影响：ZDR 会将客户内容从滥用监控日志中排除，取代最长 30 天的默认保留期；而且 /v1/responses 和 /v1/chat/completions 上的 store 参数会被视为 false，即使请求试图将其设为 true。

在一个关于成本的页面上，最关键的细节是：/v1/batches 不在符合 ZDR 资格的端点列表中。 OpenAI 的数据控制页面将其列为不符合资格，应用状态会保留直至被删除。因此，在 GPT-6 Astra 上，Batch 层级的 50% 折扣与零数据保留是互斥的——受合规约束、需要 ZDR 的工作负载应按标准费率而非批量费率来做预算，上面的 94 美元数字对它并不适用。

还有三点需要直说的注意事项，因为一个过度吹捧 ZDR 的页面，比一个完全不提它的页面更糟。ZDR 并非绝对：在“Eyes Off”下，Ope​nAI 保留一项权利：在提前书面通知后，可让特定客户的模型不具备 ZDR 资格；而在“Safety Retention”下，当分类器标记出严重风险时，内容可能会被保留并接受人工审核。即使启用 ZDR，被标记为可能存在 CSAM 的图像和文件输入也会被保留以供人工审核。而且 ZDR 止步于 Ope​nAI 的边界——如果你的智能体调用远程 MCP 服务器或其他供应商的 API，相关流量将受那一方的保留政策约束，而不是本政策。另外，数据驻留是与 ZDR 不同的控制措施，需要单独审批；在美国境外，还需要一份 Modified Retention 修订协议，并且带有上文提到的 10% 上浮。如果你在 ZDR 下依赖缓存，请阅读 Ope​nAI 的数据控制页面，了解缓存会保留什么；我们不会为它公布一个连我们自己都无法在该页面上读到的保留数字。

文档中所述的速率限制，以及最先咬人的那一个

Ope​nAI 的模型页面公布了 GPT-6 Astra 的以下按层级限制——每分钟请求数和 token 数，然后是批处理队列限制：

• 第 1 级 — 500 RPM，500,000 TPM，批量队列 1,500,000

• 二级 — 5,000 RPM，1,000,000 TPM，批处理队列 3,000,000

• 第 3 层 — 5,000 RPM、2,000,000 TPM、批处理队列 100,000,000

• 第 4 级 — 10,000 RPM，4,000,000 TPM，批量队列 200,000,000

• 第 5 级 — 15,000 RPM、40,000,000 TPM、批量队列 15,000,000,000

我们将点出两个限制，它们没有文档记录，而不是凭空补上：没有已发布的免费层限制，因为 GPT-6 Astra 根本不在免费层；而且我们没有找到 Tier 5 以上的已公布上限，也没有 Fast 模式单独的限额表。如果供应商没有发布某项限制，就把这种缺失视为尚未确定——不要假定它是无限的。

首先卡住智能体工作负载的数字，是 Tier 1 的 500,000 TPM。对此模型的单次调用可以承载 500,000 个 token 的对话记录，这意味着 一次请求在入门层级上就能耗尽你整整一分钟的 token 预算。如果该层级无法推送这些 token，那么对于在 120 轮中一直占用同一份对话记录的智能体来说，百万 token 的上下文窗口并没有多大用处。要根据上面示例中的 token 量来规划层级，而不是根据请求数——并注意，层级晋升取决于支出和账户历史，因此值得在截止日期之前就确定下来，而不是等到截止日期再处理。

Azure 和 AWS Bedrock，各一行

• Microsoft Azure — GPT-6 Astra 可在 Microsoft Foundry 中以相同的 gpt-6-astra id 进行部署，Foundry 的报道将其正式可用时间定在 2026 年 9 月初，并称提供 Global Standard 和 US Data Zone 部署，发布时无 EU Data Zone，费率与 OpenAI 的标价相同或接近，并设有长上下文档位。我们是从 Foundry 的报道而非 Microsoft 自己的目录页面读到的这一点；今天我们无法访问后者——在基于它规划部署之前，请先在 Microsoft 自己的文档中核实当前的部署列表、区域集和费率。

• AWS Bedrock — 列为 openai.gpt-6-astra，可通过受支持的 Bedrock API 使用，并在 AWS 日期为 2026 年 9 月 15 日的每周综述中得到确认，具备 Bedrock 自身的治理边界（VPC 终端节点隔离、KMS 加密、Guardrails），且 AWS 声明推理数据不会用于模型训练。据报告，Bedrock 上的区域内和地理跨区域推理计费比基础费率高出 10%；这一数字在我们看来是二手信息，因此请查看 AWS 自己的定价页面。

两条路线都不改变模型。两者改变的是采购方式，而对企业读者来说，这正是关键所在：Foundry 或 Bedrock 部署可以纳入现有的云承诺，继承其 IAM、日志记录和网络边界，并落到财务已经批准的发票上——这往往就是试点与真正上线交付之间的差别。代价在于，你要接受云厂商的模型生命周期和云厂商的费率，而且据报道，这两家云的价格都等于或高于 OpenAI 的标价，而非低于它。

路由器的适用场景，包括反对使用它的部分

GPT-6 Astra 已在 OrcaRouter 目录中，型号为 openai/gpt-6-astra，OrcaRouter 会以0% 加价的方式透传供应商的标价——厂商的价格就是我们的价格，厂商一旦调价，当天就会体现在你的账单上，而不是等到续费时才变动。对于这个价位的模型而言，这可不是一句"可以忽略不计"的说辞：上面的算式，与你在直接购买时所支付的完全是同一套算式。

这里采用路由的诚实理由不在于价格，而在于可逆性。Astra 大约是其下一档模型的 2.5 倍，而它的成本会随一个由你的架构控制的阈值波动，因此大多数团队希望在把生产路径定下来之前，先用一小部分真实流量试用它。通过一个密钥，你可以把它放在与你已经在运行的模型相同的端点后面，把一部分流量发给它，并在它没能挣回差价时自动故障转移到更便宜的方案——这是一次配置变更，而不是迁移，一个 API 覆盖 200 多个模型，一个路由 DSL 能把多个模型组合进单次调用，还有当你想要一组模型共同作答时的模型融合。

反对它的那些理由，直白地说出来。路由器是请求路径上多出的一跳，也是数据流中多出的一方——而在这个模式下，这并不是假设情况，因为 ZDR 在 OpenAI 是按组织批准的，而被路由的请求并不会自动落入你的 ZDR 批准范围。如果你要发送受监管数据，请在发送前确认该路由的数据条款，并准备好为那项工作负载直接致电供应商。路由还会增加一个可能发生故障或增加延迟的组件，并且它让更换模型变得如此容易，以至于有可能在未经审查的情况下改变正在为用户作答的是什么。对大多数团队来说，这些都不足以压过试用与可逆性的理由；在你认定路由器是免费之前，所有这些都值得了解。我们在另一篇文章中让各个路由平台一较高下，而不是在这里重述那项比较。

三个不能用单个分句回答的问题

我可以对 GPT-6 Astra 进行微调，或将其与 Assistants API 一起使用吗？ 两方面都不行，而且这是一个设计边界，而不是你遗漏的某个配置。Ope​nAI 的模型页面将 Chat Completions、Responses 和 Batch 列为支持的端点，并明确将 Fine-tuning 和 Assistants 列为不支持，而且 Ope​nAI 的微调定价表中也没有 GPT-6 Astra 这一行。如果你的架构依赖于一个经过微调的旗舰模型，那么 Astra 就必须改用提示词方式，这会把成本从训练转移到输入 token 上——而在大型系统提示词上每百万 $10.00 的价格下，这是一笔真实的预算项，而不是一个脚注。

模型会拒绝我获得授权进行的安全工作吗？有时会，而且在动手构建之前就值得了解。GPT-6 Astra 是该公司《预备框架》下首个达到“关键”网络安全能力阈值的 Ope​nAI 模型，而按发布版本，它会拒绝高级网络任务，例如编写概念验证型漏洞利用代码。Ope​nAI 表示，计划通过其 Daybreak 计划，以限制更少的防护措施扩大访问范围。对防御方而言，这表现为一种拒绝——既不是速率限制，也不是程序缺陷——应在错误处理中为它留出预算，而不是反复重试撞上去。

调用这个模型需要特殊审批吗？对于标准端点来说不需要——调用 gpt-6-astra 没有等待名单，也没有审批环节，只需一个已开通计费的账户。你可能需要审批的是它周边的一切：零数据保留，这需要按应用申请审批；美国境外的数据驻留，这需要单独的补充协议；以及层级提升，如果你打算通过 Tier 1 账户推送智能体规模的 token 量。模型本身是采购中最简单的部分。

该关注什么，以及谁现在应该行动

如果你要基于这个模型做开发，值得关注的四个点全部都在供应商一侧，而且全部带有日期属性。OpenAI 是否会为 gpt-6-astra 发布带日期的快照——这会把这个裸 id 变成一个移动目标，也让固定版本变得有意义。272,000 token 的阈值是否会变动，因为这一行对你账单的影响比页面上任何基准测试都大。Bedrock 和 Foundry 的费率是会向 OpenAI 的标价靠拢，还是保持在其之上，因为这和模型本身一样，决定了采购路径。以及 Daybreak 计划是否会改变该端点的拒绝范围，对安全团队来说，这决定了它是一个可用的工具，还是一个演示品。

至于该由谁来行动，分化很清楚。如果你已经在为长周期智能体工作以促销价购买 GPT-5.6 Sol，那么 2.5 倍是实实在在的，问题也很明确：在你自己的实际工作负载上，任务完成率的提升能否跑赢价格差？拿一部分真实流量跑一跑就知道了——上面的完整示例会在你开始之前告诉你这部分流量的成本是多少。如果你的工作是短上下文对话或大吞吐量分类，那这不是你的模型；长上下文重新定价加上 50.00 美元的输出价格，会让它成为做某件 GPT-5.6 Luna 能以零头价格完成之事的高昂方式。而如果你是一家有合规要求的企业，请先启动 ZDR 相关的沟通，因为它制约着 Batch 折扣、驻留溢价以及你的路由选择——而这一切都不是你在需要它的当天才做决定的事。