ODANIGEEK

Preço de API de IA em 2026: Anthropic, OpenAI e Google mexeram na tabela, e o corte que importa está no cache

O Dani Geek — arte original

Três fornecedores mexeram no preço em poucas semanas e a manchete virou “IA ficou barata”. Fui conferir nas docs oficiais o que muda de fato na fatura de quem roda um sistema, e a resposta está na linha de cache hit.

Só um dos três foi corte de preço

Vale começar desmontando a manchete, porque ela junta três coisas diferentes.

A Anthropic tornou permanente o preço de $2 por milhão de tokens de input e $10 de output no Sonnet 5. Esse valor já estava em vigor desde o lançamento, como preço introdutório até 31 de agosto, e a doc de preços diz com todas as letras que o aumento para $3/$15 marcado para 1º de setembro “will not occur”. Ninguém pagou menos no dia seguinte ao anúncio. O que caiu foi o preço futuro.

O Google lançou um modelo novo. O Gemini 3.7 Flash chegou a $0,75 de input e $3,75 de output por milhão, e a doc é explícita: esse valor vale até 31 de dezembro de 2026 e dobra em 1º de janeiro, para $1,50 e $7,50. Existe um degrau mais barato, se você migrar. Migrar cobra trabalho.

A OpenAI foi a única que baixou o preço de um modelo que já estava na praça. O GPT-5.6 Sol está em $4 de input, $0,40 de cached input e $20 de output. Os agregadores registram $5/$30 antes da mudança; a doc oficial só mostra o preço atual, então trate o valor antigo como número de terceiro. O que a doc confirma é o prazo: preço promocional “at least through November 21, 2026”. Noventa dias, mais ou menos.

Resumo sem maquiagem: dois dos três preços têm data de validade, e o único que virou permanente foi justamente o que nunca chegou a ser corte.

O que a tabela diz sobre cache

A fatura de quem opera um sistema em cima de API se compõe de cinco linhas: input cru, cache write, cache hit, output e batch. A manchete fala da primeira. A conta é dominada pela terceira.

Na Anthropic os multiplicadores são relativos ao preço base de input: cache write de 5 minutos custa 1,25×, write de 1 hora custa 2×, e o hit custa 0,1×. No Sonnet 5 isso dá $2 de input, $2,50 de write curto, $4 de write longo e $0,20 por milhão de tokens lidos do cache. Opus 5 segue a mesma escada a partir de $5, com hit a $0,50. Haiku 4.5 parte de $1, hit a $0,10. A doc publica o ponto de equilíbrio: o cache de 5 minutos se paga na primeira leitura, o de 1 hora na segunda. A Batch API tira 50% de input e output, e empilha com o cache.

Uma exceção que vale registrar: Fable 5.1 e Mythos 5.1 têm hit a 0,025× do base, ainda mais barato. E o fast mode do Opus 5 custa $10/$50, com os multiplicadores de cache incidindo por cima disso.

Na OpenAI o cached input do Sol é $0,40 contra $4 de input, um desconto de 90%. GPT-6 Astra fica em $10/$1/$50, Terra em $2/$0,20/$12, Luna em $0,20/$0,02/$1,20.

No Google o context caching do 3.7 Flash custa $0,075 por milhão, e aí aparece uma linha que os outros dois não cobram do mesmo jeito: armazenamento de cache, $0,50 por milhão de tokens por hora. No Gemini 3.1 Pro o armazenamento é $4,50 por milhão por hora. Volto nisso adiante, porque muda a conta.

A conta que sustenta a tese

Pegue o Sol, o único corte de verdade. Se o número antigo dos agregadores estiver certo, o corte tirou $1 de cada milhão de tokens de input. Agora pegue esse mesmo milhão de tokens e faça ele bater em cache em vez de entrar cru: de $4 para $0,40, ou $3,60 a menos. Mover input para cache vale 3,6 vezes o corte de preço. E esse número vale enquanto a promoção durar; depois de 21 de novembro, a diferença entre cru e cache só cresce.

No Sonnet 5 a lógica é a mesma. Um hit custa 10% do input. Quem tem 70% do input batendo em cache paga, em média, $0,74 por milhão de tokens de entrada em vez de $2. Nenhum anúncio de tabela chega perto disso.

