Resultados da medição do custo de tokenização do Claude 4.7

• O Claude 4.7 gera em média 1,3~1,45x mais tokens do que a versão anterior, resultando em aumento de 20~30% no custo por sessão dentro da mesma estrutura de preços
• O aumento de tokens é mais evidente em conteúdo em inglês e código, enquanto em conteúdo CJK (chinês, japonês e coreano) quase não há mudança
• Devido à tokenização mais granular, a aderência a instruções (Instruction Following) melhora cerca de 5 pp, com redução especialmente de erros de formatação
• Como aumenta o número de tokens do prefixo em cache e do histórico da conversa, o custo de cache e a velocidade de consumo do rate limit também sobem
• Como resultado, o Claude 4.7 é avaliado como uma estrutura em que se aceita um custo extra de tokens em troca de mais precisão e execução mais detalhada de instruções

---

Resultados da medição do tokenizador do Claude 4.7

• Foi informado que o Claude Opus 4.7 da Anthropic usa 1,0~1,35x mais tokens do que a versão anterior, 4.6, mas nas medições reais foi confirmado um nível de 1,45~1,47x
• Com o mesmo preço e as mesmas cotas, o aumento no número de tokens causa efeitos como maior velocidade de consumo da janela máxima, aumento do custo do prefixo em cache e atingimento antecipado do rate limit
• O experimento foi composto por duas partes: medição de custo e medição de aderência a instruções

Método de medição de custo

• Foi usado o endpoint POST /v1/messages/count_tokens da API da Anthropic para inserir o mesmo conteúdo nos modelos 4.6 e 4.7 e comparar apenas a diferença do tokenizador
• Foram usados dois conjuntos de amostras
  • 7 amostras reais de uso enviadas por usuários reais do Claude Code
  • 12 amostras artificiais com inglês, código, dados estruturados, CJK, emoji, símbolos matemáticos etc.

• Resultados com conteúdo real do Claude Code

  • Média ponderada de 1,325x nas 7 amostras reais (8.254 → 10.937 tokens)
  • Principais exemplos
  • Arquivo CLAUDE.md: 1,445x
  • Prompt do usuário: 1,373x
  • Post de blog: 1,368x
  • Diff de código: 1,212x

• Resultados por tipo de conteúdo (12 amostras artificiais)

  • Média de conteúdo em inglês e código: 1,345x
  • Média de conteúdo CJK (chinês, japonês e coreano): 1,01x
  • Exemplos detalhados
  • Documentação técnica: 1,47x
  • Shell script: 1,39x
  • Código TypeScript: 1,36x
  • Prosa em inglês: 1,20x
  • JSON: 1,13x
  • Prosa em japonês e chinês: 1,01x

Padrões de mudança do tokenizador

• Conteúdo CJK, emojis e símbolos ficam em 1,005~1,07x, ou seja, quase sem mudança
  • Vocabulário não latino aparentemente não sofreu grandes alterações
• Conteúdo em inglês e código aumenta 1,20~1,47x, com código sendo mais afetado do que prosa
  • Strings repetidas em código (palavras-chave, imports, identificadores etc.) são subdivididas e separadas em mais tokens
• A proporção de caracteres por token no inglês cai de 4,33→3,60, e no TypeScript de 3,66→2,69
  • O mesmo texto passa a ser representado dividido em unidades menores

Por que usa mais tokens

• A Anthropic enfatiza que, no 4.7, há uma “tendência a seguir instruções de forma mais literal”
• Unidades de token menores reforçam a atenção no nível da palavra (attention) e contribuem para melhorar execução precisa de instruções, tarefas no nível de caracteres e precisão em chamadas de ferramentas
• Parceiros como Notion, Warp e Factory relataram redução de erros na execução de ferramentas
• No entanto, além da tokenização, os pesos do modelo e o post-training também foram alterados, então não é possível isolar a causa

Teste de aderência a instruções

• Foi usado o benchmark IFEval (2023, Google): entre 541 prompts como “responda com exatamente N palavras” e “escreva sem vírgulas”, foram testadas 20 amostras
• Resultados
  • Modo estrito por prompt: 4.6 → 85%, 4.7 → 90% (+5 pp)
  • Modo estrito por instrução: 86% → 90% (+4 pp)
  • No modo flexível, não houve diferença
• A melhora ocorreu principalmente pela redução de erros relacionados à formatação
• Uma diferença clara foi confirmada apenas em um único prompt (change_case:english_capital)
• Como o tamanho da amostra é pequeno (+5 pp é estatisticamente incerto), a melhora é avaliada como pequena, mas consistente

