SSD Nodes Learn Hosting plans →
Guias Matt ConnorPor Matt Connor · Atualizado 2026-10-28

Tokens de entrada vs saída: o custo 5x do Claude

Tokens de saída do Claude custam cinco vezes mais que os de entrada. Entenda prefill, decodificação e o impacto dessa diferença na fatura mensal de agentes.

Por que os tokens de saída custam mais do que os tokens de entrada

Os tokens de saída custam cinco vezes mais do que os tokens de entrada em todos os modelos Claude do catálogo atual. A causa está na forma como o cálculo é realizado. A leitura de um prompt exige uma passagem pelo modelo. A geração de uma resposta exige uma passagem por token, e cada passagem precisa aguardar a anterior.

Essa proporção é igual em todas as linhas da tabela de preços, portanto o modelo escolhido não altera quanto da sua fatura corresponde à saída. O que determina esse valor é o formato da carga de trabalho. Uma etapa de um agente que lê 60,000 tokens e responde com 800 quase não gasta com saída. Um trabalho de redação que lê 2,000 tokens e escreve 12,000 quase não gasta com entrada. Os dois casos são calculados abaixo com base nas tarifas publicadas pela Anthropic, verificadas em 27 de outubro de 2026.

O prefill é executado uma vez; o decoding, uma vez por token

Um servidor de inferência processa uma solicitação em duas fases com custos muito diferentes. O prefill lê o prompt. O decoding escreve a resposta.

O prefill processa o prompt inteiro de uma vez. Cada token do prompt entra na rede na mesma passagem forward, então o trabalho de atenção e feed-forward se transforma em um pequeno número de grandes multiplicações de matrizes que abrangem milhares de tokens por vez. Uma leitura dos pesos do modelo da memória atende ao prompt inteiro. As unidades de matrizes do acelerador permanecem ocupadas, o que significa que o prefill geralmente é limitado por computação: o limite é a velocidade com que o chip consegue multiplicar. A documentação de serving da NVIDIA cita as exceções: prefills muito curtos e prefills em que um prefixo longo já é um cache hit tornam-se limitados pela memória.

O decoding comum não pode funcionar assim, porque o token 2 depende do token 1. O token que o modelo acabou de produzir passa a fazer parte da entrada da próxima etapa, então as etapas são executadas uma após a outra. Cada token de saída tem sua própria passagem forward, e cada uma dessas passagens lê da memória de alta largura de banda o conjunto completo de pesos do modelo, além do KV cache (cache de key/value, o estado de atenção armazenado para cada token até o momento), para produzir um único token. Isso geralmente torna o decoding limitado pela memória: o limite é a velocidade com que os pesos e o estado armazenado podem ser transferidos, não a velocidade com que podem ser multiplicados; em contextos longos, a NVIDIA destaca as leituras do KV cache como o gargalo. O mesmo tráfego de pesos que processou um prompt inteiro durante o prefill produz um token durante o decoding.

O speculative decoding contorna essa regra sem quebrá-la. Um modelo de rascunho pequeno prevê vários tokens à frente, e o modelo grande verifica todos eles em paralelo em uma única passagem, o que, segundo a NVIDIA, pode deslocar o decoding para um cenário limitado por computação. O modelo grande ainda aceita as previsões em ordem e para no primeiro erro, portanto uma resposta longa ainda custa muitas passagens.

Os sistemas de serving compensam isso com batching. Muitas solicitações fazem decoding juntas, então uma leitura dos pesos produz um token para cada solicitação do batch. É por isso que o decoding é acessível. O limite volta a ser a memória. Cada solicitação em andamento mantém seu próprio KV cache, esse cache cresce a cada token gerado e, quando preenche o acelerador, o batch não pode crescer mais.

Nada disso fornece um número exato, e você não deve interpretar 5x como uma proporção de hardware medida. Esse é um preço definido pela Anthropic e influenciado por essa assimetria. O que você pode verificar por conta própria é a direção, e isso leva cerca de um minuto.

Meça você mesmo a diferença entre entrada e saída

Instale as ferramentas em qualquer servidor Ubuntu:

sudo apt update && sudo apt install -y curl jq moreutils

