Prompt caching reduz custo 90%. Você não está usando?

Prompt caching reduz custo 90%. Você não está usando?

Você é founder de SaaS.

Seu produto:

• Agente de IA (WhatsApp, web, Slack)
• Usa AWS Bedrock, OpenAI, ou Claude
• Você envia contexto + pergunta pro modelo (todo request)
• Seu custo: R$ 10K-50K/mês (tokens, tokens, tokens)
• Você assume: "É o custo de fazer IA. Não tem jeito."

Seu problema agora:

• AWS descobriu (ou admitiu): Prompt caching reduz custo 90%
• Method: Cache tokens que se repetem (não reprocessa)
• Math: 10.000-token contract + 50 perguntas = 500K tokens (sem cache) vs 10K tokens (com cache)
• Result: 95% redução (ou 90% no conservador)
• Your question: "Por que ninguém falou disso antes?"
• Real answer: "AWS sabe há tempo. Você não descobriu ainda."
• Your fear: "Minha margem... está 90% maior do que poderia ser?"
• Reality: "Sim. Provavelmente SIM."

A notícia que quebra o modelo de negócio (de novo):

AWS Bedrock agora oferece prompt caching (feature que existia, mas ninguém usava). Funciona assim: você envia 10K tokens de contexto (contrato, documento, sistema prompt) + 50 perguntas de clientes. Sem cache: 10K × 50 = 500K tokens pagos (contexto reprocessado 50x). Com cache: 10K tokens pagos 1x + 50 × 100 tokens (perguntas) = ~15K tokens total. Economia: 97%. AWS versão conservadora: 90%. Your implication: Você está pagando 10x mais que deveria (se não usar cache). Your action: Implemente HOJE (ganho imediato de 90% em margin).

---

O problema: você está reprocessando o mesmo contexto 1000x

Exemplo real (seu caso)

=== YOUR CURRENT ARCHITECTURE (sem cache) ===

Your SaaS use case: "Legal AI" (analisa contratos)

Workflow: ├─ Customer 1 uploads: Contract (5K tokens) ├─ Customer 1 asks: "Quais são cláusulas de confidencialidade?" (100 tokens) ├─ Your system sends to Claude/Bedrock: 5K + 100 = 5.1K tokens INPUT ├─ Claude processes: Reads contract, answers question ├─ You pay: 5.1K tokens × price │ ├─ Customer 1 asks: "Quando expira?" (50 tokens) ├─ Your system sends to Claude: 5K + 50 = 5.05K tokens INPUT (contract AGAIN) ├─ Claude processes: Reads contract (again!), answers question ├─ You pay: 5.05K tokens × price (same context, reprocessed) │ ├─ Customer 1 asks: 48 more questions (average 75 tokens each) ├─ Your system sends: 5K contract + question (every time) ├─ Claude processes: Reads contract 50 times (!) (same doc, 50x reprocessing) ├─ You pay: 5K × 50 = 250K tokens (just for contract) ├─ Plus: 50 × 75 = 3.75K tokens (questions) ├─ Total per customer: ~254K tokens │ └─ Monthly impact: ├─ 100 customers × 50 questions each = 5K questions ├─ Cost at $0.003/input token: 5K questions × 5.1K tokens = 25.5M tokens ├─ Price: 25.5M × $0.003 = R$ 76.5K/month (rough) └─ Status: "We're spending R$ 76K/month on tokens"

=== YOUR FUTURE ARCHITECTURE (com cache) ===

Same workflow, but with prompt caching:

