Um orçamento de IA que o time consegue cumprir
Por que tetos por assento quebram em cargas de agente, como orçar por carga de trabalho e a revisão semanal de quinze minutos que mantém o número honesto.
Todo time que adota o Claude Code escreve a mesma linha no orçamento: "US$ X por desenvolvedor por mês." Três meses depois, essa linha é ignorada ou disputada — porque o gasto de agente não se comporta como custo por assento. Ele se comporta como custo por carga de trabalho. Este post é o orçamento que sobrevive ao contato com a forma como agentes realmente cobram.
Transparência desde o início: eu opero o Teapot Router, um gateway de equipe para GPT e Claude Code com cotas por key e consolidação de gastos em nível de organização. O método abaixo funciona em qualquer endpoint que mede por requisição — nada aqui depende de usar o nosso.
Tetos por assento quebram primeiro
Um teto flat por desenvolvedor é o primeiro orçamento que todos tentam e o primeiro que falha, por um motivo estrutural: o gasto de agente varia com a atribuição, não com a pessoa. O mesmo desenvolvedor pode gastar 5x o normal numa semana só porque a tarefa mudou — um refactor gigante com centenas de turnos, ou um codebase com cache ruim. O teto pune a carga de trabalho, não a pessoa, e os três modos padrão de falha vêm a seguir:
- O teto sufoca as atribuições pesadas — exatamente o trabalho que justificou comprar as ferramentas.
- O teto nunca prende usuários leves — a média perde o sentido e o financeiro para de confiar na linha inteira.
- A execução cai em planilhas, semanas tarde, quando o dinheiro já foi gasto e a discussão já apodreceu.
Orce a carga de trabalho, não o assento
Pegue as três variáveis que decidem o gasto de agente — turnos, contexto reenviado, taxa de acerto de cache — e aloque contra elas em escala de time:
- Modele o custo mensal por dev a partir da forma real, não de médias: turnos diários × tamanho de contexto × comportamento de cache. Duas semanas de dados observados valem mais que qualquer benchmark.
- Aloque por projeto ou classe de tarefa, não por headcount: manutenção boilerplate e trabalho arquitetural difícil merecem pistas diferentes — e rotear assim é a maior economia honesta.
- Fixe tetos no percentil 80 da forma observada, não na média — um teto que a carga atinge numa semana normal é um teto que ninguém respeita.
Imponha onde a medição acontece
Orçamento imposto em planilha é desejo. As requisições já são medidas em algum lugar — modelo, tokens, acertos de cache, custo, por requisição — então o orçamento deveria morar no mesmo lugar: cotas por key que limitam em vez de estourar em silêncio, alertas de anomalia em vez de alerta em cada linha, e um consolidado por organização que o financeiro reconcilia com a fatura. Quando o que cobra também é o que impõe o orçamento, o orçamento deixa de ser briga.
A revisão semanal de quinze minutos
Três perguntas, uma vez por semana, mantêm o orçamento vivo: a tendência de acerto de cache está plana ou caindo? Qual key ou projeto mais se moveu, e a carga realmente mudou? O teto precisa de rebalanceamento antes que alguém o atinja por um motivo legítimo? Isso não é reunião — é um olhar num livro-razão de três colunas, e substitui inteiramente o incêndio trimestral.
Orçamentos falham quando são palpites impostos por planilha. Firme-se quando são modelos da carga real, impostos onde a medição já acontece, e corrigidos semanalmente em quinze minutos em vez de trimestralmente em incêndio.
Perguntas frequentes
Quanto orçar por desenvolvedor?
Não há número universal — modele sua forma (turnos diários, tamanho de contexto, taxa de acerto; a calculadora em teapotrouter.com/en/claude-code-cost-calculator faz a conta), observe duas semanas e fixe o teto no percentil 80 do observado.
E quando alguém estoura?
A key limita e um alerta dispara — sem drama, sem linchamento. Estouro é informação sobre a forma da carga: a atribuição mudou, o cache degradou, ou o teto era palpite. Os três se corrigem na revisão semanal.
Estamos em planos de assinatura — ainda aplica?
Planos acertam para algumas formas (o ponto de equilíbrio é outro post), mas escondem o dado por requisição — sem trilha de auditoria. Se o financeiro precisa dos itens, só o medido por uso reconcilia.