OpenAI Daybreak Blue 与 Red 把 API 拆成了两套：每个网关运营方现在都应该审计的事

8 月 7 日，OpenAI 在 Daybreak 网络安全项目下发布了两个新模型 ID，分别是 daybreak-blue-latest 和 gpt-5.6-cyber。大多数报道着眼于模型能做什么。GPT-5.6 Sol 用于防御性工作，专门训练的 Cyber 模型用于漏洞验证和红队演练。但报道普遍没有谈到 Daybreak 对网关层意味着什么。

两个模型都只支持 Responses API，明确不支持 v1/chat/completions，不支持批处理，不支持微调。如果你的团队或你的客户通过标准的 OpenAI 兼容代理来跑安全工具（Cursor、使用自定义网关端点的 Claude Code、任何默认调用 /v1/chat/completions 的 SDK），即便 API Key 有效，这些请求也会立即失败。

Daybreak 实际发布了什么

Daybreak Blue（daybreak-blue-latest）是一个别名模型，默认指向 GPT-5.6 Sol，设计用于广泛的防御性安全工作流，涵盖漏洞发现、安全代码审查、检测工程、事件响应、恶意软件分析和补丁验证。上下文窗口 1,050,000 tokens，最大输入 922,000 tokens，最大输出 128,000 tokens。

Daybreak Red（gpt-5.6-cyber）是专门训练的网络安全模型，上下文窗口更窄，400,000 tokens，最大输入 272,000，最大输出 128,000。定价是每百万输入 token $12.50，每百万输出 token $75，大约是 GPT-5.6 Sol 标准层级的 3 倍输入价格和 10 倍输出价格。超过 272K 输入 token 时，输入价格翻倍，输出价格额外增加 50%。

两个模型都支持流式输出、结构化输出、函数调用、文件搜索、图像输入、网络搜索、prompt 缓存、代码解释器、hosted shell、apply_patch、skills、computer use 和 mc。两个都仅限 Responses API。

大多数运营方会忽略的申请门槛

Daybreak 的访问权限不是有 OpenAI API Key 就能解锁的。它需要通过 Daybreak Access 表单单独申请和开通。一个处于标准 Enterprise 或 API 层的组织，在没有获得批准的情况下调用这些模型 ID，不管账单状态如何，都会收到 401 或 404。

这带来了一个值得明说的开通架构问题。一个在多客户组织间共享端点的网关运营方，除非每个组织都单独申请并获批了 Daybreak 访问权，否则无法代表这些组织路由 Daybreak 流量。从单个已批准的 Daybreak 账户向下游客户委托授权的路径是不存在的。模型要求客户层级的授权，而不是网关层级的授权。

这在结构上与大多数路由工作方式不同。使用 GPT-5.6 Sol、Azure AI Foundry 或 Anthropic 标准 Claude API 层级时，网关运营方用单个上游密钥认证，代表客户路由请求。Daybreak 打破了这个拓扑结构。

端点不兼容不是可以绕过去的问题

Responses API 和 Chat Completions API 不是同一个端点。Chat Completions（v1/chat/completions）是 OpenAI 兼容 SDK、Cursor、Claude Code 以及几乎所有第三方集成默认使用的 API。Responses API（v1/responses）更新，请求结构不同，用 input 而不是 messages，用 text.format 而不是 response_format，工具调用结构也不一样。

如果运营方让 OpenAI SDK 指向某个网关端点并请求 gpt-5.6-cyber，得到的是端点错误，而不是模型错误。SDK 大概率在调用 /v1/chat/completions，模型在那个路径上根本不响应。适配需要把 SDK 迁移到 Responses API，或者让网关实现转译层，而这又要求网关专门识别 Daybreak 模型 ID 并区别路由。

对网关运营方来说，今天实际的决策路径分四步。

1. 客户中是否有正在运行授权安全工作流、可能受益于 Daybreak 的场景？
2. 如果有，这些客户已经获得 Daybreak 批准，还是需要去申请？
3. 如果有，他们的 SDK 是在调用 Responses API 还是 Chat Completions？
4. 如果是 Chat Completions，网关是否对特定模型 ID 做 Responses API 转译？

大多数网关运营方在第 1 步就会回答"没有"，到此为止。但对于构建安全工具平台或服务安全团队的运营方来说，第 2 到第 4 步的答案决定了 Daybreak 究竟能不能用。

与 Anthropic 的受限模型架构对比

Anthropic 有自己的受限层级先例。Fable 5 走独立发布轨道，更早的 Astra "Critical Cyber"（8 月在我们的报道中提到过）则是另一个例子。但 Anthropic 受限模型使用的仍是相同的 Messages API 端点。Fable 模型 ID 走的是所有 Claude 流量使用的同一个 /v1/messages 路径，限制发生在授权阶段，而不是端点路由阶段。

OpenAI Daybreak 的架构破坏性更大，因为端点本身就是受限的。Daybreak Blue 和 Red 只在 v1/responses 上响应。这意味着 Daybreak 流量不只是在策略上路由不同，在 HTTP 路径和请求结构上也完全不同。

从路由策略的角度看，这有个更清晰的好处。网关可以专门把 Daybreak 模型 ID 路由到 Responses API 端点，把其他所有请求路由到 Chat Completions，无需在路由层检查认证状态。模型 ID 本身就区分了端点。坏处是，网关下面的 SDK 层需要同时支持两个端点，或者网关需要做请求结构转译。

接下来 90 天值得关注的事

OpenAI 的 Daybreak Cyber Partner Program 还在扩展。当前合作伙伴列表包括企业安全厂商，Codex Security 集成进一步深化了 Daybreak 模型与 agentic 安全工作流之间的关联。

如果你今天在 OpenAI Responses API 上构建任何东西，不只是安全用途，Daybreak 作为一个模式值得持续观察。Responses API 一直在获得 Chat Completions 没有收到的新能力，retained reasoning、stored outputs、computer use 工具。Daybreak 仅限 Responses API，与 OpenAI 把 Responses API 定位为前向端点、把 Chat Completions 定位为遗留端点的大方向一致。

对运营方来说，如果客户群里的安全团队开始询问你网关里的 Daybreak 模型 ID，要先确认两件事，他们是否有 Daybreak 开通权限，以及你的网关是否处理 v1/responses 转译。定价是之后才需要比较的事。

TheRouter 用户应该关注什么

TheRouter 通过配置好的上游 provider 路由 OpenAI 兼容流量。对标准 OpenAI 模型 ID，路由走 /v1/chat/completions。Daybreak 模型 ID 不在标准 OpenAI 兼容路由范围内，需要 Responses API 端点以及单独的申请资格。

如果你在为安全用例评估 Daybreak，先直接向 OpenAI 确认 Daybreak 开通状态，再搭建网关配置。Daybreak 相关的端点限制见官方文档 developers.openai.com/api/docs/models/daybreak-blue-latest 和 /gpt-5.6-cyber。