Au-delà des limites de débit : élargir l'accès à Codex et Sora

Au cours de la dernière année, Codex et Sora ont tous deux connu une adoption rapide, l’utilisation dépassant rapidement ce que nous avions initialement prévu. Nous avons observé un schéma récurrent : les utilisateurs s'engagent, découvrent une véritable valeur, puis rencontrent des limites de débit.

Les limites de débit peuvent aider à lisser la demande et à assurer un accès équitable; cependant, lorsque les utilisateurs obtiennent de la valeur, se heurter à un arrêt brutal peut être frustrant. Nous souhaitions offrir aux utilisateurs un moyen de continuer tout en préservant les performances du système et la confiance des utilisateurs dans notre approche.

Pour résoudre ce problème, nous avons construit un moteur d’accès en temps réel qui compte l’utilisation. Une des couches de ce moteur est la possibilité d’acheter des crédits. Lorsque les utilisateurs dépassent leurs limites de débit, les crédits leur permettent de continuer à utiliser nos produits en utilisant leur solde de crédits.

Sous ce système se trouve un système complexe qui intègre les limites, le suivi de l'utilisation en temps réel et les soldes de crédit dans un modèle d'accès unique. Cet article aborde pourquoi l'extension de Codex et Sora a nécessité de repenser le contrôle d'accès, comment un système en temps réel, prouvé correct, intègre des limites de débit et des crédits par demande, et comment cette base permet désormais un accès supplémentaire pour les deux produits.

En prenant du recul, les modèles d’accès traditionnels tendent à imposer un choix :

• Les limites de débit peuvent être utiles au début, mais elles laissent les utilisateurs avec une mauvaise expérience lorsqu'ils les atteignent : « revenez plus tard »
• La facturation basée sur l’utilisation est flexible, mais laisse les utilisateurs payer dès le premier token — ce qui n’est pas idéal pour soutenir une exploration précoce

Pour Codex et Sora, aucun des deux n'était suffisant à lui seul. Si nous augmentions simplement les limites de débit, nous perdrions d’importants mécanismes de lissage de la demande et de contrôle de l’équité, et nous manquerions de capacité pour servir tout le monde. Si nous nous appuyions entièrement sur la facturation d’utilisation asynchrone, nous introduirions de la latence, des dépassements ou des problèmes de rapprochement—précisément le genre de problèmes que les utilisateurs remarquent lorsqu’ils sont le plus engagés.

Ce dont nous avions besoin, c’était d’un système hybride unique combinant des limites en temps réel et un accès avec paiement à l’utilisation :

Ce système devait :

• Appliquer les limitations de débit jusqu’à ce qu’elles soient atteintes
• Passez en toute fluidité aux crédits dans la même demande
• Prendre cette décision en temps réel
• Être rigoureusement précis et auditable lors du suivi de la consommation de crédits

L’un des principaux changements conceptuels que nous avons apportés a été de modéliser l’accès comme un processus décisionnel en cascade. Au lieu de demander « est-ce permis? », nous demandons « combien est permis et d’où? » Lors du calcul de l'utilisation, le système suit la séquence suivante :

Ce modèle reflète comment les utilisateurs perçoivent réellement l'expérience du produit. Les limites de débit, les niveaux gratuits, les crédits, les promotions et les droits d'accès d'entreprise ne sont que des couches dans la même pile de décision. Du point de vue de l’utilisateur, il ne « change pas de système » — il continue simplement d’utiliser Codex et Sora. C’est pourquoi les crédits semblent invisibles : ils ne sont qu’un autre élément de la cascade.

Nous avons évalué des plateformes tierces de facturation et de mesure de l'utilisation pour gérer la consommation de crédits. Ils conviennent bien à la facturation et aux rapports, mais ne satisfaisaient pas à deux exigences essentielles :

Lorsqu’un utilisateur atteint une limite et dispose de crédits, le système doit en être informé immédiatement. Le comptage au mieux ou différé se traduit par des blocages inattendus, des soldes incohérents et des frais incorrects. Pour les produits interactifs tels que Codex et Sora, ces échecs deviennent visibles et frustrants.

Nous devions également offrir une transparence sur chaque résultat :

• Pourquoi une demande a été autorisée ou bloquée
• Quelle quantité d'utilisation a été consommée
• Quelles limites ou équilibres ont été appliqués

Cette fonctionnalité devait être intégrée de manière étroite dans notre cascade de décisions, plutôt que d'être résolue isolément dans une plateforme de facturation distincte qui ne voyait qu'une partie de la situation. Pour permettre aux utilisateurs d’accéder à nos produits sans compromettre la confiance, nous devions avoir un contrôle total sur l’exactitude, le moment opportun et la capacité d'observation. Cela nous a orientés vers une solution interne.

Pour ce faire, nous avons mis en place un système d'utilisation et d'équilibrage distribué spécialement conçu pour les décisions d'accès synchrones.

À un niveau élevé, le système :