Cálculo de custo por sessão no Claude Code

• Suposição de uma sessão com 80 interações de ida e volta
  • Prefixo estático: 6K tokens (CLAUDE.md 2K + definição de ferramentas 4K)
  • Histórico da conversa: cresce 2K por turno, chegando a 160K em 80 turnos
  • Entrada/saída: 500 / 1.500 tokens por turno
  • Taxa de acerto de cache: 95%

• Custo por sessão no 4.6

  • | Item | Cálculo | Custo |
  • | --- | --- | --- |
  • | Primeira gravação no cache | 8K × $6.25/MTok | $0.05 |
  • | Leitura de cache (79 vezes) | 79 × 86K × $0.50/MTok | $3.40 |
  • | Nova entrada | 79 × 500 × $5/MTok | $0.20 |
  • | Saída | 80 × 1.500 × $25/MTok | $3.00 |
  • | Total | | cerca de $6.65 |

• Custo por sessão no 4.7

  • CLAUDE.md: 1,445x → 2K → 2,9K
  • Definição de ferramentas: 1,12x → 4K → 4,5K
  • Histórico da conversa: 1,325x → 160K → 212K
  • Entrada do usuário: 1,325x → 500 → 660
  • Prefixo médio em cache: cerca de 115K tokens
  • | Item | Cálculo | Custo |
  • | --- | --- | --- |
  • | Primeira gravação no cache | 10K × $6.25/MTok | $0.06 |
  • | Leitura de cache (79 vezes) | 79 × 115K × $0.50/MTok | $4.54 |
  • | Nova entrada | 79 × 660 × $5/MTok | $0.26 |
  • | Saída | 80 × 1.500–1.950 × $25/MTok | $3.00–$3.90 |
  • | Total | | cerca de $7.86–$8.76 |
  • Aumento de 20~30% no custo por sessão, sem mudança no preço por token
  • Usuários do plano Max passam a ter o encerramento da sessão mais cedo dentro da mesma janela de tempo

Impacto no prompt cache

1. Devido à separação de cache por modelo, ao migrar para o 4.7 o cache existente do 4.6 é invalidado
   • A primeira sessão começa sem cache aplicado, com um custo maior de prefixo
2. O próprio volume de cache aumenta 1,3~1,45x, então tanto leitura quanto gravação sobem na mesma proporção
3. Mesmo com o mesmo log de conversa, o número de tokens muda, criando uma descontinuidade em relação aos valores cobrados e aos números de monitoramento do passado

Contra-argumentos e interpretação

• “A maior parte da entrada é leitura de cache, então o impacto é mínimo”

  • Quando a taxa de acerto de cache é alta, o impacto no custo é pequeno, mas em casos de expiração de TTL, invalidação de cache e troca de modelo, o custo aumenta na proporção total

• “1,35x não é um teto, é uma faixa”

  • Os valores medidos na prática se concentram perto do limite superior (1,325x), e alguns arquivos passam disso
  • No uso real, é mais seguro planejar com base no limite superior

Conclusão

• Em tarefas centradas em inglês e código, o uso de tokens aumenta 1,3~1,45x
• A aderência a instruções melhora cerca de +5 pp, um ganho pequeno, mas prático
• O custo por sessão sobe 20~30%, com o mesmo preço por token
• Como resultado, isso é avaliado como uma estrutura em que se paga um custo adicional para obter maior precisão e execução mais detalhada de instruções

[kaydash]

Não é o Claude 4.7, e sim o Opus 4.7.

[GN⁺]

Comentários do Hacker News

