Pular para o conteúdo principal
OpenAI

13 de fevereiro de 2026

Engenharia

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

Por Jonah Cohen, membro da equipe técnica.

Carregando…

No último ano, tanto o Codex quanto o Sora tiveram uma rápida adoção, com o uso ultrapassando rapidamente o que esperávamos inicialmente. Observamos um padrão consistente: os usuários começam a usar o produto, encontram valor real e, em seguida, se deparam com limites de taxa de transferência.

Os limites de taxa podem ajudar a suavizar a demanda e garantir o acesso justo; no entanto, quando os usuários estão obtendo valor, ser atingido por um limite rígido pode ser frustrante. Nosso objetivo era encontrar uma maneira de permitir que os usuários continuassem utilizando o sistema, ao mesmo tempo em que protegíamos o desempenho do sistema e a confiança do usuário.

Para resolver isso, criamos um mecanismo de acesso em tempo real que contabiliza o uso. Uma das funcionalidades desse motor gráfico é a possibilidade de comprar créditos. Quando os usuários excedem seus limites de uso, os créditos permitem que eles continuem usando nossos produtos, consumindo o saldo de créditos disponível.

Por trás disso, existe um sistema complexo que combina limites, monitoramento de uso em tempo real e saldos de crédito em um único modelo de acesso. Este artigo aborda por que a expansão do Codex e do Sora exigiu uma reformulação do controle de acesso, como um sistema comprovadamente correto e em tempo real combina limites de taxa e créditos por solicitação, e como essa base agora desbloqueia acesso adicional para ambos os produtos.

Por que os modelos de acesso existentes falharam?

Em uma perspectiva mais ampla, os modelos de acesso tradicionais tendem a impor uma escolha:

  • Limites de requisição podem ser úteis no início, mas deixam os usuários com uma experiência ruim quando atingem o limite: “volte mais tarde”.
  • A cobrança baseada no uso é flexível, mas faz com que os usuários paguem desde o primeiro token — o que não é ideal para apoiar a exploração inicial.

Para o Codex e o Sora, nenhum dos dois era suficiente por si só. Se simplesmente aumentássemos os limites de tarifa, perderíamos importantes mecanismos de suavização da demanda e de controle da equidade, e ficaríamos sem capacidade para atender a todos. Se dependêssemos exclusivamente da cobrança assíncrona pelo uso, introduziríamos atrasos, cobranças adicionais ou problemas de conciliação — exatamente os tipos de problemas que os usuários percebem quando estão mais engajados.

O que precisávamos, na verdade, era de um sistema híbrido único que combinasse limites em tempo real com acesso pré-pago:

Interface do painel de controle com dois botões rotulados como “Limites de taxa” e “Créditos”, e um cartão abaixo intitulado “Limite de taxa com opção de crédito”.

Este sistema precisava:

  • Impor limites de taxa até que sejam atingidos
  • Transição perfeita para créditos dentro da mesma solicitação
  • Tome essa decisão em tempo real.
  • Seja rigorosamente preciso e auditável ao monitorar o consumo de crédito.

Acesso como uma cachoeira, não um portão

Uma das principais mudanças conceituais que fizemos foi modelar o acesso como um fluxo de decisões. Em vez de perguntar “isso é permitido?”, perguntamos “quanto é permitido e de onde?” Ao contabilizar o uso, o sistema segue a seguinte sequência:

Árvore de decisão para avaliar o acesso às nossas funcionalidades.

Este modelo reflete como os usuários realmente interagem com o produto. Limites de taxa, planos gratuitos, créditos, promoções e direitos empresariais são apenas camadas na mesma estrutura de decisão. Do ponto de vista do usuário, eles não "trocam de sistema" — eles simplesmente continuam usando o Codex e o Sora. É por isso que os créditos parecem invisíveis: são apenas mais um elemento na cascata.

Por que desenvolvemos isso internamente?

Avaliamos plataformas de terceiros para faturamento e medição de uso, com o objetivo de gerenciar o consumo de crédito. Eles são adequados para faturamento e geração de relatórios, mas não atendem a dois requisitos essenciais:

Correção em tempo real

Quando um usuário atinge um limite e possui créditos disponíveis, o sistema deve ser notificado imediatamente. A contagem feita com base no princípio do melhor esforço ou com atraso resulta em bloqueios inesperados, saldos inconsistentes e cobranças incorretas. Para produtos interativos como Codex e Sora, essas falhas se tornam visíveis e frustrantes.

Reconciliação e confiança

Também precisávamos oferecer transparência em relação a cada resultado:

  • Por que uma solicitação foi permitida ou bloqueada?
  • Quanto tempo de uso consumiu
  • Quais limites ou saldos foram aplicados?

Essa funcionalidade precisava ser integrada de forma rigorosa ao nosso fluxo de decisões, em vez de ser resolvida isoladamente em uma plataforma de faturamento de uso separada, que só enxergava uma parte do que estava acontecendo. Para permitir que os usuários acessassem nossos produtos sem comprometer a confiança, precisávamos de controle total sobre a correção, o tempo e a observabilidade. Isso nos levou a buscar uma solução interna.

Construindo um sistema de utilização e equilíbrio em grande escala

