Como calcular o custo por decisão antes de trocar o LLM por um classificador próprio

Fala aí, beleza? Trocar o LLM por um classificador próprio só economiza dinheiro acima de um volume específico, e esse volume dá pra calcular ANTES de escrever qualquer linha de treino

E o momento pra refazer essa conta é agora

O Claude Haiku 5.5 saiu em 7 de outubro de 2026 e chegou como o modelo Claude mais barato, com preço por token bem abaixo do Haiku 4.5

Ou seja: o ponto de virada de muita gente subiu, e aquela planilha montada meses atrás provavelmente tá desatualizada…

Neste post a unidade de medida é uma só: custo por decisão

Que decisão? Uma classificação, um roteamento, um sim/não, aquela saída curtinha que o modelo devolve e o seu sistema usa pra seguir o fluxo

Bora montar a conta? 🙂

O que você precisa ter em mãos antes de fazer a conta

Antes de qualquer fórmula, junta os insumos

Sem eles a conta vira achismo, e achismo em custo é como sair dirigindo sem olhar o tanque haha

• Volume de decisões por mês, o atual e o projetado
• Média de tokens de entrada e de saída por decisão, tirada dos logs reais e não estimada no olho
• Quanto do prompt se repete entre chamadas (instruções fixas, exemplos), porque é isso que define o ganho com cache
• Se a tarefa tolera resposta em até 24h, o que abre a porta pro batch
• Taxa de acerto atual do LLM numa amostra rotulada
• Custo da sua infraestrutura de inferência local, que só você consegue preencher, porque varia MUITO de ambiente pra ambiente

Uma planilha simples resolve, não precisa de nada sofisticado

Passo a passo para calcular o custo por decisão e o ponto de virada

A lógica é: primeiro descobrir quanto cada decisão custa na API de verdade (com desconto e tudo), depois descobrir quanto o classificador custa de verdade (com o custo escondido junto), e só então comparar

Passo 1: como medir os tokens reais de cada decisão?

Puxa uma amostra dos logs de produção e calcula a média de tokens de entrada e de saída por chamada

Se você já grava o uso de tokens de cada requisição, é só agregar:

import csv

# log exportado com uma linha por decisão
# colunas: tokens_entrada, tokens_saida
with open('log_decisoes.csv') as f:
    linhas = list(csv.DictReader(f))

media_entrada = sum(int(l['tokens_entrada']) for l in linhas) / len(linhas)
media_saida = sum(int(l['tokens_saida']) for l in linhas) / len(linhas)

print(media_entrada, media_saida)

O erro comum deste passo: estimar pelo tamanho do prompt que tá no código e esquecer o histórico da conversa ou os exemplos few-shot que entram junto

O prompt do repositório é uma coisa, o que chega na API é outra 😛

Passo 2: como calcular o custo por decisão na API?

A fórmula é direta: tokens vezes preço, dividido por um milhão (os preços vêm por milhão de tokens)

Os preços de referência deste post:

• Claude Haiku 5.5 (prompts de até 100 mil tokens): US$ 0,10 por milhão de entrada e US$ 0,50 por milhão de saída, conforme a página de preços da Claude Platform
• GPT-5.4 nano: US$ 0,20 de entrada e US$ 1,25 de saída por milhão
• GPT-5.4 mini: US$ 0,75 de entrada e US$ 4,50 de saída por milhão

def custo_por_decisao(tokens_in, tokens_out, preco_in, preco_out):
    # preços em US$ por milhão de tokens
    return (tokens_in * preco_in + tokens_out * preco_out) / 1_000_000

# cenário de exemplo: 500 tokens de entrada, 10 de saída
haiku_55 = custo_por_decisao(500, 10, 0.10, 0.50)   # 0.000055
nano     = custo_por_decisao(500, 10, 0.20, 1.25)   # 0.0001125
mini     = custo_por_decisao(500, 10, 0.75, 4.50)   # 0.00042