• Suit l'utilisation par utilisateur et par fonctionnalité
• Maintient les fenêtres de limitation de débit
• Maintient les soldes de crédit en temps réel
• Débite les soldes de manière idempotente à l'aide d'un processeur asynchrone en flux continu

Chaque demande passe par un parcours d’évaluation unique qui prend une décision en temps réel sur la quantité d'utilisation autorisée en consommant de manière synchrone les limites de débit et, si nécessaire, en vérifiant la suffisance des crédits; elle renvoie ensuite un résultat définitif tout en réglant de manière asynchrone tout débit de crédits. Cela garantit un comportement cohérent à travers les produits et élimine la duplication de logique entre les équipes.

L’un des principes clés de conception de ce système est que nous devons pouvoir prouver que notre facturation est correcte. Cela reflète les racines de notre soutien en crédit, qui ont pris naissance avec des clients d'entreprise. Dans le schéma du système ci-dessus, nous avons trois ensembles de données distincts qui sont tous interconnectés :

• Événements d’utilisation du produit : Ce que l’utilisateur a vraiment fait
• Événements de monétisation : Ce que nous facturons à l'utilisateur pour son utilisation
• Mises à jour du solde : Le montant de l’ajustement du solde de crédit de l’utilisateur et la raison de cet ajustement

Ces ensembles de données ne sont pas un simple sous-produit : ils pilotent réellement le système, chaque ensemble de données déclenchant le suivant. La séparation de ce qui s'est produit, des frais associés et de ce que nous avons débité nous permet de vérifier, de rejouer et de rapprocher chaque couche de manière indépendante. Il s'agit d'un compromis intentionnel où nous privilégions l'exactitude vérifiable, au détriment d'une mise à jour légèrement retardée du solde de crédit. Comment nous l'avons réalisé :

• Les événements d’utilisation du produit sont publiés pour toute activité utilisateur, qu'elle entraîne ou non une consommation de crédits. Cela fournit une piste d’audit de l’activité des utilisateurs et nous permet d’expliquer pourquoi nous avons facturé ou n’avons pas facturé de crédits.
• Chaque événement comporte une clé d'idempotence stable, de sorte que les nouvelles tentatives, les relectures ou les redémarrages des travailleurs ne peuvent jamais débiter deux fois un solde, ce qui empêche les doubles facturations. Cela nous permet également d'effectuer un rapprochement par lot pour vérifier notre travail hors ligne.
• Nous effectuons des mises à jour asynchrones (mais toujours en temps quasi réel) du solde au lieu de mises à jour synchrones afin de créer une piste d'audit. Nous tolérons un léger délai dans la mise à jour du solde de l’utilisateur afin de prouver que le système fonctionne et d’assurer à nos utilisateurs que nous ne les facturons pas incorrectement. Lorsque ce bref délai nous amène à dépasser le solde de crédit d’un utilisateur, nous le remboursons automatiquement; nous privilégions l’exactitude vérifiable et la confiance des utilisateurs plutôt que l'application stricte des règles.
• Nous réduisons le solde de crédit et insérons un enregistrement de mise à jour du solde dans une transaction atomique unique de base de données. Les mises à jour de solde sont sérialisées par compte, ce qui empêche les demandes concurrentes de dépenser les mêmes crédits. L’enregistrement mise à jour du solde contient à la fois le montant du débit et l’attribution à l’événement de monétisation qui a déclenché la mise à jour; en encapsulant cela dans une seule transaction de base de données, nous garantissons une piste d’audit pour chaque ajustement du solde de crédit.

Toute cette rigueur soutient un objectif : rendre l’accès simple et sécuritaire. Lorsque les gens créent ou codent, ils ne devraient pas avoir à se demander si une demande sera acceptée, s'ils seront surfacturés ou si leur solde est exact. En rendant l’utilisation, la facturation et les soldes indubitablement corrects, nous offrons aux utilisateurs un système qui ne perturbe pas leur expérience. C’est ce qui nous permet de remplacer les arrêts brusques par un accès continu, et c’est ce qui rend les crédits utilisables en plein travail réel, pas seulement sur une facture.

Le principe directeur de notre approche est de protéger la continuité de l'expérience utilisateur. Chaque décision architecturale se traduit par un résultat visible pour l’utilisateur : les soldes en temps réel préviennent les interruptions inutiles, la consommation atomique empêche la double facturation et une logique d’accès unifiée assure un comportement prévisible. Il en résulte que les gens peuvent travailler plus longtemps, explorer plus en profondeur et mener les projets plus loin sans se heurter à des blocages ou à des changements de plan prématurés.

Lorsque les utilisateurs sont engagés, le système devrait les aider à continuer, pas les gêner. Les limites et les crédits disparaissent à l’arrière-plan.

La création de cette expérience a nécessité de repenser l’accès, l’utilisation et la facturation comme un système unique et de bâtir une infrastructure qui considère l’exactitude comme une caractéristique produit de premier ordre. La même base peut s'étendre à d'autres produits au fil du temps; Codex et Sora ne sont que le commencement.