Jenseits von Ratenlimits: Skalierter Zugriff auf Codex und Sora

Im vergangenen Jahr haben sowohl Codex als auch Sora eine schnelle Verbreitung erfahren, wobei die Nutzung unsere ursprünglichen Erwartungen schnell übertraf. Wir haben ein konsistentes Muster beobachtet: Nutzer:innen steigen ein, erkennen echten Mehrwert und stoßen dann auf Ratenlimits.

Ratenlimits können helfen, die Nachfrage zu glätten und einen fairen Zugang zu gewährleisten; jedoch kann es frustrierend sein, wenn Nutzer:innen einen abrupten Stopp erleben, während sie gerade einen Nutzen daraus ziehen. Wir wollten eine Möglichkeit schaffen, damit Nutzer:innen weitermachen können, und gleichzeitig die Systemleistung und das Vertrauen der Nutzer:innen in unseren Ansatz schützen.

Um das Problem zu lösen, haben wir eine Echtzeit-Zugriffs-Engine entwickelt, die die Nutzung zählt. Eine der Funktionen dieser Engine ist die Möglichkeit, Credits zu erwerben. Wenn Nutzer:innen ihre Nutzungslimits überschreiten, können sie durch den Einsatz von Credits weiterhin unsere Produkte nutzen, indem sie ihr Credit-Guthaben aufbrauchen.

Darunter liegt ein komplexes System, das Limits, Echtzeit-Nutzungsverfolgung und Credit-Guthaben in einem einzigen Zugriffsmodell vereint. Dieser Beitrag erklärt, warum die Skalierung von Codex und Sora ein Umdenken bei der Zugriffskontrolle erforderte, wie ein nachweislich korrektes Echtzeitsystem Ratenlimits und Credits pro Anfrage kombiniert und wie diese Grundlage nun zusätzlichen Zugriff für beide Produkte ermöglicht.

Im größeren Kontext betrachtet, erzwingen traditionelle Zugriffsmodelle in der Regel eine Entscheidung:

• Nutzungslimits können anfangs hilfreich sein, aber hinterlassen eine schlechte Nutzererfahrung, wenn sie aufgebraucht sind: „Komm später wieder“.
• Nutzungsbasierte Abrechnung ist flexibel, aber Nutzer:innen zahlen ab dem ersten Token – nicht ideal zur Unterstützung der frühen Erkundungsphase

Für Codex und Sora war keine von beiden allein ausreichend. Wenn wir die Ratenlimits einfach erhöhen würden, würden wir wichtige Mechanismen zur Nachfragesteuerung und Fairness verlieren und nicht mehr in der Lage sein, alle zu bedienen. Wenn wir uns vollständig auf asynchrone nutzungsbasierte Abrechnung verlassen würden, würden wir Verzögerungen, Überschreitungen oder Abstimmungsprobleme einführen – genau die Art von Problemen, die Nutzer:innen bemerken, wenn sie am engagiertesten sind.

Was wir stattdessen benötigten, war ein einziges Hybridsystem, das Echtzeit-Limits mit einem nutzungsbasierten Zugang kombinierte:

Dieses System musste:

• Ratenlimits durchsetzen, bis sie erreicht sind
• Nahtloser Übergang zu Credits innerhalb derselben Anfrage
• die Entscheidung in Echtzeit treffen
• beim Nachverfolgen des Credit-Verbrauchs äußerst genau und prüfbar sein

Eine der wichtigsten konzeptionellen Änderungen, die wir vorgenommen haben, war, den Zugriff als Entscheidungswasserfall zu modellieren. Statt zu fragen „Ist das erlaubt?“, fragen wir: „Wie viel ist erlaubt und woher?“ Bei Zählung der Nutzung durchläuft das System die folgende Sequenz:

Dieses Modell zeigt, wie Nutzer:innen das Produkt wirklich erleben. Ratenlimits, Gratis-Tarife, Credits, Aktionen und Unternehmensberechtigungen sind allesamt nur Ebenen im selben Entscheidungsprozess. Aus der Nutzerperspektive „wechseln sie nicht das System“ – sie verwenden einfach weiterhin Codex und Sora. Deshalb wirken Credits unsichtbar: Sie sind einfach nur ein weiteres Element im Wasserfall.

