Custo dos provedores, AI gateway e eventos de uso
Uma fonte monetária e rateio que conserva o total
Custo por cliente, usuário e modelo
Pricing, alertas e agente de IA
O que resolve
- O custo de IA bate com a fatura do provedor, dia a dia.
- Cada real de custo atribuído a cliente, usuário e modelo, ou marcado como sem atribuição.
- Heavy users e planos com margem negativa aparecem sozinhos.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- Acesso às APIs de custo e uso dos provedores ou do AI gateway
- O identificador do usuário e do cliente gravado em cada chamada
- Planos e preços do billing, e a taxa de câmbio declarada
O que você recebe
- Uma tabela de consumo usuário x modelo x dia, com tokens, requisições e custo
- Custo por cliente e por plano contra a receita, no mês
- Alertas de usuários e clientes acima do limite
- Um agente de IA que responde sobre custo com a fonte monetária certa
Onde ativar
Custo de servir por plano contra o MRR, para revisar limites, créditos e preço.
Aviso diário de usuários e clientes acima do limite ou do p99, com o modelo que puxou o custo.
Responde quanto custou cada cliente e modelo pela fonte monetária, e avisa quando um dia ainda não fechou.
As APIs de custo têm limites (não agrupam usuário e modelo juntos, fecham o dia em UTC, paginam devagar) e o rateio do custo compartilhado precisa ser desenhado. Comece pela fonte monetária e acrescente a atribuição depois. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
O provedor fatura por projeto ou chave, a ferramenta de analytics sabe qual usuário fez a chamada, e as duas não batem. O analytics precifica todos os tokens como novos e infla o custo; a API de custo não devolve usuário e modelo na mesma consulta; o dia do provedor é UTC. E o custo compartilhado, como infraestrutura do modelo, fica sem dono. O resultado é um custo por cliente que não fecha com a fatura e um preço que ninguém consegue defender.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
O custo em dinheiro vem da fatura ou da API de custo do provedor ou do gateway. Eventos de analytics dizem quem, em qual projeto e com qual ferramenta, mas não servem como valor: numa base real, o analytics mandava todos os tokens como novos, sem descontar o cache de prompt, e inflava o custo várias vezes. Use o analytics só para atribuir, e concilie as duas fontes por dia.
Antes de confiar num dia, confira se a soma do custo por usuário reconstitui o custo do modelo no dia (por exemplo, 99% ou mais, com uma tolerância absoluta para modelos de custo irrisório) e se os usuários coletados cobrem o total informado pela API. Dia que não fecha dispara alarme e é recoletado.
APIs de relatório costumam agrupar por modelo ou por usuário, não pelos dois. Consulte o custo por modelo no dia, como referência, e, para cada modelo, o custo por usuário. Grave com merge pela chave data, produto, modelo e usuário, para recoletar um dia sem duplicar.
Custo sem usuário na origem (infraestrutura, chamadas em lote, cobranças fixas do provedor) é rateado por um peso de uso declarado: requisições, tokens ou eventos. A soma rateada é igual ao custo original. O que não tem uso rastreável no dia vai para um balde de custo sem atribuição, visível, nunca espalhado em silêncio.
O mesmo usuário aparece com e-mail, id de login e id do app. Leve tudo a um id canônico e some os fragmentos. Nomes de modelo mudam com versões e datas: normalize num modelo canônico com o provedor ao lado. Marque usuários de desenvolvimento e confira, a cada carga, o mapa de chave de API para produto: chave e rótulo trocados não dão erro.
O uso da própria equipe (testes, agentes internos, desenvolvimento) é despesa da empresa, não custo do produto. Separe numa linha própria e tire do custo por cliente e da margem do plano.
O provedor fecha o dia em UTC, que cobre pedaços de dois dias de São Paulo. No diário, declare qual dia está usando; no mensal, a diferença é pequena. Nunca misture colunas de dia UTC e de dia local na mesma soma.
A maior parte do custo de API é cobrada em dólar. Guarde o valor e a moeda de origem, converta com a taxa do dia da competência numa camada só e nunca some valores de moedas diferentes. Exposição cambial = soma do valor de origem em USD.
Some o custo dos usuários do cliente no mês e compare com o MRR e com os créditos comprados. Mostre a distribuição de custo por usuário em percentis (p50, p75, p90, p99): a média esconde os heavy users. Um limite simples de alerta funciona, como usuário com mais de US$ 20 num dia.
Eventos de uso enviados pelo produto podem chegar duas vezes. Deduplique por um hash do conteúdo do evento antes de somar tokens, e guarde as retentativas da chamada como métrica própria: retentativa consome token e não entrega resposta.
Qual fonte responde cada pergunta
Dinheiro de um lado, atribuição do outro, conciliados por dia.
Definições
Armadilhas que já aconteceram
O custo vindo dos eventos de analytics tratava todos os tokens como novos. Num mês, o provedor registrou a maior parte dos tokens de um modelo como cache, e o analytics precificou tudo como entrada nova.
Valor sempre da API de custo; analytics só para atribuir.
A carga de eventos de analytics gravava sucesso pegando só alguns minutos de dados em cerca de um terço das execuções, e dias inteiros sumiam sem nenhum alerta.
Reconcilie por dia com a fonte monetária e alarme quando a cobertura cair.
O produto era definido pela chave da API, e uma chave de um produto gravada com o rótulo de outro mandou o consumo para o produto errado, sem erro nenhum.
Valide o mapa de chave para produto a cada carga.
O valor na moeda original foi removido por parecer duplicado, e com a maior parte do custo de API em dólar ninguém conseguia dizer a exposição cambial.
Guarde valor e moeda de origem emparelhados.
Eventos de uso chegavam repetidos pela fila de mensagens, e o consumo de tokens de alguns fluxos aparecia dobrado.
Deduplique por hash do conteúdo do evento.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Para cada dia e modelo, a soma do custo por usuário reconstitui pelo menos 99% do custo do modelo informado pelo provedor.
- Custo atribuído + custo sem atribuição + uso interno = custo total do dia, sem diferença.
- O custo total do mês bate com a fatura dos provedores (diferença abaixo de 1%, explicada por câmbio).
- Nenhum usuário aparece com dois ids diferentes no mesmo dia.
- Recoletar um dia não muda o total dos outros dias nem duplica linhas.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Custo de IA por cliente - O valor em dinheiro vem da API de custo do provedor ou do gateway. Eventos de analytics servem só para atribuir usuário e projeto, nunca como valor. - Custo do dia = atribuído + sem atribuição + uso interno. - Custo compartilhado é rateado por peso de uso declarado (<peso>). A soma rateada é igual ao original. - Uso interno do time não entra no custo por cliente nem na margem do plano. - O dia do provedor é UTC. Diga qual dia está usando. - Valores na moeda de origem nunca são somados entre moedas. Conversão pela taxa do dia da competência. - Usuários e modelos estão em ids canônicos. - Custo por cliente é comparado com o MRR e os créditos do cliente. Use percentis, não só média. - Se um dia não passou na trava de completude, diga que o dia ainda não fechou. Exceções por cliente: - <cliente>: plano <plano> inclui <n> créditos de IA por mês. - <cliente>: projeto <projeto> é uso interno.
Construa no meu workspace Nekt o caso "Custo de IA por cliente, usuário e modelo" seguindo as regras em https://academy.nekt.com/industrias/saas/custo-ia-por-cliente.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Quando cada envio ou documento gerado tem o seu registro de custo de LLM, some por entrega e compare com o preço unitário.
Uma série diária de custo e economia atribuída a cada troca de modelo ou de prompt, para provar que a mudança valeu.
Intervenções humanas e retentativas por conversa, para saber se o modelo mais barato está piorando o atendimento.