O Custo Invisível de Cada Chamada

Imagine que toda vez que você abre uma reunião, o assistente lê em voz alta todas as regras da empresa antes de começar. Duzentas páginas. Todo dia. Em cada reunião. Mesmo que todo mundo já saiba o que está escrito ali.

Parece absurdo. Mas é exatamente o que acontece na maioria das soluções de IA construídas com Claude via API. A cada chamada, o mesmo contexto, as mesmas instruções, os mesmos documentos de referência são enviados e reprocessados do zero. Como se Claude nunca tivesse visto aquilo antes.

O custo disso não aparece em um único item da fatura. Ele se acumula silenciosamente, chamada por chamada, até virar um número que ninguém consegue explicar.

Existe uma solução. E ela tem tudo a ver com a forma como Gambito joga suas cartas.

O Mutante Que Nunca Desperdiça Energia

Gambito não é o mutante mais forte dos X-Men. Não tem o adamantium de Wolverine, a telepatia de Xavier nem o controle climático de Tempestade. O que ele tem é algo mais raro: a capacidade de carregar energia cinética em qualquer objeto e liberá-la no momento exato, sem desperdício.

Ele não recarrega uma carta que já está carregada. Não gasta energia nova no que já foi processado. Cada joule é aplicado uma vez, com precisão, e reutilizado ao máximo antes de ser descartado.

É exatamente assim que funciona o Prompt Caching da API do Claude.

Em qualquer solução construída com Claude via API, a maior fonte de custo invisível não é a resposta que Claude gera. É o contexto que você envia em cada chamada: o system prompt com as regras do negócio, o documento que está sendo analisado, o histórico da conversa. Tudo isso é reprocessado do zero a cada requisição, como se Gambito recarregasse cada carta antes de cada jogada.

O Prompt Caching resolve isso. Você carrega o contexto uma vez, ele fica armazenado, e nas chamadas seguintes Claude lê do cache a uma fração do custo original. A carta já está carregada. É só jogar.

O Problema Que Ninguém Vê na Fatura

Para entender o impacto do Prompt Caching, é preciso entender como a API do Claude funciona por baixo.

A API do Claude é stateless: cada chamada é processada do zero, sem memória das anteriores. Isso significa que se você tem um system prompt de 5.000 tokens descrevendo as regras de negócio da sua solução, esses 5.000 tokens são enviados e reprocessados em cada chamada.

Imagine uma solução de atendimento ao cliente que recebe 10.000 conversas por dia. Em cada conversa, o system prompt de 5.000 tokens é reprocessado. Isso é 50 milhões de tokens de entrada só de contexto repetido, todo dia, pagos na mesma tarifa que os tokens novos.

Ou imagine um agente de análise de documentos que lê um contrato de 50.000 tokens e responde dez perguntas diferentes sobre ele. Sem caching, o contrato é reprocessado dez vezes. Com caching, ele é processado uma vez e lido nove vezes a 10% do custo.

Gambito não relança as mesmas cartas do zero. Ele mantém as que já estão carregadas e usa a energia onde ela ainda não foi aplicada.

Como o Prompt Caching Funciona na Prática

O mecanismo é direto. Quando o time de engenharia faz a primeira chamada à API com um bloco de conteúdo marcado para cache, a Anthropic processa e armazena aquele conteúdo. Nas chamadas seguintes que usam o mesmo conteúdo, Claude lê do cache em vez de reprocessar.

A estrutura de preços reflete exatamente esse comportamento:

A primeira chamada que cria o cache custa 1,25x o preço normal de tokens de entrada para cache de 5 minutos, ou 2x para cache de 1 hora. É o custo de carregar a carta.

As chamadas seguintes que leem do cache custam apenas 10% do preço normal de tokens de entrada. É o custo de reutilizar a carta já carregada.

O break-even é imediato: com cache de 5 minutos, a segunda chamada já paga o custo de escrita e começa a gerar economia. Com cache de 1 hora, a economia começa na terceira chamada.

Na prática, para um agente que recebe 100 chamadas com o mesmo system prompt de 10.000 tokens usando o Claude Sonnet 4.6:

Sem cache: 100 chamadas × 10.000 tokens × $3/MTok = $3,00 Com cache: 1 escrita (12.500 tokens × $3/MTok = $0,038) + 99 leituras (10.000 tokens × $0,30/MTok = $0,297) = $0,34

Uma redução de 88% no custo de entrada com uma mudança de implementação que leva menos de uma hora.

