Como calcular a margem de um serviço feito com Claude Code?

Tem serviço que parece lucrativo na proposta e some no fim do mês

Você entregou, o cliente aprovou, o valor caiu na conta, e mesmo assim a sensação é de que sobrou pouco (ou nada)

O padrão é quase sempre o mesmo: quem cobra por projeto feito com Claude Code olha só o valor da assinatura, acha que aquilo é "o custo da ferramenta" e encerra a conta ali

Aí some da planilha o tempo de revisar código gerado, as rodadas extras de retrabalho, a espera por reset e o consumo que estourou o incluso do plano

Esse post entrega o MÉTODO, não valores

Nada de tabela de preço, nada de conversão pra real, nada de "gasta X por projeto": você vai montar a conta com os números do SEU serviço, medidos na sua máquina

Bora?

O que você precisa antes de fazer a conta

O mínimo pra conta não sair torta:

• Saber qual plano você usa, e isso muda a leitura de tudo. O bloco Session do /usage é referência pra quem usa chave de API. Assinantes Pro e Max enxergam barras de uso do plano, não custo faturável
• Ter o Claude Code em uso no projeto, com as sessões daquele serviço rodando de verdade (a medição vem do histórico real, não da memória)
• Ter Node instalado, porque o ccusage roda sem instalação global via npx
• Um registro simples de horas por projeto, pode ser planilha, pode ser bloco de notas. Se não tem registro, não tem margem: tem chute

Esse último item é o que mais gente pula

E é justamente o que costuma pesar mais na conta final

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Passo a passo para calcular a margem do seu serviço

1. Delimite o escopo e o período do serviço. Antes de medir qualquer coisa, escreva o que entra na entrega e entre quais datas o trabalho aconteceu. Sem recorte de período, o consumo de um cliente contamina o de outro

O erro comum deste passo: medir "o mês inteiro" e atribuir tudo a um cliente só, quando você tocou três projetos no mesmo intervalo

2. Meça o consumo da ferramenta. Dentro do Claude Code, rode:

/usage

Ele mostra o uso de tokens da sessão, as barras de uso do plano, estatísticas de atividade e o detalhamento de consumo

E entenda o que está sendo cobrado: a cobrança do Claude Code é por token consumido, com linhas separadas de input, output, cache read e cache write

Ou seja, não é "uma mensagem = um custo": o mesmo pedido pode pesar diferente conforme o tamanho do contexto e o comportamento do cache. Se quiser ver essa lógica de custo por token aplicada em outro modelo, dá pra estudar o mesmo raciocínio em um exemplo de cálculo de gasto por token na API

O erro comum deste passo: assinante Pro ou Max tratar o número de custo da sessão como custo faturável. Nesses planos o uso já está incluído na assinatura, então aquele valor não é a conta que você repassa pro cliente

3. Puxe o histórico do período. O /usage te dá a foto de agora, mas margem se calcula sobre um intervalo. Pra isso existe o ccusage, uma CLI de terceiros que lê os arquivos JSONL de sessão gravados localmente pelas CLIs de agente e monta relatórios de uso e custo estimado

npx ccusage@latest

Ele é local e gratuito, não exige chave de API pra funcionar, e o pacote está publicado no npm com o nome ccusage

Os relatórios saem em recortes diário, semanal, mensal e por sessão, que é exatamente o que você precisa pra ratear consumo por período de serviço

O erro comum deste passo: usar o número do relatório como verdade absoluta de faturamento. É custo ESTIMADO a partir dos logs locais, serve pra dimensionar a conta, não pra emitir nota

4. Contabilize o seu tempo. Anote as horas em três baldes separados: escrever e refinar prompt, revisar a saída, testar o que voltou

Separe mesmo, não jogue tudo em "horas do projeto"

Quando você separa, aparece na cara qual etapa está comendo sua margem

O erro comum deste passo: contar só o tempo de "pedir" e esquecer o tempo de ler linha por linha o que a IA produziu. Revisão é trabalho, e é caro

5. Contabilize o retrabalho. Rodadas extras, correção de coisa que voltou errada, refatoração do que foi aceito rápido demais

Retrabalho merece linha própria porque ele tem causa e a causa é corrigível (quase sempre escopo mal definido)

O erro comum deste passo: diluir retrabalho dentro das horas normais. Assim você nunca descobre que o problema não foi a ferramenta, foi o briefing

6. Some os custos fixos rateados do período. Assinaturas, infraestrutura, ferramentas de apoio. Divida pelo número de projetos ativos no intervalo e leve só a fatia do serviço em questão

Se você trabalha com mais gente, esse rateio muda de figura e vira uma conta de custo por dev por mês, com assentos e não com uma assinatura só

O erro comum deste passo: jogar o fixo inteiro em um único cliente e concluir que "esse projeto deu prejuízo"