• Partindo do pressuposto de que a curva de desempenho/custo dos LLMs existe em forma logarítmica, não está claro se o Opus 4.5+ é um novo ponto nessa curva ou se apenas está numa faixa em que o custo dispara para obter desempenho mais alto
  O fato de a Anthropic elevar os preços rapidamente pode ser um sinal de que isso reflete uma alta acentuada nos custos operacionais
  Acho que a prática de mostrar o eixo x em escala logarítmica de custo nos gráficos de avaliação de modelos acaba escondendo essa realidade

  • Foi citado o texto de Toby Ord sobre análise do custo por hora de agentes de IA. O conceito dele de fronteira de desempenho/custo merece mais atenção
  • Acho que chegou a hora de os desenvolvedores fazerem o dimensionamento adequado (right-sizing) do tamanho do modelo e do nível de esforço conforme a tarefa
    A era de simplesmente usar sempre o melhor modelo acabou. É preciso ter opções para escolher diferentes pontos dependendo do trabalho
    Para tarefas complexas, acho aceitável usar um modelo maior e gastar 5 horas de tokens de uma vez
    Mas muita gente não vai gostar dessa complexidade de escolha, e imagino que veremos mais tentativas de roteamento inteligente daqui para frente
  • Como a Anthropic está se aproximando de um IPO, a pressão para aumentar a receita por usuário é grande. No fim, eles estão caminhando para uma estrutura de preços que reflete o custo real de operar o modelo
  • Quando o modelo for implementado diretamente em silício, o custo vai cair e a velocidade vai aumentar. Vale olhar iniciativas como a Taalas
  • Se os clientes estiverem dispostos a arcar com custos mais altos, acho que seria possível oferecer modelos muito mais poderosos
    Assim como existe um público que quer opções ultracaras como as da Apple, um mercado de LLMs de altíssimo desempenho também pode existir

• Muita gente foca no custo dos modelos de IA, mas na prática o tempo gasto por humanos para orientar e revisar agentes de codificação com IA é muito mais caro
  $200/mês é caro como hobby, mas do ponto de vista de negócios é um valor irrisório
  O importante é o quão bem o modelo faz o trabalho, e nessa faixa de preço o ponto central é a eficiência em relação ao tempo

  • Nossa equipe lançou três produtos este ano com Claude. Em especial, um projeto estimado em 9 pessoas por 6 meses foi concluído com 2 pessoas em 2 meses
    Acho que o valor econômico da assinatura do Claude fica na faixa de 10 mil a 40 mil euros.
    Eu compraria mesmo que o preço subisse 100 vezes. Só começaria a avaliar alternativas se chegasse a 20 mil euros por mês, mas hoje o ganho de produtividade é esmagador
  • $200 praticamente não pesam para uma empresa, mas são difíceis de justificar para um hobby pessoal
  • Minha instância do Openclaw gerou cobrança de $200 por dia usando Opus. O problema maior é a otimização de roteamento. Era ótimo a $1/hora, mas a $15/hora já perde competitividade

• Acho que a melhora na qualidade dos modelos vai acabar chegando a uma faixa de retorno decrescente
  Como em telas 8K vs 16K, a maioria dos usuários nem percebe a diferença
  Se houver um aumento de custo de 20~30%, precisa haver um aumento de valor perceptível equivalente

  • Por isso acho que a maior parte da pesquisa está se concentrando em codificação. A dificuldade continua aumentando e o valor econômico também se mantém
    Já as consultas conversacionais gerais estão praticamente saturadas, então fica difícil diferenciar os modelos
  • Mesmo que pareça ter 99% de precisão, quando se tomam 100 mil decisões por dia, pequenos erros se acumulam e viram um grande problema
  • Se surgir um modelo 4K capaz de rodar localmente, os grandes laboratórios vão passar aperto. Ainda assim, o Google provavelmente aguenta por causa da receita com anúncios
  • Depende do tipo de tarefa. Por exemplo, em design de fármacos, a diferença entre 95% pronto e 100% pronto gera uma diferença de dezenas de vezes em valor
  • Para busca na web ou resumo, já chegamos ao limite, mas a complexidade da programação pode se expandir infinitamente

• O multiplicador de modelo do GitHub Copilot aumentou de 3 para 7,5
  Parece uma tentativa da Microsoft de reduzir prejuízos
  Veja a documentação oficial

  • Por isso recomendamos na nossa organização: “não ativem Opus 4.7 de jeito nenhum”. 4.6 (3x) e 4.5 (3x) tudo bem, mas 4.7 (7,5x) não vale o custo de forma alguma
  • Recentemente o Opus 4.6 vem mostrando queda na qualidade de raciocínio. Está apressando conclusões e pulando a lógica. Sem um grande avanço, parece que virá uma forte degradação de qualidade (en**)**

• O título do artigo induz ao erro. O número de tokens aumentou, mas o custo por tarefa pode ser diferente
  Parte-se da suposição de que o Opus 4.7 não usa o mesmo caminho de raciocínio do Opus 4.6
  É preciso esperar os resultados do Intelligence Index da Artificial Analysis

  • Em benchmarks internos, o Opus 4.7 estava 50% mais barato e teve pontuação de desempenho de 80% (vs 60%)
  • O título do artigo foi ajustado de “Claude Opus 4.7 costs 20–30% more per session” para uma formulação mais neutra
  • Segundo o experimento comparativo com 28 tarefas, o 4.7 tem custo parecido com o 4.6 antigo e é cerca de 20% mais caro que o 4.6 novo
  • Pelos meus dados pessoais, o 4.7 teve custo mais alto que o 4.6, e a melhora de desempenho não ficou clara
  • Até no gráfico do anúncio oficial dá para verificar a base da alegação de “strictly better”