├─ Customer 1 uploads: Contract (5K tokens) ├─ First request: Contract cached (AWS stores it) ├─ Subsequent requests: Contract NOT reprocessed (cache hit) │ ├─ Request 1: 5K contract (cached) + 100 question tokens = INPUT │ ├─ Cached tokens: 5K × $0.0003 (30% of regular price, rough) │ ├─ New tokens: 100 × $0.003 (regular price) │ ├─ Cost: (5K × $0.0003) + (100 × $0.003) = R$ 1.50 + R$ 0.30 = R$ 1.80 │ └─ vs without cache: 5.1K × $0.003 = R$ 15.30 (12x cheaper!) │ ├─ Request 2-50: Same │ ├─ Cache already warm (contract cached from request 1) │ ├─ Cost per request: ~R$ 1.80 (not R$ 15.30) │ └─ Savings: 88% per request │ └─ Monthly impact: ├─ 100 customers × 50 questions = 5K questions ├─ Cost with caching: ~5K questions × R$ 1.80 = R$ 9K/month (rough) ├─ Cost without caching: R$ 76.5K/month ├─ Savings: R$ 67.5K/month (88% reduction!) └─ Status: "We just found R$ 67.5K of 'free' margin"

=== THE MATH THAT MATTERS ===

Without prompt caching: ├─ Revenue: R$ 50K/month (100 customers × R$ 500) ├─ Cost (tokens): R$ 76.5K ├─ Operating costs (salaries, etc): R$ 30K ├─ Profit: R$ 50K - R$ 76.5K - R$ 30K = -R$ 56.5K (YOU LOSE MONEY) ├─ Runway: Bankrupt in 2-3 months └─ Status: "This business model doesn't work"

With prompt caching: ├─ Revenue: R$ 50K/month (same) ├─ Cost (tokens): R$ 9K (cached, 88% less) ├─ Operating costs: R$ 30K (same) ├─ Profit: R$ 50K - R$ 9K - R$ 30K = R$ 11K/month ├─ Runway: Infinite (profitable!) └─ Status: "This business model WORKS"

=== THE LESSON ===

Prompt caching is not a "nice to have". It's the difference between: ├─ Business dies (negative unit economics) ├─ Business survives (positive unit economics)

If your SaaS uses repeated context (like most do), you're likely: ├─ Burning money (paying 10x more tokens than needed) ├─ Losing on every customer (unit economics are broken) ├─ Not even realizing it (just "tokens are expensive")

---

Como funciona prompt caching (e por que não tem downsides)

A mecânica simples que ninguém implementou

=== WHAT IS PROMPT CACHING ===

Traditional flow: ├─ Request 1: Send [5K contract] + [question] → Model processes all ├─ Request 2: Send [5K contract] + [question] → Model processes all AGAIN ├─ Request 3: Send [5K contract] + [question] → Model processes all AGAIN ├─ Result: Contract is read 3 times (wasteful) └─ Cost: Contract tokens paid 3 times (wasteful)

With prompt caching: ├─ Request 1: Send [5K contract] + [question] │ ├─ Model processes contract │ ├─ AWS caches it: "This 5K token block stays in GPU memory" │ └─ You pay: 5K tokens (full price) ├─ Request 2: Send [same 5K contract] + [different question] │ ├─ Model recognizes: "Contract is identical to Request 1" │ ├─ AWS retrieves from cache: "Don't reprocess, use cached version" │ └─ You pay: 5K tokens × 30% (cache price) = 1.5K token cost ├─ Request 3: Same as Request 2 (cache hit) │ └─ You pay: 5K tokens × 30% (cache price) = 1.5K token cost └─ Result: Contract is read 1 time, cached for future (efficient)

=== THE MAGIC NUMBER: 90% cost reduction ===

When does caching save 90%? ├─ Large static context (contracts, documents, system prompts) ├─ Many questions against same context (typical SaaS pattern) ├─ Example: │ ├─ Context: 10K tokens (contract, rules, system prompt) │ ├─ Questions: 50 × 100 tokens each = 5K tokens │ ├─ Without cache: (10K × 50) + 5K = 505K tokens │ ├─ With cache: 10K (first request) + (10K × 0.3) × 49 (cache hits) + 5K = ~160K tokens │ ├─ Savings: (505K - 160K) / 505K = 68% (conservative) │ └─ Real world (with more questions): 90%+ savings

=== WHO BENEFITS MOST ===

