Chat Completions
OpenAI 风格的单轮对话补全 API 格式，被广泛用于现有 LLM 应用代码与 SDK 集成
核心事实
时间轴 (近 90 天)
文章观点：若使用场景集中在标准 Chat Completions 且不涉及实时连接，升级到 v3.36.0 的收益相对有限。
M3.1 Flash 可通过 AI SDK、Chat Completions、Responses 以及 Anthropic Messages API 调用，模型名称为 minimax/minimax-m3.1-flash。
开发者使用模型名 elorian/glimpse 即可通过 AI SDK 或 Chat Completions 接口调用 Glimpse。
OpenAI Agents SDK 的默认通信接口是 Responses API，而非 Chat Completions。
OpenAI Chat Completions 流式响应默认不包含用量信息，必须显式设置 stream_options: { include_usage: true } 才会在流结束前额外发送一个携带 usage 字段的 chunk，且该 chunk 的 choices 数组为空。
OpenAI Chat Completions 流式返回的携带 usage 的 chunk 中 choices 为空数组，若代码直接访问 chunk.choices[0].delta.content 而不使用可选链会在该 chunk 上抛异常。
OpenAI Chat Completions 的 usage 字段中，prompt_tokens 包含缓存 Token（prompt_tokens_details.cached_tokens 是其子集），计算成本时需先减去缓存部分再对剩余部分应用全价。
把同一个 OpenAI Agents SDK Agent 从默认的 Responses API 切换到 Chat Completions 后，格式错误回答从 41 降到 9；换用公开的接地系统提示词则降到 20，说明 API 默认值是格式漂移的主因。
在 Muse Wonder API 的三种端点中，推理力度参数命名不同：Responses 中为 reasoning.effort，Chat Completions 中为顶层 reasoning_effort。
在 Chat Completions 端点上，推理内容不会跨轮次持久化，导致多轮 agent 对话前后不一致；修复方法是改用 Responses API。
还有 8 条时间轴事件
全部知识事实 (19)
OpenAI API格式已成为大模型领域事实上的行业标准接口规范，其核心是/v1/chat/completions端点
80%已验证M3.1 Flash 可通过 AI SDK、Chat Completions、Responses 以及 Anthropic Messages API 调用，模型名称为 minimax/minimax-m3.1-flash。
75%待验证文章观点：若使用场景集中在标准 Chat Completions 且不涉及实时连接，升级到 v3.36.0 的收益相对有限。
50%待验证开发者使用模型名 elorian/glimpse 即可通过 AI SDK 或 Chat Completions 接口调用 Glimpse。
50%待验证OpenAI Agents SDK 的默认通信接口是 Responses API，而非 Chat Completions。
50%待验证OpenAI Chat Completions 流式返回的携带 usage 的 chunk 中 choices 为空数组，若代码直接访问 chunk.choices[0].delta.content 而不使用可选链会在该 chunk 上抛异常。
50%待验证OpenAI Chat Completions 流式响应默认不包含用量信息，必须显式设置 stream_options: { include_usage: true } 才会在流结束前额外发送一个携带 usage 字段的 chunk，且该 chunk 的 choices 数组为空。
50%待验证OpenAI Chat Completions 的 usage 字段中，prompt_tokens 包含缓存 Token（prompt_tokens_details.cached_tokens 是其子集），计算成本时需先减去缓存部分再对剩余部分应用全价。
50%待验证把同一个 OpenAI Agents SDK Agent 从默认的 Responses API 切换到 Chat Completions 后，格式错误回答从 41 降到 9；换用公开的接地系统提示词则降到 20，说明 API 默认值是格式漂移的主因。
50%待验证在 Muse Wonder API 的三种端点中，推理力度参数命名不同：Responses 中为 reasoning.effort，Chat Completions 中为顶层 reasoning_effort。
50%待验证在 Chat Completions 端点上，推理内容不会跨轮次持久化，导致多轮 agent 对话前后不一致；修复方法是改用 Responses API。
50%待验证Chat Completions、Responses与Anthropic Messages是不同接口，一个网关声称OpenAI兼容，通常只保证其中某一种接口的部分行为，并不意味着三种都可用。
50%待验证gpt-6-luna在Chat Completions上使用函数调用仅当推理力度为none时可用；使用内置工具需改用Responses API。
50%待验证开发者可通过 AI SDK 中的 reasoning 参数或 Chat Completions 接口中的 reasoning_effort 参数控制 Gemini 4 Argon 的思考等级。
50%待验证在传统 Chat Completions 范式里，system 消息通常只允许出现在消息列表开头
50%待验证任何支持Chat Completions格式的服务商都适用于本文的回退链方案
50%待验证none effort参数被从schema中删除，依赖该参数在chat completions端点执行函数调用的遗留系统工具调用能力将失效，需迁移到Responses API
50%待验证Responses 协议是 Microsoft Agent Framework 支持的一种通信协议，与 Chat Completions 协议相比更适合有状态的多轮对话和流式输出场景
50%待验证Chat 模式对应 OpenAI 的 /v1/chat/completions 接口，以多轮对话消息列表为输入
50%