Sari la conținutul principal
OpenAI

13 februarie 2026

Inginerie

Dincolo de limitele de rată: scalarea accesului la Codex & Sora

De Jonah Cohen, membru al personalului tehnic

Se încarcă…

În ultimul an, atât Codex, cât și Sora au fost adoptate rapid, iar utilizarea lor a depășit rapid așteptările noastre inițiale. Am observat un tipar constant: utilizatorii se implică, găsesc valoare reală și apoi se confruntă cu limite de rată.

Limitările de rată pot ajuta la uniformizarea cererii și la asigurarea unui acces echitabil; totuși, când utilizatorii obțin valoare, o oprire bruscă poate fi frustrantă. Ne-am dorit o modalitate prin care utilizatorii să poată continua, protejând performanța sistemului și încrederea lor în abordarea noastră.

Pentru a rezolva asta, am construit un motor de acces în timp real, care contorizează utilizarea. Unul dintre straturile acelui motor este capacitatea de a cumpăra credite. Când utilizatorii depășesc limitele de rată, creditele le permit să continue să folosească produsele noastre prin consumarea soldului de credite.

Sub acest sistem se află un sistem complex care îmbină limitele, urmărirea utilizării în timp real și soldurile de credit într-un singur model de acces. Această postare explică de ce scalarea Codex și Sora a necesitat regândirea controlului accesului, cum un sistem corect demonstrabil, în timp real, combină limitele de rată și creditele per solicitare și cum această fundație deblochează acum accesul suplimentar pentru ambele produse.

De ce modelele de acces existente au fost insuficiente

Privind în ansamblu, modelele tradiționale de acces tind să impună o alegere:

  • Limitele de rată pot fi utile la început, dar oferă utilizatorilor o experiență neplăcută când se epuizează: „revino mai târziu”
  • Facturarea bazată pe utilizare este flexibilă, dar îi face pe utilizatori să plătească de la primul token — ceea ce nu este ideal pentru a susține explorarea timpurie

Pentru Codex și Sora, niciuna dintre ele nu a fost suficientă de una singură. Dacă am mări pur și simplu limitele de rată, am pierde controale importante pentru uniformizare a cererii și echitate și am rămâne fără capacitatea de a-i deservi pe toți. Dacă ne-am baza în întregime pe facturarea asincronă în funcție de utilizare, am introduce întârzieri, depășiri sau probleme de reconciliere - exact genul de probleme pe care utilizatorii le observă atunci când sunt cei mai implicați.

Ceea ce aveam nevoie în schimb era un sistem hibrid unic, care să combine limitele în timp real cu accesul cu plată în funcție de utilizare:

Interfață de utilizare a tabloului de bord cu două butoane etichetate „Limite de rată” și „Credite” și un card dedesubt intitulat „Limită de rată cu rezervă de credit”.

Acest sistem trebuia să:

  • Aplică limitele de rată până când sunt atinse
  • Treci fără probleme la credite în cadrul aceleiași cereri
  • Ia decizia în timp real
  • Fie riguros de precis și auditabil atunci când urmărește consumul de credite

Acces ca o cascadă, nu ca o poartă

Una dintre schimbările conceptuale cheie pe care le-am făcut a fost modelarea accesului ca un lanț de decizii. În loc să întrebi „este permis?”, întrebăm noi „cât este permis și de unde?” Când se contorizează utilizarea, sistemul parcurge următoarea secvență:

Arbore decizional pentru evaluarea accesului la funcționalitățile noastre

Acest model reflectă cum trăiesc utilizatorii experiența produsului. Limitele de rată, nivelurile gratuite, creditele, promoțiile și drepturile enterprise sunt toate doar straturi în același stack de decizie. Din perspectiva unui utilizator, ei nu „schimbă sisteme” — pur și simplu continuă să folosească Codex și Sora. De aceea creditele par invizibile: sunt doar un alt element din cascadă.

De ce l-am construit intern

Am evaluat platforme de facturare și contorizare a utilizării de la terți pentru a gestiona consumul de credite. Sunt potrivite pentru facturare și raportare, dar nu au îndeplinit două cerințe critice:

Corectitudine în timp real

Când un utilizator atinge o limită și are credite disponibile, sistemul trebuie să știe imediat. Numărarea cu eforturi maxime sau întârziată apare sub formă de blocaje surpriză, solduri inconsecvente și taxe incorecte. Pentru produse interactive precum Codex și Sora, aceste eșecuri devin vizibile și enervante.

Reconciliabilitate și încredere

De asemenea, a trebuit să oferim transparență în fiecare rezultat:

  • De ce o solicitare a fost permisă sau blocată
  • Câtă utilizare a fost consumată
  • Ce limite sau solduri au fost aplicate

Această capabilitate trebuia să fie integrată strâns în cascada noastră de decizii, nu rezolvată izolat într-o platformă separată de facturare a utilizării, care vedea doar o parte din ceea ce se întâmpla. Pentru a le permite utilizatorilor să acceseze produsele noastre fără a compromite încrederea, aveam nevoie de control deplin asupra corectitudinii, sincronizării și observabilității. Acest lucru ne-a împins spre o soluție internă.

Construirea unui sistem de utilizare și echilibrare la scară înaltă

Pentru a susține acest lucru, am construit un sistem distribuit de utilizare și sold, conceput special pentru decizii sincrone de acces.