7. Aplique a fórmula. Agora é aritmética:

custo total = custo da ferramenta no período
            + horas de prompt, revisão e teste x seu valor/hora
            + horas de retrabalho x seu valor/hora
            + fixos rateados do período

margem em valor = preço cobrado - custo total
margem em % = (margem em valor / preço cobrado) x 100

Calcule os dois: valor e percentual

Valor te diz quanto entrou no bolso, percentual te diz se o modelo de negócio se sustenta quando o projeto escalar

O erro comum deste passo: olhar só o valor absoluto. Um serviço grande pode entregar bastante em reais e ainda assim ter percentual ruim, o que quebra quando você tenta repetir a operação

8. Defina o preço mínimo a partir da margem alvo. Decidiu que quer trabalhar com uma margem X? Então o preço não é palpite:

preço mínimo = custo total / (1 - margem alvo em decimal)

Esse número vira o seu piso de orçamento pro próximo serviço parecido

O erro comum deste passo: esquecer que os limites de sessão e semanal são compartilhados entre todos os modelos, então trocar de modelo no meio do aperto não devolve acesso. Se o prazo depende disso, o cronograma (e o preço) precisa considerar a espera

Os custos que quase todo mundo esquece na conta

Esses aqui raramente entram na planilha e são exatamente os que corroem a margem:

• Retrabalho por escopo mal definido. É o campeão. Cada ida e volta consome token E consome hora sua, dobrando o custo do mesmo pedaço de entrega
• Tempo de revisão do código gerado. Você não entrega o que saiu sem ler. Se lê, é hora trabalhada, e hora trabalhada é custo
• Espera por reset. O limite de uso por sessão reinicia a cada cinco horas, e existe também um limite semanal que zera em um horário fixo atribuído à conta. Prazo apertado somado a reset vira madrugada, e madrugada é margem indo embora
• Consumo extra por contexto longo ou perda de cache. No detalhamento do /usage, em planos Pro, Max, Team e Enterprise, o Claude Code sinaliza comportamentos que respondem por 10% ou mais do uso recente (como contexto longo ou perda de cache) e traz dica de redução. Vale olhar esse aviso: ele aponta onde você está queimando uso sem perceber
• O gasto além do incluso. Ao bater o limite incluso, assinantes de Pro, Max 5x e Max 20x podem seguir trabalhando com créditos de uso, cobrados nas tarifas padrão da API. Isso é ótimo pra não travar a entrega e é péssimo pra margem se ninguém estiver olhando

Uma forma simples de organizar isso na planilha:

Como colocar um teto de gasto para proteger a margem

Medir depois é bom

Mas travar antes é melhor 🙂

A ideia aqui é simples: em vez de descobrir o estouro na fatura, você combina um limite de gasto com créditos de uso e deixa o próprio Claude Code te avisar quando estiver chegando perto

São dois ajustes:

1. Defina o limite mensal. Em planos Pro e Max, dá pra definir um limite mensal de gasto com créditos de uso pelo comando dentro do Claude Code:

/usage-credits

Esse é o teto: o número que você não quer passar dentro do mês, alinhado com a margem que combinou pro serviço

2. Configure recarga automática e alertas. É possível configurar recarga automática por limiar de saldo (quando o saldo cai abaixo do ponto que você definiu, ele recompõe sozinho) e alertas de uso quando o gasto se aproxima do limite

O alerta é a parte que interessa aqui: ele te avisa ANTES do estouro, no momento em que ainda dá pra renegociar prazo ou escopo com o cliente

O erro comum deste passo: ligar a recarga automática e esquecer o alerta. Aí o trabalho nunca trava, o que parece bom, só que você só descobre o tamanho da conta quando ela já aconteceu

Pensa no teto como uma trava de margem: você traduz "quero fechar esse serviço com margem X" em um número que o próprio orçamento do projeto respeita

Se o teto encostou, não é a ferramenta que está cara, é o escopo que cresceu sem o preço acompanhar

Veja também: repositório open source para turbinar seu agente

Pra quem quer explorar ferramentas open source dentro do fluxo de trabalho com agentes, esse vídeo do canal mostra um repositório gratuito sendo plugado num agente:

Conclusão

Margem se mede com registro, não com estimativa de memória

A conta é sempre a mesma: consumo da ferramenta no período, mais o seu tempo (prompt, revisão, teste), mais retrabalho, mais fixos rateados, comparado com o que você cobrou

O próximo passo é concreto e cabe em uma tarde: no fim do próximo serviço, rode /usage no Claude Code, gere o relatório do período com npx ccusage@latest, anote as horas que você realmente gastou e refaça a fórmula

Depois compare com o valor que você tinha cobrado

Se bateu, você já tem seu piso de orçamento. Se não bateu, você acabou de descobrir por que o mês passado foi apertado…

Até o próximo post!