Más allá de los límites de tasa: ampliar el acceso a Codex y Sora

En el último año, tanto Codex como Sora han observado una rápida adopción, cuyo uso ha superado rápidamente la expectativa original. Hemos visto un patrón constante: los usuarios exploran, encuentran un valor real y luego se enfrentan a límites de tasa.

Los límites de tasa pueden ayudar a suavizar la demanda y garantizar un acceso justo; sin embargo, cuando los usuarios están obteniendo valor, encontrarse con una interrupción repentina puede ser frustrante. Buscamos una manera para que los usuarios siguieran avanzando, a la vez que nos permitía proteger el rendimiento del sistema y la confianza de los usuarios en nuestro enfoque.

Para solucionar esto, desarrollamos un motor de acceso en tiempo real que cuenta el uso. Una de las capas de ese motor es la capacidad para adquirir crédito. Cuando los usuarios superan sus límites de tasa, los créditos les permiten seguir utilizando nuestros productos descontando el uso de su saldo de crédito.

Este planteamiento se sostiene en un complejo sistema que fusiona límites, el seguimiento del uso en tiempo real y saldos de crédito en un único modelo de acceso. Esta publicación explica por qué la ampliación de escala de Codex y Sora requirió replantear el control de acceso, cómo un sistema con capacidad de corrección en tiempo real 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 tasa pueden ser útiles al principio, pero dejan a los usuarios con una mala experiencia cuando se agotan: «vuelve más tarde»
• La facturación por uso es flexible, pero exige que los usuarios tengan que pagar desde el primer token, lo cual no es ideal para apoyar la exploración inicial

Codex y Sora no eran suficientes por sí mismos. Con simplemente aumentar los límites de tasa, perderíamos importantes controles de suavizado de la demanda y de equidad, y nos quedaríamos sin capacidad para atender a todos. Si confiáramos completamente en la facturación por uso asíncrona, introduciríamos retrasos, sobrecargos o problemas de conciliación: exactamente el tipo de problemas que los usuarios observan cuando están más inmersos.

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

Este sistema tenía que:

• Aplicar límites de tasa hasta que se alcancen
• Tránsito fluido a créditos dentro de la misma solicitud
• tomar esa decisión en tiempo real
• ser rigurosamente preciso y auditable a la hora de hacer un seguimiento del consumo de crédito

Uno de los cambios conceptuales principales que aplicamos fue modelar el acceso como una cascada de decisiones. En lugar de preguntar «¿se permite esto?», preguntamos «¿cuánto se permite y desde dónde?». Al contar el uso, el sistema sigue la siguiente secuencia:

Este modelo refleja cómo experimentan los usuarios realmente el producto. Los límites de tasa, los niveles gratuitos, los créditos, las promociones y las concesiones empresariales son solo una serie de capas en una misma pila de decisiones. Desde la perspectiva del usuario, no tienen que «cambiar de sistema», sino que siguen usando Codex y Sora. Por eso los créditos parecen invisibles: son simplemente un elemento más en la cascada.

Evaluamos plataformas de facturación y medición de uso de terceros para gestionar el consumo de créditos. Estas plataformas eran adecuadas para la facturación y la elaboración de informes, pero no cumplían dos requisitos esenciales:

Cuando un usuario alcanza un límite y tiene crédito disponible, el sistema debe saberlo de inmediato. El recuento basado en la mejor intención o que se realiza de forma diferida genera bloqueos inesperados, saldos inconsistentes y cargos incorrectos. Para productos interactivos como Codex y Sora, esos fallos se hacen visibles y resultan frustrantes.

También teníamos que ofrecer transparencia con cada resultado:

• Razón para permitir o bloquear una solicitud
• Consumo de uso
• Límites o saldos aplicados

Necesitábamos integrar fuertemente esta capacidad en nuestra cascada de decisiones, en lugar de dejar que se resolviera de manera aislada en una plataforma independiente de facturación por uso que solo veía una parte de lo que estaba sucediendo. Para que los usuarios puedan acceder a nuestros productos sin comprometer la confianza, necesitábamos tener un control total sobre la corrección, el tiempo y la capacidad de observación, lo cual nos llevó a tomar una solución interna.

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

En un nivel elevado, el sistema:

• Realiza un seguimiento del uso por usuario y por función
• Mantiene ventanas de límite de tasa
• Mantiene los saldos de crédito en tiempo real
• Carga saldos de forma idempotente a través de un procesador asíncrono de transmisión

Cada solicitud pasa por una única vía de evaluación que toma una decisión en tiempo real sobre cuánto uso se permite consumiendo de manera síncrona desde los límites de tasa y, si es necesario, verificando que haya crédito suficiente; luego, devuelve un resultado definitivo mientras liquida de manera asíncrona cualquier débito de crédito. Esto asegura un comportamiento coherente en todos los productos y elimina la duplicación de lógica entre los equipos.

Uno de los principios clave del diseño de este sistema es que debemos ser capaces de demostrar que nuestra facturación es correcta. Esto refleja la base de nuestro soporte de crédito, que surgió con clientes empresariales. En el diagrama del sistema anterior, tenemos tres conjuntos de datos independientes que se vinculan entre sí:

• 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 tuvimos que ajustar 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 activa el siguiente. Separando lo ocurrido, los cargos asociados y lo que hemos adeudado nos permite auditar, reproducir y conciliar de forma independiente cada capa. Esta es una compensación intencionada en la que dimos prioridad a la capacidad de corrección demostrable, a cambio de que las actualizaciones del saldo de crédito puedan retrasarse ligeramente. Cómo lo conseguimos:

• Los eventos de uso de productos se publican para toda la actividad de los usuarios, tanto si impulsan el consumo de créditos o no. Esto proporciona un registro de auditoría de la actividad de los usuarios que nos permite explicar por qué hemos cobrado, o no, créditos.
• Cada evento conlleva una clave estable de idempotencia, de manera que los reintentos, las repeticiones o los reinicios de un trabajador nunca pueden cargar dos veces un saldo, evitándose así el doble cobro. Esto también nos permite realizar una conciliación por lotes para verificar nuestro trabajo fuera de línea.
• Hacemos actualizaciones asíncronas (aunque casi en tiempo real) del saldo en lugar de actualizaciones síncronas para crear un registro de auditoría. Toleramos un pequeño retraso en la actualización del saldo del usuario para demostrar que el sistema funciona y asegurar a nuestros usuarios que no les estamos cobrando incorrectamente. Cuando ese breve retraso hace que excedamos el saldo de crédito de un usuario, lo reembolsamos automáticamente; preferimos la corrección demostrable y la confianza del usuario a una aplicación estricta.
• Redujimos 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, así que las solicitudes simultáneas nunca pueden competir para gastar los mismos créditos. El registro Actualizaciones de saldo incluye tanto el importe del débito como la atribución al evento de monetización que provocó la actualización. Al encerrar todo esto en una única transacción de base de datos, garantizamos un registro de auditoría para cada ajuste del saldo de crédito.

Todo este rigor tiene un objetivo: que el acceso sea sencillo y seguro. Cuando los usuarios están creando o programando, no deberían tener que preguntarse si se procesará una solicitud, si se les cobrará de más o si su saldo es correcto. Al garantizar que tanto el uso como la facturación y los saldos sean demostrablemente correctos, ponemos a disposición de los usuarios un sistema que no les distrae de su experiencia. Estos nos permite sustituir interrupciones bruscas por un acceso continuo, a la vez que se facilita el uso de créditos en mitad del proceso real de trabajo, sin quedar relegados a un simple reflejo en la factura.

El principio rector en el que se basa nuestro enfoque es proteger el impulso de los usuarios. Cada decisión estructural se traduce en un resultado visible para el 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. En consecuencia, los usuarios pueden trabajar más tiempo, explorar más a fondo y llevar los proyectos más lejos sin enfrentarse a cortes bruscos o cambios de plan prematuros.

Cuando los usuarios están inmersos en tareas, el sistema debería ayudarlos a seguir, en lugar de interponerse en su camino. Los límites y los créditos se desvanecen en el fondo.

Para ofrecer esta experiencia fue necesario replantear el acceso, el uso y la facturación como un sistema único y desarrollar una infraestructura que haga de la corrección una característica de producto de primera clase. Esta misma base puede ampliarse a más productos con el paso del tiempo: Codex y Sora son solo el principio.