Wir haben Drittanbieter-Plattformen für die nutzungsbasierte Abrechnung und Messung evaluiert, um den Credit-Verbrauch zu verwalten. Sie sind gut geeignet für die Rechnungsstellung und Berichterstattung, erfüllten jedoch zwei wesentliche Anforderungen nicht:

Wenn Nutzer:innen ein Limit erreicht und Credits verfügbar sind, muss das System sofort Bescheid wissen. Zählung nach bestem Wissen und Gewissen und verzögerte Zählung führen zu überraschenden Sperren, inkonsistenten Guthaben und falschen Abbuchungen. Bei interaktiven Produkten wie Codex und Sora werden diese Fehler sichtbar und frustrierend.

Wir mussten auch Transparenz in jedes Ergebnis bringen:

• Warum eine Anfrage erlaubt oder blockiert wurde
• Wie viel Nutzung verbraucht wurde
• Welche Limits oder Guthaben angewendet wurden

Diese Fähigkeit musste eng in unseren Entscheidungsprozess integriert werden, anstatt isoliert in einer separaten Nutzungsabrechnungsplattform gelöst zu werden, die nur einen Teil des Geschehens erfasste. Um den Nutzer:innen den Zugriff auf unsere Produkte zu ermöglichen, ohne das Vertrauen zu beeinträchtigen, benötigten wir die volle Kontrolle über Korrektheit, Timing und Beobachtbarkeit. Das hat uns zu einer internen Lösung bewegt.

Um dies zu ermöglichen, haben wir ein verteiltes Nutzungs- und Abrechnungssystem entwickelt, das speziell für synchrone Zugriffsentscheidungen konzipiert ist.

Auf übergeordneter Ebene leistet das System Folgendes:

• Erfasst die Nutzung pro Nutzer:in und pro Funktion
• Hält Ratenlimit-Fenster aufrecht
• Verwaltet Echtzeit-Credit-Guthaben
• Bucht Guthaben idempotent über einen Streaming-Async-Prozessor ab

Jede Anfrage durchläuft einen einzigen Evaluierungspfad, der in Echtzeit darüber entscheidet, wie viel Nutzung erlaubt ist, indem er synchron die Ratenlimits beansprucht und bei Bedarf ausreichende Guthaben überprüft; anschließend wird ein eindeutiges Ergebnis ausgegeben, während etwaige Credit-Abbuchungen asynchron verrechnet werden. Dies stellt ein konsistentes Verhalten über alle Produkte hinweg sicher und eliminiert doppelte Logik in verschiedenen Teams.

Eines der zentralen Designprinzipien dieses Systems ist, dass wir in der Lage sein müssen, nachzuweisen, dass unsere Abrechnung korrekt ist. Dies spiegelt die Wurzeln unseres Credit-Supports wider, der bei Unternehmenskund:innen ihren Ursprung hat. Im obigen Systemdiagramm haben wir drei separate Datensätze, die alle miteinander verbunden sind:

• Produktnutzungsereignisse: Was Nutzer:innen tatsächlich gemacht haben
• Monetarisierungsereignisse: Wofür wir Nutzer:innen die Nutzung in Rechnung stellen
• Guthabenaktualisierungen: Um wie viel wir das Guthaben von Nutzer:innen angepasst haben und warum

Diese Datensätze sind kein beiläufiges Nebenprodukt; sie treiben das System tatsächlich an, wobei jeder Datensatz den nächsten auslöst. Indem wir trennen, was passiert ist, alle zugehörigen Gebühren und was wir abgebucht haben, können wir jede Ebene unabhängig prüfen, erneut wiedergeben und abgleichen. Dies ist ein bewusster Kompromiss, bei dem wir die nachweisbare Korrektheit priorisieren, auch wenn dies bedeutet, dass die Aktualisierungen des Guthabens leicht verzögert sind. Wie wir das erreicht haben:

• Produktnutzungsereignisse werden für alle Nutzeraktivitäten veröffentlicht, unabhängig davon, ob sie den Credit-Verbrauch beeinflussen oder nicht. Dies bietet einen Prüfpfad für Nutzeraktivitäten und ermöglicht es uns, zu erklären, warum wir Credits berechnet oder nicht berechnet haben.
• Jedes Ereignis hat einen stabilen Idempotenzschlüssel, sodass Wiederholungsversuche, erneute Wiedergaben oder Worker-Neustarts niemals zu einer doppelten Belastung eines Guthabens führen können, was eine doppelte Abrechnung verhindert. Das ermöglicht es uns auch, eine Batch-Abstimmung durchzuführen, um unsere Arbeit offline zu verifizieren.
• Wir führen asynchrone (aber dennoch nahezu in Echtzeit erfolgende) Guthabenaktualisierungen statt synchroner Aktualisierungen durch, um einen Prüfpfad zu erstellen. Wir tolerieren eine kleine Verzögerung bei der Aktualisierung des Guthabens von Nutzer:innen, um nachzuweisen, dass das System funktioniert, und um unseren Nutzer:innen zu versichern, dass wir keine falschen Beträge in Rechnung stellen. Wenn diese kurze Verzögerung dazu führt, dass wir das Guthaben von Nutzer:innen überschreiten, erstatten wir es automatisch; wir legen mehr Wert auf nachweisbare Korrektheit und das Vertrauen der Nutzer:innen als auf strikte Durchsetzung.
• Wir verringern das Credit-Guthaben und fügen in einer einzigen atomaren Datenbanktransaktion einen Guthabenaktualisierung-Datensatz ein. Guthabenaktualisierungen werden pro Konto serialisiert, sodass gleichzeitige Anfragen niemals in einen Wettlauf geraten können, um dieselben Guthaben auszugeben. Der Guthabenaktualisierung-Datensatz enthält sowohl den Sollbetrag als auch die Zuordnung zum Monetarisierungsereignis, das die Aktualisierung ausgelöst hat. Die Einbettung in eine einzige Datenbanktransaktion stellt sicher, dass wir für jede Anpassung des Credit-Guthabens einen Prüfpfad haben.

All diese Sorgfalt verfolgt ein Ziel: den Zugang einfach und sicher zu gestalten. Wenn Menschen etwas erstellen oder programmieren, sollten sie sich keine Gedanken darüber machen müssen, ob eine Anfrage durchgeht, ob ihnen zu viel berechnet wird oder ob ihr Guthaben korrekt ist. Indem wir Nutzung, Abrechnung und Guthaben nachweislich korrekt gestalten, bieten wir Nutzer:innen ein System, das nicht von ihrem Erlebnis ablenkt. Das ist es, was uns ermöglicht, abrupte Stopps durch kontinuierlichen Zugriff zu ersetzen – und genau das ermöglicht es, Credits mitten in der eigentlichen Arbeit einzusetzen, nicht nur auf einer Rechnung.

Das Leitprinzip hinter unserem Ansatz ist der Schutz der Nutzerdynamik. Jede Architekturentscheidung führt zu einem Ergebnis, das sich konkret auf die Nutzer:innen auswirkt: Echtzeit-Guthaben verhindern unnötige Unterbrechungen, atomare Nutzung verhindert doppelte Abrechnungen, und eine einheitliche Zugriffslogik sorgt für vorhersehbares Verhalten. Das Ergebnis ist, dass Menschen länger arbeiten, tiefer erkunden und Projekte weiter vorantreiben können, ohne auf abrupte Stopps oder vorzeitige Planänderungen zu stoßen.

Wenn Nutzer:innen engagiert sind, sollte das System ihnen helfen, weiterzumachen, anstatt ihnen im Weg zu stehen. Limits und Credits verschwinden im Hintergrund.

Um diese Erfahrung zu schaffen, war es notwendig, Zugriff, Nutzung und Abrechnung als ein einheitliches System neu zu überdenken und eine Infrastruktur zu entwickeln, die Korrektheit als ein zentrales Produktmerkmal behandelt. Die gleiche Grundlage kann im Laufe der Zeit auf weitere Produkte ausgeweitet werden; Codex und Sora sind erst der Anfang.