Tem um detalhe de arquitetura que vale mais que parece. Na Anthropic o preço do hit é um multiplicador do base, então qualquer corte de tabela derruba o cache junto, sem ninguém pedir. Na OpenAI o cached input é um número listado separadamente. Hoje os dois andam juntos; nada na doc garante que continuem andando.

O corte de 33% do Sonnet 5 encolhe para 13%

Este é o fato que ninguém está contando. A doc da Anthropic avisa que os modelos a partir do 4.7 usam um tokenizador novo, e que ele “produces approximately 30% more tokens for the same text”. Sonnet 4.6 para trás usa o antigo.

Faça a conta com o mesmo texto. No Sonnet 4.6, a $3 por milhão, 1 milhão de tokens. No Sonnet 5, a $2 por milhão, cerca de 1,3 milhão de tokens pelo mesmo conteúdo. Dá $2,60. O corte real fica na casa de 13%. A doc diz que o aumento exato depende do conteúdo, então meça no seu corpus antes de repetir qualquer número; o meu ainda está sendo medido e por isso vai em “cerca de”.

E aqui a tabela de cache ajuda de novo: os 30% a mais de tokens também batem em cache a $0,20. O prefixo estável fica mais comprido e mais barato ao mesmo tempo.

No Gemini, cache parado paga aluguel

O contexto em cache do Gemini custa armazenamento por hora, e isso inverte a lógica do hit rate. Um exemplo com os números da doc: 100 mil tokens em cache por uma hora custam $0,05 de armazenamento no 3.7 Flash. Cada leitura desse cache economiza $0,0675 por milhão, ou seja, $0,00675 nesses 100 mil tokens. Para pagar o aluguel de uma hora você precisa de umas oito leituras naquela hora.

No 3.1 Pro o armazenamento é $4,50 por milhão por hora, e a conta fica bem mais difícil de fechar. A variável que importa no Gemini deixa de ser quanto do seu input está em cache e passa a ser quantas vezes por hora você lê aquele cache. Um sistema que roda de madrugada, uma peça por vez, com intervalos longos, pode pagar mais de armazenamento do que economiza de leitura. O batch tira 50% de tudo, inclusive do caching, o que ajuda, e não resolve o aluguel.

A doc de preços não diz se o cache implícito, aquele que o Gemini aplica sozinho, também cobra armazenamento. Vou testar antes de afirmar.

A linha da fatura que eu controlo

No meu sistema, cada peça de conteúdo nasce de um prompt com três blocos na mesma ordem: o brand book da marca, que muda uma vez por mês, as instruções do formato, que mudam uma vez por trimestre, e o briefing da pauta, que muda a cada chamada. Cache de prompt funciona por prefixo. Se o briefing viesse primeiro, nenhum byte do brand book seria reaproveitado. Com o brand book na frente, a maior parte do input de cada chamada é hit a $0,20.

Isso é ordem de prompt. Custou zero de troca de modelo e continua valendo quando a promoção do Sol acabar e quando o Flash dobrar de preço em janeiro. O TTL entra na mesma lógica: se a fila roda em rajadas, o cache de 5 minutos se paga na primeira leitura; se as chamadas se espalham pela hora, o de 1 hora se paga na segunda, conforme a doc. Escolher errado joga o write de 2× no lixo.

O que eu ainda não posso mostrar é o antes e depois por lane com hit rate medido. Preciso de um ciclo de fatura inteiro com a tabela nova, com o tokenizador contabilizado, para publicar número que aguente pergunta. O que posso mostrar hoje é a aritmética das docs, e ela já é suficiente para a decisão: quem só troca de modelo depende do fornecedor e do calendário dele. Quem arruma a ordem do prompt depende de si.

O próximo fio

Fica uma pergunta para quem opera sistema parecido: qual é o seu hit rate de cache hoje? Se você nunca olhou essa linha da fatura, ela provavelmente está perto de zero, e aí o corte de preço da manchete é a menor das suas alavancas. Quando eu tiver o ciclo fechado, volto com os números por lane. Enquanto isso, se você mediu o tokenizador novo no seu corpus e achou algo diferente de 30%, quero ver: @odanigeek no X ou no Threads.

Fontes