Gere Testes de API com GPT-6 Luna: Quanto Custa Realmente uma Especificação OpenAPI Completa

Gerar testes a partir de uma especificação OpenAPI deixou de ser um problema técnico faz tempo. Modelos capazes de ler um path item e emitir uma requisição plausível existem há dois anos. O problema era a conta. A geração de testes custava o suficiente por execução para que as equipes a tratassem como uma migração pontual: gerar uma suíte uma vez, commitar, e depois mantê-la à mão para sempre, porque regenerar a cada mudança na especificação apareceria como um item de linha sobre o qual alguém perguntaria.

O GPT-6 Luna, anunciado em 22 de setembro de 2026 a $0,10 por milhão de tokens de entrada e $0,50 por milhão de saída, move o trabalho para o outro lado dessa linha. Uma passada completa sobre uma especificação de 42 endpoints dá cerca de $0,29 sem cache e menos de $0,10 com ele. Isso é barato o bastante para parar de manter uma suíte gerada e simplesmente regenerá-la a cada merge.

Aqui está a aritmética, o formato da requisição, a latência com que você tem de planejar, e as duas coisas que o modelo ainda erra.

O preço que mudou de patamar

O GPT-6 Luna é um novo modelo da família GPT-6, não um GPT-5.6 renomeado. A OpenAI diz que Sol e Luna foram treinados com métodos semelhantes aos do GPT-6 Astra, e que ambos são 50% mais baratos do que o preço promocional do GPT-5.6. Esse qualificador é da própria OpenAI e importa: a comparação é com uma tarifa promocional, não com um preço de tabela. A linhagem completa está no nosso resumo da guerra de preços de modelos de IA.

Para este trabalho, a janela de contexto importa mais do que o preço de manchete. Um milhão de tokens significa que a especificação inteira, as convenções de teste da sua casa e um conjunto de requisições de exemplo cabem em um único prompt com folga. Você não está fatiando nada, nem escrevendo lógica de recuperação para descobrir de quais schemas uma operação depende. Mais sobre o modelo em o que é o GPT-6 Luna.

Modele o trabalho antes de precificá-lo

Duas abordagens, custos bem diferentes.

A versão de disparo único coloca a especificação inteira no contexto e pede a suíte completa em uma única completion. Mais barata na entrada, pior na saída: uma completion cobrindo 42 operações se esvazia bastante por volta da vigésima, em que os endpoints iniciais ganham cinco casos cada um e a cauda ganha um happy path e um encolher de ombros. Também há uma única unidade de retry para a execução inteira.

A versão por operação envia o contexto compartilhado da especificação mais uma operação, 42 vezes. A entrada aumenta porque o contexto compartilhado se repete, mas a qualidade da saída se mantém, cada chamada pode ser repetida de forma independente, e cada arquivo gera um diff limpo em relação à execução anterior. O cache recupera a maior parte do custo extra de entrada, o que faz dessa a abordagem a precificar.

Orçamento para uma chamada, usando uma especificação de porte médio:

As duas primeiras linhas são idênticas byte a byte em todas as chamadas. Esse prefixo de 52.000 tokens é sobre o que o cache atua, e colocar o material invariante primeiro é a decisão de maior alavancagem na configuração.

Quanto custa uma passada

Com 42 operações nesse orçamento, a execução chega a 2.247.000 tokens de entrada e 126.000 tokens de saída.

Nas tarifas do Luna, isso dá $0,2247 de entrada e $0,0630 de saída, ou seja, $0,2877 pela passada, um pouco abaixo de sete décimos de centavo por endpoint. O mesmo perfil de tokens contra os outros modelos que foram lançados ou reprecificados na mesma quinzena:

O Astra tem exatamente 100 vezes a tarifa do Luna tanto na entrada quanto na saída, então custa exatamente 100 vezes mais neste trabalho. O Claude Opus 5.5, 40 vezes.

Essa diferença é a decisão inteira. A $28,77 por passada, você constrói lógica incremental: rastrear quais operações mudaram, fazer hash de cada path item, regenerar apenas o diff e depois depurar essa maquinaria quando ela sai de sincronia com a especificação. A $0,29, você apaga a lógica incremental. Vinte merges por mês dão $5,75, menos do que os minutos de CI gastos executando os testes que o modelo escreveu. Para dar escala, a OpenAI relata que seu pesquisador mediano gasta mais de $600 por dia com agentes de código, com o percentil 90 acima de $7.000.

Onde o cache de prompt entra

O GPT-6 trouxe um lançamento real de cache junto com a mudança de preço: 90% de desconto nas leituras de entrada em cache, taxas de acerto maiores por padrão, um dashboard e uma ferramenta de diagnóstico, breakpoints explícitos para você escolher onde o prefixo em cache termina, e a sobrevivência do cache a mudanças no esforço de raciocínio e na disponibilidade de ferramentas. O GitHub relatou mais de 50% menos tokens de prompt precisando de processamento novo em bilhões de requisições. Detalhes em cache de prompt do GPT-6.

Aplicado à execução acima, tirando 90% da tarifa de entrada de $0,10, o que dá $0,01 por milhão para leituras em cache:

Cerca de um terço do custo sem cache, um fio abaixo de um quarto de centavo por endpoint. Duas coisas a não presumir. A OpenAI afirma os 90% de desconto, mas, em nossas fontes, não publica uma tarifa em dólares de leitura em cache para o Luna, então o $0,01 acima é aritmética, não uma tarifa publicada. E nada do que temos cita um tempo de vida do cache, então dispare as 42 chamadas em sequência, em vez de espalhá-las por uma fila de CI lenta, e confirme a taxa de acerto no dashboard.

