Cache de prompt

Como funciona um acerto de cache

Um modelo de linguagem lê cada requisição a partir do primeiro token. Um agente de IA no meio de uma tarefa envia suas instruções, suas definições de ferramentas e toda a conversa até ali em cada chamada, então, numa tarefa longa, essa leitura repetida é a maior parte do que você paga. O cache de prompt permite que o provedor pule um trabalho que acabou de fazer: se o começo da sua requisição coincide com o começo de uma requisição recente, token por token, esse trecho é servido a partir do que o provedor guardou e cobrado com a tarifa de cache.

Três detalhes decidem se isso acontece:

• É uma correspondência de prefixo. O cache cobre tudo desde o primeiro token até a primeira diferença, e nada depois dela. Mude um caractere perto do topo e cada token abaixo desse ponto é lido, e cobrado, integralmente de novo.
• Ele expira. As entradas sobrevivem a minutos de inatividade, não a dias, e a janela varia por provedor e por modelo, então uma requisição feita depois de uma pausa longa paga o preço cheio mesmo que nada nela tenha mudado.
• Ele tem um piso. Abaixo de um tamanho mínimo de prompt nada vai para o cache, e esse mínimo é definido por modelo. Consulte a documentação atual do provedor em vez de confiar num número copiado de um post antigo de blog.

Em setembro de 2026, Anthropic, OpenAI e Google cobram a leitura de cache nos seus modelos atuais por cerca de um décimo do preço normal de entrada. Google e OpenAI aplicam o cache automaticamente; a Anthropic guarda em cache até os pontos de corte que você marca na requisição e cobra um adicional para gravar uma entrada. Uma diferença de dez para um é grande o bastante para que a parcela da sua entrada que está em cache, e não o tamanho do seu prompt, muitas vezes decida quanto custa uma execução de agente.

Por que enxugar o contexto deixou nossos agentes mais caros

Rodamos agentes de longa duração que criam e editam sites para clientes, e uma sessão de criação de site nos mostrou quanto custa um contexto sem limite. Em pouco menos de quatro horas ela fez 622 chamadas ao modelo, enquanto a conversa relida a cada chamada crescia até cerca de 310 mil tokens. O texto que o modelo de fato escreveu correspondeu a aproximadamente 6% da conta. Todo o resto foi ler o mesmo histórico outra vez.

A correção óbvia era podar: antes de cada chamada, remover resultados antigos de ferramentas com base nos quais o agente já tinha agido. Medimos isso no nosso próprio workspace de teste, 366 chamadas reais ao modelo no total, e no trecho em que a poda de fato disparou, cada chamada custou cerca de 28% a mais, enquanto só uns 23 mil tokens saíam de cada prompt. A poda avançava a partir do resultado mais antigo, então a cada chamada reescrevia um ponto um pouco mais adiante dentro do prefixo que o provedor tinha acabado de guardar em cache. A entrada fora do cache por chamada passou de 2–8 mil tokens para 5–25 mil, e com uma relação de preço de dez para um isso engoliu a economia. Vale guardar a conta: uma mudança dentro de um prefixo em cache precisa remover cerca de nove vezes mais tokens do que invalida só para empatar.

O que funcionou no lugar foi um teto, e não um corte. Limitamos em 200 mil tokens o contexto que um agente pode acumular, de modo que o histórico é compactado de uma só vez quando se aproxima desse limite, em vez de ser editado um pouco a cada chamada, e desligamos a poda por chamada. Uma reescrita seguida de uma longa sequência de chamadas que só acrescentam é o formato que o cache recompensa. A lição que tiramos é olhar a entrada em cache e a entrada fora do cache em cada chamada antes de acreditar que qualquer mudança economizou dinheiro, porque o tamanho do prompt, sozinho, nos dizia o contrário do que a conta dizia.

Como manter seus acertos de cache

A maior parte da economia vem da ordem, não da configuração. Se você está construindo sobre a API de um modelo, quatro hábitos cobrem quase tudo:

• Material estável primeiro, material que muda por último. Instruções, definições de ferramentas e documentos de referência vão no topo e continuam idênticos byte a byte entre as chamadas. Um timestamp, o nome de um usuário ou um ID de requisição perto do topo de um prompt de sistema derruba o cache em silêncio a cada requisição.
• Acrescente, não edite. Adicione os novos turnos ao final da conversa. Reescrever, reordenar ou resumir turnos anteriores no lugar invalida tudo o que vem depois da edição — o erro que a nossa poda cometia um passo de cada vez.
• Reescreva raramente, e de uma vez só. Se o histórico precisa encolher, faça isso numa única compactação, num teto que você escolheu, e aceite uma chamada cara em troca de uma longa sequência barata depois dela.
• Meça a divisão, não o tamanho. Os provedores informam a entrada em cache e a entrada fora do cache separadamente nos dados de uso de cada resposta. Uma mudança que encurta o seu prompt e aumenta a contagem fora do cache deixou tudo mais caro, diga o tamanho do prompt o que disser.

Os números acima vêm da operação do AgentCeres — o AI Growth Officer em agentceres.com —, em que um time de agentes especialistas redige as páginas, as publicações e o contato, e o trabalho que sai para fora espera por padrão a aprovação de uma pessoa. Se você está precificando um produto construído sobre chamadas como essas, a página como precificar um produto de IA quando meus custos são variáveis? explica por que o preço deve se apoiar num custo por chamada que você mediu.