Agora transmita um prompt curto que peça uma resposta longa e registre o horário de chegada de cada linha.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s prefixa cada linha com os segundos decorridos desde o início do comando. Vale observar duas informações nessa saída. A primeira linha content_block_delta mostra o tempo até o primeiro token, e todo o prefill ocorreu dentro dela. Cada linha seguinte corresponde a uma pequena etapa de decodificação, e os registros de tempo continuam aumentando até message_stop aparecer.

Agora inverta o formato. Coloque um documento longo no prompt e limite a resposta a alguns tokens.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

O primeiro intervalo demora mais do que demorou com o prompt curto, porque o prefill precisa ler muito mais texto. Depois que ele chega, a resposta termina quase imediatamente, porque restam apenas alguns tokens para decodificar. Dezenas de milhares de tokens entraram, e o relógio quase não avançou. Algumas centenas saíram, e o relógio funcionou durante todo o processo.

Toda resposta que não usa streaming termina com os números usados para calcular a cobrança.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Registre os quatro campos em cada solicitação. output_tokens inclui tokens de raciocínio, portanto um modelo que raciocina antes de responder cobra esses tokens com a tarifa de saída. Para calcular o preço de um prompt antes de enviá-lo, POST /v1/messages/count_tokens usa o mesmo corpo de solicitação na maioria dos casos, retorna {"input_tokens": N} como uma estimativa sem executar o modelo e é gratuito dentro do próprio limite de taxa. Ele rejeita alguns corpos que a Messages API aceita: a maioria das ferramentas de servidor, como pesquisa na web, o conector MCP e blocos de imagem ou documento com uma fonte url ou file. Portanto, envie imagens e PDFs como base64 ao contabilizá-los. Essa não é a única parte da API que não tem custo, e vale consultar quais partes da Claude API nunca são cobradas antes de definir o orçamento do primeiro projeto.

Quanto a Claude cobra por milhão de tokens em outubro de 2026