Best use cases for prompt caching: ├─ ☑ Legal AI (contract analysis, repeated document) ├─ ☑ Medical AI (medical records, repeated per patient) ├─ ☑ Customer support (company docs, repeated per chat) ├─ ☑ Recruiting AI (job descriptions, repeated per application) ├─ ☑ E-commerce AI (product catalog, repeated per search) ├─ ☑ Accounting AI (financial rules, repeated per document) ├─ ☑ Any SaaS with: Large static context + many questions └─ ☑ Most of us (if you use prompts+context, you benefit)

Worst use cases: ├─ ☒ One-off questions (no repeated context) ├─ ☒ Constantly changing context (can't reuse cache) ├─ ☒ Very small context (not worth caching overhead) └─ ☒ Single-turn conversations (no repetition)

=== DOWNSIDE #1: Cache TTL (Time To Live) ===

Cached prompts expire after: ├─ AWS Bedrock: Typically 5 minutes (enough for most requests) ├─ OpenAI: Similar (cache lasts per conversation) ├─ Claude: Similar ├─ Implication: If customer doesn't ask another question in 5min, cache clears ├─ Solution: Doesn't matter (next customer loads it again, or same customer resumes) └─ Impact: Minimal (most usage patterns have <5min between requests)

=== DOWNSIDE #2: Latency ===

Cached requests might have slight latency overhead: ├─ First request: Normal latency (no cache) ├─ Cache write: Takes ~100ms extra (write to cache) ├─ Subsequent requests: Faster (cache hit, less work) ├─ Net result: First request slightly slower, rest faster ├─ Implication: Negligible for most SaaS └─ Worth it: 100ms extra for 90% cost savings? Yes.

=== DOWNSIDE #3: Setup complexity ===

Do you need to rewrite your SaaS? ├─ If using AWS Bedrock: Just set cache_control parameter (API flag) ├─ If using OpenAI: Supported in latest API ├─ If using Claude: Also supported ├─ Effort: ~4 hours of engineering (configure + test) └─ Worth it: 90% cost savings for 4 hours of work? Yes.

=== REAL DOWNSIDE: None (seriously) ===

Prompt caching has no real downside if: ├─ You have repeated context (most SaaS do) ├─ You're willing to implement (~4 hours) ├─ You're not storing secrets in cached prompts (obvious) └─ You're comfortable with 5-min cache expiry

If all above: ZERO downside, pure upside (90% cost reduction).

---

Implementação (é mais fácil do que você pensa)

Passo a passo real em 1 dia

=== AWS BEDROCK EXAMPLE ===

Before (without cache): python client = boto3.client('bedrock-runtime')

response = client.converse( modelId='anthropic.claude-3-5-sonnet-20241022-v2:0', messages=[ { 'role': 'user', 'content': f""" Contract: {contract_text} # 5K tokens every time! Question: {user_question} # User's actual question """ } ] )

After (with cache): python client = boto3.client('bedrock-runtime')

First request: cache the contract

response = client.converse( modelId='anthropic.claude-3-5-sonnet-20241022-v2:0', system=[ { 'text': system_prompt, # Your company rules 'cache_control': {'type': 'ephemeral'} # Cache this }, { 'text': contract_text, # Large document 'cache_control': {'type': 'ephemeral'} # Cache this too } ], messages=[ { 'role': 'user', 'content': user_question # Only send question (not contract) } ] )

Second request: cache hit! (no contract reprocessing)

response = client.converse( # Same system + contract (cached from previous request) # Model recognizes cache hit, uses cached version instead # You only pay for: system + contract × 0.3 (cache price) + new question )

=== KEY CHANGES ===

1. Add cache_control parameter to static content python 'cache_control': {'type': 'ephemeral'} # Cache it

2. Put contract/system prompt in system parameter (not in messages) python system=[ # Use system parameter for cached content {'text': contract, 'cache_control': {'type': 'ephemeral'}}, {'text': rules, 'cache_control': {'type': 'ephemeral'}} ]

3. Put questions in messages (these are new each time) python messages=[ # These are NOT cached (change each request) {'role': 'user', 'content': user_question} ]

=== IMPLEMENTATION CHECKLIST ===

☐ Identify your static context ├─ What doesn't change? (contracts, docs, system prompts, company rules) ├─ List them: "System prompt (always), Customer docs (per-customer, stays same across requests)" └─ Action: Write them down

☐ Identify your dynamic content ├─ What changes every request? (user questions, inputs, variables) ├─ List them: "User question, user input, current conversation" └─ Action: Write them down

☐ Restructure your API calls ├─ Move static → system parameter (add cache_control) ├─ Move dynamic → messages parameter (no cache_control) ├─ Test: Does it still work? └─ Action: Update 5-10 API calls

☐ Measure the impact ├─ Before: Log token usage (input tokens per request) ├─ After: Implement cache, log token usage again ├─ Compare: (Before - After) / Before = savings % ├─ Expected: 70-90% reduction (if use case matches) └─ Action: Run A/B test for 1 week

☐ Deploy to production ├─ After A/B test confirms savings: Deploy to all customers ├─ Monitor: Cache hit rate, latency, cost ├─ Celebrate: You just found 70-90% of "free" margin └─ Action: Update pricing/margins in financial model

☐ Update your SaaS metrics ├─ Cost per request: Updated (90% lower) ├─ Unit economics: Updated (now profitable) ├─ Gross margin: Updated (90% improvement) ├─ Runway: Updated (if was 2 months, now 20 months) └─ Action: Update investor deck, celebrate with team

=== IMPLEMENTATION TIME ===

Estimate: 1 day total ├─ Hour 0-1: Understanding (read this post) ├─ Hour 1-3: Coding (restructure API calls) ├─ Hour 3-4: Testing (verify cache works) ├─ Hour 4-6: A/B testing (measure impact) ├─ Hour 6-8: Monitoring + deploy (watch metrics) └─ Total: ~8 hours (1 engineer, 1 day)

ROI: ├─ Effort: 8 hours (one engineer, one day) ├─ Benefit: 70-90% cost reduction (recurring, forever) ├─ Monthly savings: R$ 50K-70K (depending on your usage) ├─ Yearly savings: R$ 600K-840K ├─ ROI: (R$ 600K savings) / (R$ 2K engineer cost for 1 day) = 300x └─ Decision: Do this TODAY (highest ROI engineering project)

---

Conclusão: Prompt caching é "free money" que ninguém pega

O que aconteceu:

• AWS (e OpenAI, Claude) lançaram prompt caching
• Reduz custo de tokens em 70-90%
• Ninguém está usando (ainda)
• SaaS builders estão pagando 10x mais que deveria

Por que ninguém sabe:

• AWS não fez marketing agressivo (quiet launch)
• OpenAI também silencioso (feature existia, poucos sabem)
• Developers não investem tempo em otimização (foco em features)
• CFOs não pesquisam (assumem token cost é fixo)
• Resultado: Dinheiro desperdiçado (invisível)

O que você deveria fazer:

1. Today: Identifique seu contexto estático (contrato, docs, prompts)
2. This week: Implementar cache_control (4 horas de coding)
3. Next week: Medir impacto (90% redução esperada)
4. Next month: Deploy para todos clientes + celebre
5. Ongoing: Margin melhora 70-90% (sem esforço, apenas implementação)

Na OpenClaw:

Ajudamos SaaS builders otimizar token economics em era de AI:

• Cache Implementation: Estruturar seu SaaS pra aproveitar cache (Engineering)
• Token Cost Analysis: Onde você está desperdiçando? Quanto economiza? (Financial)
• Architecture Review: É seu contexto bom para cache? (Product)
• Monitoring Setup: Rastrear cache hit rate, token savings (Operations)
• Margin Recalculation: Como muda seu unit economics? (Financial)

Você quer reclamar R$ 50-70K/mês de margin que já está lá (apenas não está sendo usada)?

Cache Implementation Audit | Token Cost Analysis | Architecture Review →