O quê

Prompt Caching é a feature que permite persistir o KV cache de um prefixo de prompt entre chamadas, cobrando uma fração do preço normal quando você reusa esse prefixo. Em vez de reprocessar 5000 tokens de system prompt + documentos toda vez que faz uma pergunta, você processa uma vez (cobrança full), e cada chamada subsequente reusa o KV cache cobrando 10-25% do preço.

Anthropic lançou em agosto de 2024, OpenAI em outubro de 2024, Google segue com Context Caching. Em 2025, é primitiva esperada de qualquer API de LLM séria. Para apps que rodam prompts longos repetidos (agents, RAG, batch processing), prompt caching reduz custos em 50-90%.

Em Magik LLM Gathering, prompt caching é tratada como Technique · Inference · Common — a primitiva de eficiência econômica em runtime.

Como funciona

O modelo de cobrança

Sem cache:

• Cada chamada: cobrança full por todos os input tokens.

Com cache:

• Primeira chamada que escreve no cache: cobrança ~1.25× (overhead pra armazenar).
• Cada cache hit subsequente: cobrança ~0.1× (Anthropic 90% desconto, OpenAI 50%).
• Cache TTL: ~5 minutos (Anthropic), até 1 hora (OpenAI extended).

Para um agent que faz 100 chamadas com mesmo system prompt de 2000 tokens:

• Sem cache: 100 × 2000 = 200k input tokens cobrados.
• Com cache: 2500 (primeira escrita) + 99 × 200 (hits) = ~22k tokens cobrados. 90% economia.

Como o cache decide quê reusar

Cache hit acontece quando você marca explicitamente porções do prompt como cacheáveis. Marcação é por breakpoint — você diz “cache até aqui”. As regras:

1. Prefix-only: o cache é por prefixo. Se você muda algo no meio do prompt, o cache antes da mudança ainda vale, depois é invalidado.
2. Exact match: até o último token cacheado tem que bater exatamente. Um espaço diferente, um número trocado, e cache miss.
3. Por breakpoint: cliente sinaliza onde dividir. Tipicamente:
   • System prompt → cache breakpoint
   • Documentos (RAG context) → cache breakpoint
   • Conversation history → pode ou não cachear
   • User message atual → nunca cacheável

Casos de uso canônicos

• Agents com system prompt longo: instruções de 5k+ tokens cacheadas; cada step do agent paga só pela mensagem nova.
• RAG: documentos recuperados injetados no prompt. Se mesmos documentos são consultados várias vezes, cache poupa.
• Multi-turn chat: conversation history acumula. Cache toda história até turno N, próximo turno só paga o delta.
• Batch processing: rodar mesmo prompt em 1000 inputs distintos — cache o template, cada input paga só o variável.
• Function calling tool schemas: schemas de ferramentas (que ocupam contexto) são tipicamente fixos — cache-os.

Por que importa

Prompt caching mudou a economia de aplicações LLM em produção:

1. Reduziu barrier de entrada pra long-context: antes, processar 100k tokens custava muito; agora, se você reusa esses 100k, custa 10%.

2. Habilita arquiteturas que eram caras demais: agents com system prompt detalhado, RAG com many-shot examples, multi-turn chat com history extensa — todos viram viáveis economicamente.

3. Pricing model muda: provedores cobram menos pra clientes que estruturam prompts bem. Engineering effort traduz direto em redução de custo.

4. Padroniza pattern de “stable prefix + variable suffix”: melhores práticas modernas: coloque o que muda no fim do prompt. Permite máximo cache reuse.

5. Pode rodar provider-agnostic com middleware: bibliotecas (LiteLLM, LangChain) abstraem cache logic — você muda Anthropic↔OpenAI sem mudar app.

A economia comparada às alternativas:

• Fine-tuning custa $100-10k+ upfront, infinitamente reusável. Inflexível.
• RAG sem cache custa por chamada, mas re-injeta context. Flexível, caro em volume.
• RAG com prompt cache: flexibilidade de RAG + custo próximo de fine-tuning. Sweet spot moderno.

Pegadinhas

• Cache hit não é garantido: provider pode evictar cache se memória aperta. Modelos seu de uso assumem cache mas custo real pode ser maior em períodos de pico.
• TTL curto: 5min (Anthropic standard) significa que cache morre se você não usar a cada 5min. Para apps com tráfego esporádico, cache pode nunca aquecer.
• Cache miss invisível: você não sabe se foi hit ou miss antes da resposta voltar. Cobrança no response te diz. Difícil debugar regressões de custo.
• Variação de provider: Anthropic cobra 1.25× write, 0.1× hit. OpenAI cobra 1× write, 0.5× hit. Google é parecido com OpenAI. Cálculos de ROI dependem do provider.
• Não cacheable: tool results, function call responses, dynamic timestamps no prompt — tudo isso quebra cache. Estruture prompts isolando isso.
• Cache key é determinístico até o byte: trim trailing whitespace, normalize newlines — qualquer divergência mata cache. Bibliotecas que reformatam prompts (templating) podem quebrar silenciosamente.
• Limitação de tamanho: cache mínimo (Anthropic exige 1024+ tokens). Prompts curtos não cachêem.
• Privacidade: cache fica no servidor do provider por TTL. Pra dados sensíveis, considere implications.

Estado em 2026

Em 2026, prompt caching é commodity: Anthropic, OpenAI, Google e praticamente todo provedor sério oferecem alguma forma. A OpenAI tornou o caching automático (sem breakpoints manuais, ~50% de desconto em prefixos repetidos), enquanto a Anthropic manteve breakpoints explícitos com desconto de até 90% e opção de TTL estendido (1 hora). O Google oferece caching implícito e explícito no Gemini. A prática de “prefixo estável, sufixo variável” virou higiene-padrão de engenharia de prompt.

O caching subiu na pilha e se fundiu com a economia de agents. Como agents fazem dezenas a centenas de chamadas reusando o mesmo system prompt e histórico, sem caching eles seriam economicamente inviáveis — é parte do motivo de loops agentic longos terem ficado pagáveis. No nível de infra, prefix caching automático em engines de serving (vLLM, SGLang) levou a mesma ideia para deployments self-hosted.

Os trade-offs de 2026 são os mesmos da origem, agora melhor compreendidos: TTL curto e eviction tornam o hit não-garantido; cache exige match exato até o byte (templating descuidado quebra silenciosamente); e há considerações de privacidade e isolamento entre tenants. A novidade econômica é que o caching virou alavanca de design: arquiteturas inteiras (RAG, many-shot, multi-agente) são desenhadas para maximizar reuso de prefixo.

Tratamento de carta — proposta

Em Magik LLM Gathering, prompt caching aparece como Technique · Inference · Common: a próxima Technique que você jogar este turno custa ⚡1 a menos. Se você jogar uma Technique igual a uma já jogada nesta partida, ela custa ⚡2 a menos. Mecânica espelha a essência: a primeira execução é cara, a repetição é barata.

É a carta universal de decks que abusam de Techniques específicas múltiplas vezes — combos repetitivos viram drasticamente mais baratos.

Veja também

• KV Cache — a estrutura subjacente que prompt cache persiste
• RAG — Retrieval-Augmented Generation — caso de uso canônico (cache documentos)
• LLM Agents — caso de uso canônico (cache system prompt)
• Context Window — viabilidade econômica de contextos longos habilitada
• Function Calling / Tool Use — schemas que tipicamente são cacheados