---
id: saas/custo-ia-por-cliente
industria: SaaS e tecnologia
uso: específico
esforco: alto
grao: Usuário x modelo x dia (fato); cliente x mês (unit economics)
---

# Custo de IA por cliente, usuário e modelo

Quanto cada cliente, plano e usuário custa em LLM, quem consome muito acima do que paga e se o preço cobre o uso, com um custo que bate com a fatura do provedor.

## Resumo executivo

**Para quem:** SaaS com IA dentro do produto que paga provedores de LLM por uso e cobra do cliente por assinatura ou crédito.

**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.

**Por que importa:** Em produto com IA, o custo variável cresce com o uso, não com a assinatura: poucos usuários podem consumir a margem de um plano inteiro. O provedor fatura por chave ou projeto, não por cliente, e as ferramentas de analytics estimam o custo sem o desconto de cache. Sem uma fonte monetária e uma regra de rateio, o preço é definido no escuro.

**Perguntas de negócio que responde**

- Quanto gastamos com IA ontem, por modelo e por produto?
- Quais usuários gastaram mais de US$ 20 num dia?
- Qual o custo médio por requisição e como ele mudou depois da troca de modelo?
- Qual o custo de IA de cada cliente contra o que ele paga, por plano?
- Quanto do custo é uso interno do time?
- Quais clientes estão acima do p99 de consumo?

**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

## Detalhado

### O problema

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.

### Regras de negócio

1. **Uma fonte para o dinheiro, outra para a atribuição.** 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. (Evite: Somar o custo estimado que vem nos eventos de analytics.)
2. **O total do dia precisa fechar.** 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. (Evite: Gravar o dia que a API devolveu, sem conferir o total.)
3. **Usuário e modelo pedem duas consultas.** 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. (Evite: Ratear o custo do modelo pelos usuários do dia sem consultar o detalhe.)
4. **Rateio de custo compartilhado conserva o total.** 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. (Evite: Deixar o custo compartilhado fora do custo por cliente, ou espalhar o resíduo sem dizer.)
5. **Canonize o usuário e o modelo.** 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. (Evite: Agrupar pelo identificador que a API devolveu.)
6. **Uso interno não é custo de servir.** 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. (Evite: Somar o uso do time no custo dos clientes.)
7. **Dia do provedor em UTC, dia do negócio em São Paulo.** 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. (Evite: Comparar o custo diário do provedor com o uso diário local.)
8. **Moeda de origem guardada ao lado.** 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. (Evite: Guardar só o valor convertido, ou somar USD e BRL.)
9. **Custo do cliente contra o que ele paga.** 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. (Evite: Olhar só o custo médio por usuário.)
10. **Eventos de uso deduplicados.** 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. (Evite: Somar tokens de todos os eventos recebidos.)

### Qual fonte responde cada pergunta

Dinheiro de um lado, atribuição do outro, conciliados por dia.

- **quanto gastamos, em dinheiro** → API de custo do provedor ou do gateway (`amount.value (OpenAI costs)`)
- **quem gastou: usuário, projeto, ferramenta** → Gateway por usuário ou eventos do produto
- **tokens lidos do cache** → Separar cache de tokens novos (`input_cached_tokens (OpenAI usage)`)
- **custo sem usuário na origem** → Rateio por peso de uso, soma conservada
- **custo sem uso rastreável no dia** → Custo sem atribuição, linha própria
- **uso do próprio time** → Linha interna, fora do custo de servir

### Definições

| Métrica | Definição |
|---|---|
| Custo de IA | valor cobrado pelos provedores de LLM e pelo gateway no dia, pela fonte monetária, na moeda de origem e convertido pela taxa do dia |
| Custo atribuído | parte do custo ligada a um usuário e a um cliente, direto ou por rateio |
| Custo sem atribuição | custo do dia sem uso rastreável, publicado em linha própria |
| Custo por requisição | soma do custo / soma das requisições, por modelo e dia |
| Custo de servir do cliente | custo atribuído aos usuários do cliente no mês, sem uso interno |
| Margem de IA do plano | (MRR do plano - custo de servir dos clientes do plano) / MRR do plano, por mês |
| Taxa de cache | tokens de entrada lidos do cache / tokens de entrada, por modelo e dia |
| Heavy user | usuário acima do p99 de custo diário do produto, ou acima do limite declarado |

### Armadilhas

- **O analytics inflou o custo.** 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. Como evitar: Valor sempre da API de custo; analytics só para atribuir.
- **Extração que perdia dias sem falhar.** 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. Como evitar: Reconcilie por dia com a fonte monetária e alarme quando a cobertura cair.
- **Chave e rótulo trocados.** 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. Como evitar: Valide o mapa de chave para produto a cada carga.
- **Dólar sem dizer quantos.** 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. Como evitar: Guarde valor e moeda de origem emparelhados.
- **Evento duplicado somou tokens.** Eventos de uso chegavam repetidos pela fila de mensagens, e o consumo de tokens de alguns fluxos aparecia dobrado. Como evitar: Deduplique por hash do conteúdo do evento.

### Teste de aceitação

- [ ] 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.

### Context document

```text
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.
```

### Variações

- **Custo por entrega:** 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.
- **Impacto de cada mudança:** 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.
- **Qualidade do bot ao lado do custo:** Intervenções humanas e retentativas por conversa, para saber se o modelo mais barato está piorando o atendimento.