Cost attribution por feature, workflow e tenant: de qual bolso saiu cada token

A fatura do provedor de LLM chega com um número em dólar. As perguntas do negócio chegam em outra unidade: quanto custou cada feature, cada workflow, cada cliente. Cost attribution é a ponte entre os dois. Em cloud, essa ponte é disciplina madura: tagging, showback, chargeback. Com LLM, a diferença central é uma só: atribuição é um schema que se decide antes do primeiro request. Este artigo entrega esse schema, o contrato de atribuição, pronto pra levar pra sua equipe.

Resumo executivo

Para quem decide e não vai abrir o gateway, o artigo cabe em quatro pontos.

• O problema. O provedor de IA fecha a conta pelo recorte dele, que é a sua organização. Esse recorte não diz qual cliente nem qual funcionalidade gerou o gasto.
• O custo de não resolver. Sem atribuição, preço, margem e corte de gasto se apoiam em estimativa. Em abril de 2026, o CTO da Uber informou que a empresa consumiu o orçamento anual de IA em quatro meses.
• A solução. Cost attribution marca cada chamada de IA com cliente, funcionalidade e processo, no momento em que ela acontece. Sem essa marca, sobra rateio estimado.
• O que pedir ao time. Uma tabela de uma página, o contrato de atribuição, decidida antes do próximo request em produção. Ela está na seção “O contrato de atribuição”.

O problema clássico

Cost allocation em cloud tem um playbook conhecido: tag em cada recurso, custo agregado por time e produto, rateio pro que é compartilhado. Showback dá visibilidade; chargeback cobra a despesa do centro de custo de cada área. O State of FinOps 2026 mostra essa disciplina engolindo a IA. Numa amostra de 693 respostas, 98% gerenciam gasto de IA, contra 63% em 2025 e 31% em 2024. E o item número um da lista de capacidades desejadas em tooling: monitoramento granular do gasto de IA, em tokens, requests de LLM e utilização de GPU.

A demanda aponta na mesma direção. Não é “quanto gastamos”, é “quem gastou e com o quê”. Isso é cost attribution.

Um caso real

A Uber incentivou o time a usar IA “o máximo possível” e chegou a ranquear o uso interno em placar de líderes. Em abril de 2026, o CTO da empresa informou que o orçamento anual de IA tinha acabado em quatro meses. A revelação foi publicada pelo The Information e reportada pelo TechCrunch.

Em 2 de junho, a Bloomberg reportou a resposta da empresa, em matéria que o TechCrunch resumiu no mesmo dia. A Uber passou a aplicar teto de US$ 1.500 por mês, por funcionário e por ferramenta de código agêntico, entre elas Claude Code e Cursor. O uso fica visível num painel interno que cada funcionário acessa. Em certos casos, o teto pode ser ultrapassado com autorização.

As dimensões desse teto são funcionário e ferramenta, não tenant nem feature. Duas coisas do caso valem para o recorte. A primeira: placar de uso mostra quem consumiu, e a Uber já tinha isso, mas placar não impede a chamada seguinte. A segunda: o limite só virou decisão operável quando ganhou dimensão explícita e teto por dimensão.

O teto do provedor

A Usage & Cost API da Anthropic agrupa uso por chave de API, workspace, modelo, service tier, janela de contexto e geografia de inferência. O custo em dólar sai agrupado por workspace.

A OpenAI agrupa por projeto, chave de API, usuário e modelo.

Repare no vocabulário: são dimensões da organização. Feature, workflow e tenant não são dimensões nativas de nenhum dos dois. Dá pra torcer workspace ou projeto pra representar um tenant grande; o cruzamento fino entre as três dimensões fica fora do alcance. O provedor fecha a conta da empresa. A pergunta do negócio se responde na sua infraestrutura, e o resto do artigo é sobre como.

Por que o schema vem antes do primeiro request

Não existe retag. Recurso de cloud vive dias ou meses. O relatório de recursos sem tag aponta o dono, a tag entra e o custo passa a ser atribuído dali em diante. Request de LLM vive milissegundos. A chamada que saiu sem nenhuma chave de correlação vira custo órfão: não há recurso vivo pra taggear depois, e o que resta é rateio estimado. Cost attribution de LLM é decisão tomada no request, não faxina de fim de mês.

O preço varia dentro do mesmo request. O mesmo modelo cobra valores diferentes pros quatro tipos de token que a Anthropic reporta: input não cacheado, input cacheado, criação de cache e output. E trocar o modelo do roteamento muda o custo da feature sem mudar uma linha do código dela. O registro por request precisa guardar o modelo e os contadores por tipo, não só o total em dólar.

Suas dimensões são combinatórias. A tentação óbvia é criar uma chave de API por coisa a medir. Só que a unidade que importa é o cruzamento: a feature de resumo, dentro do workflow de cobrança, servindo o tenant Acme. Chave por combinação explode em manutenção. As dimensões precisam viajar juntas, no mesmo request.

O contrato de atribuição

O coração de cost attribution é um schema de uma página. É o registro que todo request de LLM gera, com as dimensões de negócio e as medidas de custo. Este é o contrato pra discutir com a equipe:

Cinco definições curtas seguram a taxonomia. Tenant é a organização cliente. Cliente final é o usuário dentro do tenant, quando ele existe como entidade própria. Agente é a identidade operacional que faz a chamada. Feature é a capacidade do produto; workflow é o processo que agrupa chamadas. E modelo_resposta guarda o modelo que atendeu o request: com roteamento no gateway, ele pode diferir do modelo pedido no request.

