Tokens de entrada vs saída: custo do Claude

Porque 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 é executado. A leitura de um prompt requer uma passagem pelo modelo. A geração de uma resposta requer uma passagem por token, e cada passagem tem de esperar pela anterior.

Essa proporção é igual em todas as linhas da tabela de preços. Por isso, o modelo escolhido não altera quanto da sua fatura corresponde à saída. Isso é determinado pelo perfil da carga de trabalho. Um passo de um agente que lê 60,000 tokens e responde com 800 quase não tem custos de saída. Um trabalho de redação que lê 2,000 tokens e escreve 12,000 quase não tem custos de entrada. Os dois casos são calculados abaixo com base nas tarifas publicadas pela Anthropic em August 2026.

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

Um servidor de inferência processa um pedido em duas fases com custos muito diferentes. O prefill lê o prompt. O decoding gera a resposta.

O prefill processa o prompt inteiro de uma só vez. Todos os tokens do prompt entram na rede na mesma passagem forward. Assim, o trabalho de attention e feed-forward transforma-se num pequeno número de multiplicações de matrizes grandes, abrangendo milhares de tokens de cada vez. Uma leitura dos pesos do modelo a partir da memória serve todo o prompt. As unidades de matrizes do acelerador permanecem ocupadas. Por isso, o prefill é limitado pelo processamento: o limite é a velocidade a que o chip consegue multiplicar.

O decoding não pode funcionar dessa forma, porque o token 2 depende do token 1. O token que o modelo acabou de produzir passa a fazer parte da entrada do passo seguinte. Por isso, os passos não podem ser executados ao mesmo tempo. Cada token de saída tem a sua própria passagem forward. Cada uma dessas passagens lê o conjunto completo de pesos do modelo a partir da memória de alta largura de banda para produzir um único token. Por isso, o decoding é limitado pela memória: o limite é a velocidade a que os pesos podem ser transferidos, não a velocidade a que podem ser multiplicados. O mesmo tráfego de pesos que processa um prompt inteiro durante o prefill produz um token durante o decoding.

Os sistemas de serving compensam esta limitação através de batching. Muitos pedidos fazem decoding em conjunto. Assim, uma leitura dos pesos produz um token para cada pedido do batch. É por isso que o decoding é viável. O limite volta a ser a memória. Cada pedido em execução mantém uma KV cache (key/value cache, o estado de attention armazenado para cada token produzido até ao momento). Essa cache cresce a cada token gerado. Quando ocupa toda a memória do acelerador, o batch já não pode crescer.

Nada disto fornece um número exato. Também não deve interpretar 5x como uma relação de hardware medida. É um preço definido pela Anthropic e fundamentado nessa assimetria. O que pode verificar por si próprio é a direção da relação. Isso demora cerca de um minuto.

Meça você mesmo o atraso de entrada e saída

Instale as ferramentas em qualquer máquina Ubuntu:

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

Agora envie um prompt curto que peça uma resposta longa e registe a hora 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 adiciona a cada linha o número de segundos decorridos desde o início do comando. Há dois valores importantes nessa saída. A primeira linha content_block_delta é o tempo até ao primeiro token, e todo o prefill ocorreu dentro dela. Cada linha seguinte corresponde a um pequeno passo de decoding, e os tempos continuam a aumentar até message_stop chegar.

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 no prompt curto, porque o prefill tem muito mais texto para ler. Depois de chegar, a resposta termina quase imediatamente, porque restam apenas alguns tokens para fazer o decoding. Entraram dezenas de milhares de tokens e o relógio quase não avançou. Saíram algumas centenas e o relógio continuou a contar durante toda a operação.

Todas as respostas sem streaming terminam com os números usados para calcular a faturação.

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

Registe os quatro campos de cada pedido. output_tokens inclui o extended thinking, portanto um modelo que pensa antes de responder contabiliza esse processamento à taxa de saída. Para calcular o preço de um prompt antes de o enviar, POST /v1/messages/count_tokens aceita o mesmo corpo do pedido, devolve {"input_tokens": N} sem executar o modelo e não tem custos. Não é a única parte da API que não tem custos, e vale a pena consultar quais partes da Claude API nunca são faturadas antes de orçamentar o primeiro projeto.

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

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "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 resultado dividido pela entrada e apresenta 5 em todas as linhas. O Haiku 4.5 cobra $1 pelos tokens de entrada e $5 pelos de saída. O Opus 5 cobra $5 e $25. O Fable 5, o mais caro, cobra $10 e $50; vale a pena ler o que essas tarifas do Fable 5 permitem fazer antes de descartar essa linha superior. Subir na gama multiplica ambos os lados pelo mesmo fator. Isso altera o total, mas mantém exatamente a mesma proporção entre entrada e saída.

O Sonnet 5 aparece duas vezes porque a tarifa introdutória expira. Até 31 de agosto de 2026, cobra $2 e $10. A partir de 1 de setembro de 2026, aplica-se a tarifa padrão de $3 e $15, que é 50% superior em ambos os lados. Todos os exemplos abaixo usam a tarifa de agosto.

