| Item de cobrança | Preço público do Claude Opus 4.7 |
|---|---|
| Tokens de entrada base | US$ 5 / 1 milhão de tokens |
| Tokens de saída | US$ 25 / 1 milhão de tokens |
| Escrita em cache por 5 minutos | US$ 6,25 / 1 milhão de tokens |
| Escrita em cache por 1 hora | US$ 10 / 1 milhão de tokens |
| Cache hit / refresh | US$ 0,50 / 1 milhão de tokens |
Sem cache, a fórmula básica é:
custo = input_tokens / 1.000.000 × 5
+ output_tokens / 1.000.000 × 25
Com prompt caching, separe o contexto reutilizável: a primeira escrita no cache de 5 minutos usa US$ 6,25/MTok; a primeira escrita no cache de 1 hora usa US$ 10/MTok; acessos posteriores em cache hit/refresh usam US$ 0,50/MTok. Perguntas novas e mensagens não cacheadas continuam entrando pelo preço normal de input, e a resposta do modelo continua pelo preço de output.
Se você vai resumir ou analisar um arquivo grande apenas uma vez, sem perguntas posteriores, a conta é direta. Documento, instruções de sistema e pergunta entram como input; a resposta do modelo entra como output.
| Cenário | Input | Output | Custo estimado |
|---|---|---|---|
| Resumo de documento longo menor | 100k | 5k | cerca de US$ 0,625 |
| Análise de documento médio/grande | 300k | 8k | cerca de US$ 1,70 |
| Análise de documento muito grande | 1M | 10k | cerca de US$ 5,25 |
Exemplo com 300k tokens de entrada e 8k tokens de saída:
300.000 / 1.000.000 × 5 = 1,50
8.000 / 1.000.000 × 25 = 0,20
total = 1,70 dólar
Um cuidado importante na migração: a documentação de preços informa que o Opus 4.7 usa um novo tokenizer, e a mesma sequência fixa de texto pode gerar até 35% mais tokens. Portanto, se uma aplicação antiga estimava 300k tokens de input, vale testar novamente ou aplicar uma margem conservadora.
Com essa margem máxima, 300k viram 405k tokens. Mantendo 8k de saída:
405.000 / 1.000.000 × 5 = 2,025
8.000 / 1.000.000 × 25 = 0,20
total ≈ 2,23 dólares
Em produtos de análise documental, o maior custo nem sempre é a primeira resposta. O problema aparece quando o sistema reenvia o mesmo PDF, contrato, relatório ou base de contexto em cada nova pergunta. Se o usuário fará várias perguntas sobre o mesmo material, prompt caching deve entrar no desenho de custos desde o início.
Suponha:
| Estratégia | Composição | Custo estimado |
|---|---|---|
| Primeira rodada, criando cache de 5 minutos | 300k × US$ 6,25/MTok + 2k × US$ 5/MTok + 2k × US$ 25/MTok | cerca de US$ 1,935 |
| Rodada seguinte com cache hit | 300k × US$ 0,50/MTok + 2k × US$ 5/MTok + 2k × US$ 25/MTok | cerca de US$ 0,21 |
| Sem cache, reenviando tudo a cada vez | 302k × US$ 5/MTok + 2k × US$ 25/MTok | cerca de US$ 1,56 |
Nesse exemplo, a primeira rodada com cache é mais cara do que uma rodada sem cache. Mas, a partir da segunda pergunta sobre o mesmo documento, o custo acumulado já muda:
sem cache, duas rodadas: cerca de 1,56 × 2 = 3,12 dólares
com cache de 5 min, duas: cerca de 1,935 + 0,21 = 2,145 dólares
Por isso, o número mais importante para esse tipo de aplicação é a taxa de cache hit: o documento é realmente reutilizado? As perguntas acontecem dentro da janela de cache? Cada rodada traz pouco conteúdo novo ou continua anexando grandes blocos fora do cache?
O mesmo raciocínio vale para chats longos e agentes. Se a aplicação manda todo o histórico para o modelo a cada rodada, a parte de input cresce rápido. O ideal é identificar quais trechos do contexto são estáveis e reutilizáveis e avaliar se fazem sentido para prompt caching.
Exemplo:
| Estratégia | Custo estimado |
|---|---|
| Sem cache: 200k de histórico + 1k de nova mensagem + 2k de saída por rodada | cerca de US$ 1,055 / rodada |
| Escrever 200k de histórico em cache de 5 minutos, na primeira rodada | cerca de US$ 1,305 |
| Rodada posterior com cache hit de 5 minutos | cerca de US$ 0,155 / rodada |
| Escrever 200k de histórico em cache de 1 hora, na primeira rodada | cerca de US$ 2,055 |
| Rodada posterior com cache hit de 1 hora | cerca de US$ 0,155 / rodada |
A escolha entre cache de 5 minutos e de 1 hora depende menos da tabela de preços isolada e mais do comportamento do usuário:
Tarefas em lote aparecem em classificação, rotulagem, resumo em massa e análise offline. Mas, antes de confirmar o preço aplicável ao seu contrato, conta ou plataforma, evite colocar descontos não verificados no orçamento formal. Uma forma conservadora é estimar primeiro pelo preço público síncrono da Claude API e depois substituir pelos valores efetivos, se houver batch pricing aplicável.
A fórmula conservadora é:
custo total = total de input tokens / 1.000.000 × 5
+ total de output tokens / 1.000.000 × 25
Exemplo: 10.000 tarefas, cada uma com 2k tokens de input e 500 tokens de output.
total de input = 10.000 × 2.000 = 20.000.000 tokens
total de output = 10.000 × 500 = 5.000.000 tokens
custo de input = 20 × 5 = 100 dólares
custo de output = 5 × 25 = 125 dólares
total = 225 dólares
Nesse caso, US$ 225 é o valor conservador sem desconto de batch. Se depois você confirmar um preço específico de lote, substitua as tarifas na fórmula.
Também vale separar o preço da API direta do preço cobrado por nuvem ou intermediário. O CloudPrice, fonte de terceiros, lista Opus 4.7 em Anthropic/global a US$ 5 de input e US$ 25 de output por MTok, mas também mostra alguns códigos regionais do AWS Bedrock a US$ 5,50 de input e US$ 27,50 de output por MTok. Use esse tipo de dado como alerta de conferência; para compra e orçamento final, valide no painel de cobrança, contrato e documentação da plataforma usada.
Sem logs reais, uma estimativa baseada só em médias tende a subestimar a fatura. Pelo menos três fatores devem entrar como margem:
Como regra de planejamento, não como preço oficial da Anthropic, uma margem prática pode ser:
| Fase | Multiplicador sugerido |
|---|---|
| Prova de conceito ou piloto | valor teórico × 1,2 a 1,5 |
| Produção com tráfego relativamente estável | valor teórico × 1,35 a 1,6 |
| Migração de modelo antigo para Opus 4.7 com muito contexto longo | valor teórico × 1,5 a 1,8 |
Depois do lançamento, substitua suposições por dados: distribuição real de tokens, proporção de cache hit, tamanho médio de resposta e valores cobrados na fatura.
Sem cache, você pode começar com:
custo mensal ≈ requisições por dia × 30
× (input médio / 1.000.000 × 5
+ output médio / 1.000.000 × 25)
Com cache, não misture tudo em uma média única. Separe:
custo mensal ≈ custo de input normal
+ custo de cache write
+ custo de cache hit / refresh
+ custo de output
Campos mínimos para preencher:
| Variável | Exemplo |
|---|---|
| Input médio por chamada | 300.000 tokens |
| Output médio por chamada | 8.000 tokens |
| Requisições por dia | 1.000 |
| Tokens de cache write | 300.000 por documento |
| Tokens de cache hit | 300.000 por acerto |
| Cache hit rate | 60% |
| Margem de tokenizer | até × 1,35 |
| Margem operacional | por exemplo × 1,35 a 1,6 |
Para uma análise única de documento longo, estime com US$ 5/MTok de input e US$ 25/MTok de output.
Para perguntas repetidas sobre o mesmo documento ou conversas que carregam muito histórico, simule prompt caching antes de fechar o orçamento. No exemplo com documento de 300k tokens, pergunta de 2k e resposta de 2k, uma rodada com cache hit de 5 minutos sai por cerca de US$ 0,21, contra cerca de US$ 1,56 ao reenviar o documento inteiro.
Para tarefas em lote, use o preço público síncrono como piso conservador até confirmar descontos, contrato ou tarifa do provedor. E, se estiver migrando para o Opus 4.7, não esqueça a margem de tokenizer: em cenários de contexto longo, multiplicar o input estimado por até 1,35 antes de adicionar a margem operacional tende a aproximar melhor o orçamento da fatura real.