Para viabilizar isso, construímos um sistema distribuído de uso e balanceamento projetado especificamente para decisões de acesso síncrono.

Em linhas gerais, o sistema:

  • Monitora o uso por usuário e por recurso.
  • Mantém janelas de limite de taxa
  • Mantém saldos de crédito em tempo real.
  • Saldos de débitos idempotentes através de um processador assíncrono de streaming

Cada solicitação passa por um único caminho de avaliação que toma uma decisão em tempo real sobre a quantidade de uso permitida, consumindo de forma síncrona os limites de taxa e, se necessário, verificando se há créditos suficientes; em seguida, retorna um resultado definitivo, liquidando quaisquer débitos de crédito de forma assíncrona. Isso garante um comportamento consistente entre os produtos e elimina a duplicação de lógica entre as equipes.

Sistema de acesso: Combinação de limites de taxa em tempo real e rastreamento assíncrono de crédito e saldo.

Um sistema de faturamento comprovadamente correto

Um dos princípios fundamentais deste sistema é que devemos ser capazes de comprovar que nossa cobrança está correta. Isso reflete as raízes do nosso suporte de crédito, que teve origem com clientes corporativos. No diagrama do sistema acima, temos três conjuntos de dados separados que se conectam:

  • Eventos de uso do produto: O que o usuário realmente fez
  • Eventos de monetização: o valor que cobramos do usuário pelo seu uso.
  • Atualizações de saldo: quanto ajustamos no saldo de crédito do usuário e por quê.

Esses conjuntos de dados não são um subproduto casual; na verdade, eles impulsionam o sistema, com cada conjunto de dados desencadeando o próximo. Separar o que ocorreu, quaisquer encargos associados e o que debitamos nos permite auditar, reproduzir e conciliar cada etapa de forma independente. Trata-se de uma compensação intencional, na qual priorizamos a comprovação da correção, ao custo de um ligeiro atraso nas atualizações do saldo de crédito. Como conseguimos isso:

  • Os eventos de utilização do produto são publicados para toda a atividade do usuário, independentemente de gerar consumo de crédito ou não. Isso fornece um registro de auditoria da atividade do usuário e nos permite explicar por que cobramos, ou não cobramos, créditos.
  • Cada evento possui uma chave de idempotência estável, portanto, novas tentativas, repetições ou reinicializações de processos nunca podem debitar o saldo duas vezes, o que impede a cobrança dupla. Isso também nos permite executar uma reconciliação em lote para verificar nosso trabalho offline.
  • Realizamos atualizações de saldo assíncronas (mas ainda quase em tempo real) em vez de atualizações síncronas para criar um registro de auditoria. Toleramos um pequeno atraso na atualização do saldo do usuário para que possamos comprovar o funcionamento do sistema e garantir aos nossos usuários que não estamos realizando cobranças indevidas. Quando esse breve atraso nos leva a ultrapassar o saldo de crédito de um usuário, reembolsamos automaticamente o valor; priorizamos a comprovação da exatidão dos resultados e a confiança do usuário em detrimento da aplicação rigorosa das regras.
  • Reduzimos o saldo credor e inserimos um registro de atualização de saldo em uma única transação atômica de banco de dados. As atualizações de saldo são serializadas por conta, portanto, solicitações simultâneas nunca competem para gastar os mesmos créditos. O registro de Atualização de Saldo contém tanto o valor do débito quanto a atribuição ao evento de monetização que desencadeou a atualização; encapsular isso em uma única transação de banco de dados garante que tenhamos um registro de auditoria para cada ajuste no saldo credor.

Todo esse rigor visa um único objetivo: tornar o acesso simples e seguro. Quando as pessoas estão criando ou programando, elas não deveriam ter que se perguntar se uma solicitação será processada, se serão cobradas em excesso ou se o saldo está correto. Ao tornar o uso, a cobrança e os saldos comprovadamente corretos, oferecemos aos usuários um sistema que não interfere em sua experiência. É isso que nos permite substituir bloqueios rígidos por acesso contínuo — e é isso que torna os créditos utilizáveis durante o trabalho real, não apenas em uma fatura.

Arquitetura a serviço do ímpeto

O princípio orientador da nossa abordagem é proteger o ritmo de aprendizagem do usuário. Cada decisão arquitetônica está diretamente relacionada a um resultado para o usuário: saldos em tempo real evitam interrupções desnecessárias, consumo atômico impede cobranças duplicadas e a lógica de acesso unificada garante um comportamento previsível. O resultado é que as pessoas podem trabalhar por mais tempo, explorar mais a fundo e levar os projetos adiante sem enfrentar interrupções bruscas ou mudanças prematuras de planos.

Quando os usuários estão engajados, o sistema deve ajudá-los a continuar, e não atrapalhá-los. Os limites e os créditos desaparecem em segundo plano.

Para criar essa experiência, foi necessário repensar o acesso, o uso e a cobrança como um sistema único e construir uma infraestrutura que trate a correção como um recurso de produto de primeira classe. A mesma base pode ser estendida a mais produtos ao longo do tempo; Codex e Sora são apenas o começo.

Autoria

Jonah Cohen

Agradecimentos

Um agradecimento especial a toda a equipe da FinEng que criou os créditos.