Cache em backend é um dos truques mais rentáveis do ofício: pagar caro uma vez pelo resultado e servir cópias baratas depois. Prompt caching via API promete o mesmo pro custo de LLM. Leitura de token cacheado sai na faixa de 10% do preço do input nos modelos principais dos três grandes provedores. Só que a analogia com Redis esconde a pegadinha. O desconto na casa de 90% não vem de ligar uma flag. Ele só se materializa se o prompt tiver um prefixo estável, reutilizado dentro do TTL (o prazo de validade do cache). O artefato pra levar pra equipe é o layout do prefixo estável, mais a lista de erros que zeram o hit rate.
O que o provedor cacheia (não é a resposta)
Primeiro ajuste no modelo mental: o cache de prompt não guarda resposta pronta. Ele guarda o estado interno que o modelo computa ao processar o começo do prompt. No hit, o modelo retoma desse ponto e gera a resposta do zero.
A doc da OpenAI é explícita: caching não muda a geração de output, e dois requests idênticos podem retornar respostas diferentes. O que você economiza é o reprocessamento do prefixo: custo e tempo até o primeiro token.
A Anthropic declara melhora geral de time-to-first-token pra documentos longos. No mapa do artigo dos quatro eixos, o prompt caching move custo e latência ao mesmo tempo, sem tocar qualidade.
Onde a analogia com cache clássico quebra
Escrever pode custar mais caro que não cachear. No Redis, gravar é barato. Aqui, a Anthropic cobra a escrita de cache a 1,25x o preço do input no TTL de 5 minutos, e 2x no TTL de 1 hora. A OpenAI cobra 1,25x nos modelos GPT-5.6 em diante. Cache escrito e nunca relido é prejuízo de 25% sobre a opção de não fazer nada.
O hit não usa chave, usa prefixo exato. Cache clássico busca por chave. Qualquer request com a mesma chave acerta. Aqui o sistema exige prefixo idêntico: o começo do prompt precisa bater exatamente com o que foi cacheado. Na hierarquia da Anthropic, o prompt cacheia na ordem tools, system, messages: mudança em um nível invalida esse nível e todos os seguintes. Trocar uma tool invalida o cache inteiro. Na OpenAI, o cache também é de prefixo: o que vem depois do trecho cacheado pode mudar. Qualquer diferença dentro do prefixo derruba o hit.
O TTL é curto e o relógio é do provedor. Redis expira quando você mandar. Aqui, a Anthropic dá 5 minutos por padrão, com opção de 1 hora pagando escrita a 2x. Na OpenAI, o cache em memória dos modelos pré-GPT-5.6 costuma viver de 5 a 10 minutos de inatividade, com teto de 1 hora. Os GPT-5.6+ garantem 30 minutos, e modelos listados aceitam retenção estendida de até 24 horas. Uso em cadência regular renova o cache de 5 minutos da Anthropic sem nova cobrança de escrita. Tráfego esparso além do TTL paga escrita de novo a cada rajada.
Os números dos três provedores
Os mecanismos diferem mais que os preços. Tabela comparativa, com dados das docs e páginas de pricing de cada provedor:
| Anthropic (Claude) | OpenAI | Google (Gemini) | |
|---|---|---|---|
| Ativação | cache_control no request (automático) ou por bloco |
automática a partir de 1.024 tokens | automática (implicit) nos modelos 2.5+ |
| Mínimo cacheável | 512 a 4.096 tokens, por modelo | 1.024 tokens (estrito nos GPT-5.6+; 1.024 a 2.048 nos anteriores) | 2.048 a 4.096 tokens, por modelo |
| Custo de escrita | 1,25x (5 min) ou 2x (1h) | grátis até GPT-5.5; 1,25x nos GPT-5.6+ | sem taxa de escrita publicada; cache explícito cobra armazenamento |
| Custo de leitura | 10% do input | 10% do input nos flagship (ex.: gpt-5.6-sol, $0,50 vs $5,00) | 10% do input (ex.: 3.6 Flash, $0,075 vs $0,75) |
| Campo no usage | cache_read_input_tokens, cache_creation_input_tokens |
cached_tokens, cache_write_tokens (GPT-5.6+) |
total_cached_tokens |
Três notas de projeto que a tabela não carrega. Na Anthropic, cache é opt-in: sem cache_control, nada é cacheado. Na OpenAI, o roteamento usa hash do início do prompt. O parâmetro prompt_cache_key melhora o hit rate (a taxa de acerto) e vira obrigatório pra matching confiável nos GPT-5.6+. A doc recomenda cerca de 15 requests por minuto por chave. No Gemini, além do cache implícito, existe o cache explícito. Você cria o objeto de cache e paga armazenamento de $1,00 por milhão de tokens por hora enquanto ele viver. Preço por modelo e por tier fica nas páginas de pricing linkadas nas fontes. O desenho que segue vale pra qualquer um deles.
Opinião minha, e dá pra discordar dela: o opt-in da Anthropic é o melhor default dos três. Cache automático economiza sem pedir licença. É exatamente por isso que ninguém para pra desenhar o prompt. O cache_control obriga alguém a decidir onde o prefixo estável termina, e essa decisão é o trabalho inteiro. O automático entrega parte do desconto e cobra o resto em desenho que nunca acontece.
A conta do break-even
Quando o cache compensa? Conta ilustrativa minha, usando os multiplicadores da Anthropic (escrita 1,25x ou 2x, leitura 0,1x), em unidades do custo base do prefixo:
| Usos do prefixo dentro do TTL | Sem cache | Cache 5 min | Cache 1h |
|---|---|---|---|
| 1 | 1,00 | 1,25 | 2,00 |
| 2 | 2,00 | 1,35 | 2,10 |
| 3 | 3,00 | 1,45 | 2,20 |
| 10 | 10,00 | 2,15 | 2,90 |
O cache de 5 minutos se paga já no segundo uso. O de 1 hora, no terceiro. E a linha de 10 usos mostra por que loop de agente é candidato forte: cada iteração reenvia system prompt, tools e histórico inteiros. Dez chamadas com o mesmo prefixo custam 2,15 em vez de 10,00 no input do prefixo. A mesma conta vale como alerta: uma única chamada com escrita e nenhuma releitura fica 25% mais cara. Prompt caching é aposta na reutilização. A tabela diz o quanto você precisa acertar. Nos GPT-5.6+ da OpenAI, os multiplicadores de escrita e leitura são os mesmos da conta acima. Nos modelos anteriores, sem cobrança de escrita, qualquer releitura já sai no lucro. No cache explícito do Gemini, some o armazenamento por hora à conta.
Da unidade pro dólar
A tabela acima fala em unidades do custo do prefixo. Em dólar, prompt caching deixa de ser detalhe de formato e vira linha de orçamento.
Conta ilustrativa minha, com as premissas na mesa. Agente com prefixo estável de 8.000 tokens e 1 milhão de requests por mês. Preço de input de $5,00 por milhão de tokens, o do gpt-5.6-sol citado na tabela dos provedores. Escrita a 1,25x e leitura a 0,1x, os mesmos multiplicadores da conta acima. A variável que decide tudo é o reuso, ou seja, quantos requests caem na mesma janela de TTL antes de o prefixo ser reescrito.
| Reusos por janela | Escritas/mês | Leituras/mês | Custo do prefixo/mês | vs. sem cache |
|---|---|---|---|---|
| 1 (escreve e nunca relê) | 1.000.000 | 0 | $50.000 | +25% |
| 2 | 500.000 | 500.000 | $27.000 | -33% |
| 5 | 200.000 | 800.000 | $13.200 | -67% |
| 20 | 50.000 | 950.000 | $6.300 | -84% |
| 100 | 10.000 | 990.000 | $4.460 | -89% |
Sem cache nenhum, esse mesmo prefixo custa $40.000 por mês. O piso teórico é $4.000, que seria leitura pura. Ninguém chega lá, porque toda janela de TTL paga pelo menos uma escrita.
Três coisas aparecem aqui que a versão em unidades escondia. A primeira é o tamanho do erro. Cachear com reuso 1 joga $10.000 por mês fora, e a fatura não avisa. A segunda é onde mora o dinheiro. Do reuso 1 pro 5 você captura três quartos de toda a economia possível. Do 20 pro 100 sobra pouco mais de 4%. A terceira é o rendimento decrescente do esforço. Passado o reuso de 20 por janela, brigar por mais reuso rende menos que brigar por prefixo maior.
O sufixo variável fica fora dessa conta. Ele é cobrado como input normal nos dois cenários e some na comparação. Troque o preço pelo do seu modelo, que a forma da curva não muda.
Bônus que não aparece na fatura: na maioria dos modelos Claude, cache hit não desconta do ITPM, o rate limit de tokens de input por minuto. O artigo do token budget desceu nesse detalhe. Cache bem usado compra throughput dentro do mesmo tier, sem upgrade de conta.
O layout do prefixo estável
A regra que os três provedores publicam é a mesma: conteúdo estático no começo, variável no fim. O layout ordena o prompt por estabilidade decrescente:
| Posição | Bloco | Muda quando | No cache |
|---|---|---|---|
| 1 | definições de tools | deploy | prefixo compartilhado por todo o tráfego |
| 2 | system prompt | deploy | prefixo compartilhado por todo o tráfego |
| 3 | contexto grande: docs, few-shot, base de conhecimento | por versão do conteúdo | prefixo por versão |
| 4 | histórico da conversa | a cada turno, só por append | prefixo da sessão, cresce a cada turno |
| 5 | a vez atual do usuário | a cada request | sufixo agora; entra no prefixo no turno seguinte |
A propriedade que sustenta o layout: append no fim não invalida o começo. A conversa cresce, o prefixo cacheado permanece válido e o breakpoint (o marcador que fecha o trecho cacheável) automático da Anthropic avança sozinho a cada turno. Edição em qualquer bloco anterior invalida dali pra frente. Um limite documentado: a busca por escritas anteriores olha até 20 blocos pra trás. Conversa que cresce mais que isso entre escritas pede um segundo breakpoint.
Como isso cai na prática, no orquestrador que eu mantenho: o prompt é congelado quando a task é criada, e tudo que varia por run entra como sufixo. A lista de ferramentas MCP é o caso que quase escapou. Ela não é congelável, porque depende do adapter e da URL do daemon, e nenhum dos dois existe na hora de gerar o prompt. Pela ordem em que o código roda, ela podia ter virado cabeçalho. Virou sufixo, e o prefixo congelado sobreviveu.
E a lista dos assassinos de cache, os erros que zeram ou diluem o hit rate:
- Timestamp, request ID ou nonce no system prompt. Prefixo novo a cada chamada, hit rate zero. E, onde a escrita é cobrada, você paga cache write em todo request.
- Lista de tools montada dinamicamente. Ordem de serialização instável muda o primeiro nível da hierarquia e invalida tudo.
- Dados do usuário interpolados no início. Nome, tenant ou saldo no topo do system prompt encolhe o compartilhamento. O prefixo passa a valer só pros requests daquele usuário.
- Prefixo abaixo do mínimo do modelo. Abaixo do mínimo, o request funciona normal e nada entra no cache. Nenhum erro avisa.
- Tráfego mais esparso que o TTL. Job que roda a cada 20 minutos nunca acerta o cache de 5 minutos da Anthropic. Avalie o TTL de 1 hora ou aceite o custo.
- Variação de prompt no meio do tráfego. A/B test de system prompt divide o tráfego em populações de cache separadas. Cada braço paga as próprias escritas.
Fechar o loop: medir antes de comemorar
O layout é hipótese. O usage da resposta é o veredito. Os campos da tabela comparativa dizem, por request, quanto foi lido do cache. Anthropic e OpenAI (nos GPT-5.6+) reportam também quanto foi escrito. Onde os dois contadores existem, a razão entre leitura e escrita é o primeiro sinal. Na conta da minha tabela de break-even, pouco mais de 1 escrita relida a cada 4 já empata o TTL de 5 minutos. No de 1 hora, cada escrita precisa de mais de uma releitura. Muita escrita e pouca leitura significa pagar o prêmio da escrita sem colher o desconto da leitura.
Observação minha, fora da cadeia das fontes. Instrumentei 104 runs de agente num orquestrador que eu mantenho, ao longo de cerca de duas semanas. Nas 76 runs de Claude, 1.888 turnos no total, o input somou 133,3 milhões de tokens e custou US$ 175,80. Desse input, 126,0 milhões vieram do cache e 7,3 milhões foram escrita. Hit rate de 94,5%, mediana de 93,2% por run, mínimo de 77,9%. A razão leitura/escrita ficou em 17,3:1, bem acima do empate do TTL de 1 hora.
Dois avisos antes de você levar esse número pra alguma reunião. Primeiro, quem acerta o cache ali é o CLI do agente, cacheando o próprio prefixo de conversa entre os turnos dele. O orquestrador manda um prompt por run e não tem mérito nenhum na taxa. Segundo, a amostra é de um operador, um projeto, duas semanas. É telemetria de campo de uma instalação, não benchmark.
O que mais me surpreendeu foi o input cru: 6.631 tokens nas 76 runs, 87 por run. Quase nada é cobrado como input simples. Cada byte ou está sendo lido do cache ou está sendo escrito nele. Em trabalho de agente, essa distribuição não é espectro. É binária. E é por isso que prompt caching com TTL longo deixa de ser luxo nesse regime.
Tem ainda um modo de falha que a doc dos provedores não cobre: o agente que não reporta nada. O agente default do meu orquestrador é o GitHub Copilot CLI. Sondei os 21 tipos de linha do envelope na versão 1.0.75. Não existe contador de input, output ou cache. O que ele devolve é um modelCacheState com o prazo do cache, cacheTtlSeconds: 300, e nada sobre acerto. A taxa de cache ali não é ruim. Ela é inobservável. Antes de desenhar o prefixo, confira se o seu agente reporta o usage. Sem os contadores, o layout fica sendo hipótese pra sempre. Prompt caching sem contador é aposta, não alavanca.
Cuidado também com contador que existe mas mede outra coisa. Nas minhas 14 runs de Codex, o campo de escrita de cache veio zerado. Não é run sem escrita, é campo que aquele CLI não preenche. Quem aplica a mesma fórmula de hit rate nos dois está comparando denominadores diferentes.
A própria OpenAI recomenda comparar volume de escrita com as leituras seguintes e ajustar o posicionamento do breakpoint. Esses contadores já têm lugar no contrato de atribuição do artigo anterior. Com eles persistidos por request, a pergunta “o cache está pagando o próprio custo nesta feature?” vira consulta, não ato de fé.
Um limite pra manter no radar: cache não atravessa fronteira de conta. Na Anthropic, o isolamento é por workspace. Na OpenAI, organizações nunca compartilham cache. O prefixo compartilhado que interessa é entre os seus próprios requests, e maximizá-lo é exatamente o que o layout faz.
Fechando
Prompt caching é a rara alavanca de custo sem trade-off de qualidade: a resposta é gerada igual, só o reprocessamento do prefixo some. O preço dessa alavanca é disciplina de formato. O desconto na casa de 90% não está na flag. Está no prompt desenhado como prefixo estável, reutilizado dentro do TTL, medido pelo usage. Comece pelo layout, cace os assassinos de cache no seu system prompt e acompanhe a razão leitura/escrita por uma semana. A fatura conta o resto.
Deixe um comentário