O erro comum deste passo: usar a faixa de preço errada

Acima de 100 mil tokens de prompt, o Haiku 5.5 passa a custar US$ 0,50 por milhão de entrada e US$ 2,50 por milhão de saída

Pra classificação curta isso raramente acontece, mas se o seu prompt carrega documento grande, confere!

Passo 3: quais descontos entram no custo por decisão?

Aqui mora a parte que mais gente esquece

O preço cheio da API quase nunca é o preço que você precisa pagar

Prompt caching: no Haiku 5.5 (prompts de até 100 mil tokens), a leitura de cache custa US$ 0,01 por milhão de tokens, a escrita de cache de 5 minutos custa US$ 0,125 por milhão e a de 1 hora custa US$ 0,20 por milhão

A Anthropic fala em economia de até 90% com cache

Em classificação isso casa muito bem, porque instrução fixa e exemplos se repetem em TODA chamada

# 500 tokens de entrada: 400 fixos (em cache) + 100 variáveis
custo_com_cache = (400 * 0.01 + 100 * 0.10 + 10 * 0.50) / 1_000_000
# compara com o custo sem cache calculado no Passo 2
# some à parte o custo de escrita do cache (0.125 ou 0.20 por milhão)

Nesse exemplo o custo por decisão cai bastante, porque a maior parte da entrada passa a ser cobrada no preço de leitura de cache (fora as escritas de cache)

Batch API: tanto a Anthropic quanto a Batch API da OpenAI dão 50% de desconto em entrada e saída pra cargas que toleram até 24 horas de processamento

Se a sua classificação roda em lote (triagem noturna, reprocessamento de base e etc), é desconto na mesa

Flex processing da OpenAI: cobra os tokens a preço de Batch API, só que com respostas mais lentas e indisponibilidade ocasional

Está em beta com modelos limitados, e quando falta recurso ele devolve erro 429 sem cobrar a requisição, então seu código precisa saber lidar com retry

Tome cuidado com uma coisa: não há confirmação de que desconto de batch e de cache se somem no Haiku 5.5, então não multiplica os dois na planilha

O erro comum deste passo: comparar o classificador com o preço cheio da API, quando a carga cabia tranquilamente em batch ou cache

Aí o classificador parece genial, mas só porque o adversário entrou na briga com a mão amarrada haha

Passo 4: qual é o custo escondido de um classificador próprio?

Inferência local barata é só a ponta do iceberg

O que entra de verdade:

• Coleta e rotulagem de dados: alguém precisa montar e revisar o dataset
• Treino: um fine-tuning de modelo aberto de 7B é estimado entre US$ 40 e US$ 1.600 por execução (LoRA na ponta baixa, fine-tune completo na ponta alta)
• Deploy: servir o modelo, com a infraestrutura que você já levantou nos pré-requisitos
• Monitoramento: acompanhar se a qualidade tá caindo
• Retreinos periódicos: quando os dados mudam, o modelo precisa ser treinado de novo

O erro comum deste passo: contar só uma execução de treino

Classificador em produção não é next, next e finish, ele envelhece junto com os seus dados

Passo 5: como calcular o ponto de virada?

O ponto de virada é o volume mensal em que o custo total do classificador fica abaixo do custo da API

custo_fixo_mensal = (rotulagem + treinos_por_ano * custo_treino + setup_deploy) / 12
                    + manutencao_mes

volume_virada = custo_fixo_mensal / (custo_api_decisao - custo_local_decisao)

Se o seu volume mensal fica acima de volume_virada, o classificador começa a se pagar

Abaixo disso, a API ainda ganha

Um exemplo só com os preços verificados, olhando APENAS o custo de treino (sem rotulagem, deploy nem inferência local, que ficam como variável):

custo_decisao_haiku = 0.000055      # preço cheio, cenário 500/10
custo_decisao_batch = 0.0000275     # com 50% de batch

