这套设计为什么让 Capriole 更实用
一份 USD 8 Premium 会员覆盖受支持 Premium 模型范围内的无限浏览器聊天、每月 500 万 API 计费 token 和六条持续维护的编程智能体路径。应用继续使用原有协议，用户则只需管理一个 Capriole 账户、密钥、余额和账单页面。 相较于分别组装多个提供商账户，这是一项实际优势。带日期的成本对比还显示，三个受测的 500 万 token 工作负载在 Capriole 下均为 USD 8。采用官方直连付费 Standard 定价时，成本在 USD 15 至 USD 90 之间。通过 OpenRouter 并计入其公开充值手续费后，成本则在 USD 15.83 至 USD 94.95 之间。公共路径
成功路由的响应和流式事件会保留客户端所请求的协议。Responses payload 在返回时不会转换成 Chat Completions，Anthropic Messages stream 也不会重新包装成 OpenAI 输出。
这样可以保留 Responses、Messages 和 Chat Completions 客户端预期的协议特定行为。
共享层处理访问和计量，每条公共路由则保留对应客户端期望的请求与响应契约。模型分组是针对不同路由的兼容集合，并没有层级关系。一个模型如果实现了多种契约，就可能出现在多条受支持路由上。
为什么一条 endpoint 不够
各模型家族的差异不限于字段名称。 OpenAI Responses 用带类型的事件和 items 表达输出。Anthropic Messages 使用自己的 content blocks 和流式事件，Chat Completions 又有另一套请求与响应结构。推理控制、tool calls、用量数据、错误和 token-counting 行为也不相同。 简单适配器可以让基础文本提示词工作。编程智能体和生产客户端很快就会暴露缺少的细节，因为它们依赖流式顺序、工具结果轮次、用量 metadata 和模型特定控制。 因此，Capriole 在同一套身份验证和账单层背后维护多条保留协议的路由。一个密钥，明确选择模型
所有公共生成路由共用同一个 Capriole API key 和账户余额，所请求的模型仍须属于所选协议。 例如，Responses 路径接受持续维护的 OpenAI 别名和受支持的 Responses-compatible OpenAI 模型。Messages 路径接受持续维护的 Claude 别名和受支持的 Claude Messages model ID。Compatible chat 路径则可以提供范围更广的公共聊天模型。 模型不适用于所选路由时，请求应当验证失败。Capriole 不会把已经停用且不受支持的旧 key 悄悄改映射到其他模型。 明确失败比返回调用方没有请求的模型答案更安全。Latest aliases 与可复现 ID
Capriole 在支持它们的公共路径上提供openai-latest、claude-latest 和 google-latest 等持续维护的别名。
别名会在上游分发之前解析。用量、配额和 fallback 记录会关联到解析后的 canonical model，不会落在含义模糊的“latest”分组中。
希望 Capriole 的持续维护默认值随受支持版本更新时，可以使用别名。如果精确版本属于结果的一部分且必须可复现，则应使用具体 model ID。
List models endpoint提供当前公开清单。不要假定浏览器聊天中出现的模型会自动适用于每一种 API 协议。
Fallback 只在响应开始前发生
对于受支持的路由，如果第一个来源在发送任何响应字节前失败，Capriole 可以尝试另一个已配置来源。 流式响应开始后再切换来源，可能产生重复或互相矛盾的输出。因此，自动 fallback 只会在输出开始前运行。它无法掩盖所有提供商故障，也不能在响应进行到一半时更换模型。 通过受支持的来源 fallback 时，请求所用 model key 保持不变。Capriole 更改的是交付来源，不会改变用户明确选择的模型。 浏览器聊天还可以单独提供可选的自动模型切换，以及在对话中手动更换模型。这些属于工作区行为，不是原始 API fallback 契约。用量始终可见
程序化工作负载会被计量。Capriole 根据对应协议提供的 metadata 记录用量，在可获得用量信息时也包括已经完成的流式响应。 Premium 当前每月包含 500 万 API 计费 token。对于这份余额，Capriole 按 100% 计算未缓存输入和输出，按 10% 计算缓存输入。还可以通过 top-up 购买额外 token 包。Premium 的无限部分适用于受支持 Premium 模型范围内的浏览器聊天，不适用于 API 或编程智能体流量。 计费 token 文章提供准确公式、取整规则和可复现示例。 浏览器聊天与自动化 API 工作负载使用不同额度。编程智能体处理数百万 token 时，会消耗可见的计费 token 余额。统一层实际提供什么
共享层提供下面这些外围产品契约，不会把各协议改成同一种响应 schema。- 一个 Capriole 账户和 API key
- 一份可见的 API 余额
- 持续维护的模型别名
- 根据所选协议进行验证
- 在输出开始前使用受支持的来源 fallback
- 按解析后的模型记录用量
- 为应用和编程智能体提供设置文档
我们如何测试兼容性
一条路由只有在协议契约与具有代表性的真实客户端流程均通过后，才会被 Capriole 记录为受支持。成功返回一条文本提示词只是初步检查。流式响应、工具结果轮次、别名解析、用量计量和协议反向测试共同提供其余证据。 截至 2026-08-10，针对公共路由和文件转换的集中测试套件，已经在受控的上游响应上完成 68 项自动化测试，这些并非生产环境实时调用。另有本地上游和编程智能体运行，用于检查 mock endpoint 无法证明的行为。
流式检查会读取完整响应，并要求出现各协议自己的结束事件。Responses 以自己的 completion event 结束，Chat Completions 到达
[DONE]，Messages 则到达 message_stop。工具测试会把工具结果发回，并要求返回最终 assistant turn。
反向测试让协议边界保持可见。google-latest 在 Responses 上会失败，openai-latest 在 Messages 上也会失败。Capriole 不会把任何一个请求转移到其他 endpoint。
公共 API 文件支持使用单独的发布门槛。每条候选路由需要使用同一组小型图片、PDF、CSV 和 DOCX fixture，通过内容特定答案测试，在支持时重复流式测试，并记录准确的 SDK、model ID、请求结构和测试日期。实时 fixture 通过前，公共 API 文档会继续遵循每种原生协议支持的文件格式，不会宣传共享的 Capriole attachment field。