過去一年，Codex 和 Sora 均獲得快速採用，其使用量迅速超出我們最初的預期。我們觀察到一個固定的模型：用戶開始使用、發現真正的價值，然後便會觸及速率限制。
速率限制有助於平穩需求並確保公平存取；然而，當用戶正在獲取價值時，遭遇硬性中斷可能會令人沮喪。我們希望找到一種方法，既能讓用戶持續使用，同時又能保護系統性能及用戶對我們方法的信任。
為了解決這個問題，我們構建一個計算用量的實時存取引擎。該引擎的其中一層功能，就是購買信用積分的能力。當用戶超出其速率限制時，信用積分允許他們透過消耗信用積分餘額來繼續使用我們的產品。
其背後是一個將限制、實時用量追蹤和信用額度餘額結合在單一存取模型內的複雜系統。本文將闡述：為何擴展 Codex 和 Sora 需要重新思考存取控制、一個可證明正確的實時系統如何融合每個請求的速率限制與信用額度，以及這個基礎現在如何為兩個產品釋放額外的存取能力。
總體來看，傳統的存取模型往往迫使我們做出選擇：
- 使用限制起初有幫助，但當用戶用完時會留下不良體驗：「請稍後再來」
- 按使用量計費基於用量的計費很靈活，但讓用戶從第一個 Token 就開始付費——不利於支持早期探索
對於 Codex 和 Sora 而言，兩者本身均不足夠。如果我們單純提高速率限制，將會失去重要的需求平穩與公平性控制，並耗盡服務所有人的容量。如果我們完全依賴非同步用量計費，則會引入延遲、超額收費或對帳問題——這正是用戶在最投入時會注意到的問題類型。
我們需要的，反而是一個結合實時限制與隨用隨付存取的單一混合系統：
這個系統必須：
- 執行速率限制直至達到上限
- 在同一個請求內無縫過渡至使用信用積分
- 即時作出決定
- 在追蹤信用額度消耗時具備嚴謹的準確性和可審計性
我們所做的一個關鍵概念轉變，是將存取模型化為一個決策瀑布流。我們不問「這是否允許？」,而是問「允許多少，以及從哪裡扣除？」在計算用量時，系統會遵循以下順序：
這個模型反映用戶實際體驗產品的方式。速率限制、免費層級、信用額度、促銷活動和企業權限，都只是同一個決策堆疊中的不同層次。從用戶的角度來看，他們並沒有「切換系統」——他們還是持續使用 Codex 和 Sora。這就是為甚麼信用額度讓人感覺是隱形的：它們只是瀑布流中的另一個元素。
我們曾評估使用第三方用量計費和計量平台來處理信用額度消耗。這些平台非常適合處理發票和報告，但未能滿足兩個關鍵要求：
當用戶觸及限制但仍有可用信用額度時，系統必須立即知曉。盡力而為或延遲的計數會可能導致意外中斷、不一致餘額和錯誤計費。對於像 Codex 和 Sora 這類互動式產品，這些失誤會十分明顯且令人沮喪。
我們還需要為每一個結果提供透明度：
- 為何某個請求被允許或拒絕
- 消耗多少用量
- 適用哪些限制或餘額
這項能力需要緊密整合到我們的決策瀑布，而不能在一個僅掌握局部情況的獨立用量計費平台中孤立地解決。為了讓用戶存取我們的產品而不損害信任，我們需要完全掌控正確性、時序和可觀測性。這促使我們轉向自主建構解決方案。
為實現此目標，我們構建一個專為同步存取決策而設計的分佈式用量與餘額系統。
從高層次來看，該系統：
- 追蹤每位用戶、每個功能的使用
- 維護速率限制窗口
- 維護實時信用積分餘額
- 通過串流非同步處理器以冪等方式扣除餘額
每個請求都會經過統一的評估路徑，該路徑可實時決定允許使用多少用量，其方式是同步消耗速率限制來，在必要時檢驗信用額度是否充足；然後返回一個確定的結果，同時以非同步方式處理任何信用額度扣減。這樣可確保不同產品行為的一致性，並消除跨團隊的重複邏輯。
這個系統的一個關鍵設計原則是，我們必須能夠證明我們的計費是正確的。這一理念源自我們為企業客戶提供信用額度支持的實踐。在上述系統圖中，我們有三個獨立的資料集，彼此相互關聯：
- 產品使用事件：用戶實際執行的操作
- 計費事件：我們向用戶收取其使用服務的費用
- 餘額更新：我們調整用戶信用額度餘額的數額的數量及原因
這些數據集並非隨意的副產品，而是實際驅動著系統，彼此依次觸發。將發生的事件、任何相關收費以及我們扣減的額度數量分離開來，讓我們能夠對每一層進行獨立審計、重播和對帳。這是一個有意的權衡取捨：我們優先考慮可證明的正確性，代價是信用額度餘額更新的輕微延遲。具體實現方式：
- 所有用戶活動都會發布產品使用事件，無論其是否驅動信用額度消耗。這為用戶活動提供審計軌跡，並讓我們能夠解釋收取或未收取信用額度的原因。
- 每個事件都帶有一個穩定的冪等鍵，因此重試、重播或工作進程重啟永遠不會對餘額進行雙重扣款，從而防止重複收費。這也讓我們可以進行批量對帳，以離線驗證我們的工作。
- 我們進行非同步（但仍接近實時）的餘額更新，而非同步更新，以創建審計軌跡。我們容許更新用戶餘額時有少量延遲，以便我們能夠證明系統運作正常，並向用戶保證我們沒有錯誤計費。如這種短暫延遲導致我們超額扣減用戶的信用額度餘額，我們會自動退款；我們選擇可證明的正確性和用戶信任，而非嚴格的強制執行。
- 我們在單個的原子數據庫事務中減少信用額度餘額並插入一條餘額更新記錄。餘額更新是按帳戶進行串行處理，避免並發請求競爭使用同一筆信用額度。餘額更新記錄同時包含扣款金額以及指向觸發該更新的變現事件的歸因；將這些納入單一數據庫事務中，確保我們對每次信用額度餘額調整都有審計軌跡。
所有這些嚴謹設計都服務於一個目標：讓存取變得簡單且安全。當用戶在創作或編寫代碼時，不應擔心請求能否通過、是否會被多收費，或者餘額是否準確。在讓用量、計費和餘額可證明正確後，我們為用戶提供一個不會干擾體驗的系統。這正是我們能以持續存取取代硬性中斷的原因——也使得信用額度能在實際工作中間發揮作用，而不是僅僅是體現在帳單上。
就我們方法而言，其背後的指導原則是保護用戶的動能。每一個架構決策都對應著一個面向用戶的結果：實時餘額防止不必要的中斷，原子性消費防止重複收費，統一的存取邏輯確保行為可預測。其結果是，用戶可以工作更長時間、探索更深入，並將項目推進得更遠，而不會面臨硬性中斷，也無需提前變更計劃。
當用戶投入時，系統應該幫助他們繼續，而不是成為阻礙。限制和信用積分退居幕後。
為實現這種體驗，需要將存取、使用和計費作為一個單一系統重新構思，並建立將正確性視為一等產品特性的基礎設施。相同的基礎未來可擴展到更多產品；Codex 和 Sora 只是一個開始。