# uma execução de LoRA a US$ 40
40 / custo_decisao_haiku    # ~727 mil decisões
40 / custo_decisao_batch    # ~1,45 milhão de decisões

# um fine-tune completo a US$ 1.600
1600 / custo_decisao_haiku  # ~29 milhões de decisões
1600 / custo_decisao_batch  # ~58 milhões de decisões

Se liga no que isso diz: só UM fine-tune completo já equivale a dezenas de milhões de decisões no Haiku 5.5 em batch

E isso antes de somar rotulagem, deploy, monitoramento e a inferência local, que nunca é zero

O erro comum deste passo: dividir o custo fixo pelo volume de um único mês, quando o modelo vai precisar ser retreinado

Cada retreino entra de novo no custo_fixo_mensal, por isso o treinos_por_ano tá ali na fórmula

Passo 6: como ajustar o custo por decisão pela qualidade?

Preço sozinho engana

Um modelo que custa metade e erra o dobro pode sair MUITO mais caro no fim do mês

custo_real_decisao = custo_por_decisao + taxa_erro * custo_do_erro

O custo_do_erro é o que um erro de classificação te custa na prática: ticket roteado pra fila errada, retrabalho humano, cliente irritado e por aí vai

Roda as duas opções na mesma amostra rotulada e compara a taxa de acerto lado a lado, do mesmo jeito que se faz pra testar um modelo novo antes de trocar

O erro comum deste passo: comparar só preço e trocar um modelo mais preciso por um mais barato que erra mais

Quanto custa cada decisão na API: comparação entre modelos baratos

Cenário fixo de exemplo: 500 tokens de entrada e 10 de saída por decisão, prompts bem abaixo de 100 mil tokens

A conta do Haiku 5.5, pra você conferir: 500 × 0,10 / 1.000.000 de entrada, mais 10 × 0,50 / 1.000.000 de saída, e a soma dos dois é o custo por decisão

Os outros seguem a mesma fórmula do Passo 2:

Modelo	Entrada (por milhão)	Saída (por milhão)
Claude Haiku 5.5	US$ 0,10	US$ 0,50
GPT-5.4 nano	US$ 0,20	US$ 1,25
GPT-5.4 mini	US$ 0,75	US$ 4,50
Claude Haiku 4.5 (referência)	US$ 1	US$ 5

Joga esses preços na função custo_por_decisao com os SEUS tokens médios do Passo 1 e tu tem o custo por decisão de cada um, beleza?

Se for aplicar os 50% do batch, confere antes se o modelo está disponível no batch do respectivo provedor

O que a tabela mostra: só a escolha do modelo de API já muda o ponto de virada em uma ordem de grandeza, antes mesmo de pensar em classificador

Quem calculou o ponto de virada em cima do Haiku 4.5 e agora olha pro Haiku 5.5 tem uma conta bem diferente na mão 😀

Quando vale trocar o LLM por um classificador próprio (e quando não vale)

Com a fórmula na mão, os cenários se leem quase sozinhos

Quando o classificador próprio faz sentido?

• Volume alto e estável: o custo fixo se dilui de verdade, mês após mês
• Categorias fixas que mudam pouco: menos retreino, treinos_por_ano baixo
• Latência baixa ou rodar sem API externa: aqui o motivo nem é só custo, é requisito do sistema
• Dados rotulados já disponíveis: o maior custo escondido já foi pago

Se a sua tarefa é bem estruturada, vale também olhar se ela precisa de chat mesmo ou de uma decisão tipada no lugar do prompt

Quando ainda não vale trocar?

• Volume baixo ou incerto: o custo fixo não se paga
• Categorias que mudam toda semana: cada mudança é rotulagem e retreino de novo
• Tarefa que depende de raciocínio em texto livre: classificador pequeno não substitui isso
• Carga que cabe em batch ou cache: o custo da API já cai tanto que o ponto de virada vai lá pra cima

