过去一年里，Codex 和 Sora 的采用速度迅猛，使用量远超最初预期。我们发现了一种清晰的规律：用户一旦深入使用并获得真实价值，很快就会触及速率上限。

速率限制有助于平衡需求、保障公平，但当用户在高效创作过程中遇到强制中断，难免会感到沮丧。我们希望在保障系统性能与用户信任的前提下，让用户能够不中断地继续使用。

为此，我们构建了一套实时访问引擎，用于精确统计使用量。其中一项关键机制，是支持购买额度。当用户超出速率限制时，可以通过消耗额度余额继续使用产品。

在这背后，是一种将限额控制、实时使用追踪与额度余额整合为统一访问模型的复杂系统。本文将介绍：为什么在扩展 Codex 和 Sora 时必须重构访问控制机制；一种可验证正确的实时系统如何在单次请求中融合速率限制与额度；以及这套基础设施如何为两款产品带来更灵活的访问能力。

从更宏观的角度来看，传统访问模式往往迫使我们在两种方案之间做取舍：

对于 Codex 和 Sora 来说，单一模式都不足以满足需求。如果单纯提高速率上限，就会削弱需求调节与公平机制，甚至影响整体服务能力。如果完全依赖异步计费，则可能引入延迟、超额或对账问题 — 而这些问题，往往在用户最投入时最容易被察觉。

因此，我们真正需要的是一个融合实时限额与即用即付能力的混合访问系统。

这套系统必须能够：

我们做出的一个关键转变，就是将访问机制建模为决策瀑布。与其问“是否允许？”，不如问“具体允许多少？从哪里扣减？”在计算使用量时，系统会按既定顺序逐层判断：

这种模型更贴近用户的真实体验。速率限制、免费层次、额度、促销权益、企业权限，本质上只是同一决策体系中的不同层级。对用户而言，他们并不会感知到“系统切换”，而只是持续使用 Codex 和 Sora。也正因如此，额度机制几乎是无感的 — 它只是决策瀑布中的一层。

我们曾评估第三方计费与计量平台来处理额度消耗。它们适合开票与报表场景，但无法满足两个核心要求：

当用户达到上限且仍有可用额度时，系统必须立即做出判断。延迟或“尽力而为”的计数，可能导致意外阻断、余额不一致或错误扣费。对于 Codex 和 Sora 这样的实时交互产品，这类问题会直接影响体验。

我们还需要对每一次决策保持透明：

这项能力必须深度整合进决策瀑布，而不能交由一个只掌握局部数据的独立计费平台处理。要在不损害信任的前提下开放访问，我们必须完全掌控正确性、时效性与可观测性。因此，我们选择了自建系统。

我们打造了一套分布式使用与余额系统，专门支持同步访问决策。

从整体架构来看，该系统能够：

每个请求都会进入统一评估路径：系统同步消耗速率额度，并在必要时校验额度是否充足，实时返回最终访问结果；额度扣减则在后台异步结算。这样既保证了跨产品的一致行为，也避免了团队间重复实现逻辑。

该系统的核心设计原则是：我们必须能够证明计费是正确的。这一理念源自我们为企业客户提供额度支持的实践。该系统将数据拆分为三类：

这些数据并非附属产物，而是驱动系统运行的核心机制，彼此依次触发。将“发生了什么”“产生了什么费用”“实际扣减多少额度”分离，使我们能够对每一层独立审计、重放与对账。这是一种有意识的权衡：我们优先确保可验证的正确性，即便余额更新会存在轻微延迟。具体实现方式如下：

所有这些严谨设计，都服务于一个目标：让访问更简单、更可靠。当用户创作或编写代码时，不必担心请求是否成功、是否被误扣费用，或余额是否准确。通过让使用、计费与余额具备可验证的正确性，我们提供了一个不会干扰创作体验的系统。这让我们能够用连续访问替代硬性中断，也让额度在真实工作过程中自然发挥作用，而不仅仅体现在账单上。

我们的核心原则是保护用户的创作动量。每一个架构决策，都对应一个用户体验结果：实时余额减少不必要中断，原子扣减防止重复计费，统一访问逻辑确保行为可预测。最终，用户可以更长时间地工作、更深入地探索，并将项目推进到更远的阶段，全程不会遭遇强制中断，也无需过早调整计划。

当用户高度投入时，系统应提供助力，而非制造阻碍。限额与额度退居幕后。

实现这一体验，需要将访问、使用与计费视为一个统一系统重新设计，并将“正确性”作为核心产品能力来构建基础设施。这套基础架构未来可扩展至更多产品 — Codex 和 Sora 只是起点。