Custo de IA: conte entregas aceitas, não troféus de tokens

Erik Peterson, fundador e CTO da CloudZero, critica o uso de tokens consumidos como indicador de adoção de IA e chama de “tokenmaxxing” o incentivo a gastar mais para demonstrar adesão.[5] Sua apresentação propõe medir economia por unidade de resultado, incluindo custo de autonomia, eficiência na tarefa e efeito sobre a margem.[5]

A leitura de engenharia é direta: consumo mostra atividade, mas não demonstra entrega. Antes de otimizar o preço do modelo, é preciso definir o que conta como resultado aceito.

O que muda para quem desenvolve

Peterson relata loops que consomem recursos durante dias, avaliações mais caras que os sistemas avaliados e contextos carregados com ferramentas MCP desnecessárias.[5] Também argumenta que tokens unitariamente mais baratos podem aumentar experimentação e despesa total, associando o fenômeno ao paradoxo de Jevons.[5]

Minha recomendação é tratar cada automação como uma operação com orçamento e critério de parada. Um dashboard que mostra gasto não substitui a regra que interrompe uma tarefa sem progresso. Para isso, a equipe precisa combinar uma definição técnica de sucesso com responsabilidade financeira explícita.

Separaria desenvolvimento, avaliação e atendimento em produção. Uma mudança pode baratear a resposta ao cliente e encarecer o ciclo de desenvolvimento; outra pode reduzir tokens por chamada e aumentar tentativas. Sem essa separação, a comparação escolhe o denominador mais conveniente.

Como aplicar

Comece com uma categoria de tarefa repetida, como corrigir um defeito com reprodução e regressão. Registre consumo do agente, consumo da avaliação, tempo humano de revisão, tentativas descartadas e retrabalho. Marque a entrega como aceita somente após o mesmo conjunto de verificações usado na solução convencional.

Compare combinações de modelo e fluxo sobre tarefas equivalentes. Meça custo total por entrega aceita, taxa de aceitação e prazo. Não exclua execuções que terminaram sem solução: elas também consumiram orçamento.

Antes do piloto, estabeleça limite de gasto, tempo e iterações. Defina quem pode interromper e como retomar sem começar novamente do zero. Para um serviço pago, confronte o custo de execução e suporte com a receita daquela funcionalidade, não com uma média que esconda clientes deficitários.

Um experimento útil é retirar ferramentas irrelevantes do contexto e repetir tarefas representativas. A hipótese a testar é redução de desperdício sem perda de qualidade. Não declare economia antes de observar os resultados e considerar o esforço adicional de manter o roteamento.

Cuidados e limites

A palestra mistura relatos de clientes, recortes comerciais, opiniões e previsões; Peterson atua no mercado de gestão de custos.[5] Seus números não constituem uma avaliação independente de todo o setor.

A transcrição usa a expressão “queda de 1000%” para preço de tokens, uma redução percentual incoerente que não deve ser reutilizada como medida válida.[5] Também apresenta apostas pessoais sobre autonomia em 2027 e 2028, não compromissos verificáveis de disponibilidade.[5]

Não conclua que todos os produtos carecem de limites: a própria análise ressalva que as opções variam por fornecedor.[5] Verifique o controle disponível e teste a interrupção. A meta não é consumir pouco a qualquer custo. É comprar um resultado útil sem deixar o agente decidir sozinho quanto ele vale.

Fonte

[5] Fonte: InfoQ, apresentação de Erik Peterson com transcrição integral