Duas regras de design fazem o contrato funcionar:

Taxonomia fechada. feature e workflow vêm de uma lista versionada no repositório, não de string livre. Tag com typo cria uma dimensão fantasma que nunca mais agrega com as outras. Mudança na lista passa por review, como qualquer schema.

Enforcement na admissão. Request sem tenant ou sem feature é rejeitado no gateway, igual budget estourado. A validação compara a tag recebida com a versão ativa da taxonomia e rejeita valor desconhecido. É a resposta estrutural pro “não existe retag”: o custo órfão morre na porta, não no relatório.

Duas pontes ancoram o contrato em padrão aberto. Na telemetria, as convenções GenAI do OpenTelemetry já nomeiam a metade técnica: gen_ai.response.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens e os contadores de cache. Cuidado com a semântica: no OTel, input_tokens é o total e já inclui os cacheados; os contadores de cache são detalhamento, não parcela a somar de novo. A convenção está em estabilidade “development”, e as dimensões de negócio entram como atributo custom ao lado delas. No financeiro, o FOCUS, spec da FinOps Foundation, normaliza dados de billing entre provedores. Quando o dataset informa consumo em tokens, ele entra nos campos padronizados de quantidade e unidade. O contrato não depende de nenhum dos dois; as pontes servem a quem já usa esses padrões.

O contrato no gateway

Se a equipe já opera um gateway no caminho das chamadas, ele é o lugar natural do contrato. Parte das dimensões pode exigir instrumentação na aplicação, dependendo da edição da ferramenta. No LiteLLM, que calcula o gasto automaticamente pros modelos que conhece, o request fica assim (exemplo adaptado da doc):

curl 'http://0.0.0.0:4000/chat/completions' \
  --header 'Authorization: Bearer sk-acme-agente-cobranca' \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "..."}],
    "user": "cliente-4412",
    "metadata": {
      "tags": ["feature:resumo-fatura", "workflow:cobranca-whatsapp"]
    }
  }'

Cada dimensão do contrato tem um veículo. A chave virtual identifica o agente; o team dono da chave, cadastrado antes no gateway, identifica o tenant. O campo user marca o cliente final, quando ele é uma entidade distinta do tenant. As tags marcam feature e workflow. Modelo, contadores e custo estimado o gateway preenche sozinho na volta.

Um aviso de licenciamento: no LiteLLM, tag por request é recurso Enterprise. Na versão aberta, chave e user cobrem agente, tenant e cliente. Feature e workflow exigem Enterprise, ou log da própria aplicação correlacionado pelo request_id que aparece no spend log. O contrato não muda; muda qual camada preenche cada campo. A consulta vem depois: /spend/logs?summarize=false devolve as transações individuais, e /user/daily/activity devolve o gasto diário quebrado por modelo, provedor e chave.

O que sai do outro lado

Com as dimensões persistidas num lugar só, direto no gateway ou após correlação com o log da aplicação, o relatório que hoje não existe vira um GROUP BY. Exemplo ilustrativo, com números fictícios:

Um aviso antes de tratar essa tabela como o custo da feature. Em deployment de produção, a infraestrutura em volta da chamada costuma representar de 40% a 60% do gasto total da feature. A afirmação é do relatório Token Economics da FinOps Foundation, que aponta RAG e arquiteturas agênticas como os casos em que isso mais aparece. Banco vetorial, embedding, reranker, cache e runtime de orquestração não aparecem na fatura do provedor de modelo.

O documento recomenda duas trilhas de atribuição em paralelo, unidas por um identificador comum de aplicação ou workload. O gasto de token vem do gateway, o gasto dessa infraestrutura vem do billing de cloud e de SaaS. No nosso contrato, o campo feature serve como essa chave de junção.

Uma tabela dessas destrava três decisões que a fatura sozinha não sustenta.

Reprecificar: cruzando o custo estimado por tenant com receita e câmbio, a parcela de LLM na margem de cada cliente aparece.

Rotear: a feature barata e volumosa vira candidata a um modelo mais barato, decisão que ainda passa pela avaliação de qualidade.

E orçar: o token budget do artigo anterior ganha teto por dimensão real de negócio, não chute. Budget sem atribuição bloqueia pelo recorte técnico, chave ou team, sem dizer qual feature consumiu o teto. Atribuição sem budget explica o gasto e não impede a chamada seguinte. Os dois usam a mesma infraestrutura: chave por agente, team por tenant, gateway no meio.

Fechando

No mapa do artigo dos quatro eixos, cost attribution não move nenhum knob. Ela mostra onde o gasto está e qual knob vale avaliar, pra qual tenant, com número em vez de intuição.

O primeiro passo não é ferramenta, é reunião. A tabela do contrato cabe numa página, e a taxonomia de features e workflows se decide antes do primeiro request em produção. Depois vem o gateway, o enforcement e o relatório. O total da fatura vai continuar sendo um número só. A diferença é saber de qual bolso saiu cada request.

Fontes

• FinOps Foundation: State of FinOps 2026 Report
• FinOps Foundation: Token Economics, Managing AI Value in SaaS Model Token Costs
• TechCrunch: Uber caps employee AI spending after blowing through budget in 4 months
• Anthropic: Usage and Cost API
• OpenAI: Usage API reference
• LiteLLM: Spend Tracking
• LiteLLM: Customers / End-Users
• OpenTelemetry: GenAI semantic conventions, registro de atributos
• FinOps Foundation: FOCUS specification