O cache de prompt do Amazon Bedrock lê um prefixo em cache com aproximadamente 90% de desconto, mas escrever no cache custa mais que um token de entrada normal, então um cache que nunca recebe um hit deixa sua conta pior, não melhor. O recurso está disponível de forma geral desde abril de 2025, e a duração de cache de uma hora lançada em janeiro de 2026 o torna útil para sessões inteiras e jobs em lote. A maioria dos times ainda deixa isso desligado, ou liga no lugar errado e paga um prêmio sem perceber. O desconto é real. Se você o captura depende inteiramente de onde você coloca o breakpoint do cache.

O modelo mental que confunde as pessoas é tratar o cache como uma aceleração gratuita que se aplica em qualquer lugar. Não é grátis. Cada checkpoint de cache é uma aposta de que os tokens antes dele serão reenviados, sem alteração, antes que o cache expire. Ganhe a aposta e você paga um décimo do preço de leitura. Perca e você pagou um prêmio de escrita por nada.

Como o preço realmente funciona

Três classes de token importam, e elas têm preços diferentes:

  • Escrita no cache: na primeira vez que o Bedrock armazena um prefixo, esses tokens são cobrados acima da taxa normal de entrada. Nos modelos da Anthropic, a escrita é cerca de 1.25x a entrada base para a duração curta de cache e cerca de 2x para a duração de uma hora.
  • Leitura do cache: toda requisição posterior que corresponde ao prefixo armazenado lê esses tokens a aproximadamente 0.1x, a economia de 90% anunciada.
  • Entrada sem cache: tudo depois do último checkpoint de cache, cobrado na taxa normal toda vez.

O prêmio de escrita é todo o jogo. Você está pagando adiantado para tornar leituras futuras baratas. O ponto de equilíbrio é simples: você precisa de hits suficientes em um prefixo em cache para recuperar o extra que pagou para escrevê-lo. Uma escrita mais uma leitura pode custar mais que duas chamadas simples. As economias só se acumulam quando o mesmo prefixo é lido muitas vezes.

Onde colocar o breakpoint

Um checkpoint de cache diz "tudo antes deste ponto está estável, armazene". Então coloque-o depois das partes do prompt que não mudam entre chamadas, e antes das partes que mudam. Em um assistente típico, essa ordem é:

[ system prompt        ]  stable
[ tool / function defs ]  stable
[ retrieved context    ]  semi-stable, per session
---- cache checkpoint here ----
[ conversation history ]  grows every turn
[ user's new message   ]  changes every turn

O system prompt e as definições de ferramentas são idênticos em toda chamada, então pertencem dentro do prefixo em cache. O novo turno do usuário nunca se repete, então pertence fora. O contexto recuperado fica no meio: coloque em cache se os mesmos documentos são reutilizados ao longo de uma sessão, deixe sem cache se cada chamada recupera algo novo. Erre essa ordem, coloque o checkpoint antes das definições de ferramentas, e você coloca em cache quase nada enquanto ainda paga para escrevê-lo.

Quando um miss custa mais que não ter cache

Hits de cache exigem uma correspondência exata no prefixo, byte a byte, e a entrada precisa ainda estar viva. Você perde a aposta de três formas comuns:

  • Você muta o prefixo. Injetar um timestamp, um ID de requisição, ou uma saudação por usuário perto do topo do system prompt muda os bytes, então toda chamada é uma escrita nova e nunca uma leitura. Este é o gol contra mais comum.
  • O tráfego é esparso demais para o TTL. Se as requisições chegam mais distantes entre si que a vida útil do cache, cada uma escreve e expira antes que a próxima chegue. A duração de uma hora ampliou muito essa janela, mas um endpoint de baixo tráfego ainda pode errar todas as vezes.
  • O prefixo está abaixo do mínimo. O Bedrock só coloca em cache prefixos acima de um piso de tokens por modelo. Um system prompt curto pode não ser cacheável de forma alguma, então o checkpoint é ignorado e você não ganha nada.

Em cada caso, você ou paga o prêmio de escrita sem leituras para amortizá-lo, ou não paga nada extra mas também não economiza nada enquanto pensa que otimizou. Ambos são piores que uma decisão consciente de deixar o cache desligado para aquele caminho.

Uma forma rápida de saber se está funcionando

Não assuma que o cache está quente. As respostas do Converse e do InvokeModel reportam contagens de tokens de leitura e escrita de cache em seus campos de uso. Registre-os e observe a proporção. Um caminho em cache saudável mostra um fluxo pequeno e constante de escritas e um volume grande de leituras. Se escritas e leituras andam juntas na proporção um para um, seu prefixo não está estável e você está pagando o prêmio por um cache que ninguém acerta. Corrija o prefixo ou desligue o checkpoint.

# usage block to watch on every response
cacheWriteInputTokens  -> should be rare after warmup
cacheReadInputTokens   -> should dominate on a hot path
inputTokens            -> only the tail after your checkpoint

A conclusão

O cache de prompt no Bedrock não é um botão que você liga para ganhar 90% de graça. É um desconto pré-pago: você paga um prêmio de escrita adiantado e o recupera através de leituras repetidas de um prefixo inalterado. Coloque o checkpoint depois do system prompt e das definições de ferramentas estáveis, mantenha qualquer coisa volátil fora da região em cache, e registre a proporção de leitura para escrita para poder provar que a aposta está compensando. Feito corretamente, é a maior economia barata disponível no Bedrock. Feito de forma descuidada, é um item de linha que piora sua conta enquanto parece uma otimização.

Leia isso a seguir

Para o playbook mais amplo de otimização de custos na AWS, as notas de campo sobre cloud estão em ercan.cloud, e o hub está em ercanermis.com.