GráficoClaude API list rates, US dollars per million tokens, October 2026
Os dados por trás deste gráfico
[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

A última coluna é o output dividido pelo input e mostra 5 em todas as linhas. O Haiku 4.5 cobra $1 pelo input e $5 pelo output. O Opus 5 cobra $5 e $25. O Fable 5, o mais caro, cobra $10 e $50, e vale a pena ler o que essas tarifas do Fable 5 permitem antes de descartar essa linha superior. Ao subir na escala, os dois lados são multiplicados pelo mesmo fator. Por isso, o total muda, mas a proporção entre input e output permanece exatamente igual.

O Sonnet 5 cobra $2 pelo input e $10 pelo output. A Anthropic lançou-o com essa tarifa como preço introdutório até 31 August 2026, com um aumento para $3 e $15 previsto para 1 September. Depois, definiu $2 e $10 como preço padrão. O aumento nunca entrou em vigor. Por isso, a tarifa usada em todos os exemplos abaixo é a que paga hoje.

A Anthropic também lançou modelos mais recentes desde a publicação inicial desta página, e claude.com/pricing agora lista os quatro modelos acima como modelos legados que continuam disponíveis. Os novos modelos mantêm a mesma proporção de 5x. O Opus 5.5 cobra $4 e $20, o Sonnet 5.5 cobra $2 e $10, o Fable 5.1 cobra $10 e $50, e o Haiku 5.5 cobra $0.10 e $0.50 para prompts de até 100,000 tokens, passando para $0.50 e $2.50 acima desse limite. A etapa do agente com 60,000 tokens calculada mais abaixo está abaixo desse limite, mas um agente cujo histórico continua a crescer acabará por ultrapassá-lo. Como funcionam os dois níveis de preço do Haiku 5.5 em trabalhos reais mostra o efeito desse aumento na fatura. As tarifas base de input e output do Opus 5.5 são 20% inferiores às do Opus 5. Por isso, todos os valores sem cache do Opus 5 apresentados abaixo são 20% inferiores no Opus 5.5. Os valores em cache diminuem ainda mais, porque o Opus 5.5 lê cache hits a $0.20 por milhão de tokens, contra $0.50 no Opus 5, uma redução de 60%. A etapa do agente em cache que custa $0.0725 no Opus 5 mais abaixo custa cerca de $0.047 no Opus 5.5, aproximadamente 35% menos.

As tarifas mudam, e esta página não é o local certo para as consultar. claude.com/pricing é a fonte oficial. O que permanece depois de uma alteração de preço é o método.

Há uma ressalva nas notas sob a tabela de preços da Anthropic, e não nas tarifas propriamente ditas. A página de preços da Anthropic informa que os modelos Claude 4.7 e posteriores usam um tokenizer mais recente, que produz aproximadamente 30% mais tokens para o mesmo texto do que o tokenizer do Sonnet 4.6 e anteriores. Comparar dois modelos apenas pelo preço por milhão de tokens favorece o modelo mais recente, porque o mesmo documento tem mais tokens nele. Compare o custo por tarefa concluída e conte os seus prompts reais com o modelo que pretende usar. O mesmo problema existe entre fornecedores, cujos tokenizers também diferem, por isso calcular o custo de um trabalho real no Claude e no ChatGPT informa mais do que colocar as duas tabelas de preços lado a lado. o valor de um milhão de tokens do Claude em texto real explica como esse volume se traduz na prática.

Quando o output começa a dominar o custo?

Com o output tarifado a 5 vezes o input, o ponto de equilíbrio é fácil de calcular mentalmente. Chame aos tokens de input I e aos tokens de output O. O input custa I. O output custa 5 vezes O. O output representa mais de metade do custo quando 5 vezes O é maior que I, o que corresponde a uma proporção de 5 tokens de input para 1 token de output.

Assim, se o seu prompt for mais de cinco vezes mais longo que a resposta, o input será a maior parcela do custo. Abaixo dessa proporção, será o output.

GráficoShare of spend by input to output token ratio, at 5x output pricing
Os dados por trás deste gráfico
[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

Na proporção de 100 para 1, o output representa 4.8% do custo, e reduzir o prompt é o único trabalho que vale a pena fazer. Na proporção de 5 para 1, os dois lados têm o mesmo peso. Na proporção de 1 para 6, o output representa 96.8% e o prompt tem um impacto residual. A maioria das pessoas calcula mal a própria proporção. Por isso, obtenha-a nos logs antes de otimizar qualquer coisa.

Uma carga de trabalho de agente: contexto longo na entrada, resposta curta na saída

Execute uma etapa de um agente de recuperação: 60,000 tokens de entrada com documentos recuperados e histórico da conversa, e uma resposta de 800 tokens. Isto corresponde a 75 para 1, o que é normal em qualquer processo que lê antes de escrever.

GráficoOne agent step, 60,000 input and 800 output tokens, US dollars per call
Os dados por trás deste gráfico
[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

A saída representa 6.25% desse pedido em todos os modelos, porque a proporção é fixa em toda a tabela de preços. O pedido custa $0.32 no Opus 5, $0.128 no Sonnet 5 e $0.064 no Haiku 4.5. Duzentas dessas etapas por dia no Opus 5 custam $64 por dia.

A diferença fica clara quando se vê a divisão. Reduzir a resposta de 800 tokens para 400 poupa cerca de 3% do pedido. Remover 20,000 tokens de contexto obsoleto do prompt poupa cerca de um terço do custo. Reduzir o comprimento da saída num agente que passa mais tempo a ler do que a escrever é quase esforço desperdiçado. onde vão realmente os tokens de um agente de programação explica o que preenche esse prompt.

Uma carga de trabalho de geração: prompt curto, rascunho longo

Agora inverta a proporção. Um briefing de 2.000 tokens e um rascunho de 12.000 tokens, numa proporção de 1 para 6.

GráficoOne draft, 2,000 input and 12,000 output tokens, US dollars per draft
Os dados por trás deste gráfico
[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

A saída representa 96.8% desta cobrança. O Opus 5 custa $0.31 por rascunho, contra $0.062 com o Haiku 4.5. Essa diferença de cinco vezes vem quase toda do lado da saída, que é exatamente onde um modelo mais barato gera a maior economia.

A última coluna mostra o mesmo trabalho pela Batch API, que reduz os custos de entrada e saída em 50%. O Opus 5 passa a custar $0.155 por rascunho. O processamento em lote é assíncrono, não imediato. A Anthropic informa que a maioria dos lotes termina em menos de uma hora, mas um lote que ainda esteja sendo processado após 24 horas expira. Qualquer solicitação que não tenha sido processada até esse momento também retorna como expirada, sem cobrança e sem mensagem. Portanto, esse recurso é adequado para gerar relatórios durante a noite e fazer classificação em massa, com uma etapa de reenvio para o que expirar. Não é adequado para tarefas em que alguém fica esperando pelo resultado.

O roteamento de modelos é vantajoso aqui de uma forma que nunca é no passo do agente. Se a parte extensa do trabalho for mecânica, como reformatar texto ou expandir um esboço que você já aprovou, o modelo barato produz esses tokens por um quinto do preço. escolhendo entre Opus, Sonnet e Haiku mostra onde a diferença real de qualidade está.

O cache reduz o custo da entrada, e somente da entrada

O cache de prompt armazena um prefixo do seu prompt no servidor e cobra uma fração da tarifa de entrada para lê-lo novamente. Em 27 de outubro de 2026, os multiplicadores são 1.25x a tarifa base de entrada para gravar um cache de 5 minutos, 2x para gravar um cache de 1 hora e 0.1x para ler um cache encontrado nos modelos com preços apresentados nesta página. Os modelos mais novos leem os caches encontrados por menos: 0.05x no Opus 5.5 e no Sonnet 5.5, e 0.025x no Fable 5.1.

A saída não faz parte desse acordo. Não existe saída em cache. Cada token gerado pelo modelo é cobrado pela tarifa integral de saída, todas as vezes, independentemente de quanto do prompt tenha sido recuperado do cache.

Execute a mesma etapa do agente no Opus 5, com 55,000 dos 60,000 tokens de entrada fornecidos por um cache aquecido.

GráficoThe same Opus 5 agent step, with and without a warm 55,000 token cache, US dollars
Os dados por trás deste gráfico
[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

A chamada cai de $0.32 para $0.0725. O custo da saída não muda: $0.02 antes e $0.02 depois. O cache reduz a conta e muda sua composição. A saída representava 6.25% dessa chamada. Agora ela representa mais de um quarto do total, o que muda qual alavanca vale a pena ajustar em seguida.

A primeira chamada paga a gravação. Gravar um cache de 5 minutos custa 1.25x a entrada base, então o custo se recupera após um único acesso. Gravar um cache de 1 hora custa 2x, então são necessários dois acessos. os multiplicadores de gravação e leitura e quando o cache deixa de compensar detalha esse cálculo.

Quatro controles que você pode ajustar

  1. Defina max_tokens no seu comprimento de saída p95, não no máximo do modelo.
  2. Encaminhe as etapas verbosas para um modelo mais barato.
  3. Faça batch de tudo pelo que ninguém está esperando.
  4. Exclua as instruções que aumentam o tamanho das respostas.

max_tokens é um teto rígido, e defini-lo com um valor alto não custa nada por si só, porque a cobrança é feita pelos tokens produzidos, nunca pelo teto. O que um limite generoso faz é remover a limitação de uma resposta que sai do controle. Extraia a distribuição de output_tokens dos seus logs, defina o limite um pouco acima do percentil 95 e trate stop_reason: "max_tokens" no código continuando a resposta ou tentando novamente. Uma truncagem detectada custa menos que um discurso de 4,000 tokens pelo qual você paga e que descarta. O thinking também entra em output_tokens e conta para max_tokens, então dimensione o limite com base nas mesmas evidências e, em modelos com thinking adaptativo, reduza o nível de esforço se o thinking continuar consumindo a resposta.

O roteamento funciona quando a parte cara de uma etapa é o volume, e não o julgamento. Mantenha o modelo mais forte na decisão e delegue a digitação a algo mais barato. Primeiro, meça a versão roteada no seu próprio conjunto de avaliação, porque o número importante é o custo por tarefa concluída. Na etapa do agente acima, duas tentativas com Haiku 4.5 custam $0.128, contra $0.32 de uma tentativa com Opus 5, então a diferença de preço absorve uma ou duas novas tentativas. O que ela não absorve é uma resposta errada que ninguém detecta.

O batching é o único controle que dá desconto na saída. 50% de desconto nos dois lados, a maioria dos batches concluída em até uma hora, e qualquer tarefa agendada se qualifica, desde que o job reenvie tudo o que expirar na marca de 24 horas.

O último controle é o que as pessoas ignoram. Frases como "seja minucioso" e "explique seu raciocínio" definem o tamanho da saída em todas as chamadas que você fizer. Substitua-as pelo formato desejado: "Responda em no máximo três frases" ou "Retorne apenas o objeto JSON, sem preâmbulo". Um system prompt que adiciona 300 tokens a cada resposta custa cinco vezes o que os mesmos 300 tokens custam no prompt. manter sob controle os custos de um agente em execução cobre o lado do monitoramento, e saber se a API ou uma assinatura fixa é mais barata para o seu padrão de uso vale a pena resolver antes de passar uma semana ajustando um gasto por token que uma assinatura teria absorvido. Para um desenvolvedor, isso depende principalmente de saber se os $20 mensais do Claude Pro e os limites de uso incluídos cobrem o trabalho que, de outra forma, seria cobrado por uso. Se você já atinge esses limites no meio da sessão, descobrir qual janela está aguardando vem primeiro, porque a solução a partir daí é um modelo menor, um contexto mais leve, créditos de uso adicionais ou transferir esse trabalho para a API cobrada por uso. Se a API cobrada por uso acabar sendo a opção mais barata para esse trabalho, migrar para um plano menor ou cancelar o plano mantém intacto o mês que você já pagou, então fazer a mudança não custa nada na saída. Se o plano com o qual você está comparando o Pro for o do ChatGPT, e não a API cobrada por uso, as duas opções de assinatura com os preços lado a lado mostram qual sai mais barato para trabalho de programação. Se essa pergunta estiver sendo feita para uma equipe, e não para um único desenvolvedor, observe que o Claude Enterprise combina uma taxa por assento com tokens cobrados nessas mesmas tarifas da API, então todos os controles desta página continuam se aplicando à metade da conta cobrada por uso.

FAQ

Porque custam mais os tokens de saída do que os tokens de entrada?

A geração requer muito mais tempo de acelerador por token. Um prompt é processado numa única passagem para a frente sobre todo o conteúdo, por isso uma única leitura dos pesos do modelo abrange milhares de tokens e o hardware é normalmente limitado pelo throughput de multiplicação. Na descodificação normal, a resposta é produzida um token de cada vez. Cada token requer a sua própria passagem para a frente, que lê novamente os pesos do modelo e o KV cache em crescimento. Por isso, o hardware é normalmente limitado pela largura de banda da memória. Técnicas como a descodificação especulativa reduzem essa diferença, mas não a eliminam. A Anthropic cobra pela saída cinco vezes mais do que pela entrada em todo o catálogo atual, desde Haiku 5.5 até Fable 5.1.

O prompt caching torna os tokens de saída mais baratos?

Não. O prompt caching aplica-se apenas à entrada. Em 27 October 2026, uma leitura da cache custa 0.1x da tarifa base de entrada na maioria dos modelos (0.05x no Opus 5.5 e Sonnet 5.5, 0.025x no Fable 5.1), e as gravações na cache custam 1.25x durante 5 minutos ou 2x durante 1 hora. A saída é cobrada à tarifa integral em todas as chamadas, independentemente do efeito da cache. É por isso que o caching altera tanto a estrutura como o valor da fatura: quando o custo da entrada diminui drasticamente, a saída passa a ser a parte que mais compensa reduzir.

Um max_tokens elevado custa-me dinheiro se a resposta for curta?

Não. A cobrança baseia-se nos tokens que o modelo produz efetivamente, por isso max_tokens é um limite máximo, não uma reserva. Ainda assim, é importante porque é o único limite rígido para uma resposta que se prolongue excessivamente. Defina-o ligeiramente acima do percentil 95 do seu output_tokens observado e trate stop_reason: "max_tokens" no código, em vez de publicar uma resposta truncada silenciosamente.

Como encontro a minha própria proporção entre tokens de entrada e de saída?

Registe input_tokens, output_tokens, cache_read_input_tokens e cache_creation_input_tokens no objeto usage de cada resposta e divida os totais ao longo de uma semana. Acima de 5 tokens de entrada para 1 de saída, o custo está no prompt. Coloque a parte estável em cache e reduza o restante. Abaixo desse valor, o custo está na resposta. Limite o seu comprimento e transfira os passos que geram mais conteúdo para um modelo mais barato ou para a Batch API.

Este artigo foi útil?