# Quando o prompt caching realmente reduz o custo de agentes de programação? > O prompt caching reduz custos quando muitas requisições reutilizam um prefixo grande e estável em bytes, e a economia das leituras supera a complexidade e as falhas. Meça a entrada armazenada nos registros reais em vez de supor desconto para toda instrução repetida. Prompt caching é valioso quando o agente envia repetidamente o mesmo começo grande, não apenas quando os prompts parecem semelhantes. Um horário, lista de ferramentas reordenada, resumo variável ou ID gerado próximo do início pode eliminar o reúso de tudo que vem depois. Antes de redesenhar prompts, examine metadados reais. Descubra quantos tokens são elegíveis, quantos aparecem como leituras, com que frequência o prefixo muda e se o modelo e protocolo oferecem benefício. ## Modele a base sem cache Comece pelo custo de entrada, pois o cache não reduz saída nem execução de ferramentas. ```text uncached_input_cost = requests * input_tokens_per_request * input_rate ``` Mantenha tarifas em unidades coerentes, normalmente por milhão de tokens. Não use um desconto lembrado; consulte o preço atual e os campos de uso do modelo exato. | Componente | Estável entre requisições? | Posição provável | |---|---|---| | Política de sistema | Normalmente | Primeiro | | Schemas de ferramentas | Normalmente | Início | | Convenções do repositório | Frequentemente | Início | | Checkpoint da tarefa | Às vezes | Meio | | Pedido do usuário | Raramente | Final | | Saída de ferramenta | Não | Última | ## Calcule o equilíbrio com símbolos Seja `P` o número de tokens do prefixo, `R` o total de requisições, `W` a tarifa de escrita, `H` a de leitura e `U` a tarifa comum: ```text uncached = R * P * U cached = P * W + (R - 1) * P * H savings = uncached - cached ``` Esse caso ideal supõe que todas as requisições posteriores acertam. Para uma fração medida `h`, substitua o termo posterior por uma mistura ponderada de `H` e `U`. Adicione tokens fora do prefixo à tarifa comum nos dois lados. O cache só é financeiramente útil se a economia continuar positiva após falhas e trabalho de engenharia. ## Coloque conteúdo estável primeiro Monte do estável ao volátil: * Instruções de sistema e segurança. * Definições em ordem determinística. * Convenções e referências duráveis. * Checkpoint compacto. * Requisição atual. * Última saída de ferramenta. Serializa schemas de forma determinística. Evite ordem aleatória, mudanças de espaços, horários e comentários específicos. Versione blocos estáveis para que uma mudança real gere uma falha explicável. ## Mantenha o prefixo útil, não só grande Um prefixo inflado pode aumentar leituras e, ao mesmo tempo, elevar tokens e distrair o modelo. Remova ferramentas obsoletas, políticas duplicadas e referências irrelevantes. Meça o custo por resultado aceito, não apenas a taxa de acerto. Um prompt curto sem cache que resolve em menos turnos pode superar outro grande e ruidoso. ## Instrumente requisições e resultados Registre modelo, protocolo, versão do prefixo, tokens totais, tokens armazenados quando disponíveis, saída, latência, chamadas, novas tentativas e resultado. Marque campos ausentes como indisponíveis, não como zero. | Métrica | Por que importa | |---|---| | Parcela em cache | Confirma reúso real | | Motivo da falha | Detecta mudança acidental | | Requisições por tarefa | Revela loops que anulam a economia | | Custo por alteração aceita | Liga tokens a trabalho útil | | Taxa de tentativas | Mostra custos de confiabilidade externos | Uma semana de tarefas representativas vale mais que repetir cem vezes um prompt sintético. ## Observe rotas e limites de sessão O comportamento pode depender de modelo, provedor, região, janela de retenção e roteamento. Um gateway ou fallback pode enviar a requisição a uma rota sem o mesmo prefixo aquecido. Trate o desempenho como propriedade observada da rota escolhida. A Atlas Cloud oferece vários formatos LLM em uma API, mas o guia público não promete desconto universal. Confira modelo e console antes de afirmar economia. Use [protocolos LLM](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) para escolher o formato e o [catálogo](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) para modelos atuais. ## Evite economias falsas Uma entrada mais barata pode esconder turnos extras, ferramentas com falha ou reconstruções repetidas. Diferencie também leitura de cache de armazenamento ou recuperação da aplicação: resolvem problemas distintos. Não inclua segredos só porque o conteúdo pode ser armazenado. Siga controles de dados e retenção; cache não substitui controle de acesso. ## Use uma porta prática de adoção Adote quando: * O prefixo estável é útil e reutilizado com frequência. * O uso real relata leituras do cache. * A economia sobrevive à taxa observada de falhas. * O versionamento é simples e determinístico. * Qualidade e número de turnos não pioram. Caso contrário, reduza o prompt, recupere apenas arquivos relevantes e encurte o loop. ## Conclusão Prompt caching reduz custos quando um prefixo grande, útil e estável é reutilizado vezes suficientes em uma rota que cobra menos pela entrada armazenada. Coloque o estável primeiro, calcule o equilíbrio com tarifas atuais, instrumente tarefas reais e meça o custo por alteração aceita. Uma taxa alta não ajuda se o prompt for desnecessariamente grande ou exigir mais turnos. ## FAQ ### Qual conteúdo é mais adequado para prompt caching? Instruções de sistema estáveis, schemas de ferramentas, convenções do repositório e referências que mudam pouco são melhores que logs ao vivo ou a mensagem mais recente. ### Por que o conteúdo variável deve vir depois do prefixo estável? Caches de prefixo normalmente exigem um início idêntico. Um horário, ID ou contexto variável no começo pode invalidar todo o conteúdo estável posterior. ### Prompt caching sempre reduz a latência? Não. O efeito depende da implementação, estado do cache, rota, modelo, tamanho e carga. Meça latência separadamente do custo. ### Como calcular o ponto de equilíbrio? Compare o custo de entrada comum com escrita e leitura do cache para o reúso esperado, incluindo custo de engenharia e taxa de falha. ### Definições de ferramentas podem entrar no cache? Podem fazer parte de um prefixo repetido se o provedor e o protocolo as incluírem. Confirme nos metadados de uso em vez de presumir. ### Devo armazenar toda a conversa de programação? Normalmente não. Ela muda a cada turno. Coloque primeiro instruções e schemas estáveis e depois um checkpoint compacto e a requisição atual.