Além dos limites de taxa: expandir o acesso ao Codex e ao Sora

No último ano, tanto o Codex como o Sora registaram uma rápida adoção, com a utilização a ultrapassar rapidamente as nossas expectativas iniciais. Temos observado um padrão consistente: os utilizadores mergulham, encontram valor real e depois enfrentam limites de taxa.

Os limites de taxa podem ajudar a regular a procura e a garantir um acesso equitativo. No entanto, quando os utilizadores estão a obter valor, uma interrupção abrupta pode ser frustrante. Queríamos uma forma de os utilizadores continuarem, enquanto protegíamos o desempenho do sistema e a confiança dos utilizadores na nossa abordagem.

Para resolver este problema, criámos um motor de acesso em tempo real que conta a utilização. Uma das camadas desse motor é a capacidade de adquirir créditos. Quando os utilizadores excedem os seus limites de taxa, os créditos permitem-lhes continuar a usar os nossos produtos, gastando o saldo de crédito.

Por detrás disto está um sistema complexo que funde limites, monitorização da utilização em tempo real e saldos de crédito num único modelo de acesso. Esta publicação explica porque é que escalar o Codex e o Sora exigiu repensar o controlo de acesso, como um sistema comprovadamente correto e em tempo real combina limites de taxa e créditos por pedido, e como essa base desbloqueia agora acesso adicional a ambos os produtos.

Os modelos de acesso tradicionais tendem a forçar uma escolha:

• Os limites de taxa podem ser úteis no início, mas deixam os utilizadores com uma má experiência quando se esgotam: "volte mais tarde"
• A faturação baseada na utilização é flexível, mas obriga os utilizadores a pagar desde o primeiro token — não é ideal para apoiar a exploração inicial

Para o Codex e o Sora, nenhum era suficiente por si só. Se simplesmente aumentássemos os limites de taxa, perderíamos controlos importantes de regulação da procura e de equidade, e ficaríamos sem capacidade para servir toda a gente. Se dependêssemos inteiramente da faturação assíncrona com base na utilização, poderíamos introduzir atrasos, custos adicionais ou problemas de reconciliação — exatamente o tipo de problemas que os utilizadores detetam quando estão mais envolvidos.

Em vez disso, precisávamos de um sistema híbrido único que combinasse limites em tempo real com acesso pago conforme o uso:

Este sistema teve de:

• Aplicar limites de taxa até serem atingidos
• Transitar sem problemas para créditos no mesmo pedido
• Tomar essa decisão em tempo real
• Ser rigorosamente exato e auditável no acompanhamento do consumo de crédito

Uma das principais mudanças conceptuais que fizemos foi modelar o acesso como uma cascata de decisões. Em vez de perguntar, "isto é permitido?", perguntamos "quanto é permitido e de onde?". Ao contar a utilização, o sistema segue a seguinte sequência:

Este modelo reflete a forma como os utilizadores experimentam realmente o produto. Os limites de taxa, os níveis gratuitos, os créditos, as promoções e os direitos empresariais são apenas camadas na mesma pilha de decisões. Da perspetiva de um utilizador, não "mudam de sistema" — continua a utilizar o Codex e o Sora. É por isso que os créditos parecem invisíveis: são apenas mais um elemento na cascata.

Avaliámos plataformas de faturação e medição de terceiros para gerir o consumo de créditos. São adequados para a faturação e a elaboração de relatórios, mas não satisfaziam dois requisitos essenciais:

Quando um utilizador atinge um limite e tem créditos disponíveis, o sistema deve saber imediatamente. A contagem de melhor esforço ou atrasada aparece como bloqueios inesperados, saldos inconsistentes e cobranças incorretas. Para produtos interativos como o Codex e o Sora, essas falhas tornam-se visíveis e frustrantes.

Também precisávamos de oferecer transparência em todos os resultados:

• Por que um pedido foi permitido ou bloqueado
• Quanta utilização foi consumida
• Que limites ou saldos foram aplicados

Esta funcionalidade precisava de estar fortemente integrada na nossa cascata de decisões, em vez de ser resolvida isoladamente numa plataforma de faturação de utilização separada que apenas via uma parte do que estava a acontecer. Para permitir que os utilizadores acedam aos nossos produtos sem comprometer a confiança, precisávamos de controlo total sobre a precisão, o tempo e a observabilidade. Isso levou-nos a optar por uma solução interna.

Para viabilizar isto, desenvolvemos um sistema distribuído de utilização e saldo, concebido especificamente para decisões de acesso síncrono.

Num nível elevado, o sistema:

• Regista a utilização por utilizador, por funcionalidade
• Mantém janelas de limite de taxa
• Mantém saldos de crédito em tempo real
• Debita saldos de forma idempotente através de um processador assíncrono de fluxo contínuo

Cada pedido passa por uma única via de avaliação que toma uma decisão em tempo real sobre a quantidade de utilização permitida, consumindo de forma síncrona a partir dos limites de taxa e, se necessário, verificando se existem créditos suficientes. Em seguida, devolve um resultado definitivo, liquidando de forma assíncrona quaisquer débitos de crédito. Isto garante um comportamento consistente entre produtos e elimina a duplicação de lógica entre equipas.

Um dos princípios fundamentais da conceção deste sistema é que temos de ser capazes de provar que a nossa faturação está correta. Isto reflete as raízes do nosso apoio ao crédito, que teve origem com clientes empresariais. No diagrama do sistema acima, temos três conjuntos de dados separados que estão ligados entre si:

• Eventos de utilização do produto: O que o utilizador fez realmente
• Eventos de monetização: O que cobramos ao utilizador pela sua utilização
• Atualizações de saldo: Quanto ajustámos o saldo de crédito do utilizador e por que motivo

Estes conjuntos de dados não são um subproduto casual. Na realidade, são eles que impulsionam o sistema, com cada conjunto de dados a desencadear o seguinte. Separar o que ocorreu, quaisquer encargos associados e o que debitámos permite-nos auditar, reproduzir e reconciliar cada camada de forma independente. Este é um compromisso intencional em que damos prioridade à correção comprovável, à custa de um ligeiro atraso nas atualizações do saldo de crédito. Como o conseguimos:

• Os eventos de utilização do produto são publicados para toda a atividade do utilizador, quer esta conduza ao consumo de créditos ou não. Isto fornece um registo de auditoria da atividade do utilizador e permite-nos explicar por que cobrámos, ou não cobrámos, créditos.
• Cada evento tem uma chave de idempotência estável, pelo que as tentativas, repetições ou reinícios nunca podem debitar duas vezes um saldo, o que evita a dupla cobrança. Isto também nos permite executar uma reconciliação em lote para verificar o nosso trabalho offline.
• Realizamos atualizações de saldo de forma assíncrona (mas quase em tempo real) em vez de síncronas, para criar um registo de auditoria. Toleramos um pequeno atraso na atualização do saldo do utilizador para podermos provar que o sistema está a funcionar e assegurar aos nossos utilizadores que não estamos a cobrar-lhes indevidamente. Quando esse breve atraso nos leva a ultrapassar o saldo de crédito de um utilizador, reembolsamo-lo automaticamente. Escolhemos a correção comprovada e a confiança do utilizador em vez de uma aplicação rigorosa.
• Reduzimos o Saldo de Crédito e inserimos um registo de Atualização de Saldo numa única transação atómica da base de dados. As atualizações de saldo são dispostas em série por conta, de modo que os pedidos simultâneos nunca podem competir para gastar os mesmos créditos. O registo Saldo de Crédito contém tanto o montante do débito como a atribuição ao evento de monetização que desencadeou a atualização — ao envolver isto numa única transação de base de dados, garantimos um registo de auditoria para cada ajuste ao saldo de crédito.

Todo este rigor tem um objetivo: tornar o acesso simples e seguro. Quando as pessoas estão a criar ou a programar, não deveriam ter de se perguntar se um pedido será processado, se lhes vão cobrar a mais, ou se o saldo está correto. Ao garantir que a utilização, a faturação e os saldos são comprovadamente corretos, proporcionamos aos utilizadores um sistema que não interfere na sua experiência. É isso que nos permite substituir interrupções abruptas por acesso contínuo — e é isso que torna os créditos utilizáveis durante o trabalho real, não apenas numa fatura.

O princípio orientador da nossa abordagem é proteger a dinâmica do utilizador. Cada decisão arquitetónica está ligada a um resultado voltado para o utilizador: saldos em tempo real evitam interrupções desnecessárias, o consumo atómico previne a dupla cobrança e a lógica de acesso unificada garante um comportamento previsível. O resultado é que as pessoas podem trabalhar por mais tempo, explorar mais profundamente e levar os projetos mais longe sem enfrentar interrupções abruptas ou mudanças prematuras do plano.

Quando os utilizadores estão envolvidos, o sistema deve ajudá-los a continuar, não interferir. Os limites e créditos desaparecem em segundo plano.

Construir essa experiência exigiu repensar o acesso, a utilização e a faturação como um único sistema e desenvolver uma infraestrutura que trate a precisão como uma característica de produto de primeira linha. A mesma base pode expandir-se para mais produtos ao longo do tempo. O Codex e o Sora são apenas o começo.