La un nivel înalt, sistemul:

  • Urmărește utilizarea per-utilizator, per-funcționalitate
  • Menține ferestrele de limitare a vitezei
  • Menține soldurile de credit în timp real
  • Debitează soldurile idempotent printr-un procesor asincron de streaming

Fiecare cerere trece printr-o singură cale de evaluare, care ia o decizie în timp real cu privire la câtă utilizare este permisă prin consumul sincron din limitele de rată și, dacă este necesar, verificarea existenței unor credite suficiente; apoi returnează un rezultat definitiv, în timp ce decontează asincron orice debit de credite. Acest lucru asigură un comportament consecvent între produse și elimină logica duplicată între echipe.

Sistem de acces: combinarea limitelor de rată în timp real și urmărirea asincronă a creditului & soldului.

Un sistem corect de facturare demonstrabil

Unul dintre principiile cheie de design ale acestui sistem este că trebuie să putem dovedi că facturarea noastră este corectă. Acest lucru reflectă originile asistenței noastre de credit, care a început cu clienții companii. În diagrama de sistem de mai sus, avem trei seturi de date separate, care sunt toate interconectate.

  • Evenimente de utilizare a produsului: ce a făcut utilizatorul de fapt
  • Evenimente de monetizare: pentru ce îi taxăm pe utilizatori pentru utilizarea lor
  • Actualizări ale soldului: cu cât am ajustat soldul de credit al utilizatorului și de ce

Aceste seturi de date nu sunt un produs secundar întâmplător; ele chiar pun sistemul în mișcare, fiecare set de date declanșându-l pe următorul. Separarea a ceea ce s-a întâmplat, a oricăror taxe asociate și a ceea ce am debitat ne permite să audităm, să reluăm și să reconciliem independent fiecare strat. Acesta este un compromis intenționat, unde prioritizăm corectitudinea demonstrabilă, cu prețul întârzierii ușoare a actualizărilor soldului de credite. Cum am reușit acest lucru:

  • Evenimentele de utilizare a produsului sunt publicate pentru toată activitatea utilizatorilor, indiferent dacă determină consumul de credite sau nu. Acest lucru oferă o pistă de audit pentru activitatea utilizatorilor și ne permite să explicăm de ce am taxat sau nu am taxat credite.
  • Fiecare eveniment are o cheie de idempotență stabilă, astfel încât reîncercările, reluările sau repornirile agentului nu pot debita niciodată de două ori un sold, prevenind astfel taxarea dublă. Acest lucru îți permite, de asemenea, să rulezi o reconciliere în lot pentru a-ți verifica munca offline.
  • Facem actualizări asincrone (dar totuși aproape în timp real) ale soldului în loc de actualizări sincrone, pentru a crea un istoric de audit. Tolerăm o mică întârziere în actualizarea soldului utilizatorului, astfel încât să putem demonstra că sistemul funcționează și să îi asigurăm pe utilizatorii noștri că nu îi facturăm greșit. Când acea scurtă întârziere ne face să depășim soldul de credite al unui utilizator, îl rambursăm automat; alegem corectitudinea demonstrabilă și încrederea utilizatorului în locul aplicării stricte.
  • Reducem Soldul de credit și inserăm o înregistrare Actualizare sold într-o singură tranzacție atomică de bază de date. Actualizările soldului sunt serializate pe cont, astfel încât cererile simultane nu pot concura niciodată pentru a cheltui aceleași credite. Înregistrarea Actualizare sold conține atât suma debitului, cât și atribuirea către evenimentul de monetizare care a declanșat actualizarea; includerea acesteia într-o singură tranzacție de bază de date garantează că avem o pistă de audit pentru fiecare ajustare a soldului de credit.

Toată această rigoare are un singur scop: să facă accesul simplu și sigur. Când oamenii creează sau scriu cod, nu ar trebui să se întrebe dacă o solicitare va fi procesată, dacă li se va percepe prea mult sau dacă soldul lor este corect. Făcând utilizarea, facturarea și soldurile demonstrabil corecte, le oferim utilizatorilor un sistem care nu le distrage atenția de la experiența lor. Asta ne permite să înlocuim opririle bruște cu acces continuu — și asta face ca aceste credite să fie utilizabile în mijlocul muncii reale, nu doar pe o factură.

Arhitectură în slujba impulsului

Principiul călăuzitor al abordării noastre este protejarea elanului utilizatorilor. Fiecare decizie arhitecturală se leagă de un rezultat orientat către utilizator: soldurile în timp real previn întreruperile inutile, consumul atomic previne dubla taxare, iar logica unificată de acces asigură un comportament previzibil. Rezultatul este că oamenii pot lucra mai mult, pot explora mai în profunzime și pot duce proiectele mai departe fără să se lovească de opriri bruște sau de schimbări premature ale planului.

Când utilizatorii sunt implicați, sistemul ar trebui să-i ajute să continue, nu să le stea în cale. Limitele și creditele dispar în fundal.

Construirea acelei experiențe a necesitat regândirea accesului, utilizării și facturării ca un singur sistem și dezvoltarea unei infrastructuri care tratează corectitudinea ca o caracteristică de produs de primă clasă. Aceeași fundație se poate extinde la mai multe produse în timp; Codex și Sora sunt doar începutul.

Autor

Jonah Cohen

Mulțumiri

Mulțumiri speciale întregii echipe FinEng care a construit creditele.