Como Fica no Código: O Mínimo que o Time Precisa Implementar

Para quem vai cobrar do time de engenharia, é importante entender o que a implementação envolve. É uma mudança pequena e cirúrgica: adicionar o parâmetro cache_control no bloco de conteúdo que deve ser cacheado.

Veja a diferença entre uma chamada sem cache e uma com cache para um agente de monitoramento de pipelines do Microsoft Fabric:

Sem cache — contexto reprocessado a cada chamada:

import anthropic

client = anthropic.Anthropic()

# System prompt com regras do agente: reprocessado em CADA chamada
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system="""Você é um agente de monitoramento de pipelines do Microsoft Fabric.
    Analise o status reportado e classifique a severidade seguindo estas regras:
    - CRÍTICO: pipeline com falha que afeta dados de produção em Gold
    - ALTO: pipeline com falha em Silver com impacto em relatórios
    - MÉDIO: pipeline com falha em Bronze sem impacto imediato
    - BAIXO: alertas de performance sem falha confirmada
    Sempre inclua: severidade, diagnóstico provável e próximo passo recomendado.""",
    messages=[
        {"role": "user", "content": f"Status do pipeline: {status_pipeline}"}
    ]
)

Com cache — system prompt carregado uma vez, reutilizado nas demais:

import anthropic

client = anthropic.Anthropic()

