O Imposto Oculto dos Upgrades de Modelo: Quanto o GPT-5.5 Realmente Custa

A OpenAI dobrou o preço nominal do GPT-5.5. Input subiu de US$ 2,50 para US$ 5,00 por milhão de tokens. Output subiu de US$ 15 para US$ 30 por milhão de tokens. Um aumento de 2x na etiqueta, anunciado nas notas de versão, fácil de encontrar na página de preços.

O aumento real que sua fatura de nuvem vai relatar no próximo mês fica em algum ponto entre 49 e 92 por cento. A variância é a história inteira.

Justin Summerville, da OpenRouter, rodou a análise de cohort em 4 de maio. A metodologia importa: ele isolou usuários que usaram GPT-5.4 como modelo primário na janela pré-lançamento de 21 a 23 de abril e depois usaram GPT-5.5 como modelo primário na janela pós-lançamento de 25 a 28 de abril. Mesma família de tokenizer, normalizado por milhão de tokens, requisições de mídia, canceladas e com zero tokens excluídas. Não é um benchmark de dois prompts de teste. É o que aconteceu com faturas reais, em cargas de trabalho reais, nos quatro dias seguintes ao upgrade.

O que os dados de cohort mostram é que o preço de etiqueta de 2x não se traduz limpamente em uma fatura 2x maior. Prompts mais curtos viram um aumento de custo próximo a 92 por cento, sem nenhum ganho de eficiência compensador. Prompts mais longos (10 mil tokens ou mais) viram aumentos de custo próximos a 49 por cento, porque o GPT-5.5 gerou de 19 a 34 por cento menos tokens de completion para a mesma tarefa. O novo modelo é mais eficiente em contextos longos. O novo modelo também é mais caro em todo contexto. Os dois efeitos se cancelam parcialmente em algumas cargas e se somam em outras.

Essa é a parte furtiva do imposto. Dois times da mesma empresa verão dois aumentos diferentes na fatura. Nenhum dos dois conseguirá explicar o porquê sem os dados.

Por Que o Financeiro Não Consegue Saber

O financeiro não consegue distinguir uma mudança de preço de uma deriva de uso na ausência de monitoramento por cohort. A fatura subiu 73 por cento de um mês para o outro. Foi a mudança de preço? Foi mais usuários? Foi prompts ficando mais longos porque alguém lançou uma nova feature? Foi o modelo gerando outputs de tamanhos diferentes? Em uma linha de SaaS comum, essas perguntas nem aparecem porque o preço unitário é fixo. IA precificada por token quebra essa premissa.

A ferramenta padrão não ajuda. A maioria dos times manda tudo para uma única chave da OpenAI, recebe uma única fatura e deixa a conta agregar. A fatura diz quanto você gastou. Não diz por que o custo por chamada se mexeu.

Para responder “por que”, você precisa da mesma coisa que a OpenRouter construiu para responder isso publicamente: um cohort. Mesma carga de trabalho, mesma distribuição de prompts, mesmo segmento de usuários, antes e depois da mudança. Sem isso, toda conversa de custo desaba em “o modelo ficou mais caro” e para ali. Procurement renegocia um contrato que não era o problema real. Engenharia corta tamanho de prompt que não era o motor real. Nada melhora.

Como É, na Prática, um Cohort de Custo

Um cohort de custo não é exótico. São três colunas adicionadas ao log de requisições que você já escreve:

Versão do modelo no momento da chamada. Não é “gpt-5”; é a versão publicada exata. Todo upgrade de modelo é um novo valor de coluna, nunca uma sobrescrita silenciosa.
Tag de carga de trabalho. Sumarização de vendas, rascunho de atendimento ao cliente, agente de código interno. Os cinco principais casos de uso, o que for. Uma tag por chamada.
Contagens de tokens dos dois lados. Tokens de input, tokens de output, ambos armazenados, jamais derivados depois a partir do nome do modelo.

