Cache de prompt: 80% depende de um prefixo estável

Em um estudo com mais de 500 sessões de agentes, as configurações destacadas para cada modelo reduziram o custo de API entre 41,4% e 79,6% — cerca de 80% no extremo superior — e o tempo até o primeiro token entre 6,1% e 30,9%, em uma carga com prompts de sistema de 10 mil tokens. Para preservar a parte reutilizável, coloque instruções e contexto estável no início da entrada e deixe perguntas, identificadores e resultados recentes de ferramentas no fim.

Essa organização vale para OpenAI, Claude e Gemini, mas a escolha do cache muda conforme o modelo: é preciso comparar o tamanho mínimo elegível, o prazo de retenção, a cobrança pela gravação e quantas leituras ocorrem antes de o prefixo mudar. A economia do experimento descreve aquela carga de agentes; uma aplicação com prompts curtos ou pouca repetição terá outra conta.

O prefixo determina o que pode ser reaproveitado

O cache reutiliza uma sequência inicial de entrada que permanece igual entre chamadas. Se um horário, um ID de sessão ou uma resposta nova de ferramenta aparece no meio dessa sequência, a coincidência termina ali. Mesmo que as instruções seguintes continuem iguais, elas deixam de compor o mesmo prefixo longo, e a próxima chamada pode exigir outra gravação.

Para agentes, a ordem mais útil costuma ser definições estáveis de ferramentas, regras de operação, exemplos e referências compartilhadas; depois, o histórico mantido na mesma ordem; por fim, a tarefa atual e os resultados recém-obtidos. Isso é um desenho lógico, não uma sintaxe idêntica nas três APIs. Mudar o nome, a descrição ou o esquema de uma ferramenta também altera conteúdo que pode estar antes das instruções e comprometer o reaproveitamento.

Há uma escolha adicional nas conversas longas. Preservar mensagens antigas e acrescentar novas mensagens ao final pode ampliar o trecho lido do cache; resumir ou reescrever o histórico muda a sequência a partir do ponto editado. Quando os resultados de ferramentas quase nunca se repetem entre sessões, faz mais sentido manter um limite de cache no fim da base estável do que pagar para gravá-los a cada execução.

Ativação, TTL e preço nas três APIs

Na documentação de cache da OpenAI, GPT-5.6 e modelos posteriores exigem um prefixo visível de pelo menos 1.024 tokens; a gravação custa 1,25 vez a tarifa normal de entrada e a leitura custa 0,1 vez na maioria desses modelos, com retenção mínima de 30 minutos após o último uso; em modelos anteriores, a retenção depende da configuração e pode chegar a 24 horas. Os pontos de cache podem ser implícitos ou escolhidos pelo desenvolvedor nos modelos mais recentes, enquanto os anteriores usam pontos implícitos.

O modo explícito permite encerrar a gravação logo após o trecho estável e cobrar o conteúdo posterior como entrada comum. No modo implícito, a API pode criar um ponto depois de uma mensagem que inclua dados variáveis, conforme o modelo e a estrutura da requisição. Na resposta, os campos de uso distinguem tokens lidos do cache e, nos modelos com cobrança de escrita, tokens gravados: gravações repetidas sem leituras indicam que o desenho do prompt não está se pagando.

Na documentação de prompt caching do Claude, a gravação com TTL de cinco minutos custa 1,25 vez a entrada normal, a de uma hora custa 2 vezes, a leitura custa 0,1 vez na maioria dos modelos e o mínimo elegível varia de 512 a 4.096 tokens conforme o modelo. O cache é ativado com cache_control na requisição inteira ou em blocos específicos; seu prefixo segue a ordem de ferramentas, sistema e mensagens.

O controle automático acompanha o último bloco elegível, o que favorece uma conversa cujo histórico cresce sem alterações. Se cada chamada traz um resultado novo, um ponto explícito no último bloco estável evita incluir esse resultado na gravação. Os campos de uso separam entrada comum, tokens gravados e tokens lidos, permitindo ver se a janela escolhida está recebendo chamadas repetidas.