As tarifas mudam, e esta página não é o local onde deve consultá-las. claude.com/pricing é a fonte oficial. O que permanece depois de uma alteração de preço é o método.

Há uma ressalva que a tabela de preços não mostra. A documentação da Anthropic afirma 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 usado pelo Sonnet 4.6 e anteriores. Comparar dois modelos apenas pelo preço por milhão de tokens favorece artificialmente o mais recente, porque o mesmo documento resulta em mais tokens nesse modelo. Compare o custo por tarefa concluída e contabilize os seus prompts reais no modelo que pretende utilizar. O mesmo problema existe entre fornecedores, cujos tokenizers diferem entre si ainda mais do que isso. Por esse motivo, calcular o custo de uma tarefa real no Claude e no ChatGPT informa mais do que colocar as duas tabelas de tarifas lado a lado. o valor real de um milhão de tokens do Claude explica como esse volume se traduz em texto na prática.

Quando é que a saída começa a dominar a sua fatura?

Com a saída tarifada a 5 vezes o preço da entrada, o ponto de equilíbrio é fácil de calcular mentalmente. Considere I como o número de tokens de entrada e O como o número de tokens de saída. A entrada custa I. A saída custa 5 vezes O. A saída ultrapassa metade da despesa quando 5 vezes O é maior do que I, o que corresponde a uma proporção de 5 tokens de entrada para 1 token de saída.

Assim, se o seu prompt for mais de cinco vezes mais longo do que a resposta, a entrada representa o maior custo. Abaixo dessa proporção, é a saída.

