Todo mini-software que conversa com uma IA tem uma conta escondida: a cada chamada, você paga de novo por um monte de texto que nunca muda. Instruções do sistema, regras de negócio, exemplos, a ficha de um produto. O cliente digita uma frase curta, mas o seu app reenvia três páginas de contexto.
É aqui que entra o prompt caching, o cache de prompt. Em vez de falar de tokens em geral, este artigo foca nessa técnica: como ela altera a medição do consumo, como organizar o prompt de um PWA ou mini-app para aproveitá-la e como confirmar a economia olhando os números que a própria API devolve.
Como o cache muda a medição de tokens
Com cache, a entrada de uma chamada deixa de ter um único preço e passa a ter três. Na documentação da Anthropic, o prefixo do prompt (ferramentas, depois instrução do sistema, depois mensagens) pode ser gravado uma vez e relido nas chamadas seguintes, desde que o início do texto seja idêntico. Escrever no cache custa 1,25× o preço normal de entrada (validade de 5 minutos) ou 2× (validade de 1 hora). Ler do cache custa uma fração: 0,1× na maioria dos modelos e 0,05× no Claude Sonnet 5.5 e no Opus 5.5.
A OpenAI segue a mesma lógica, com menos controle: o cache é automático para prompts acima de 1.024 tokens e o desconto anunciado no lançamento era de 50% nos tokens em cache. Os percentuais mudam entre fornecedores e versões, então confira sempre a tabela de preços atual.
Um exemplo com os valores publicados para o Sonnet 5.5 (US$ 2,00 por milhão de tokens de entrada; US$ 0,10 por milhão lido do cache). Imagine um mini-app com 3.000 tokens fixos de instruções e 1.000 chamadas por dia:
| Cenário | Tokens fixos por dia | Custo diário dessa parte | Custo em 30 dias |
|---|---|---|---|
| Sem cache | 3.000.000 | US$ 6,00 | US$ 180,00 |
| Com cache (leituras) | 3.000.000 | US$ 0,30 | US$ 9,00 |
A conta ignora as poucas gravações, que custam centavos, e assume tráfego contínuo o bastante para o cache não expirar. Se o seu app recebe uma chamada por hora, o cache de 5 minutos morre entre uma e outra e a economia some, caso em que vale avaliar a validade de 1 hora.
Organizando o prompt do mini-software
O cache só funciona com prefixo idêntico, então a ordem do prompt vira decisão de arquitetura. A regra prática: o que não muda vem primeiro, o que muda a cada chamada vem por último.
- Definições de ferramentas e instruções do sistema no início, sempre com o mesmo texto.
- Material de referência estável logo depois: catálogo de produtos, regras de negócio, exemplos de resposta.
- Breakpoint de cache (
cache_control) no último bloco que é igual entre as chamadas. - Só então a pergunta do usuário e dados voláteis, como a data e hora atuais.
O erro mais comum é colocar um carimbo de data/hora ou o nome do usuário no topo da instrução do sistema. Qualquer mudança ali invalida tudo o que vem depois, e cada chamada grava um cache novo que ninguém reaproveita. A documentação também avisa que alterar as definições de ferramentas invalida o cache inteiro, então evite gerar essas definições dinamicamente.
Há ainda um limite mínimo: prompts curtos demais não são cacheados, e a API não devolve erro, apenas ignora. Nos modelos mais recentes da Anthropic o mínimo é de 512 tokens; em alguns modelos mais antigos chega a 4.096. Para um mini-app com instrução de poucas linhas, o cache simplesmente não entra em ação.
Medindo o ganho e protegendo a chave
Não confie na sensação de que o cache está funcionando: a resposta da API informa. No caso da Anthropic, o campo usage traz cache_creation_input_tokens (gravados nesta chamada), cache_read_input_tokens (lidos do cache) e input_tokens, que são apenas os tokens depois do último breakpoint, não o total. O total de entrada é a soma dos três. Se os dois campos de cache vierem zerados, o prompt não foi cacheado, provavelmente por ficar abaixo do mínimo. Na OpenAI, o equivalente é o cached_tokens dentro de prompt_tokens_details.
O jeito simples de usar isso em um PWA é registrar esses campos de cada chamada em um log e acompanhar a taxa de acerto: tokens lidos do cache divididos pelo total de entrada. Uma taxa baixa com tráfego constante indica prefixo instável.
Um aviso de arquitetura: a chamada à API não deve sair direto do navegador com a chave embutida no código do PWA, porque qualquer visitante consegue ler essa chave e gastar seus tokens. O padrão mais seguro é um pequeno proxy, como uma função serverless, que guarda a chave, monta o prompt na ordem certa, aplica um limite por usuário e devolve ao app só a resposta. Esse mesmo ponto é o lugar natural para gravar os números de usage.
Prompt Caching na prática: como pequenos negócios podem economizar com IA
Imagine um minimercado que utiliza inteligência artificial para responder perguntas sobre produtos, organizar informações de estoque ou auxiliar no atendimento.
Se o sistema enviar as mesmas instruções à API centenas de vezes, parte dos tokens consumidos estará relacionada a informações repetidas.
O prompt caching permite reaproveitar determinadas partes dessas instruções, reduzindo os custos de entrada quando os requisitos do cache são atendidos.
Exemplos em diferentes negócios
Minimercados: reutilização de instruções sobre categorias de produtos, regras de atendimento e organização de estoque.
Farmácias: reutilização de orientações administrativas sobre produtos, validade e organização comercial, sem transmitir dados sensíveis desnecessariamente.
Clínicas: aproveitamento de instruções administrativas estáveis para agendamentos e atendimento. Dados pessoais e de saúde exigem proteção especial.
Agronegócio: reutilização de instruções sobre processos de gestão rural, categorias de insumos e relatórios operacionais.
Esses são exemplos de possíveis integrações, não funcionalidades de IA necessariamente disponíveis nos mini-softwares atuais.
Quanto é possível economizar?
Considere um sistema que envia 3.000 tokens de instruções fixas em cada chamada.
Se houver 1.000 chamadas diárias, serão processados 3 milhões de tokens desse conteúdo por dia.
Utilizando as tarifas hipotéticas do exemplo anterior, essa parcela custaria US$ 6,00 por dia sem cache e aproximadamente US$ 0,30 em leituras de cache.
Importante: essa simulação não representa a fatura completa. Os custos reais incluem gravações no cache, tokens variáveis, respostas geradas e possíveis expirações.
A economia depende das tarifas do modelo, da repetição exata das instruções e da frequência das chamadas.
Como APIs e mini-softwares se conectam?
O cache de prompt é apenas uma parte da arquitetura de um sistema inteligente.
Para compreender como aplicativos se comunicam com serviços externos, leia também:
O que é uma API? Entenda como funciona e veja exemplos práticos
Você também pode conhecer aplicações digitais voltadas para pequenos negócios:
Conheça os mini-softwares e projetos do Conecta
A tecnologia deve ser utilizada conforme a necessidade real do negócio. Antes de integrar inteligência artificial, é importante avaliar segurança, custos, manutenção e benefícios esperados.
Conclusão
Tokens medem o consumo, mas não são todos iguais: os que se repetem podem custar de 5% a 10% do preço normal quando o prompt é bem organizado. Para um mini-software ou PWA, isso significa colocar o conteúdo fixo no começo, o variável no fim, medir os campos de cache em cada resposta e manter a chave atrás de um proxy. Antes de otimizar, confirme o mínimo de tokens do seu modelo e o seu volume real de chamadas: sem tráfego recorrente, o cache de 5 minutos não ajuda.
Fontes
- Prompt caching — documentação da Anthropic (Claude Platform), consultada em 19/10/2026: multiplicadores de preço, TTL, mínimos e campos de
usage. - API Prompt Caching — anúncio da OpenAI: cache automático acima de 1.024 tokens, desconto de 50% e campo
cached_tokens. Os números são os do anúncio original e podem ter mudado. - Exemplo de custo calculado neste artigo a partir dos preços da tabela da Anthropic para o Sonnet 5.5 (US$ 2,00 entrada, US$ 0,10 leitura de cache, por milhão de tokens).
Deixe um comentário