计算公式
Capriole 会把每种受支持协议统一换算成输入 token 总数。如果所选提供商报告缓存输入，还会记录缓存输入数量。缓存输入是输入总数的一个子集。
对于 Anthropic Messages，cache creation 仍按 100% 输入计算。只有提供商报告的 cache reads 才能按 10% 计算计费 token。
三个可复现示例
第三个请求的原始输入加输出 token 总数为 228,897。由于提供商报告其中 228,224 个输入 token 已缓存，它会扣除 23,496 个计费 token。
每条请求会单独对缓存部分取整。因此，一个缓存输入 token 在
ceil(0.1) 后计费一个 token，十个缓存输入 token 也计费一个 token。
估算 500 万计费 token 可以处理多少请求
请使用自己 API 用量中的平均计费 token，不要根据原始上下文长度猜测。
这些行只是用于规划的算术示例，不代表典型工作负载。一条简短分类调用和一轮较长的编程智能体交互，可能相差几个数量级。输出长度、重复上下文、提供商报告的 cache hit 和工具结果都会改变实测平均值。
计费 token 与提供商价格使用不同单位
官方提供商可能分别公布输入、缓存输入、缓存写入、输出、工具或长上下文价格。Capriole 的计费 token 余额是一种客户配额单位，在受支持的公共 API 路由中统一采用一种公式。
不要用计费 token 乘以提供商公布的输入或输出费率。它们描述不同的计费系统。
带日期的 API 成本对比把这套公式应用到一种固定的 500 万 token 工作负载，再比较各服务的现金成本。
个人与 Team 余额边界
系统会先消耗内含配额，再消耗相应的个人或 Team top-up wallet。购买的 top-up 余额可以跨月度配额周期和付费访问中断继续保留，实际使用时仍要求符合条件的有效付费访问。浏览器聊天与 API 计量分开，编程智能体属于 API 流量，会扣除计费 token。
每月 500 万额度属于完整的 USD 8 Premium 工作区会员。它不是无限 API 方案，也不应被描述为独立 API 价格。
Top-up 用于扩展程序化用量，不会改变浏览器聊天额度、模型兼容性，也不会取消有效个人或 Team 访问权限要求。
API 记录什么
Capriole 会把经过协议统一的用量和计费用量记录为不同字段。一次成功的公共 API 请求可以记录以下数据。- 统一后的输入 token
- 输出 token
- 统一后的输入加输出 token
- 提供商报告的缓存输入 token
- 从配额中扣除的计费 token
- 解析后的模型和请求状态
POST /v1/chat 响应会在 usage 中提供 cached_tokens 和 charged_tokens。与协议兼容的 Responses、Chat Completions 和 Messages endpoint 保留各自的上游响应结构，Capriole 同时为账户用量记录相应的计费 token。
确认缓存输入是否减少了扣费
打开 Capriole AI API 页面，再使用 Key、Model 和 Status 筛选条件找出请求。比较用量表格中的这些列。
缓存 token 大于零，可以确认兼容的提供商用量 metadata 报告了 cache hit。它无法证明每个重复请求都会命中相同的提供商缓存。提供商路由、缓存时限、请求结构和模型行为都可能改变结果。
对于 Capriole-native
POST /v1/chat，同样可以检查 usage.cached_tokens 和 usage.charged_tokens。其他协议响应会保留上游 schema，因此账户用量表是跨路由比较请求的一致位置。