📋 Prompts listos (copy-run)

Objetivo

Enumera cada byte variable que impide la caché en tu pipeline, priorizado por impacto.

Prompt (cópialo y cambia <…>)

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.

Cómo verificar

Aplica las correcciones y ejecuta dos solicitudes iguales. En el usage, cache_read_input_tokens debe dejar de ser 0 a partir de la 2.ª. Si aún aparece 0, quedó un invalidator: usa el Prompt 4.

Objetivo

Garantizar que la lista de tools siempre salgan en el mismo orden entre solicitudes.

Prompt (cópialo y cambia <…>)

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).

Cómo verificar

Lanza dos requests iguales: cache_read_input_tokens pasa a ser > 0 en la 2.ª. Antes de la corrección, seguía en 0 aunque se repitiera el mismo prompt.

Objetivo

Compara el costo por turno de cargar el contexto actual con el costo único de compactar, y recomienda.

Prompt (cópialo y cambia <…>)

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.

Cómo verificar

La recomendación debe seguir el criterio del módulo 3.1: contexto pequeño / pocos turnos → continuar (conserva el caché caliente); contexto grande, cerca del límite o con calidad en descenso → compactar (se recupera la inversión en ~1 turno).

Objetivo

Encontrar el primer byte que cambia entre dos requests iguales y su origen.

Prompt (cópialo y cambia <…>)

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>.

Cómo verificar

Después del fix, vuelve a comparar los dos prefijos: debe quedar vacío. Entonces cache_read_input_tokens empieza a subir con cada turno repetido.

Objetivo

Quitar toda interpolación dinámica del system y devolverla como bloque listo para el final de las messages.

Prompt (cópialo y cambia <…>)

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.

Cómo verificar

Después del cambio, el system queda idéntico byte por byte entre requests. El caché de tools + system deja de invalidar y cache_read_input_tokens cubre este fragmento.

Objetivo

Decidir dónde colocar los cache_control y evitar el fallo del 20-block lookback.

Prompt (cópialo y cambia <…>)

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.

Cómo verificar

cache_read_input_tokens se mantiene alto y estable turno a turno. Si algún turno con muchos bloques reduce el read a 0, faltó el breakpoint intermedio del lookback.