Nas regras de cache implícito do Gemini, o recurso vem ativado por padrão em modelos Gemini 2.5 ou posteriores; os modelos 2.5 listados pedem pelo menos 2.048 tokens de entrada, enquanto os modelos mais novos listados pedem 4.096. Para aumentar a chance de acerto, o Google recomenda conteúdo grande e comum no início e chamadas com prefixos semelhantes próximas no tempo. O total de tokens aproveitados aparece nos dados de uso da resposta.

O cache explícito do Gemini cria um objeto reutilizável na API generateContent para modelos compatíveis, com TTL padrão de uma hora; a opção não está disponível na Interactions API. A cobrança inclui o armazenamento conforme a quantidade de tokens e a duração escolhida, além do uso de tokens em cache, da entrada comum e da saída. Assim, uma leitura mais barata precisa compensar também o tempo pelo qual o conteúdo ficou armazenado.

Dois modelos de prompt para agentes

No primeiro modelo, várias tarefas compartilham a mesma base: definições de ferramentas, instruções de comportamento, formato de resposta e referências realmente usadas por todas elas. O limite de cache fica ao fim dessa base quando a API permite escolhê-lo. A pergunta do usuário, os parâmetros da execução e os novos resultados de ferramentas vêm depois; mudar esses valores não desloca o prefixo compartilhado.

No segundo modelo, cada conversa reaproveita também seu próprio histórico. A requisição seguinte conserva as mensagens anteriores exatamente na mesma ordem e acrescenta as novas no final. Esse arranjo pode render mais tokens lidos do cache dentro de uma sessão ativa, mas cria mais gravações à medida que ela cresce. Para muitos usuários com poucas chamadas cada, a base comum tende a ser o trecho mais previsível; para conversas extensas e frequentes, o histórico também pode valer a retenção.

Uma calculadora para cada padrão de reutilização

Comece pela parcela de entrada. Chame de P o número de tokens do prefixo estável, D os tokens dinâmicos por chamada, N o total de chamadas com o mesmo prefixo dentro do prazo de retenção, W o multiplicador de gravação e R o de leitura. Sem cache, a conta em equivalentes de tokens de entrada é N × (P + D). Com uma gravação inicial e acerto completo nas demais chamadas, ela é P × [W + (N − 1) × R] + N × D.

Em um exemplo hipotético com ponto explícito ao fim do prefixo, dez chamadas reutilizam 8 mil tokens estáveis e acrescentam 2 mil tokens variáveis cada. Se W for 1,25 e R for 0,1, a parcela de entrada cai de 100 mil para 37,2 mil equivalentes de tokens: redução de 62,8%. O exemplo pressupõe uma gravação, nove leituras completas e nenhuma expiração; não inclui tokens de saída nem representa a economia da fatura inteira.

A fórmula também mostra o efeito do TTL. Com W de 1,25 e R de 0,1, uma gravação seguida de uma leitura custa 1,35 vez o processamento normal daquele prefixo, contra 2 vezes sem cache. Com W de 2 e o mesmo R, a primeira leitura ainda leva o total a 2,1 vezes; uma segunda leitura, se ocorrer dentro da janela, reduz o custo relativo a três processamentos sem cache. São resultados aritméticos dos multiplicadores, não uma previsão de acertos.

Para tráfego real, substitua a hipótese de N − 1 acertos pelos tokens efetivamente lidos e gravados em cada resposta. Some armazenamento no caso do Gemini explícito e use a tarifa de entrada do modelo escolhido para converter os equivalentes em dinheiro. Meça o tempo até o primeiro token na mesma carga: um desconto por token, sozinho, não informa a latência.

Quando cada configuração faz sentido

Prefixos longos e repetidos em intervalos curtos favorecem começar pelo cache implícito ou automático e observar as leituras obtidas. Quando resultados de ferramentas mudam a cada etapa, pontos explícitos oferecem controle sobre o fim da parte gravada, nos modelos que os aceitam. Para chamadas mais espaçadas, uma retenção maior pode evitar regravações, mas só compensa se as leituras adicionais pagarem seu custo.

A comparação entre provedores deve usar a mesma carga e separar entrada comum, gravações, leituras, armazenamento e saída. Um desconto alto na leitura perde relevância se o prefixo não alcançar o mínimo do modelo ou mudar antes de ser reutilizado. O indicador decisivo é quantos tokens estáveis voltam como leitura de cache, não a maior economia isolada de um benchmark.