Um modelo pode devolver uma resposta barata e ainda criar trabalho caro. Alguém precisa conferir, repetir o pedido quando dá errado e consertar o que passou despercebido.
Um erro barato continua sendo um erro, e alguém acaba recebendo a conta.
Os preços anunciados do Haiku 5.5 convidam a calcular quanto custaria um resultado aceitável numa rotina concreta. A conta começa nos tokens e segue por cada correção necessária até que a resposta possa ser usada.
A Anthropic anunciou Claude Haiku 5.5 em 7/10/2026. Na API, entrada/saída por milhão de tokens: US$ 0,10/0,50 até 100 mil tokens de prompt; US$ 0,50/2,50 acima. Disponível na Claude Platform, AWS, Google Cloud e Azure. Leituras de cache do Sonnet 5.5 custam metade. Fonte: Anthropic.
Combine antes o que significa pronto
Pense num sistema hipotético que distribui relatos de bugs entre equipes. Uma categoria parece convincente na tela; o teste é saber se leva o relato à equipe certa. Monte a avaliação com exemplos de resposta conhecida, incluindo casos que cabem em vários times e outros que precisam da decisão de uma pessoa.
Antes de trocar o modelo, defina a regra de aceitação. Uma resposta em JSON válido pode ser obrigatória, mas o formato pouco diz sobre a veracidade dos campos. Confira os valores com as evidências originais. Registre quando o sistema deve pedir ajuda ou deixar a questão em aberto. Uma dúvida explícita pode dar menos trabalho que uma resposta convincente entrando silenciosamente no banco de dados.
Some a primeira chamada, novas tentativas, encaminhamentos e a revisão humana necessária. Divida o gasto pelos resultados aceitos e apresente os casos não resolvidos separadamente. Caso contrário, o custo por tarefa concluída esconde quanto trabalho o sistema deixou para trás.
O que acompanha cada pedido
Pense em um assistente hipotético que recebe o histórico inteiro a cada pedido, incluindo planos abandonados e enganos anteriores. Cada tarefa nova herda aquela bagunça. Um experimento útil compararia esse método com uma seleção cuidadosa de evidências e um registro curto das decisões, verificando se a versão enxuta preserva tudo que faz diferença na resposta.
Cortar texto no escuro também sai caro. Uma exceção, uma data ou uma instrução removida pode virar retrabalho na etapa seguinte. Meça o tamanho do contexto junto com a qualidade. Guarde exemplos em que o detalhe omitido muda o resultado. O objetivo é entregar ao sistema um material de trabalho enxuto, com informação suficiente para resolver o pedido.
O cache merece uma conta baseada no uso real. Um bloco estável de instruções pode ser reaproveitado muitas vezes; um documento que muda constantemente pode oferecer menos oportunidades. Acompanhe as gravações, as reutilizações e as chamadas que não aproveitam o conteúdo armazenado. Confira as condições do provedor escolhido antes de usar um preço anunciado como se fosse o custo efetivo da operação.
Defina o limite de tentativas antes de aumentar o volume. No exemplo dos bugs, uma classificação incerta poderia ir para revisão quando chegasse a esse limite. Guarde o motivo do encaminhamento: várias falhas na mesma categoria podem revelar informação ausente ou uma tarefa que precisa ser redefinida. Outro prompt nem sempre resolve.
Mantenha o gasto total ao lado do custo por tarefa. Chamadas mais baratas facilitam acrescentar novos trabalhos; a redução por pedido pode conviver com uma fatura maior. Pode valer a pena, desde que seja uma escolha feita com os números à vista.
Um piloto responde à pergunta que a tabela de preços deixa em aberto. Compare o candidato com o processo atual, confira os resultados aceitos e examine os casos que falharam.
A melhor linha do painel mostra quanto custa o trabalho que dá para aceitar.
Tem outro ponto de vista? Quero ouvir. hello@maisfps.com
