Você gasta tokens de output pra receber um “billing” como resposta de classificação? Em outubro de 2026, a OpenAI lançou a Decisions API em beta público, e ela faz exatamente o que você imagina: classifica, roteia e pontua conteúdo em 150ms, cobrando apenas tokens de input. Sem custo de output. Sem cache. $0.10 por milhão de tokens de entrada e ponto final.

Eu já vi gente gastando $50 em output tokens só pra classificar tickets de suporte com o Responses API. A Decisions API resolve isso cortando o desperdício onde ele mora: na geração de texto que ninguém pediu.

O que é a Decisions API (e por que ela existe)

A ideia é simples. Você manda um texto (ou imagem), define perguntas com respostas possíveis, e o modelo escolhe. Não gera texto livre, não inventa formato, não precisa de parsing. É um switch/case turbinado com GPT-6 Luna por trás.

A diferença fundamental em relação ao Structured Outputs é que a Decisions API limita o espaço de respostas antes da inferência, enquanto Structured Outputs apenas formata o texto gerado depois. Na prática, isso significa menos computação, menos latência e menos custo.

O endpoint é POST /v1/decisions e aceita três componentes:

Os três tipos de pergunta

A API suporta três formatos de resposta, cada um otimizado para um tipo de decisão.

Predicate: “Isso é verdade?”

Retorna uma probabilidade entre 0 e 1. Perfeito pra validações binárias.

{
  "type": "predicate",
  "name": "has_damage",
  "instructions": "A imagem mostra dano visível no produto? Ignore sombras e marcas de embalagem."
}

A resposta vem como {"name": "has_damage", "probability": 0.92}. Se a probabilidade passar do seu threshold (digamos 0.8), você manda pra revisão humana. Simples.

Choice: “Qual dessas opções?”

Seleciona uma opção de uma lista fixa e retorna a confiança em cada alternativa.

{
  "type": "choice",
  "name": "department",
  "instructions": "Para qual departamento esse ticket deve ser encaminhado?",
  "choices": [
    {"value": "billing", "description": "Problemas de cobrança, pagamento, assinatura"},
    {"value": "technical", "description": "Bugs, erros, problemas de funcionalidade"},
    {"value": "shipping", "description": "Entrega, rastreamento, logística"},
    {"value": "other", "description": "Qualquer coisa que não se encaixe acima"}
  ]
}

A resposta inclui a escolha, a confiança geral e as probabilidades individuais:

{
  "name": "department",
  "choice": "billing",
  "confidence": 0.94,
  "probabilities": [
    {"value": "billing", "probability": 0.94},
    {"value": "technical", "probability": 0.03},
    {"value": "shipping", "probability": 0.02},
    {"value": "other", "probability": 0.01}
  ]
}

Score: “Quão grave é isso?”

Avalia o input contra níveis ordenados e retorna uma média ponderada por probabilidade. O score pode cair entre dois níveis, o que dá granularidade sem precisar de escala numérica arbitrária.

{
  "type": "score",
  "name": "severity",
  "instructions": "Qual a severidade desse bug report?",
  "levels": [
    {"label": "cosmetic", "description": "Problema visual, não afeta funcionalidade"},
    {"label": "workaround", "description": "Funcionalidade afetada, mas existe alternativa"},
    {"label": "blocked", "description": "Usuário completamente impedido de usar o recurso"}
  ]
}

Números que importam: latência e preço

Vamos falar de dinheiro, porque é aí que a Decisions API realmente brilha.

Pra colocar em perspectiva: classificar 1 milhão de tickets de 500 tokens cada custa aproximadamente $50 na Decisions API. Só input. No Responses API, você pagaria os mesmos $50 de input mais uns $15 a $25 de output tokens (dependendo do tamanho da resposta gerada). A economia real fica entre 20% e 40% em cenários de classificação massiva.

E o Jev da TypeSafe?

A Decisions API não surgiu no vácuo. A TypeSafe lançou o Jev duas semanas antes, um modelo construído do zero exclusivamente para decisões. E cobra $0.042 por milhão de tokens de input, menos da metade do que a OpenAI pede.

O Jev é mais barato e já está em produção, mas não processa imagens. Se você precisa classificar fotos de produtos danificados ou moderar imagens de usuários, a Decisions API é sua única opção nessa categoria.

Nenhum dos dois publicou benchmark comparativo de acurácia. Então, se precisão é crítica pro seu caso, teste ambos com seus próprios dados rotulados antes de escolher.

Cinco casos de uso que fazem sentido agora

1. Roteamento de tickets de suporte

O caso mais óbvio. Em vez de processar cada ticket com um LLM completo que gera uma resposta JSON, você define as categorias como choices e deixa a API decidir. Latência de 150ms significa que o usuário nem percebe o roteamento acontecendo.

2. Moderação de conteúdo

Use predicates pra verificar se um comentário viola guidelines. A probabilidade retornada permite calibrar thresholds: 0.9+ vai direto pra remoção, 0.5 a 0.9 vai pra fila de revisão, abaixo de 0.5 passa.

3. Lead scoring

Defina níveis de qualificação como scores (cold, warm, hot, enterprise) e classifique leads baseado na mensagem de contato. Integra direto com seu CRM sem precisar de pipeline de NLP customizado.

4. Triagem de bug reports

Severidade (cosmetic, workaround, blocked) + prioridade (low, medium, high, critical) em duas perguntas no mesmo request. O time de desenvolvimento recebe o ticket já classificado.

5. Inspeção visual de produtos

O diferencial killer da Decisions API sobre o Jev: mande a foto do produto como base64 e pergunte se tem dano visível. E-commerces com alto volume de devoluções podem automatizar a verificação inicial.

