Os custos que não são token

A reunião costuma ter esta forma. O time apresenta uma estimativa mensal e ela é defensável: multiplicou volume por tamanho de contexto, aplicou o preço por milhão de tokens da tabela e chegou a um número. Trinta dias depois chega a fatura, duas ou três vezes maior, e a primeira explicação oferecida é que o consumo cresceu.

Às vezes cresceu. Na maior parte dos casos que valem essa conversa, o consumo de token ficou perto do previsto e o dinheiro entrou por portas que a estimativa nunca abriu. Busca web tem preço por chamada. Indexar arquivo tem preço por dia de armazenamento. Sessão de agente tem preço por hora de relógio. E existe uma chave de velocidade que dobra a tarifa de token inteira sem mudar uma linha do produto.

O arco "Por que a conta cresce sozinha" prometeu os mecanismos que multiplicam a fatura sem que ninguém tenha pedido nada a mais, e este fecha a lista. Os anteriores explicaram por que o consumo aparente engana. Este explica por que a soma do time fica incompleta mesmo quando o consumo foi bem estimado.

Repare no que a tabela faz com a sua régua de comparação. Nas linhas de token, você compara fornecedores por preço por milhão e a conta fecha. Aqui a unidade muda em cada linha, e comparar exige traduzir tudo para a mesma base antes de discutir preço.

Duas linhas merecem atenção especial porque correm sem ninguém usar nada. A primeira é o armazenamento: um índice de arquivo cobrado por GB-dia continua cobrando no fim de semana, no feriado e no mês em que a área parou de usar a ferramenta. A segunda é o cache do Google, que cobra por hora de guarda além do preço de leitura, o que cria um custo de estoque que os concorrentes diretos não têm nessa forma. Isso não desqualifica o fornecedor. Muda a pergunta a fazer: quanto tempo o material fica guardado e com que frequência ele é lido.

A linha de hora de sessão é a mais estranha para quem chega de nuvem tradicional. Um agente gerenciado passou a ter custo de relógio, cobrado enquanto a sessão está ativa, mesmo nos trechos em que ele espera resposta de um sistema externo. O curso antigo dizia que a API cobra tempo de computação, e isso era falso na época. Passou a existir uma versão disso, com preço publicado, e ela nada tem a ver com o tempo de inferência que o texto antigo descrevia.

As duas colunas descrevem a mesma rota, antes e depois de uma chave. A chave custa entre 80% e 100% da linha de token daquela rota, somando o que ela desliga. O ponto de decisão é quem responde pelo requisito.

Latência baixa é requisito de produto quando o usuário espera na tela, quando existe compromisso de tempo de resposta assumido com cliente, ou quando a demora derruba conversão de forma medida. Nos outros casos ela é preferência de quem opera, e preferência de quem opera não justifica dobrar uma tarifa. A pergunta que resolve a discussão em trinta segundos: qual porcentagem do volume desta rota tem alguém esperando do outro lado. Se a resposta for pequena, o tier de velocidade está ligado no lugar errado, e provavelmente está ligado para tudo porque foi configurado uma vez, para um caso, e nunca revisto.

A revisão vale duas vezes, porque ligar prioridade fecha as duas alavancas mais baratas do curso. O lote e o cache aparecem no arco seguinte, começando por "Cache de prefixo: o desconto de 90% com risco zero", e um tier de velocidade ligado por padrão desqualifica a rota inteira para os dois.

O arco fecha aqui, e o que ele entregou foi um modelo mental completo de por que a conta cresce sem ninguém pedir nada a mais. A conversa é recobrada inteira a cada turno, como mostrou "A API não tem memória: a conversa inteira é recobrada". O rascunho que o modelo produz antes de responder tem preço de saída e volta como entrada, tema de "Tokens de raciocínio: o dial que ninguém regulou". O agente decide sozinho quantos passos vai dar, e por isso a conta dele se dimensiona por p99 e não por média, como argumentou "A conta do agente não é a conta do chat". E a fatura tem linhas que não são token, com unidade própria e franquia que esconde o problema no piloto.

Juntos, os quatro explicam a distância entre estimativa e fatura sem recorrer a nenhuma teoria de desperdício. Nenhum deles é defeito. Todos são consequência de como a cobrança funciona, e por isso todos podem ser orçados com antecedência por quem sabe que existem.

O arco seguinte muda o verbo. Sai o entender e entra o aprovar: cinco alavancas com preço, risco e custo de oportunidade declarados, cada uma dependendo de uma decisão que o time técnico não pode tomar sozinho.