在過去一年中，Codex 和 Sora 的採用速度迅速，使用率很快就超出了我們的預期。我們觀察到一個一致的模式：使用者一開始深入使用、發現真正的價值，接著便遇到速率限制。
速率限制有助於平衡需求並確保公平存取；然而，當使用者正在獲得價值時，遇到硬性中止可能會令人沮喪。我們希望有一種方法讓使用者可以繼續使用，同時保護系統效能和使用者對我們方法的信任。
為了解決這個問題，我們建立了一個即時存取引擎，用來計算使用量。該引擎的一個層面是購買額度的能力。當使用者超過其速率限制時，信用額度可讓他們扣除餘額來繼續使用我們的產品。
在這之下是一個複雜的系統，將限額、即時使用追蹤和信用餘額融合在單一存取模型中。本文探討為何在擴展 Codex 和 Sora 時需要重新考慮存取控制、如何透過可證明正確的即時系統將速率限制與每次要求的額度結合，以及這樣的基礎如何為這兩項產品釋放更多的存取權限。
從更宏觀的角度來看，傳統的存取模式往往迫使人們在以下選項之間做出取捨：
- 速率限制一開始可能很有幫助，但當使用者達到上限時，體驗會變差：「稍後回來」
- 依使用量計費很有彈性，但會讓使用者從第一個 token 開始付費，不利於支援早期探索
對於 Codex 和 Sora 來說，單靠任何一方都不夠。如果只是提高速率限制，我們將失去重要的需求平滑和公平性控制，並可能會耗盡容量，無法為所有人提供服務。如果我們完全依賴非同步使用量計費，可能會導致延遲、超額支出或對帳問題—這些正是使用者在最投入時最容易注意到的問題。
我們需要的是一個單一的混合系統，結合即時限額與隨用隨付存取：
這個系統必須：
- 執行速率限制直到達到上限
- 在同一個要求中順暢轉換至額度
- 即時做出決定
- 在追蹤額度使用量時，務必保持嚴格的精確性並確保可供稽核
我們做出的其中一項關鍵概念轉換，是將存取建模為決策瀑布。與其問「這樣可以嗎？」，我們會問「允許多少，從何而來？」在計算使用量時，系統會依序執行以下流程：
此模型反映了使用者實際的產品體驗。速率限制、免費方案、額度、促銷活動和企業權益都只是同一個決策堆疊中的層次。從使用者的角度來看，他們不會「切換系統」，而是繼續使用 Codex 和 Sora。這就是為什麼額度感覺像是隱形的：只是瀑布流中的另一個元素。
我們評估了第三方使用量計費與監測平台，以管理點數消耗。非常適合用於開立發票和製作報告，但未能滿足兩個關鍵要求：
使用者達到上限且有可用額度時，系統必須立即得知。盡力點算或延遲點算會顯示為意外障礙、不一致的餘額和錯誤的費用。對於像 Codex 和 Sora 這類互動式產品，這些失敗會變得顯而易見且令人沮喪。
我們也需要透明呈現每個結果：
- 為什麼要求會得到允許或遭到阻擋
- 消耗多少使用量
- 套用哪些限制或餘額
這項功能需要與我們的決策瀑布緊密整合，而不是在單獨的用量計費平台中解決，因為該平台只能看到整體情況的一部分。為了讓使用者在不犧牲信任的情況下存取我們的產品，我們必須對正確性、時機和可觀測性擁有完全的掌控權。這促使我們轉為採用內部解決方案。
為了支援這項功能，我們打造了一套分散式的使用狀況與餘額系統，專門為同步存取決策而設計。
從高層次來看，該系統：
- 追蹤每位使用者、每個功能的使用情況
- 維持速率限制窗口
- 維持即時信用餘額
- 透過串流非同步處理器以冪等方式扣除餘額
每個要求都會經過單一路徑進行評估，該路徑會同步消耗速率限制，並在需要時驗證是否有足夠的額度，以即時決定允許的使用量。然後會在非同步結算任何額度扣款的同時，回傳一個明確的結果。這確保了各產品之間的行為一致，並消除不同團隊的重複邏輯。
本系統的一個關鍵設計原則是，我們必須能夠證明計費是正確的。這反映了我們的信用支援起源於企業客戶。在上述系統示意圖中，我們有三個獨立但相互關聯的資料集：
- 產品使用狀況事件： 使用者實際執行的操作
- 營利事件： 我們對使用者收取的使用費用
- 餘額更新：我們調整使用者信用餘額的金額及其原因
這些資料集並不是偶然的副產品；它們實際上驅動了系統，每個資料集都會觸發下個資料集。將發生的事件、相關的費用和借記的項目分開，讓我們可以獨立稽核、重播和核對每一層。這是刻意權衡的結果，我們優先考量可證明的正確性，代價是信用餘額的更新會稍微延遲。如何達成這個目標：
- 所有使用者活動都會發布產品使用事件 (無論是否會驅動額度消耗)。這提供了使用者活動的稽核軌跡，讓我們能夠解釋為什麼收取或未收取額度。
- 每個事件都帶有穩定的冪等性鍵，因此重試、重播或工作程序重新啟動都不會導致餘額重複扣款，進而避免重複收費。這也讓我們執行批次對帳，以便在離線時驗證我們的工作。
- 我們採用非同步 (但仍接近即時) 的餘額更新，而非同步更新，以建立稽核記錄。我們容許在更新使用者餘額時出現小幅延遲，以便我們證明系統正常運作，並讓使用者放心我們不會錯誤計費。當短暫的延遲導致超出使用者的信用餘額時，我們會自動退款；我們選擇可證明的正確性和使用者信任，而非嚴格執行。
- 我們會在單一原子資料庫交易中減少信用餘額，並插入一筆 餘額更新 記錄。餘額更新會依帳戶序列化，因此同時發出的要求不會競相使用相同的額度。餘額更新記錄包含借方金額和觸發更新的營利事件的歸因；將其包裝在單一資料庫交易中，確保每次對信用餘額的調整都有稽核記錄。
所有這些嚴謹的作法都支持一個目標：讓存取變得簡單且安全。人們在創作或編寫程式時，不該擔心要求是否會通過、是否會被多收費，或是餘額是否正確。透過確保使用情況、計費和餘額的正確性，我們為使用者提供一個不會干擾使用體驗的系統。這就是為什麼我們能持續存取，而非硬性中斷—也讓我們能夠在實際工作中使用點數，而不只是在發票上。
我們方法背後的指導原則是保護使用者的動力。每一項架構決策都回溯到使用者可感知的成果：即時餘額可避免不必要的中斷，原子化扣點可防止重複收費，而統一的存取邏輯則確保行為可預期。結果是，人們可以工作更久、探索得更深入，並在不遇到硬性中斷或過早變更計畫的情況下，將專案推進得更遠。
使用者投入時，系統應該協助他們繼續，而不是妨礙他們。限額和額度會消失在背景中。
打造這種體驗需要將存取、使用和計費視為一個系統來重新思考，並建立將正確性視為一流產品功能的基礎架構。隨著時間，同樣的基礎可以延伸到更多的產品；Codex 和 Sora 只是一個開始。
