Más allá del límite de velocidad: ampliando acceso a Codex y Sora

En el último año, tanto Codex como Sora experimentaron una rápida adopción, con un uso que rápidamente superó lo que originalmente esperábamos. Observamos un patrón constante: los usuarios se sumergen, encuentran un valor real y, luego, se topan con límites de velocidad.

Los límites de uso pueden ayudar a equilibrar la demanda y asegurar un acceso equitativo; sin embargo, cuando los usuarios están obteniendo valor, toparse con un límite rígido puede ser frustrante. Queríamos una manera para que los usuarios continuaran, mientras protegíamos el rendimiento del sistema y la confianza de los usuarios en nuestro enfoque.

Para resolver esto, desarrollamos un motor de acceso en tiempo real que contabiliza el uso. Una de las capas de ese motor es la posibilidad de comprar créditos. Cuando los usuarios exceden sus límites de tasa, los créditos les permiten seguir usando nuestros productos al reducir su saldo de crédito.

Debajo de esto hay un sistema complejo que integra límites, monitoreo del uso en tiempo real y saldos de crédito en un único modelo de acceso. Esta publicación cubre por qué escalar Codex y Sora requirió replantear el control de acceso, cómo un sistema en tiempo real y demostrablemente correcto combina límites de tasa y créditos por solicitud, y cómo esa base ahora desbloquea acceso adicional para ambos productos.

Ampliando la perspectiva, los modelos de acceso tradicionales tienden a forzar una elección:

• Los límites de uso pueden ser útiles al principio, pero dejan a los usuarios con una mala experiencia cuando se agotan: “vuelve más tarde”
• La facturación basada en el uso es flexible, pero hace que los usuarios paguen desde el primer token, lo cual no es ideal para apoyar la exploración temprana.

Para Codex y Sora, ninguno de los dos era suficiente por sí mismo. Si simplemente aumentáramos los límites de tasa, perderíamos controles importantes para suavizar la demanda y garantizar la equidad, y nos quedaríamos sin capacidad para atender a todos. Si confiáramos completamente en la facturación por uso asincrónica, introduciríamos retrasos, excesos o problemas de conciliación, justo el tipo de problemas que los usuarios notan cuando están más involucrados.

Lo que necesitábamos en cambio era un único sistema híbrido que combinara límites de tiempo real con acceso de pago por uso:

Este sistema tenía que realizar lo siguiente:

• Aplicar límites de tasa hasta que se alcancen
• Transita sin problemas a créditos dentro de la misma solicitud
• Tomar esa decisión en tiempo real
• Ser preciso y asegurarse de que el seguimiento del consumo de créditos sea auditable

Uno de los cambios conceptuales clave que realizamos fue modelar el acceso como una cascada de decisiones. En lugar de preguntar “¿esto está permitido?”, nos preguntamos “¿cuánto se permite, y desde dónde?” Al contar el uso, el sistema sigue la siguiente secuencia:

Este modelo refleja cómo los usuarios experimentan realmente el producto. Los límites de uso, los niveles gratuitos, los créditos, las promociones y las concesiones empresariales son solo capas en la misma pila de decisiones. Desde la perspectiva de un usuario, no “cambian de sistema”; simplemente siguen usando Codex y Sora. Por eso los créditos parecen invisibles: son solo otro elemento en la cascada.

Evaluamos plataformas de facturación y medición de uso de terceros para manejar el consumo de créditos. Son adecuados para la facturación y la elaboración de informes, pero no cumplieron con dos requisitos críticos:

Cuando un usuario alcanza un límite y tiene créditos disponibles, el sistema debe saberlo de inmediato. El conteo con el mejor esfuerzo o retrasado se manifiesta como bloqueos inesperados, saldos inconsistentes y cargos incorrectos. Para productos interactivos como Codex y Sora, esos fallos se hacen visibles y frustrantes.

También necesitábamos ofrecer transparencia en cada resultado:

• Por qué se permitió o bloqueó una solicitud
• ¿Cuánto uso se consumió?
• Qué límites o restricciones se aplicaron

Esta capacidad necesitaba integrarse estrechamente en nuestra cascada de decisiones, en lugar de resolverse de manera aislada en una plataforma de facturación por uso separada que solo veía una parte de lo que ocurría. Para permitir que los usuarios accedan a nuestros productos sin comprometer la confianza, necesitábamos tener control total sobre la precisión, el tiempo y la observabilidad. Eso nos impulsó hacia una solución interna.

Para lograr esto, desarrollamos un sistema distribuido de uso y balance diseñado específicamente para decisiones de acceso sincrónicas.

A un nivel general, el sistema hace lo siguiente:

• Realiza un seguimiento del uso por usuario y por característica.
• Mantiene ventanas de límite de tasa.
• Mantiene saldos de crédito en tiempo real.
• Debita saldos de manera idempotente a través de un procesador asíncrono de transmisión.

Cada solicitud pasa por un único camino de evaluación que toma una decisión en tiempo real sobre cuánto uso se permite al consumir sincrónicamente los límites de tasa y, si es necesario, verificar que haya suficientes créditos; luego devuelve un resultado definitivo mientras liquida cualquier débito de créditos de manera asincrónica. Esto asegura un comportamiento uniforme en todos los productos y elimina la duplicación de lógica entre equipos.

Uno de los principios clave del diseño de este sistema es que debemos ser capaces de probar que nuestra facturación es correcta. Esto refleja las raíces de nuestro soporte de crédito, que se originaron con clientes empresariales. En el diagrama del sistema anterior, tenemos tres conjuntos de datos separados que se interrelacionan:

• Eventos de uso del producto: lo que realmente hizo el usuario
• Eventos de monetización: lo que cobramos al usuario por su uso
• Actualizaciones de saldo: cuánto ajustamos el saldo de crédito del usuario y por qué

Estos conjuntos de datos no son un subproducto casual; en realidad, impulsan el sistema, y cada conjunto de datos desencadena el siguiente. Separar lo que ocurrió, los cargos asociados y lo que debitamos nos permite auditar, reproducir y conciliar de manera independiente cada capa. Este es un compromiso intencional en el que priorizamos la corrección demostrable, a costa de que las actualizaciones del saldo de crédito se retrasen ligeramente. Cómo logramos esto:

• Los eventos de uso del producto se publican para toda actividad de usuario, ya sea que impulse el consumo de créditos o no. Esto proporciona un registro de auditoría de la actividad del usuario y nos permite explicar por qué cobramos, o no cobramos, créditos.
• Cada evento lleva una clave de idempotencia estable, por lo que los reintentos, las repeticiones o los reinicios del trabajador nunca pueden debitar dos veces un saldo, lo que evita el doble cobro. Esto también nos permite realizar una conciliación por lotes para verificar nuestro trabajo sin conexión.
• Hacemos actualizaciones de saldo asincrónicas (pero aún así casi en tiempo real) en lugar de actualizaciones sincrónicas para crear un historial de auditoría. Toleramos una pequeña demora en actualizar el saldo del usuario para demostrar que el sistema funciona y asegurar a nuestros usuarios que no estamos cobrando de más. Cuando ese breve retraso nos lleva a exceder el saldo de crédito de un usuario, lo reembolsamos automáticamente; preferimos la corrección demostrable y la confianza del usuario sobre la aplicación estricta.
• Disminuimos el Saldo de crédito e insertamos un registro de Actualización de saldo en una única transacción atómica de base de datos. Las actualizaciones de saldo se serializan por cuenta, por lo que las solicitudes concurrentes nunca pueden competir para gastar los mismos créditos. El registro de Actualización de saldo incluye tanto el monto del débito como la atribución al evento de monetización que provocó la actualización; al encapsular esto en una única transacción de base de datos, se garantiza que tengamos un rastro de auditoría para cada ajuste del saldo de crédito.

Todo este rigor tiene un solo objetivo: hacer que el acceso sea sencillo y seguro. Cuando las personas están creando o programando, no deberían tener que preguntarse si una solicitud se procesará, si se les cobrará de más o si su saldo es preciso. Al hacer que el uso, la facturación y los saldos sean demostrablemente correctos, les proporcionamos a los usuarios un sistema que no distrae de su experiencia. Eso es lo que nos permite reemplazar los cortes abruptos por un acceso continuo, y es lo que hace que los créditos sean utilizables en medio del trabajo real, no solo en una factura.

El principio rector de nuestro enfoque es proteger el impulso del usuario. Cada decisión arquitectónica se relaciona con un resultado orientado al usuario: los saldos en tiempo real evitan interrupciones innecesarias, el consumo atómico previene el doble cobro y la lógica de acceso unificada asegura un comportamiento predecible. El resultado es que las personas pueden trabajar más tiempo, explorar más a fondo y llevar los proyectos más lejos sin enfrentarse a interrupciones abruptas ni a cambios prematuros de plan.

Cuando los usuarios están involucrados, el sistema debería ayudarlos a seguir, no interferir. Los límites y los créditos desaparecen en el fondo.

Crear esa experiencia requirió repensar el acceso, el uso y la facturación como un solo sistema y construir una infraestructura que considere la precisión como una característica de producto de primera clase. La misma base puede ampliarse a más productos con el tiempo; Codex y Sora son solo el principio.