• Ontem, quando usei o Opus, ele estava incrivelmente bom, mas hoje continua errando até tarefas simples
  Precisei apontar o mesmo problema pela terceira vez, a sessão caiu várias vezes e houve compaction em excesso
  No fim, decidi voltar para o Sonnet

  • Isso não é bug, é uma política de redução de carga computacional. Vai piorar daqui para frente
  • LLM não é uma personalidade. Ao amostrar de uma distribuição de probabilidade, a chance de sair uma sessão ruim é 100%. É preciso reiniciar o contexto e tentar de novo
  • Também venho vendo com frequência resultados horríveis no Opus 4.7. Foi amargo ver o modelo reconhecer o próprio erro e tentar novamente

• Ultimamente penso com frequência: “será que realmente precisamos de modelos mais poderosos?”
  O setor está obcecado com a corrida por desempenho e deixando de lado eficiência e sustentabilidade
  Acho que, daqui para frente, será importante seguir na direção de otimizar modelos de 0,5B~1B parâmetros para tarefas específicas

  • Eu também ficaria plenamente satisfeito se pudesse rodar o Sonnet 4.6 localmente
    Como no texto CPUs Aren’t Dead, o modelo Gemma 4 E2B do Google roda até em celular e supera o GPT-3.5-turbo
    Segundo o Intelligence Index da Artificial Analysis, os modelos 2B mais recentes têm desempenho comparável ao de modelos 175B de 3 a 4 anos atrás
    O Gemma 4 E4B chega até a superar o GPT-4o
    Nesse ritmo, logo poderemos rodar modelos de primeira linha até em notebooks
  • Muita gente esperava que o Sonnet 4.6 tivesse desempenho no nível do Opus 4.5, mas na prática não foi isso que aconteceu
  • Eficiência não dá dinheiro. Para as grandes empresas de LLM, é mais lucrativo manter alto o custo de inferência
    Esse tipo de divulgação de “o novo modelo é insano” no fim é marketing de FOMO
  • Nem todo mundo precisa de uma calculadora avançada. O importante é escolher a ferramenta no nível necessário
  • Mas não dá para ficar satisfeito com um “modelo preguiçoso e impreciso”. O laboratório que resolver isso vai conquistar uma vantagem decisiva

• Os vendedores de doces de Kolkata, na Índia, como não conseguiam aumentar os preços apesar da alta nos insumos, reagiram reduzindo o tamanho do produto
  É assim que a adaptação psicológica das pessoas funciona

  • Isso acontece no mundo todo. A embalagem dos salgadinhos continua igual, mas o conteúdo diminuiu. Até o tubo de Pringles ficou mais fino e mais curto
  • Esse fenômeno é chamado de Shrinkflation

• A Anthropic introduziu um novo modo xhigh no 4.7
  Como o modo max usa muitos tokens e pode provocar raciocínio excessivo, o recomendado na maioria dos casos é o xhigh
  Veja a documentação oficial

  • Adicionar a etapa xhigh e empurrar o max para mais longe passa uma sensação de “isso vai até 11”

• Em código real, o Opus 4.7 mostrou cerca de 30% de aumento de tokens
  O mais importante é: “que nova capacidade o 4.7 oferece em relação ao 4.6?”
  Ainda é cedo para julgar, e se houver valor nisso, dá para aceitar o aumento de custo

  • Um ponto interessante nas discussões é que muita gente corre atrás do modelo novo, mas o Sonnet 4.6 por si só já é eficiente o bastante
    Se o escopo da tarefa for reduzido, fica mais fácil revisar e gerenciar, e dá para corrigir rápido com diffs pequenos
    Se o consumo de tokens do Copilot aumentar 7 vezes, acho que isso vai até quebrar o fluxo de trabalho
  • Recentemente há muitas reclamações de que o 4.6 piorou de desempenho
  • Não sei por quanto tempo o 4.6 vai continuar disponível. Para empresas talvez dure mais um pouco, mas para assinantes individuais parece que a opção logo vai desaparecer