[
  {
    "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, a saída representa 4.8% da despesa, 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, a saída representa 96.8% e o prompt é um erro de arredondamento. A maioria das pessoas estima incorretamente a sua própria proporção, por isso obtenha-a dos seus logs antes de otimizar qualquer coisa.

Uma carga de trabalho de agente: muito contexto de entrada, resposta curta

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

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "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 à tarifa de agosto e $0.064 no Haiku 4.5. Duzentas dessas etapas por dia no Opus 5 custam $64 por dia.

A medida fica evidente quando se observa 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 orientado para leitura é quase esforço desperdiçado. onde os tokens de um agente de programação são realmente utilizados explica o que preenche esse prompt.

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

Agora inverta a proporção. Um resumo de 2,000 tokens, um rascunho de 12,000 tokens, numa proporção de 1 para 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "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 fatura. O Opus 5 custa $0.31 por rascunho, contra $0.062 no Haiku 4.5. Essa diferença de cinco vezes resulta quase toda do lado da saída, que é precisamente onde um modelo mais barato permite poupar mais.

A última coluna mostra o mesmo trabalho através da Batch API, que reduz em 50% o custo da entrada e da saída. O Opus 5 passa a custar $0.155 por rascunho. A Batch devolve os resultados num prazo de 24 horas, em vez de imediatamente, pelo que é adequada para gerar relatórios durante a noite e para classificação em massa. Não é adequada para tarefas em que uma pessoa está a aguardar pelo resultado.

O encaminhamento entre modelos compensa neste caso, ao contrário do que acontece na etapa do agente. Se a parte mais extensa do trabalho for mecânica, como reformatar texto ou expandir um esquema já aprovado, o modelo barato produz esses tokens por um quinto do preço. escolher entre Opus, Sonnet e Haiku explica onde fica realmente o limite de qualidade.

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

O cache de prompts armazena um prefixo do prompt no servidor e cobra uma fração da tarifa de entrada para o ler novamente. Em agosto de 2026, os multiplicadores são 1.25x da 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 resultado do cache.

A saída não está incluída nesse mecanismo. Não existe saída em cache. Cada token escrito pelo modelo é cobrado sempre à tarifa total de saída, independentemente da quantidade do prompt que tenha sido reutilizada a partir do cache.

Considere o mesmo passo do agente no Opus 5, com 55,000 dos 60,000 tokens de entrada servidos a partir de um cache ativo.

[
  {
    "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 passa de $0.32 para $0.0725. A linha da saída não muda: $0.02 antes e $0.02 depois. O cache reduz a fatura e altera a sua composição. A saída representava 6.25% dessa chamada. Agora representa mais de um quarto do total, o que altera a alavanca que vale a pena ajustar a seguir.

A primeira chamada paga a gravação. Gravar um cache de 5 minutos custa 1.25x a entrada base, por isso o custo é recuperado depois de uma única reutilização. Gravar um cache de 1 hora custa 2x, por isso são necessárias duas reutilizações. os multiplicadores de gravação e leitura e quando o cache deixa de compensar explica esse cálculo.

Quatro alavancas que controla

1. Defina max_tokens no comprimento p95 da sua saída, não no máximo do modelo.
2. Encaminhe as etapas verbosas para um modelo mais barato.
3. Agrupe tudo aquilo por que ninguém está à espera.
4. Elimine as instruções que aumentam o tamanho das respostas.

max_tokens é um limite rígido. Defini-lo com um valor alto não tem, por si só, qualquer custo, porque paga pelos tokens produzidos e nunca pelo limite. Um limite generoso apenas remove a restrição de uma resposta que corre mal. 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 repetindo o pedido. Uma truncagem detetada custa menos do que um discurso de 4,000 tokens pelo qual paga e que depois elimina. O raciocínio prolongado também entra em output_tokens, por isso defina esse orçamento com base nos mesmos dados.

O encaminhamento funciona quando a parte dispendiosa de uma etapa é o volume, e não a capacidade de decisão. Mantenha o modelo mais forte na decisão e entregue a redação a algo mais barato. Meça primeiro a versão encaminhada no seu próprio conjunto de avaliação, porque um modelo barato que precisa de duas tentativas custa mais do que uma tentativa com um modelo dispendioso.

O processamento em lote é a única alavanca que reduz o preço da saída. Desconto de 50% nos dois lados, resultados em 24 horas e qualquer tarefa agendada são elegíveis.

A última alavanca é a que as pessoas ignoram. Frases como "seja minucioso" e "explique o seu raciocínio" definem o comprimento da saída em todas as chamadas que fizer. Substitua-as pelo formato que pretende: "Responda em no máximo três frases" ou "Devolva apenas o objeto JSON, sem introdução". Um system prompt que acrescenta 300 tokens a cada resposta custa cinco vezes mais do que os mesmos 300 tokens custam no prompt. manter os custos de um agente em execução sob controlo aborda o lado da monitorização, e determinar se a API ou uma subscrição fixa é mais barata para o seu padrão de utilização vale a pena resolver antes de passar uma semana a otimizar a despesa por token que uma subscrição teria absorvido. Para um developer, isso resume-se sobretudo a saber se os $20 mensais do Claude Pro e os limites de utilização associados cobrem o trabalho que, de outro modo, estaria a contabilizar. Se já atinge esses limites a meio da sessão, determinar qual a janela que está a aguardar vem primeiro, porque a solução pode ser um modelo mais pequeno, um contexto mais leve, créditos de utilização adicionais ou a transferência desse trabalho para a API com medição. Se a API com medição acabar por ser a opção mais barata para esse trabalho, mudar para um plano mais pequeno ou cancelar a subscrição mantém intacto o mês que já pagou, por isso a mudança não lhe custa nada. Se o plano com que está a comparar o Pro for o do ChatGPT, e não a API com medição, a comparação lado a lado dos dois níveis de subscrição mostra qual fica mais barato para trabalho de programação. Se a questão for colocada para uma equipa, e não para um único developer, tenha em conta que o Claude Enterprise combina uma tarifa por lugar com tokens contabilizados às mesmas taxas da API, pelo que todas as alavancas desta página continuam a aplicar-se à parte da fatura com medição.

FAQ

Porque e que os tokens de saida custam mais do que os tokens de entrada?

A geracao demora muito mais tempo de acelerador por token. Um prompt e processado numa unica passagem para a frente sobre todo o conteudo, por isso uma unica leitura dos pesos do modelo cobre milhares de tokens e o hardware fica limitado pelo throughput de multiplicacoes. Uma resposta e produzida um token de cada vez. Cada token precisa da sua propria passagem para a frente, que volta a ler todos os pesos do modelo. Por isso, o hardware fica limitado pela largura de banda da memoria. A Anthropic cobra cinco vezes mais pela saida do que pela entrada em todo o catalogo atual, desde Haiku 4.5 ate Fable 5.

O prompt caching torna os tokens de saida mais baratos?

Nao. O prompt caching aplica-se apenas a entrada. Em agosto de 2026, uma leitura da cache custa 0.1x da tarifa base de entrada. As escritas na cache custam 1.25x para a duracao de 5 minutos ou 2x para a duracao de 1 hora. A saida e faturada a tarifa total em todas as chamadas, independentemente do efeito da cache. Por isso, o caching altera tanto a estrutura como o valor da fatura: quando o custo da entrada diminui, a saida passa a ser a parcela que merece ser otimizada.

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

Nao. A faturacao baseia-se nos tokens que o modelo produz efetivamente, por isso max_tokens e um limite superior, nao uma reserva. Ainda assim, este valor e importante porque e o unico limite rigido para uma resposta que se prolongue excessivamente. Defina-o ligeiramente acima do percentil 95 do seu output_tokens observado. Depois, trate stop_reason: "max_tokens" no codigo em vez de publicar uma resposta truncada sem aviso.

Como encontro a minha propria proporcao entre tokens de entrada e de saida?

Registe input_tokens, output_tokens, cache_read_input_tokens e cache_creation_input_tokens a partir do objeto usage de cada resposta. Depois, divida os totais de uma semana. Acima de 5 tokens de entrada para 1 de saida, o custo esta no prompt. Coloque a parte estavel em cache e reduza o restante. Abaixo dessa proporcao, o custo esta na resposta. Limite o seu comprimento e transfira os passos que geram a maior parte dela para um modelo mais barato ou para a Batch API.