Com esses três campos, você responde qualquer pergunta de custo em SQL. Agrupe por versão do modelo, mantenha a tag de carga constante, e o efeito de preço sai limpo. Agrupe pela tag de carga, mantenha a versão do modelo constante, e a deriva de uso sai limpa. As duas perguntas param de se misturar.

A maioria dos times não tem esses três campos. Tem um único contador de tokens que agrega tudo e um nome de modelo que atualiza silenciosamente quando o fornecedor aponta “gpt-5” para uma nova versão. Quando a fatura pula, ninguém roda a análise que a OpenRouter rodou. Ninguém roda nem uma versão privada dela em uma única carga de trabalho.

A Nota de Rodapé de Procurement Virou Disciplina Operacional

Durante quase toda a história da nuvem, governança de custo foi nota de rodapé de procurement. Você negociava compromissos, etiquetava recursos, o financeiro fazia revisão trimestral e o preço unitário não se mexia entre revisões. Inferência de IA quebra o modelo. Preços unitários se movem no calendário do fornecedor, frequentemente sem SLA de retrocompatibilidade de custo. O fornecedor dobra o preço de manchete; se a sua fatura dobra, triplica ou fica plana depende da distribuição de prompts, do tamanho do output e de qual carga de trabalho usa mais aquele modelo. Procurement não consegue responder essas perguntas. Engenharia não gera, naturalmente, os dados para respondê-las.

Duas mudanças decorrem disso:

Primeira, o papel de FinOps para IA não pode ser uma auditoria trimestral. Tem que ser uma revisão semanal de cohort na semana de todo anúncio de upgrade de modelo, com os dados já em mãos desde antes do upgrade. A janela de 4 dias pós-lançamento que a OpenRouter usou é, aproximadamente, a janela que uma empresa tem para descobrir se o novo modelo aumentou os custos para ela especificamente, ou para o mix de carga de trabalho de outro.

Segunda, a responsabilidade de engenharia sobre telemetria de custo precisa migrar de “etiquetamos nossos gastos” para “conseguimos reproduzir a análise do fornecedor sobre os nossos próprios dados”. Se a OpenRouter consegue isolar um cohort de troca em milhões de usuários, o seu time de plataforma consegue isolar um cohort de troca nos seus cem serviços. A forma do dado é a mesma. A query é mais curta.

Como argumentamos em A Convergência de 5 de Fevereiro, as fronteiras entre mudanças de capacidade do fornecedor e mudanças de despesa operacional agora estão acopladas. Um upgrade de modelo não é um lançamento de feature. É uma mudança de contrato com implicações de custo que você não consegue ler no contrato. Como argumentamos em Medindo IA no Desenvolvimento de Software, disciplina de medição é o que separa times que melhoram de times que torcem. Custo é a medição que mais times pulam primeiro e descobrem por último.

O Teste para o Seu Time

Três perguntas, ainda esta semana:

Você consegue me dizer, para qualquer carga de trabalho em produção, qual percentual do gasto de IA do mês passado veio de mudança de preço, de mudança de volume ou de mudança de prompt? Se a resposta for um número único sem decomposição, a disciplina de cohort não existe.

Você consegue produzir um snapshot pré-upgrade e pós-upgrade de qualquer migração de modelo nos últimos 90 dias, normalizado por milhão de tokens? Se a resposta envolver explicar que o dado se perdeu, você está pagando o imposto oculto e vai pagar de novo no próximo upgrade.

Quem é dono da revisão semanal? Se a resposta for “o financeiro” ou “a engenharia” ou ninguém, a disciplina não existe. A revisão é uma reunião de 30 minutos entre um engenheiro de plataforma que sabe escrever o SQL e um parceiro de financeiro que sabe lê-lo. A saída é uma página.

O custo de construir isso é pequeno. O custo de não construir é um upgrade grande de distância da capa do deck do CFO.

Fontes

Summerville, Justin. “GPT-5.5 Cost Analysis.” OpenRouter, Maio de 2026.

A Victorino ajuda times de finanças e plataforma a montar monitoramento por cohort antes do próximo upgrade de modelo: contato@victorino.com.br | www.victorino.com.br