Decisions API chegou para matar a espera

Decisions API é o tipo de lançamento que parece pequeno no changelog e enorme na fatura. Quem opera pipeline com LLM conhece a dor. Você chama um modelo gigante só para decidir entre aprovar ou negar, rotear para A ou B, classificar um ticket como urgente ou não, e paga um a três segundos de latência mais alguns centavos por algo que um classificador faria em milissegundos. A OpenAI finalmente admitiu isso e liberou para todos os clientes a sua resposta ao Jev da TypeSafe, aquele modelo de decisão que transformou uma startup criada por um ex-pesquisador de laboratório de fronteira em uma empresa de 7,6 bilhões de dólares.

Eu testei esse padrão dezenas de vezes em produção. Trocar um LLM generalista por um modelo de decisão do tipo 'System One' quase sempre corta custo em 10x e latência em 10x, mas cobra outro preço. Calibração ruim, confiança inventada e um ranking confuso de benchmarks que ninguém entende direito. É exatamente nesse terreno pantanoso que a OpenAI decidiu entrar, não com um modelo novo treinado do zero, mas com o Luna reconfigurado para inferência rápida. Funciona, mas será que escala para tudo.

PublicidadeAnuncie aqui336x280 / responsivo

O fato: OpenAI entra no jogo dos modelos de decisão

A história é direta. Anunciada no dev day em 29 de setembro, a Decisions API foi aberta para todos os clientes nesta quinta. Não é um chatbot, não gera texto longo, não raciocina em cadeia. Ela recebe um conjunto de opções, devolve a escolha e um score de confiança. É um super classificador com esteroides de deep learning, feito para substituir LLMs em workflows onde velocidade importa mais que eloquência.

Nos testes iniciais com Box, Datadog, Ramp e Speak, a troca foi de throughput puro. O caso mais claro veio da Speak, que constrói tutores de idiomas com IA. O CTO Andrew Hsu relatou queda no tempo entre ações de 1,4 segundo para 0,13 segundo depois de migrar parte do roteamento para a Decisions API. A própria OpenAI usou o produto para deixar o assistente de voz Dots mais responsivo. O recado do product lead Nikunj Handa resume a estratégia. A equipe viu o Jev, pensou em um milhão de casos de uso internos, e correu para oferecer a sua versão. O grande desbloqueio, segundo ele, foi sair de um a três segundos para 100, 120, 180 milissegundos.

Como funciona na visão de quem opera

Em termos de arquitetura, pense na Decisions API menos como um cérebro e mais como um porteiro muito rápido e bem calibrado. Você envia o contexto mais a lista de classes ou ações possíveis, com ou sem imagem e agora com voz no pacote público, e recebe de volta a decisão mais provável com probabilidade calibrada. Por baixo, pelo que a OpenAI admite, não há ainda um treinamento específico para decisão. É o Luna normal, mas com stack de inferência otimizado, batching agressivo, destilação parcial na hora de servir e roteamento geográfico para manter a latência baixa em diferentes regiões.

Isso tem implicações práticas de custo e latência. Um LLM tradicional gera token por token, o que estoura tempo e preço mesmo para uma resposta de uma palavra. Um modelo de decisão faz um forward pass único para scoring, sem decodificação autoregressiva longa. Minha inferência técnica, e aqui é leitura de operador, não informação oficial, é que a OpenAI está usando cabeças de classificação sobre embeddings do Luna, com temperatura calibrada por workload, mais cache de prefixo e hardware dedicado por região. Resultado. Menos tokens cobrados, p99 muito menor, e a possibilidade de chamar o modelo dezenas de vezes por segundo sem quebrar o orçamento.

Por que Luna reconfigurada e não modelo novo

