Você não é um modelo: não precifique por token

A cobrança por token surgiu de forma adequada na camada de modelos, como instrumento para medir a computação consumida por uma inferência. Mas, segundo a tese defendida no texto, aplicá-la à maioria das aplicações de IA é um erro: esses produtos combinam dados próprios, ferramentas, integrações, orquestração e lógica de fluxo de trabalho para entregar trabalho concluído, e não apenas acesso a um modelo.

Cobrar pela camada de valor

A recomendação é precificar na camada mais alta de valor que a empresa consiga medir, atribuir e defender. Provedores de modelos podem cobrar por tokens; aplicações que transformam modelos em trabalho útil deveriam cobrar pela unidade reconhecível desse trabalho, muitas vezes por meio de créditos; e produtos que entregam resultados empresariais claros poderiam cobrar pelo resultado, como uma conversa de suporte resolvida, um lead qualificado, uma reunião marcada, um sinistro processado ou um dólar recuperado.

O texto argumenta que não existe uma métrica universal para aplicações de IA. Um agente de pesquisa de contas vende um relatório concluído, e um agente de programação vende uma alteração implementada, não a quantidade de buscas ou chamadas de modelo realizadas. Produtos de voz podem começar cobrando por minutos e migrar para conversas resolvidas; copilotos podem combinar licenças por usuário com cobrança por uso quando o trabalho agentivo tornar custos e valores mais variáveis. A pergunta central deveria ser qual unidade de valor o cliente já entende e que a empresa consegue medir de modo consistente.

Clareza para o cliente e uso de créditos

Clientes costumam pedir tokens por dois motivos: comparação e controle orçamentário. Porém, comparar tokens entre aplicações pode produzir uma falsa precisão, porque cada produto combina modelos, dados, ferramentas e níveis de automação diferentes. Além disso, equipes financeiras e de tecnologia precisam atribuir gastos a departamentos, projetos ou clientes, mas prever contexto, recuperação de dados, tentativas repetidas, tempo de raciocínio e tokens de saída pode transformar um cálculo de retorno em um exercício de previsão de computação.

A alternativa proposta é mostrar detalhes suficientes sobre o uso para gerar confiança e permitir orçamentos e rateios, sem fazer do consumo técnico a unidade comercial. Créditos podem organizar trabalho variável, desde que representem tarefas compreensíveis, e não sejam apenas tokens convertidos em uma moeda opaca. Um sistema bem desenhado abstrai a infraestrutura, explica diferenças de esforço e permite que vários tipos de trabalho sejam cobertos por um mesmo contrato. Em uma pesquisa com 50 compradores técnicos de IA, 27 preferiram créditos ligados a trabalhos reconhecíveis, contra 14 que preferiram tokens.

Margens e modelos híbridos

Separar o valor do trabalho de seu custo de entrega também pode proteger margens. O preço dos créditos deve refletir valor para o cliente, disposição a pagar e concorrência; a quantidade de créditos consumida deve refletir custo e complexidade relativos. Assim, melhorias em roteamento, cache, prompts e infraestrutura podem aumentar a margem, mesmo quando o custo dos modelos cai.

A Clay é apresentada como exemplo de abordagem híbrida: separa créditos de dados de terceiros das ações de orquestração, mantém preços fixos para modelos previsíveis e repassa, sem margem, custos de tokens de modelos de raciocínio mais caros e voláteis. O texto reconhece que diferentes medidores podem coexistir: licenças para acesso, créditos para trabalho variável, repasse de tokens em usos excepcionais e cobrança por resultado quando a atribuição for clara. A conclusão é que o problema não são vários medidores, mas usar o medidor errado para a camada errada.