Custo de IA

O custo da IA visível a cada requisição

Medindo consumo de token e saldo em tempo real numa plataforma SaaS.

BUFF-OLaboratório / P&Dexit 1302025–2026Pesquisa e desenvolvimento próprios

FastAPINext.jsSupabaseLangfuseTraefik

o problema

Margem de SaaS de IA morre no consumo invisível de tokens. Como tornar esse custo visível antes da fatura?

O ponto cego de quem cobra por IA

SaaS de IA cobra uma assinatura fixa e absorve o custo de token — que é variável e invisível até a fatura do provedor chegar no fim do mês.
Quem não mede o custo por requisição descobre a margem furada tarde demais, sem saber qual usuário ou qual conversa pesou.
Definir o comportamento de cada agente no código significa um deploy para cada ajuste de personalidade — e quem escreve a persona raramente é quem escreve o código.
Um monólito com estado espalhado aguenta o protótipo, mas não multi-tenancy de verdade.

As três decisões difíceis

Cada uma tinha um caminho óbvio. Em todas eu segui o outro — e em todas isso custou alguma coisa.

O custo da IA é do usuário — e ele precisa ver

o caminho óbvio: Cobra uma assinatura mensal e absorve o custo de token por dentro.
o que eu fiz: Rastreio por token com custo por modelo gravado a cada requisição, e o saldo descontando ao vivo na interface via Supabase Realtime — o usuário vê o custo da própria conversa descendo na tela.
por quê: Margem de SaaS de IA morre no consumo invisível. Quem não mede o custo por requisição só descobre o problema na fatura.
o que custou: Cada chamada carrega o overhead de contabilização, e o preço por modelo vira um dado que precisa ser mantido atualizado.

Persona é arquivo, não código

o caminho óbvio: Cada agente é uma classe no código-fonte.
o que eu fiz: Agentes definidos em Markdown, carregados e montados em runtime. Ajustar a personalidade de um agente é editar um arquivo de texto, não fazer deploy.
por quê: Quem escreve a persona não é quem escreve Python. Tirar isso do código tira o deploy do caminho de cada ajuste fino.
o que custou: A validação vira coisa de runtime, não de compilação — um arquivo malformado só falha quando roda, não quando builda.

Reconstruir em vez de remendar

o caminho óbvio: O v1 funciona. Vai empurrando e adicionando em cima.
o que eu fiz: Parei e comecei o 2.0 do zero como sete microsserviços orientados a eventos — RabbitMQ, Qdrant para busca vetorial, TimescaleDB e rastreamento distribuído com OpenTelemetry.
por quê: O v1 era um monólito com estado espalhado. Multi-tenancy de verdade — isolamento por cliente — não cabia ali sem reescrever o núcleo.
o que custou: Muito. O 2.0 não está pronto: o serviço de cobrança ainda é um esqueleto vazio. Veja abaixo o que eu aprendi com isso.

o pulo do gato

O custo descendo na tela, em tempo real

No v1, cada requisição ao modelo passa por um middleware que calcula o custo daquele consumo pelo preço do modelo usado, debita do saldo e publica a mudança. O front assina essa mudança via Supabase Realtime — o número na tela cai sozinho, sem recarregar a página.

requisição ─▶ middleware de token
                 ├─ conta tokens de entrada + saída
                 ├─ aplica o preço do modelo usado
                 └─ debita o saldo ─▶ Supabase Realtime
                                          │
                        front assina ◀────┘
                        (o saldo cai na tela, ao vivo)

Contabilização de custo por requisição com saldo em tempo real (v1)

em português claro

Dá para ver o custo de cada conversa com a IA descendo na tela, em tempo real — nada de surpresa na fatura.

O que eu refiz

Comecei o 2.0 convencido de que multi-tenancy de verdade exigia sair do monólito para sete microsserviços. Tecnicamente, continuo achando que estava certo. Na prática, subestimei o tamanho de uma reescrita distribuída para uma pessoa só — o serviço de cobrança do 2.0 ainda é um esqueleto vazio. A lição não foi “não reconstruir”. Foi que a prova de valor, o custo por token visível, já estava rodando no v1, e eu deveria tê-la mantido de pé enquanto o 2.0 amadurecia, em vez de tratar o que funcionava como descartável. É a mesma lição que aplico hoje num projeto de cliente: nunca desligue o que paga a conta antes de o substituto estar pronto.

Onde chegou

tempo real

saldo de token descontando na interface a cada requisição (v1)

serviços desenhados na arquitetura 2.0, orientada a eventos

personas em arquivo de texto, sem deploy para cada ajuste

No v1, o rastreio de custo por token funciona ponta a ponta — middleware de contabilização, saldo ao vivo via Supabase Realtime, observabilidade de LLM com Langfuse e proxy com Traefik. O 2.0 leva isso para uma arquitetura distribuída multi-tenant, com mensageria, busca vetorial e rastreamento distribuído.

o que ainda falta

A prova de controle de custo funciona no v1. A reconstrução 2.0 está parcial — o serviço de cobrança ainda é um esqueleto vazio.
Nunca foi comercializado: é P&D. Está aqui como prova de que sei medir e conter custo de infraestrutura de IA, não como produto à venda.

Tem um problema parecido?

Vamos conversar