A escolha de reaproveitar o Luna faz sentido de engenharia. Treinar um decisor do zero exigiria meses de coleta de dados de preferência, calibração e avaliação por domínio. Reconfigurar um modelo multimodal forte entrega de cara uma vantagem onde a OpenAI já ganha. Classificação de imagens. Handa afirma que o Luna tem se mostrado extremamente poderoso e com melhor calibração em imagem, e que clientes pedem mais flexibilidade inclusive para usar imagens como saída. É um atalho inteligente, mas tem limite. Um modelo generalista otimizado para velocidade tende a ser bom em média e mediano nos extremos, o que explica parte dos benchmarks abaixo.

O que isso muda na prática

Quem ganha agora é quem vive de roteamento. Suporte, moderação, triagem de documentos, orquestração de agentes, validação de tool calls, controle de diálogo por voz. Se hoje você usa GPT ou Luna para decidir qual intent chamar, qual rota seguir ou se deve escalar para humano, você provavelmente está pagando caro por inteligência que não usa. Quem perde espaço é o middleware improvisado de ifs com LLM e aquela camada de prompts gigantes só para extrair um sim ou não em JSON. E quem precisa se mexer é a TypeSafe, que até aqui liderava em adoção no OpenRouter mesmo sem ser líder em todos os índices públicos.

  • Audite seus prompts classificadores: liste todos os lugares onde o LLM responde apenas com categoria, booleano ou score e marque como candidatos à migração.
  • Rode teste A/B com calibração real: não confie só em acurácia, meça ECE, taxa de abstinência e custo por mil decisões em tráfego espelhado por sete dias.
  • Defina thresholds por ação: use a confiança para decidir quando automatizar, quando pedir segunda opinião de um LLM maior e quando escalar para humano.

A ação prática mais valiosa para esta semana é simples. Pegue um fluxo de alto volume e baixa complexidade, como classificação de tickets ou roteamento de intenções em voz, e replique com a Decisions API em shadow mode. Compare latência p50 e p99, custo por decisão e precisão calibrada. Na Speak a diferença foi de mais de 10x em velocidade. Se você repetir algo parecido, a migração se paga no primeiro mês.

O problema que ninguém resolveu ainda

Aqui entra a tensão real. Ninguém sabe definir exatamente o que faz um bom modelo de decisão, além de funciona para mim. Os benchmarks públicos como AIM System One Index e Artificial Analysis Decision Index colocam na frente o D1 Ultra da Liquid e o Elephant-1 da Base Lab, com o Jev mais recente em sétimo e terceiro, e o modelo da OpenAI em oitavo e décimo quarto. E ainda tem o JevMan, onde modelos de decisão jogam PacMan tomando decisões em poucas centenas de milissegundos a cada cruzamento, e que o Jev atual lidera. Divertido, mas diz pouco sobre o seu funil de pagamentos às três da manhã.

O CEO da TypeSafe, Diogo Almeida, tem um ponto quando desconfia de benchmarks e manda testar no próprio workload. Calibração, inteligência, custo e velocidade têm pesos diferentes por tarefa. O modelo da OpenAI perde hoje em ranking puro, mas ganha em multimodalidade e distribuição global, dois fatores que pesam muito em produção. A pergunta que fica para mim é outra. Se o futuro é 60 milissegundos por decisão, a ponto de chamar a API para cada frame de vídeo como o Handa sugere, quem aguenta a conta de infraestrutura e observabilidade. Decisão rápida e barata ainda precisa de log, replay, avaliação contínua e rollback. Isso escala tecnicamente, mas operacionalmente cria um novo gargalo. Não mais o modelo lento, e sim milhares de microdecisões que ninguém audita.

Conclusão

No fim, a OpenAI não matou o Jev, ela validou a categoria e trouxe escala, voz, visão e latência global para o jogo. Se você opera agentes ou voz em tempo real, ignorar modelos de decisão agora é pagar pedágio à toa. A questão que fica no ar é direta. Quantas das suas chamadas de LLM de hoje são na verdade decisões disfarçadas de geração de texto.