Existe um caminho intermediário?

Existe, e é o mais massa da história toda

Enquanto o volume não justifica treinar, usa o próprio LLM pra rotular os dados

Você segue pagando por decisão (barato), e de quebra vai acumulando o dataset que um dia vai alimentar o classificador

Quando a conta virar, o custo de rotulagem já tá praticamente pago 🙂

Próximo passo: refaça a conta com os preços atuais

Recapitulando a lógica:

• Custo por decisão na API, com tokens reais e descontos de batch e cache aplicados
• Custo fixo do classificador amortizado, contando rotulagem, treinos, deploy, monitoramento e retreinos
• Ponto de virada ajustado pela qualidade, somando o custo de cada erro

O próximo passo concreto é simples:

1. Puxa uma semana de logs
2. Mede os tokens médios de entrada e saída
3. Monta a planilha com o Haiku 5.5 e os descontos de batch e cache
4. Só então decide se o classificador entra no roadmap

E lembra: preço de API cai com frequência, então essa conta não é pra fazer uma vez e esquecer

Saiu modelo novo? Refaz a conta!

Até o próximo post!

Perguntas frequentes

Quanto o Haiku 5.5 muda a conta de custo por decisão em relação ao Haiku 4.5?

O Haiku 4.5 cobrava US$ 1 por milhão de tokens de entrada e US$ 5 por milhão de saída, e o Haiku 5.5 cobra US$ 0,10 de entrada e US$ 0,50 de saída por milhão (prompts até 100 mil tokens). Com o custo por decisão na API bem menor, o ponto de virada pra trocar por classificador próprio sobe bastante. Vale refazer a planilha antes de assumir que o classificador ainda compensa no mesmo volume de antes.

Dá pra somar o desconto de prompt caching com o desconto de batch no Haiku 5.5?

Não há confirmação pública de que os dois descontos se somem no Haiku 5.5. Por isso a recomendação do post é não multiplicar cache e batch na mesma planilha. Use um desconto por vez pra manter a estimativa conservadora e não inflar artificialmente a vantagem da API.

Quanto custa treinar um classificador próprio em modelo aberto de 7B antes de rodar a inferência?

Um fine-tuning de modelo aberto de 7B em 2026 custa de US$ 40 a US$ 1.600 por execução, variando do LoRA (ponta baixa) ao fine-tune completo (ponta alta). Esse valor é só o treino: rotulagem de dados e infraestrutura de inferência entram depois, como custo separado. É por isso que o passo 4 do post trata isso como custo escondido.

O Flex processing da OpenAI cobra quando retorna erro 429?

Não. O Flex processing está em beta com modelos limitados, e quando falta recurso ele devolve o erro 429 Resource Unavailable sem cobrar a requisição. Em troca, as respostas saem mais lentas e a disponibilidade é ocasional. O código precisa lidar com retry pra aproveitar esse preço de Batch API.

Existe um volume fixo de decisões por mês a partir do qual o classificador próprio sempre vale a pena?

Não existe um número universal, e esse post evita inventar um. O ponto de virada sai da equação entre o custo por decisão na API (já com cache e batch aplicados) e o custo total do classificador, incluindo rotulagem, infra e manutenção. Só rodando os passos 1 a 4 da planilha dá pra achar o número certo pro seu caso.

Qual a diferença de preço do Haiku 5.5 entre prompts até 100 mil tokens e acima disso?

Até 100 mil tokens, o Haiku 5.5 cobra US$ 0,10 por milhão de tokens de entrada e US$ 0,50 por milhão de saída. Acima de 100 mil tokens, o preço sobe para US$ 0,50 de entrada e US$ 2,50 de saída por milhão. Pra classificação curta isso raramente pesa, mas se o prompt carrega documento grande, vale conferir qual faixa a sua chamada realmente cai.