📋 Prompts prontos (copy-run)

Objetivo

Listar cada byte de variação que impede o cache no seu pipeline, priorizado por impacto.

Prompt (copie e troque <…>)

Audite o prompt caching do meu pipeline em <caminho/do/projeto>.
Varra TUDO que alimenta o prefixo (a lista de `tools`, o `system` e o
começo estável das `messages`) e liste cada silent invalidator:
- datetime.now() / Date.now() / uuid / id aleatório no prefixo;
- json.dumps sem sort_keys=True;
- iteração de set (ordem não garantida);
- tools montadas por usuário/modo;
- seção condicional no system (if flag: system += ...).
Para cada achado, dê: arquivo, linha, por que quebra o cache e o fix mínimo.
Ordene por impacto — o que fica mais na FRENTE do prefixo primeiro.

Como verificar

Aplique os fixes e rode duas requisições iguais. No usage, cache_read_input_tokens deve deixar de ser 0 a partir da 2ª. Se ainda vier 0, sobrou um invalidator — use o Prompt 4.

Objetivo

Garantir que a lista de tools saia sempre na mesma ordem entre requests.

Prompt (copie e troque <…>)

Em <caminho/do/arquivo>, a lista de `tools` é montada assim:
<cole aqui o trecho que monta as tools>
Reescreva pra serialização ficar DETERMINÍSTICA:
1) ordene as tools por nome antes de enviar
   (ex.: sorted(tools, key=lambda t: t["name"]));
2) garanta que cada objeto interno saia ordenado
   (json.dumps(..., sort_keys=True));
3) confirme que a ordem é IDÊNTICA entre dois requests.
Mostre o diff e explique por que isso preserva o prefixo (posição 0).

Como verificar

Dispare dois requests iguais: cache_read_input_tokens passa a ser > 0 no 2º. Antes da correção, ele ficava 0 mesmo repetindo o mesmo prompt.

Objetivo

Comparar o custo por turno de carregar o contexto atual com o custo único de compactar, e recomendar.

Prompt (copie e troque <…>)

Estou com um contexto de ~<N> tokens e ainda faltam ~<M> turnos.
Compare os dois caminhos (use read≈0,1× · write 5min≈1,25×):
(a) CONTINUAR sem compactar: custo por turno = N @ 0,1× ≈ N/10-equiv,
    repetido em todos os <M> turnos;
(b) COMPACTAR pra ~<K> tokens: 1 write frio K @ 1,25× (uma vez) e
    depois K @ 0,1× por turno.
Diga o payback (em quantos turnos a compactação se paga) e recomende
compactar OU continuar — considerando também o teto de 1M e a qualidade
(context rot). Se a conversa for curta, avise que continuar pode ser melhor.

Como verificar

A recomendação deve seguir a régua do módulo 3.1: contexto pequeno / poucos turnos → continuar (preserva o cache quente); contexto grande, perto do teto ou qualidade caindo → compactar (payback em ~1 turno).

Objetivo

Achar o primeiro byte que muda entre dois requests iguais e a sua origem.

Prompt (copie e troque <…>)

Meu cache_read_input_tokens vem SEMPRE 0 repetindo o MESMO prompt.
Capture os bytes exatos do prefixo (tools + system + começo das messages)
de DOIS requests consecutivos e faça o diff entre eles.
Aponte o PRIMEIRO ponto que difere e explique a origem
(relógio/datetime.now(), uuid, ordem de set/dict, json.dumps sem sort_keys,
seção condicional no system). Proponha o fix determinístico.
Arquivos que montam o prefixo: <cole os caminhos>.

Como verificar

Depois do fix, refaça o diff dos dois prefixos: ele deve ficar vazio. Aí cache_read_input_tokens passa a subir a cada turno repetido.

Objetivo

Tirar toda interpolação dinâmica do system e devolvê-la como bloco pronto pro fim das messages.

Prompt (copie e troque <…>)

Aqui está meu system prompt:
<cole o system prompt inteiro>
Remova TODA interpolação dinâmica dele (data/hora, nome do usuário, modo,
e qualquer valor que muda entre requests) e mova esse contexto pro FIM
das messages — nunca no system. Devolva:
1) o system CONGELADO (fixo, sem variáveis);
2) o bloco de contexto dinâmico pronto pra ir nas messages;
3) o diff comentado, explicando por que cada mudança preserva o prefixo.

Como verificar

Depois da troca, o system fica idêntico byte a byte entre requests. O cache de tools + system para de invalidar e cache_read_input_tokens cobre esse trecho.

Objetivo

Decidir onde posicionar os cache_control e evitar o furo do 20-block lookback.

Prompt (copie e troque <…>)

Meu prompt tem esta estrutura:
<descreva: tamanho do system; se as tools mudam; se há um trecho
 compartilhado seguido de um sufixo que varia por request>
Sugira onde colocar os cache_control (MÁX. 4 por request). Tipicamente:
- no fim do `system` estável;
- no fim do maior trecho COMPARTILHADO, antes da parte variável.
Alerte sobre o 20-block lookback: se um turno adiciona >20 blocos
(loops com muitos tool_use/tool_result), proponha um breakpoint
intermediário (~a cada 15 blocos). Explique cada escolha.

Como verificar

cache_read_input_tokens fica alto e estável turno a turno. Se algum turno com muitos blocos derruba o read pra 0, faltou o breakpoint intermediário do lookback.