Como usar hoje (com código real)

A Decisions API está em beta público. Você precisa de uma API key da OpenAI e do SDK atualizado (Python >= 3.26.0, JavaScript >= 7.30.0).

Exemplo com curl

curl -s -X POST "https://api.openai.com/v1/decisions" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "Fui cobrado duas vezes na minha assinatura mensal",
    "questions": [
      {
        "type": "choice",
        "name": "department",
        "instructions": "Para qual departamento esse ticket deve ir?",
        "choices": [
          {"value": "billing", "description": "Cobrança e pagamentos"},
          {"value": "technical", "description": "Problemas técnicos"},
          {"value": "account", "description": "Gerenciamento de conta"},
          {"value": "other", "description": "Outros assuntos"}
        ]
      }
    ]
  }'

Exemplo com Python

from openai import OpenAI

client = OpenAI()

response = client.decisions.create(
    model="gpt-6-luna",
    input="O botão de checkout não funciona no Safari",
    questions=[
        {
            "type": "choice",
            "name": "department",
            "instructions": "Classifique esse ticket",
            "choices": [
                {"value": "billing", "description": "Cobrança"},
                {"value": "technical", "description": "Bug ou erro"},
                {"value": "account", "description": "Conta do usuário"},
                {"value": "other", "description": "Outros"}
            ]
        },
        {
            "type": "score",
            "name": "severity",
            "instructions": "Qual a gravidade?",
            "levels": [
                {"label": "low", "description": "Cosmético"},
                {"label": "medium", "description": "Funciona com workaround"},
                {"label": "high", "description": "Bloqueante"}
            ]
        }
    ]
)

print(f"Departamento: {response.answers[0].choice}")
print(f"Severidade: {response.answers[1].score}")

Repare que você pode mandar múltiplas perguntas independentes no mesmo request. Cada uma retorna sua resposta no array answers, identificada pelo campo name.

Alternativa: Structured Outputs (funciona hoje, sem beta)

Se você não quer esperar o GA ou prefere algo mais testado, o Structured Outputs do Responses API já faz algo parecido. Custa mais (paga output tokens), mas funciona:

from openai import OpenAI
from pydantic import BaseModel
from typing import Literal

client = OpenAI()

class RoutingDecision(BaseModel):
    category: Literal["billing", "technical", "account", "spam"]

completion = client.chat.completions.parse(
    model="gpt-6-luna",
    messages=[
        {"role": "system", "content": "Classifique o ticket em uma categoria."},
        {"role": "user", "content": "Fui cobrado duas vezes"},
    ],
    response_format=RoutingDecision,
)

print(completion.choices[0].message.parsed.category)
# "billing"

A diferença é que aqui o modelo ainda gera texto (que é formatado como JSON). Na Decisions API, ele seleciona de uma lista fechada, sem geração. Por isso é mais rápido e mais barato.

O framework de quatro passos pra modelar decisões

A OpenAI sugere um processo pra pensar decisões que funciona bem na prática:

1. Capture o estado: Junte todo o contexto relevante. Pra um ticket de suporte, isso inclui a mensagem do cliente, histórico de compras, plano atual.

2. Defina a pergunta limitada: A pergunta precisa ser específica o suficiente pra que pessoas razoáveis concordem na resposta. “Esse ticket é sobre cobrança?” é uma boa pergunta. “Esse cliente está feliz?” não é.

3. Selecione do espaço de respostas: Deixe o modelo escolher. Choices pra categorias, predicates pra validações, scores pra severidade.

4. Execute no código: Trate a decisão do modelo como evidência, não como autoridade. Seu código decide o que fazer com a resposta. Se a confiança é baixa, manda pra revisão humana. Se é alta, automatiza.

Limitações que você precisa conhecer

Antes de migrar tudo pra Decisions API, olha o que ela ainda não faz:

Só GPT-6 Luna. Sem opção de modelo. Se você precisa de mais capacidade de raciocínio (GPT-6 Sol, por exemplo), volta pro Responses API.

Imagens só em base64. Nada de URL hospedada ou file ID. Se suas imagens estão no S3 ou Cloudflare, você precisa baixar e converter antes de enviar. Isso adiciona latência no seu lado.

Sem streaming. A resposta vem inteira de uma vez. Pra classificação isso não importa (150ms é instantâneo), mas é bom saber.

Beta público. A API pode mudar. A OpenAI prometeu GA “nas próximas semanas”, mas você sabe como promessas de timeline funcionam em tech.

Sem benchmark comparativo. Nem a OpenAI nem a TypeSafe publicaram comparação de acurácia. Você está voando às cegas se não testar com seus próprios dados.

Decisions API vs. Structured Outputs vs. Function Calling

Pra fechar, uma tabela que vai facilitar sua vida na hora de decidir qual abordagem usar:

A Decisions API não substitui nenhuma dessas abordagens. Ela cobre um nicho específico, decisões fechadas sobre dados, que antes era resolvido com ferramentas genéricas demais pro problema.

Se você está gastando tokens de output pra receber respostas de uma palavra, a Decisions API é o upgrade óbvio. $0.10 por milhão de tokens, 150ms de latência, zero custo de output. A OpenAI finalmente fez um endpoint que cobra pelo que você realmente precisa.

A API está em beta público desde 6 de outubro de 2026. Playground disponível em platform.openai.com/decisions. SDK mínimo: Python 3.26.0, JavaScript 7.30.0. Teste, compare com o Jev da TypeSafe ($0.042/M tokens, mas sem imagem), e escolha com dados, não com hype.

Fonte de inspiração: Decisions API is in public beta (OpenAI Developer Docs)