# System prompt cacheado: processado apenas na primeira chamada
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": """Você é um agente de monitoramento de pipelines do Microsoft Fabric.
            Analise o status reportado e classifique a severidade seguindo estas regras:
            - CRÍTICO: pipeline com falha que afeta dados de produção em Gold
            - ALTO: pipeline com falha em Silver com impacto em relatórios
            - MÉDIO: pipeline com falha em Bronze sem impacto imediato
            - BAIXO: alertas de performance sem falha confirmada
            Sempre inclua: severidade, diagnóstico provável e próximo passo recomendado.""",
            "cache_control": {"type": "ephemeral"}  # ← essa linha ativa o cache
        }
    ],
    messages=[
        {"role": "user", "content": f"Status do pipeline: {status_pipeline}"}
    ]
)

# Verificando se o cache está funcionando
uso = response.usage
print(f"Tokens escritos no cache: {uso.cache_creation_input_tokens}")
print(f"Tokens lidos do cache: {uso.cache_read_input_tokens}")

A diferença é uma linha: “cache_control”: {“type”: “ephemeral”}. O resto da lógica não muda. Para o time de engenharia, essa é uma das otimizações de maior retorno por menor esforço no ecossistema Claude.

Um Caso Real: Agente de Qualidade de Dados no Fabric

Para tornar o impacto concreto, considere um agente de qualidade de dados construído sobre o Microsoft Fabric. Ele monitora tabelas da camada Silver, detecta anomalias e gera alertas para o time de dados.

O agente tem um system prompt de 8.000 tokens com as regras de qualidade, thresholds aceitáveis por domínio de dados, padrões de nomenclatura e formato esperado de alertas. Ele roda 500 verificações por dia, uma para cada tabela monitorada.

Sem Prompt Caching: 500 chamadas × 8.000 tokens × $3/MTok = $12,00/dia = $360/mês só de context repetido.

Com Prompt Caching: 1 escrita (10.000 tokens × $3/MTok = $0,03) + 499 leituras (8.000 tokens × $0,30/MTok = $1,197) = $1,23/dia = $36,90/mês

Uma economia de $323/mês com uma linha de código adicionada ao system prompt. Em um ano, são mais de $3.800 economizados em um único agente.

E esse é um cenário conservador. Agentes de maior volume, com system prompts mais longos ou que processam documentos extensos, têm economias proporcionalmente maiores.

O Que Pode e O Que Não Pode Ser Cacheado

Gambito sabe que nem todo objeto vale a pena carregar. Cartas pequenas demais não acumulam energia suficiente para justificar o gesto. O mesmo raciocínio se aplica ao Prompt Caching.

Candidatos ideais para cache:

O system prompt é o candidato mais óbvio. Se a solução tem um conjunto fixo de instruções, regras de negócio ou personas que acompanham cada chamada, esse conteúdo deve ser cacheado. Ele nunca muda entre chamadas, mas é reprocessado em cada uma delas.

Documentos de referência são outro candidato poderoso. Um agente que analisa especificações técnicas, contratos de dados ou documentação de APIs pode cachear esse conteúdo e fazer múltiplas perguntas sem reprocessar a cada pergunta.

Definições de ferramentas em sistemas agenticos com muitas tools também se beneficiam. Se o agente tem 20 ferramentas definidas e usa apenas 3 em cada chamada, cachear todas as definições evita reprocessamento constante.

Quando o cache não compensa:

Conteúdo que muda a cada chamada não pode ser cacheado de forma eficiente. Se o contexto varia significativamente entre requisições, não há cache hit e você paga o custo de escrita sem o benefício da leitura.

O conteúdo também precisa ter no mínimo 1.024 tokens para ser elegível ao cache nos modelos Sonnet e Haiku. Blocos menores são processados normalmente sem erro, mas sem cache.

Como um Arquiteto Deve Cobrar Isso do Time

Você não precisa implementar o Prompt Caching. Mas precisa saber quando exigi-lo e como validar que está funcionando.

As perguntas certas para o time de engenharia:

“O system prompt da solução está sendo cacheado?” Esta é a pergunta mais básica. Se a resposta for não, ou se o time não souber responder, há uma oportunidade imediata de redução de custo.

“Qual é a proporção de cache hits versus cache misses nas chamadas de produção?” A API retorna métricas de cache em cada resposta: cache_creation_input_tokens para escritas e cache_read_input_tokens para leituras. Um dashboard monitorando essa proporção é o mínimo esperado de qualquer solução em produção.

“Qual é o TTL configurado: 5 minutos ou 1 hora?” Para soluções com alto volume de chamadas em janelas curtas, o cache de 5 minutos geralmente é suficiente e mais barato de escrever. Para soluções com picos espaçados, o cache de 1 hora garante que o contexto permaneça disponível entre os picos.

O sinal de que o cache não está funcionando:

Se o custo por chamada não cai conforme o volume aumenta, o cache provavelmente não está ativo ou está sendo invalidado. Em uma solução saudável com Prompt Caching, o custo marginal de cada chamada adicional deve cair progressivamente à medida que o cache é reutilizado.

Prompt Caching e Batch API: A Combinação Que Muda o Jogo

O Prompt Caching não existe isolado. Combinado com a Batch API da Anthropic, o potencial de redução de custo sobe para até 95%.

A Batch API processa requisições de forma assíncrona com desconto de 50% em todos os tokens. Para workloads que não precisam de resposta em tempo real, como geração de relatórios, classificação em lote, análise de documentos ou enriquecimento de dados, a combinação Batch API + Prompt Caching entrega o custo mais baixo possível no ecossistema Claude.

A lógica é simples: Batch API reduz o custo de saída e entrada padrão em 50%. Prompt Caching reduz o custo de entrada repetida em 90%. Aplicados juntos em workloads elegíveis, o resultado é uma fração mínima do custo original.

Gambito não escolhe apenas a carta certa. Ele escolhe o momento certo para jogá-la.

Quando Exigir Prompt Caching em uma Solução

Para um arquiteto avaliando ou revisando uma solução que usa Claude via API, o Prompt Caching deve ser requisito em qualquer cenário onde:

O system prompt tem mais de 1.024 tokens e é enviado em todas as chamadas. O volume de chamadas é superior a 10 por hora com o mesmo contexto base. A solução analisa documentos grandes com múltiplas perguntas na mesma sessão. O agente tem muitas ferramentas definidas que são carregadas em cada chamada. O custo de API está crescendo proporcionalmente ao volume sem redução marginal.

Se esses critérios estão presentes e o Prompt Caching não está implementado, a solução está pagando full price pelo que já devia estar no cache. São as cartas de Gambito sendo recarregadas do zero antes de cada jogada.

Conclusão: A Energia Certa no Momento Certo

O que torna Gambito letal não é a quantidade de energia que ele tem. É a precisão com que ele a aplica. Carregar uma carta uma vez e usá-la múltiplas vezes é mais eficiente do que recarregar antes de cada jogada.

O Prompt Caching é a implementação direta dessa filosofia em soluções com Claude. O contexto que não muda não precisa ser reprocessado. A energia, nesse caso o custo de tokens, deve ser aplicada onde realmente há algo novo a processar.

Para líderes e arquitetos que estão levando Claude para produção, essa não é uma otimização opcional. É uma decisão de arquitetura com impacto direto na viabilidade econômica da solução. Uma solução de alto volume sem Prompt Caching é como Gambito jogando todas as cartas sem ter carregado nenhuma delas.

O custo será sempre maior do que deveria.

Referências