Claude para Indie Hackers: o guia completo de quem usa de verdade
Do básico ao avançado — modelos, API, Claude Code, MCP, prompt engineering e hacks reais para extrair o máximo do ecossistema Claude em 2026. O único guia que você precisa.
Alienhub Team
AI Engineering
A maioria dos guides de Claude ensina a usar o chat. Esse não é um desses.
Este é o guia que a gente queria ter quando começou a construir produtos reais com Claude. Cobre tudo: a hierarquia dos modelos, como a API funciona de verdade, prompt engineering que vai além do básico, Claude Code, MCP, hacks de custo, e padrões de arquitetura que a gente viu funcionar (e quebrar) em produção.
Se você é indie hacker ou founder de SaaS usando IA como alavanca — esse é o seu manual.
O ecossistema Claude: mapa antes de entrar
Claude não é só um chatbot. É um ecossistema com camadas distintas:
- Claude.ai — interface de chat, Projects, memória, Artifacts. O lugar onde a maioria para.
- Anthropic API — acesso programático direto aos modelos. É aqui que você constrói produto.
- Claude Code — CLI de agente de código que roda no terminal. Delega tarefas de dev inteiras.
- MCP (Model Context Protocol) — protocolo aberto para conectar Claude a qualquer ferramenta ou dado.
- Cowork — desktop app para automação de arquivos e tarefas. Ainda em preview.
A maioria dos indie hackers usa Claude.ai e acha que sabe o que Claude pode fazer. Está errado em aproximadamente 80% das capacidades.
Os modelos: qual usar quando
Em 2026, a família Claude tem três modelos principais com trade-offs radicalmente diferentes.
Claude Opus 4.6
O modelo mais capaz da linha. Use quando o problema é genuinamente difícil — raciocínio complexo, análise profunda, decisões de arquitetura, tarefas que exigem nuance.
O Opus pensa mais devagar e custa mais. Em produção, isso significa que você não vai usá-lo pra cada request. Mas para tarefas críticas onde qualidade importa mais do que velocidade, é onde você quer estar.
Casos de uso certos: análise de código complexo, geração de conteúdo de alta qualidade, raciocínio jurídico/financeiro, decisões de produto que precisam de perspectiva ampla.
Claude Sonnet 4.6
O cavalo de trabalho do ecossistema. Equilíbrio entre capacidade, velocidade e custo que faz dele o padrão pra maioria dos casos de uso em produção.
A regra de ouro: se você está em dúvida sobre qual modelo usar, use Sonnet. Ele resolve 80% dos casos de uso do Opus a uma fração do custo.
Casos de uso certos: geração de conteúdo, customer support bot, code review, extração de dados, a maioria dos agentes, análises de dados.
Claude Haiku 4.5
Rápido. Barato. Surpreendentemente capaz em tarefas focadas.
Haiku é o modelo que você usa quando velocidade e custo são críticos e o problema é bem definido. Classificação, extração simples, respostas curtas, pré-filtros antes de uma chamada mais cara.
Casos de uso certos: classificação de intent, extração de campos específicos, sumarização de textos curtos, qualquer pipeline de alto volume onde Sonnet seria caro demais.
A tabela real
| Modelo | Token Input | Token Output | Velocidade | Quando usar |
|---|---|---|---|---|
| Opus 4.6 | $$$ | $$$ | Lento | Tarefas críticas, raciocínio complexo |
| Sonnet 4.6 | $$ | $$ | Médio | Produção geral, agentes, conteúdo |
| Haiku 4.5 | $ | $ | Rápido | Alto volume, tarefas simples, filtros |
Regra de decisão: comece com Sonnet. Suba para Opus se qualidade não é suficiente. Desça para Haiku se custo/latência estão quebrando o produto.
Claude.ai: o que a maioria não usa
A interface web tem mais do que parece.
Projects
Projects é memória persistente com contexto customizável. Você cria um projeto, sobe documentos (arquivos, links, código), escreve instruções e o Claude carrega tudo isso automaticamente em cada conversa.
Para indie hacker, isso significa:
- Projeto "Meu SaaS": sobe a documentação do produto, exemplos de copy, guias de estilo. Toda vez que você pedir ajuda com o produto, Claude já tem o contexto.
- Projeto "Customer Support": coloca FAQ, políticas, docs de produto. Usa pra rascunhar respostas rapidamente.
- Projeto "Código Base": sobe os arquivos mais relevantes do seu codebase. Pede review sem ter que re-explicar a arquitetura toda vez.
O limite de contexto de Projects é absurdamente generoso. Use.
Artifacts
Artifacts são outputs que vivem fora da conversa — arquivos de código, documentos, visualizações — que você pode editar, exportar e iterá-los diretamente.
O que muda na prática: em vez de receber uma resposta de texto com código que você copia para o editor, você recebe um arquivo editável dentro da interface. Você pode pedir pra Claude editar diretamente, sem re-copiar.
Para founders: use Artifacts pra gerar landing pages (HTML completo), scripts de automação, templates de email, relatórios. A iteração fica muito mais rápida.
Memória
Claude.ai tem memória de usuário que persiste entre conversas. Você pode deixar explícito o que quer que Claude lembre:
"Sempre que eu pedir análise de código, assuma que estou usando Node.js com TypeScript e prefiro async/await a promises em cadeia."
Isso não é RAG. É mais simples — é memória de preferências. Mas economiza dezenas de linhas de contexto em cada conversa.
A API: do zero ao primeiro request útil
A API da Anthropic é onde você para de usar Claude e começa a construir com Claude.
Setup
pip install anthropic
import anthropic
client = anthropic.Anthropic(api_key="sua-chave-aqui")
message = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[
{"role": "user", "content": "Explique o conceito de MRR em 3 frases."}
]
)
print(message.content[0].text)
Isso é o básico. Mas o básico não é o que você precisa saber — você precisa saber como extrair o máximo.
System prompts que funcionam
O system prompt é onde você define quem o Claude é nessa instância. A maioria usa mal. Dois erros comuns:
Erro 1: System prompt vazio ou genérico ("Você é um assistente útil"). Erro 2: System prompt de 10 páginas com instruções contraditórias.
O que funciona: system prompt cirúrgico, com persona clara, contexto de tarefa e formato de output.
system_prompt = """Você é um analista de dados sênior especializado em métricas de SaaS.
Contexto: você trabalha para founders de early-stage que precisam interpretar dados de produto rapidamente.
Suas respostas devem:
- Ser diretas e acionáveis
- Incluir sempre uma recomendação concreta
- Usar números quando disponíveis
- Sinalizar quando um número parece fora do padrão do setor
Formato: responda em prosa, não use bullet points a menos que seja uma lista de ações."""
Tool use (function calling)
Tool use é o que transforma Claude de chatbot em agente. Você define funções que Claude pode chamar, e ele decide quando usá-las.
tools = [
{
"name": "buscar_dados_cliente",
"description": "Busca dados de um cliente pelo email no banco de dados",
"input_schema": {
"type": "object",
"properties": {
"email": {
"type": "string",
"description": "Email do cliente"
}
},
"required": ["email"]
}
},
{
"name": "criar_ticket_suporte",
"description": "Cria um ticket de suporte no sistema",
"input_schema": {
"type": "object",
"properties": {
"titulo": {"type": "string"},
"descricao": {"type": "string"},
"prioridade": {"type": "string", "enum": ["baixa", "media", "alta", "critica"]}
},
"required": ["titulo", "descricao", "prioridade"]
}
}
]
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
tools=tools,
messages=[{
"role": "user",
"content": "O cliente joao@empresa.com está com erro ao fazer login há 2 dias."
}]
)
# Claude vai chamar buscar_dados_cliente e depois criar_ticket_suporte
# com a prioridade correta inferida do contexto
O que é poderoso aqui: Claude infere contexto. Ele não espera você dizer "prioridade alta" — ele lê "2 dias sem conseguir logar" e conclui sozinho.
Streaming
Para qualquer interface com usuário, streaming é obrigatório. Sem ele, o usuário fica olhando pra tela vazia esperando.
with client.messages.stream(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}]
) as stream:
for text in stream.text_stream:
print(text, end="", flush=True)
Streaming não só melhora UX — também faz seu produto parecer mais rápido mesmo quando não é. Primeira palavra aparece em 200-500ms enquanto o modelo continua gerando.
Prompt engineering específico para Claude
Claude responde de forma diferente de outros modelos. Algumas técnicas que funcionam especificamente com ele.
XML tags para estrutura
Claude foi treinado com XML e responde melhor quando você usa XML para estruturar o prompt. Não é mito — é observável.
Em vez de:
"Analise o texto abaixo e diga o sentimento, os pontos principais e uma recomendação de ação."
Texto: [texto]
Use:
<tarefa>
Analise o texto abaixo e produza:
1. Sentimento (positivo/neutro/negativo com score 1-10)
2. Pontos principais (máximo 3)
3. Recomendação de ação concreta
</tarefa>
<texto>
{texto_aqui}
</texto>
<formato_output>
Responda em JSON com campos: sentimento, score, pontos_principais, recomendacao
</formato_output>
A diferença na consistência do output é real.
Extended thinking
Claude Sonnet 4.6 e Opus 4.6 suportam "extended thinking" — o modelo pensa em voz alta antes de responder. Para problemas complexos, isso muda o nível de resposta.
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=16000,
thinking={
"type": "enabled",
"budget_tokens": 10000 # tokens que Claude pode usar para pensar
},
messages=[{
"role": "user",
"content": "Qual arquitetura de banco de dados faz mais sentido para um SaaS B2B com multi-tenancy?"
}]
)
# O response vai ter dois blocos:
# thinking_block: o raciocínio interno
# text_block: a resposta final
for block in response.content:
if block.type == "thinking":
print("Raciocínio interno:", block.thinking)
elif block.type == "text":
print("Resposta:", block.text)
Quando usar extended thinking: decisões de arquitetura, análise de código complexo, debugging de problemas não-triviais, qualquer pergunta onde "dê me a resposta certa" importa mais que "dê me a resposta rápida".
Quando não usar: tasks simples e bem definidas. Extended thinking tem custo de tokens e latência. Não desperdice.
Few-shot examples: o mais subutilizado
Claude aprende de exemplos no próprio prompt melhor do que a maioria dos outros modelos. Poucas pessoas exploram isso.
O padrão mais eficaz:
prompt = """Você classifica e-mails de suporte em categorias.
Exemplos:
<exemplo>
Email: "Não consigo fazer login, minha senha não funciona"
Categoria: acesso
Prioridade: alta
Ação: reset_senha
</exemplo>
<exemplo>
Email: "Gostaria de cancelar minha assinatura"
Categoria: cancelamento
Prioridade: media
Ação: oferta_retencao
</exemplo>
<exemplo>
Email: "Quando sai a próxima versão?"
Categoria: produto
Prioridade: baixa
Ação: newsletter
</exemplo>
Agora classifique:
Email: "{email_do_usuario}"
"""
Três exemplos bem escolhidos ensinam o formato, o nível de granularidade e os edge cases melhor do que 500 palavras de instrução. Sempre prefira mostrar a explicar.
Como pedir para Claude não alucinar
Claude alucina menos que a média dos LLMs, mas ainda alucina. A forma de reduzir:
<instrucao>
Responda apenas com informações presentes no contexto abaixo.
Se a resposta não estiver no contexto, diga explicitamente "Não encontrei essa informação no contexto disponível."
Não extrapole nem infira além do que está escrito.
</instrucao>
<contexto>
{documentos_aqui}
</contexto>
<pergunta>{pergunta}</pergunta>
O que funciona: dar saída alternativa honesta ("diga que não sabe") é mais eficaz do que simplesmente dizer "não alucine". Claude precisa de uma rota de escape para quando não sabe.
Chain of thought explícito
Para problemas de raciocínio, pedir o processo em voz alta melhora muito a qualidade da resposta final:
Antes de responder, trabalhe o problema passo a passo:
1. Identifique as variáveis relevantes
2. Liste as restrições
3. Avalie as opções
4. Chegue à conclusão
Depois apresente apenas a conclusão final de forma concisa.
O raciocínio intermediário fica no output mas a resposta final é mais acurada. Para cálculos, lógica e análise de trade-offs, essa técnica vale a pena.
Prompt caching: o hack que economiza real
Prompt caching é a feature que a maioria dos indie hackers ignora e que pode cortar 80-90% do custo de token em casos específicos.
A ideia: quando você tem um prefixo de prompt que é igual em muitas requests (system prompt longo, documentos de contexto, exemplos), o Anthropic cacheia esse prefixo. As requests seguintes que usam o mesmo prefixo pagam uma fração do preço pelos tokens cacheados.
Custo dos tokens de cache: aproximadamente 10% do preço normal de input. Tokens que batem no cache custam muito menos que tokens processados do zero.
Como implementar
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": """Você é o assistente de suporte da AcmeSaaS.
Aqui está toda a documentação do produto:
[documentação de 50 páginas aqui]
Políticas de suporte:
[políticas aqui]
FAQ completo:
[FAQ aqui]
""",
"cache_control": {"type": "ephemeral"} # marca para caching
}
],
messages=[
{"role": "user", "content": "Como faço para exportar dados em CSV?"}
]
)
Quando faz sentido
O cache é mais valioso quando:
- Você tem um system prompt ou contexto longo (1024+ tokens) que repete em muitas chamadas
- Você está fazendo RAG e passa os mesmos documentos para muitas queries
- Você tem examples ou instructions que são iguais em toda a sessão
Não faz sentido quando cada request tem contexto completamente diferente — aí não há cache hit.
Estimativa real: se você tem um system prompt de 5.000 tokens e faz 10.000 requests por dia, sem caching você paga por 50 milhões de tokens de input. Com caching e 90% de hit rate, você paga por 5 milhões de tokens normais + 45 milhões de tokens de cache (a 10% do preço). A economia é de 85%+ no custo de input.
Contexto de 200k tokens: o que isso significa na prática
Claude Sonnet e Opus aceitam até 200.000 tokens de contexto. Para ter dimensão: 200k tokens é aproximadamente 150.000 palavras — um livro inteiro.
O que você consegue jogar num único request:
- Codebase completo de um projeto médio
- Documentação técnica extensa
- Centenas de emails de suporte para análise
- Múltiplos PDFs longos simultaneamente
- Histórico completo de conversas de um cliente
Quando contexto longo ganha de RAG
RAG (Retrieval-Augmented Generation) é poderoso, mas tem overhead: você precisa de pipeline de embedding, vector DB, retrieval, e o resultado ainda pode trazer chunks irrelevantes.
Contexto longo simplifica isso. Se seu corpus cabe em 200k tokens, você não precisa de RAG — joga tudo e deixa o modelo encontrar o que importa.
Use contexto longo quando: corpus é menor que 150k tokens e você precisa de análise holística (padrões entre documentos, inconsistências, visão geral).
Use RAG quando: corpus é maior que 200k tokens, ou você precisa de retrieval em tempo real de dados que mudam frequentemente.
O problema do "lost in the middle"
Com contextos muito longos, Claude (como todos os LLMs) tende a dar mais atenção ao começo e ao final do contexto. Informação no meio pode ser subutilizada.
Mitigação: coloque as informações mais críticas no início ou no final do prompt. Se você está passando 10 documentos, coloque os mais relevantes primeiro e últimos.
Claude Code: o dev agent que muda o jogo
Claude Code é um CLI (interface de linha de comando) que roda Claude como agente de desenvolvimento diretamente no terminal. Você delega tarefas inteiras, não apenas perguntas.
# instalar
npm install -g @anthropic-ai/claude-code
# rodar no diretório do projeto
claude
Dentro do Claude Code, você fala em linguagem natural e ele age no codebase:
> Adiciona um endpoint POST /api/webhooks que valida a assinatura Stripe
e salva o evento no banco. Usa o padrão de outros endpoints do projeto.
> Refatora a função de autenticação em /src/auth.ts. Está muito longa,
extrai a lógica de validação de JWT para um helper separado.
> Há um bug reportado: ao fazer upload de imagem maior que 5MB,
o servidor retorna 500 sem mensagem. Encontra e corrige.
Claude Code lê seus arquivos, escreve código, roda comandos, e itera — sem você precisar copiar e colar nada.
CLAUDE.md: o contexto persistente do projeto
Crie um arquivo CLAUDE.md na raiz do projeto. É o equivalente de um briefing para um dev novo, mas para o Claude:
# Projeto: AcmeSaaS API
## Stack
- Node.js 22 + TypeScript
- Fastify (não Express)
- Prisma + PostgreSQL
- Redis para cache e jobs
- AWS S3 para arquivos
## Padrões do projeto
- Sempre use async/await, nunca callbacks
- Todos endpoints precisam de middleware de autenticação (auth.middleware.ts)
- Erros de validação: retornar 422 com { error: string, field?: string }
- Logs: usar logger.ts, não console.log
## Arquivos importantes
- src/routes/ — endpoints organizados por domínio
- src/services/ — lógica de negócio
- src/lib/ — utilitários e integrações externas
- prisma/schema.prisma — schema do banco
## O que não fazer
- Não instalar deps sem perguntar
- Não modificar migrations existentes
- Não usar any no TypeScript
## Comandos úteis
- npm run dev — server em modo dev
- npm run test — rodar todos os testes
- npm run db:push — sincronizar schema sem migration
Com CLAUDE.md bem escrito, você para de repetir contexto em cada sessão. Claude Code lê no começo de cada conversa.
Slash commands
Claude Code tem slash commands que estendem o que você pode fazer:
/help— lista de comandos disponíveis/clear— limpa o contexto da conversa/compact— comprime o contexto (útil quando está ficando longo)/review— faz code review dos changes atuais/init— inicializa CLAUDE.md com análise do projeto
Hooks
Hooks são scripts que rodam antes ou depois de ações do Claude Code. Eles permitem automações como:
- Rodar testes automaticamente depois de qualquer modificação de arquivo
- Validar que o código segue padrões antes de aceitar uma mudança
- Notificar Slack quando Claude Code completa uma task longa
// .claude/hooks.json
{
"post_tool_use": [
{
"matcher": "write_file",
"command": "npm run lint -- {file_path}"
}
]
}
Todo arquivo que Claude Code escreve passa pelo lint automaticamente. Erros aparecem na sessão e Claude pode corrigir antes de continuar.
MCP: o protocolo que conecta tudo
MCP (Model Context Protocol) é um protocolo aberto criado pela Anthropic que permite que Claude se conecte a qualquer ferramenta, banco de dados ou serviço externo de forma padronizada.
Pense em MCP como USB para integrações de IA. Em vez de cada ferramenta criar sua própria forma de integrar com Claude, existe um protocolo padrão. Um servidor MCP expõe tools e resources — Claude pode usar qualquer servidor MCP compatível.
Por que importa para indie hackers
Antes do MCP: você integrava Claude com seu banco via código customizado, gerenciava context injection, lidava com autenticação. Cada integração era um projeto separado.
Com MCP: você instala um MCP server para PostgreSQL, um para Slack, um para GitHub. Claude Code (e outros clientes MCP) se conecta a todos automaticamente. Você não escreve glue code.
Servidores MCP disponíveis (os mais úteis)
Databases:
@modelcontextprotocol/server-postgres— Claude lê e escreve no seu PostgreSQL em linguagem natural@modelcontextprotocol/server-sqlite— para projetos locais
Dev tools:
@modelcontextprotocol/server-github— Claude lê issues, PRs, código do GitHub@modelcontextprotocol/server-filesystem— acesso ao sistema de arquivos local
Produtividade:
@modelcontextprotocol/server-slack— Claude lê e posta no Slack@modelcontextprotocol/server-google-drive— acesso a documentos do Drive
Monitoramento:
- Datadog MCP, Sentry MCP — Claude analisa erros e métricas
Conectando MCP no Claude Code
// .claude/mcp_settings.json
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/meu_saas"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "seu-token-aqui"
}
}
}
}
Depois disso, dentro do Claude Code:
> Quais foram os 5 clientes com mais churn nos últimos 30 dias?
[Claude consulta o PostgreSQL diretamente]
> Cria uma issue no GitHub para o bug do upload que encontramos,
com a análise que fizemos e a proposta de fix.
[Claude cria a issue formatada]
Criando seu próprio MCP server
Se você tem uma API interna, um dado específico do seu produto ou uma ferramenta customizada, criar um MCP server é mais simples do que parece:
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
const server = new Server(
{ name: "meu-saas-mcp", version: "1.0.0" },
{ capabilities: { tools: {} } }
);
// Define as tools que Claude pode usar
server.setRequestHandler(ListToolsRequestSchema, async () => ({
tools: [
{
name: "buscar_metricas_cliente",
description: "Busca MRR, churn e LTV de um cliente específico",
inputSchema: {
type: "object",
properties: {
cliente_id: { type: "string", description: "ID do cliente" }
},
required: ["cliente_id"]
}
}
]
}));
// Implementa o que cada tool faz
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === "buscar_metricas_cliente") {
const { cliente_id } = request.params.arguments;
const metricas = await db.query(`
SELECT mrr, churn_risk, ltv
FROM clientes WHERE id = $1
`, [cliente_id]);
return {
content: [{ type: "text", text: JSON.stringify(metricas.rows[0]) }]
};
}
});
const transport = new StdioServerTransport();
await server.connect(transport);
Com isso, Claude tem acesso direto às métricas de qualquer cliente do seu produto, em linguagem natural, sem você precisar construir uma interface.
Casos de uso reais para indie hackers
Pipeline de conteúdo a custo zero
Você tem um blog com artigos técnicos. Toda semana quer publicar conteúdo novo. O processo manual leva horas.
import anthropic
import json
client = anthropic.Anthropic()
def gerar_post_blog(topico: str, artigos_relacionados: list[str]) -> dict:
"""
Gera um post de blog completo a partir de um tópico
e contexto de artigos existentes para manter consistência.
"""
contexto_artigos = "\n\n".join(artigos_relacionados[:3])
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=8000,
system=[
{
"type": "text",
"text": f"""Você escreve posts técnicos para founders de SaaS e devs.
Tom: direto, sem bullshit, prático. Referências reais, números reais.
Estrutura: lead forte que desafia convenção, seções com H2, exemplos concretos, checklist no final.
Tamanho: 1.500-2.500 palavras.
Artigos existentes (para manter consistência de voz e evitar repetição):
{contexto_artigos}""",
"cache_control": {"type": "ephemeral"}
}
],
messages=[{
"role": "user",
"content": f"""Escreva um post completo sobre: {topico}
Retorne em JSON com campos:
- title: string
- description: string (max 160 chars)
- content: string (markdown)
- tags: array de strings
- related_topics: array de 3 tópicos para posts futuros"""
}]
)
return json.loads(response.content[0].text)
# Uso
post = gerar_post_blog(
topico="Como usar Stripe webhooks para automatizar lifecycle de clientes",
artigos_relacionados=[conteudo_artigo_1, conteudo_artigo_2]
)
O caching do system prompt com os artigos existentes economiza tokens em cada chamada subsequente.
Customer support bot que não parece robô
O erro mais comum em bots de suporte: resposta genérica que não resolve o problema real.
def responder_suporte(pergunta: str, dados_cliente: dict, historico_tickets: list) -> str:
"""
Gera resposta de suporte personalizada com contexto real do cliente.
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system="""Você é o suporte da AcmeSaaS. Você tem acesso completo
ao histórico e dados do cliente e usa essas informações para personalizar respostas.
Regras:
- Nunca fingir que não sabe algo que está nos dados do cliente
- Se o problema é técnico conhecido, dar solução direta (não "entre em contato com o suporte")
- Se não conseguir resolver, escalar com contexto completo para o time humano
- Tonalidade: direto e útil, sem formulaico""",
messages=[
{
"role": "user",
"content": f"""Dados do cliente:
Nome: {dados_cliente['nome']}
Plano: {dados_cliente['plano']}
Conta ativa desde: {dados_cliente['criado_em']}
Último login: {dados_cliente['ultimo_login']}
Status de pagamento: {dados_cliente['status_pagamento']}
Tickets anteriores:
{json.dumps(historico_tickets[-3:], ensure_ascii=False)}
Pergunta atual: {pergunta}"""
}
]
)
return response.content[0].text
A diferença para respostas genéricas: o Claude sabe que o cliente está com pagamento em atraso, que fez login pela última vez há 2 semanas, que teve um ticket similar resolvido há um mês. A resposta é diferente porque o contexto é diferente.
Code review como parte do CI/CD
import subprocess
def review_pr(pr_diff: str, contexto_projeto: str) -> dict:
"""
Faz code review de um PR e retorna issues categorizadas.
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=4000,
messages=[{
"role": "user",
"content": f"""Faça code review deste PR. Contexto do projeto:
{contexto_projeto}
Diff:
{pr_diff}
Retorne JSON com:
- bugs: lista de bugs reais (não opiniões de estilo)
- seguranca: vulnerabilidades de segurança
- performance: issues de performance com impacto significativo
- sugestoes: melhorias menores (opcional implementar)
- aprovado: boolean (true se não há bugs ou issues de segurança)
- resumo: string com contexto para o desenvolvedor"""
}]
)
return json.loads(response.content[0].text)
# Integra com GitHub Actions
# O job falha se aprovado == false e há bugs críticos
Extração de dados de documentos não estruturados
def extrair_dados_contrato(pdf_texto: str) -> dict:
"""
Extrai campos estruturados de contratos em linguagem natural.
"""
response = client.messages.create(
model="claude-haiku-4-5-20251001", # Haiku é suficiente para extração
max_tokens=1000,
messages=[{
"role": "user",
"content": f"""Extraia os seguintes campos do contrato abaixo.
Se um campo não estiver presente, retorne null.
Campos necessários:
- valor_mensal: number (em reais)
- data_inicio: string (formato YYYY-MM-DD)
- data_fim: string ou null
- partes: {{ contratante: string, contratado: string }}
- multa_rescisao: number ou null
- renovacao_automatica: boolean
Contrato:
{pdf_texto}
Retorne apenas o JSON, sem explicação."""
}]
)
return json.loads(response.content[0].text)
Note o uso de Haiku aqui — extração de campos estruturados não precisa de Opus ou Sonnet. Haiku é mais rápido, mais barato, e igualmente eficaz para essa task.
Otimização de custos: as regras que a gente seguir
Regra 1: use o menor modelo que resolve o problema
Antes de escolher Sonnet, pergunte: Haiku resolve? Antes de escolher Opus, pergunte: Sonnet resolve?
Teste os três no mesmo eval set. Você vai descobrir que 60-70% das suas tasks funcionam bem com Haiku.
Regra 2: cache agressivamente
Todo prefixo que se repete (system prompt, documentos de contexto, examples) deve ter cache_control: ephemeral. Se você está passando o mesmo contexto em 100 requests por hora, está pagando 100x. Com cache, paga 10-15x.
Regra 3: prompt engineering reduz tokens
Um prompt verboso de 500 tokens pode virar um prompt cirúrgico de 150 tokens com o mesmo resultado. Menos tokens de input = menos custo.
Teste: pegue seu system prompt atual e peça ao Claude para reescrevê-lo "de forma mais concisa, mantendo todas as instruções". Você vai ficar surpreso.
Regra 4: SLM como porteiro antes do LLM caro
Se você tem uma pipeline de alto volume, use um modelo pequeno (Haiku, ou até um Llama local via Ollama) para filtrar requests antes de mandar pro Sonnet/Opus.
def precisa_llm_caro(mensagem: str) -> bool:
"""
Haiku classifica se a mensagem precisa de Sonnet ou pode ser
respondida por ele mesmo.
"""
response = client.messages.create(
model="claude-haiku-4-5-20251001",
max_tokens=10,
messages=[{
"role": "user",
"content": f"""Classifique: essa pergunta precisa de raciocínio complexo?
Responda apenas "sim" ou "nao".
Pergunta: {mensagem}"""
}]
)
return "sim" in response.content[0].text.lower()
# Uso
if precisa_llm_caro(mensagem_usuario):
resposta = chamar_sonnet(mensagem_usuario)
else:
resposta = chamar_haiku(mensagem_usuario)
Dependendo do seu mix de queries, isso pode cortar 40-60% do custo.
Regra 5: monitore tokens por request
Você não sabe onde está gastando se não monitora. Cada response inclui usage:
response = client.messages.create(...)
print(f"Input tokens: {response.usage.input_tokens}")
print(f"Output tokens: {response.usage.output_tokens}")
print(f"Cache creation tokens: {response.usage.cache_creation_input_tokens}")
print(f"Cache read tokens: {response.usage.cache_read_input_tokens}")
Log isso em produção. Coloque em dashboard. Você vai encontrar requests que estão gastando 10x mais que deveriam — e vai saber onde otimizar.
Checklist: indo para produção com Claude
Antes de qualquer produto com Claude virar público:
[ ] Modelo certo para cada task (não está usando Opus onde Haiku resolve)
[ ] Prompt caching implementado para prefixos recorrentes
[ ] System prompt versionado em git
[ ] Eval set com 30+ casos criado e passando
[ ] Streaming implementado para qualquer interface com usuário
[ ] Max tokens configurado (não deixe em default — caro e lento)
[ ] Timeout e retries implementados (API pode ficar lenta em pico)
[ ] Logs estruturados com input_tokens, output_tokens por request
[ ] Custo estimado por request calculado
[ ] Fallback para erro de API (graceful degradation)
[ ] Tool use com validação de output (JSON mal-formado acontece)
[ ] Rate limiting do lado do seu app (não espere a API reclamar)
[ ] CLAUDE.md atualizado se estiver usando Claude Code
[ ] MCP servers testados com dados reais, não apenas com dados mock
Onde isso está indo
A trajetória do ecossistema Claude aponta para algumas coisas claras:
Modelos mais capazes, não apenas maiores. Claude Opus 4.6 já passa pela maioria dos benchmarks de raciocínio. O próximo salto não é tamanho — é eficiência e confiabilidade.
MCP como padrão de mercado. A Anthropic abriu o protocolo. Outros players (incluindo OpenAI) estão adotando. MCP vai virar a forma padrão de dar ferramentas a agentes, independente do modelo.
Claude Code amadurecendo. Delegar tarefas de dev inteiras para um agente ainda tem fricção. Esse fricção vai diminuir. Nos próximos 12-18 meses, a pergunta não vai ser "devo usar Claude Code?" mas "quais tasks eu ainda faço manualmente?"
Custos caindo. Sempre caem. O que hoje parece caro demais para produção vai ser viável em 12 meses.
Para indie hacker, isso significa: aprenda o ecossistema agora, antes que seja commodity. Quem entende bem os primitivos (API, tool use, MCP, prompt engineering) vai construir produtos que outros não conseguem replicar apenas com interfaces de chat.
Se você implementou qualquer coisa desse guia e tem números reais — positivos ou negativos — a gente quer saber. Esse tipo de feedback é o que mantém conteúdo honesto sendo honesto.
Segue o blog pra mais conteúdo técnico real. Sem fluff.
Construindo seu SaaS?
Receba insights semanais sobre produto, tecnologia e negócios para fundadores de SaaS e Micro-SaaS.
Continue Lendo