A requisição

Nada de exótico. A ordenação é o que se paga:

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "reasoning_effort": "high",
    "messages": [
      { "role": "system",
        "content": "You write API tests. Emit one test file. Assert on status, response schema and error shape. Never assert on a field absent from the supplied schema." },
      { "role": "user",
        "content": "Shared spec context:\n<components, securitySchemes, servers>" },
      { "role": "user",
        "content": "Operation under test:\nPOST /orders\n<path item and examples>" }
    ]
  }'

O prompt de sistema e o bloco compartilhado da especificação são idênticos byte a byte nas 42 chamadas e vêm primeiro. A operação varia e vem por último. Inverta os dois e você não faz cache de nada, então a execução custa $0,29 em vez de $0,096. Essa é a mecânica inteira.

A configuração de esforço high é deliberada. Os ganhos publicados do Luna sobre seu antecessor são medidos com esforço mais alto e, como o cache do GPT-6 sobrevive a uma mudança de esforço, você pode ajustá-lo por operação sem reconstruir o prefixo. Guarde as configurações mais altas para endpoints que envolvem dinheiro ou autenticação.

Orce tempo, não dinheiro

Barato não é rápido. A Artificial Analysis, uma terceira parte, mede a variante de raciocínio máximo do Luna em 153,9 tokens de saída por segundo, com um tempo até o primeiro token de 124,23 segundos. Os dois números são deles, não da OpenAI, ambos se aplicam especificamente à variante máxima, e a AA reavalia as pontuações continuamente, então trate-os como indicativos.

Tomando ao pé da letra, uma chamada em esforço máximo é mais ou menos 124 segundos de espera mais cerca de 20 segundos para transmitir 3.000 tokens, digamos 144 segundos. Quarenta e duas em sequência dão cerca de 101 minutos. Oito em paralelo dão cerca de 13 minutos, um estágio de CI comum.

Isso corta no sentido oposto ao da maioria dos argumentos de seleção de modelo, e é por isso que o par funciona: o tempo até o primeiro token é um desastre para um assistente interativo e quase irrelevante para um job em lote que escreve arquivos. O mesmo trade-off no irmão maior, em tempo até o primeiro token do GPT-6 Sol.

O que ele acerta, e as duas coisas que ele não acerta

Os resultados publicados da OpenAI para o Luna são mais fortes do que o preço sugere. No DeepSWE 1.1 ele chega a 66,6% em esforço máximo, o que a OpenAI coloca em pé de igualdade com Claude Opus 5 e Fable 5 em esforço médio, custando 93% menos por tarefa que o Opus 5 e 96% menos que o Fable 5. No AutomationBench ele supera seu antecessor em 5,4 pontos percentuais, com 58% menos custo por tarefa. Todos são execuções da OpenAI em harnesses da OpenAI, e nenhum mede geração de testes a partir de uma especificação.

Dois modos de falha importam mais aqui do que qualquer benchmark.

O modelo só consegue testar o que a especificação diz. Se sua especificação documenta um 200 e um 400 para POST /orders, mas o serviço também retorna 409 em uma chave de idempotência duplicada, você não ganha nenhum teste de conflito e a suíte ainda parece completa. A qualidade da geração é limitada pela qualidade da especificação, o que faz da especificação o artefato no qual vale a pena investir, não o prompt.

Geração barata falha por parecer certa. O erro característico não é um teste quebrado, é um teste que passa afirmando algo sobre um campo que a resposta nunca contém, ou um código de status que o endpoint nunca emite. Esses passam pela revisão porque parecem testes. Valide cada asserção gerada contra o schema de forma mecânica antes que ela entre no código, rejeitando qualquer uma que referencie um campo ausente de components. Essa verificação não custa nada e mata a classe de erro de vez.

Tornando a saída executável

Arquivos de teste gerados valem exatamente o quanto vale o harness em que eles rodam. Mantenha a especificação como fonte da verdade, gere a partir dela e depois coloque os casos em algum lugar onde eles sejam executados a cada push.

O Apidog cobre a metade final desse ciclo. Ele importa a especificação a partir da qual você está gerando, então o contexto compartilhado no seu prompt e as definições de requisição no seu runner vêm de um único documento e não podem divergir. Os casos gerados se tornam cenários de teste cujas asserções são validadas contra o schema importado, transformando a verificação acima em um portão mecânico em vez de uma tarefa de revisão. O Smart mock serve a especificação enquanto o backend ainda está sendo escrito, então uma suíte gerada pode falhar honestamente antes de existir algo real para atingir. E os cenários rodam no CI, o único lugar em que um fluxo de regenerar a cada merge compensa.

Vale a pena direcionar isso para o Luna?

Sim, com uma ressalva. O custo já não é razão para pular isso: $0,29 por passada, ou menos de $0,10 com cache, é menos do que a reunião em que você debate se deve regenerar. A latência é real, mas cai em uma janela em que ninguém está esperando. E os resultados publicados do Luna o colocam perto de modelos que custam de 40 a 100 vezes mais em trabalho de codificação agêntica.

Nada disso torna a saída confiável ao chegar. Gaste o que você economizou em um portão de validação de schema e em uma leitura humana da primeira execução, e trate o resultado como um primeiro rascunho que cobre completamente a superfície documentada e não cobre em nada a não documentada. Ainda assim, uma posição de partida melhor do que a suíte escrita à mão que parou de acompanhar a especificação quatro releases atrás.