🔢 Entendendo tokens — input vs output, cache vs fresh
O que é
Entender a estrutura de custo é o pré-requisito para qualquer estratégia de otimização. Sem esse conhecimento, você otimiza o componente errado e gasta esforço sem resultado.
Por que aprender
📊 Estrutura de custo dos LLMs
Input tokens
O que você envia ao modelo: system prompt + briefing + histórico. Geralmente mais barato que output. Em português: ~2–3 caracteres por token.
Output tokens
O que o modelo responde: drafts, críticas, análises. Mais caro que input. O principal driver de custo em loops de iteração.
Cache de prompt
Tokens de input que se repetem entre chamadas são cobrados a 10% do preço normal (Claude). System prompts constantes são candidatos perfeitos para cache.
Fresh tokens
Tokens cobrados ao preço cheio. O que varia a cada chamada (o briefing, os drafts) são sempre fresh — não beneficiam de cache.
Conceitos-chave
Output geralmente custa 3–5x mais que input — o loop de iteração amplifica esse custo
10% do preço para tokens repetidos — system prompts longos beneficiam muito
Estimativa para português — texto em pt-BR usa mais tokens que inglês para o mesmo conteúdo
Cada modelo tem preço diferente — verificar openrouter.ai/models antes de escolher
🧮 Como calcular custo antes de rodar uma tarefa pesada
O que é
Estimar custo antes de executar elimina surpresas. Em tarefas novas, uma estimativa ruim pode resultar em custo 10x maior que o esperado — mas a fórmula é simples.
Por que aprender
Estime o tamanho do briefing (input do Worker)
Regra prática: 750 palavras ≈ 1.000 tokens. Um briefing detalhado de 1 página ≈ 500–800 tokens.
Estime o tamanho de cada draft (output do Worker)
Análises médias produzem 500–2.000 tokens por ângulo. Com 3 ângulos: 1.500–6.000 tokens por iteração do Worker.
Multiplique pelo número esperado de iterações
Sistema bem calibrado: 2–3 iterações. Sistema novo ou prompt não otimizado: 5–10 iterações. Use 5 como estimativa conservadora para tarefas novas.
Aplique o preço do modelo e adicione 30% de margem
Exemplo: DeepSeek V4 a $0,87/M output tokens. 5 iterações × 3.000 tokens output = 15.000 tokens × $0,87/M = $0,013 + 30% = ~$0,017.
Conceitos-chave
Regra de bolso para estimar tamanho de texto em tokens
Buffer para variação de tokens, críticas longas e overhead do sistema
Para tarefas novas sem histórico de calibração do prompt
Comparar depois de cada tarefa para calibrar estimativas futuras
⚠️ Rate limits — o que são, quando acontecem, como evitar
O que é
Rate limits são o principal ponto de falha em loops overnight. Saber quando acontecem e como evitá-los é o que garante que o trabalho noturno chega completo pela manhã.
Por que aprender
📋 Tipos de rate limit
TPM — Tokens por Minuto
O mais comum. Em loops intensivos, um único modelo pode atingir o TPM em minutos. Solução: usar BYOK direto no provedor, que tem limites mais altos.
RPM — Requisições por Minuto
Limite no número de chamadas de API por minuto. Relevante quando o Triad faz muitas chamadas pequenas (ex: Crítico avaliando ângulos individualmente).
Limite por dia (RPD/TPD)
Alguns modelos têm limites diários no free tier. Quando atingidos, o modelo fica indisponível até o reset (geralmente meia-noite UTC).
Erro 429
"Too Many Requests" — o código de erro que indica rate limit atingido. O Hermes deve ter retry automático com backoff exponencial para esse erro.
💡 BYOK como solução para rate limits
BYOK (Bring Your Own Key) — usar sua chave direta do provedor (DeepSeek, Anthropic) em vez de passar pelo pool compartilhado do OpenRouter. Limites são muito mais altos porque são dedicados à sua conta, não compartilhados entre todos os usuários do OpenRouter.
Conceitos-chave
Os dois limites mais comuns — tokens por minuto e requisições por minuto
O código de erro de rate limit — o Hermes deve ter retry com backoff exponencial
Chave própria no provedor = limites dedicados, não compartilhados com outros usuários
Quanto mais você gasta historicamente, maior o tier e mais altos os limites
📅 Estratégias de orçamento por modelo e por semana
O que é
Orçamento por modelo evita que um loop runaway consuma créditos ilimitados. É o freio de segurança financeiro do sistema — e precisa ser definido antes de colocar o Triad em produção intensiva.
Por que aprender
💼 Modelo de orçamento semanal por papel
| Papel | Modelo sugerido | Orçamento semanal | Justificativa |
|---|---|---|---|
| Condutor | Claude Opus | $5/semana | Tarefas estratégicas são poucas — usar Opus só quando necessário |
| Worker | DeepSeek V4 | $10/semana | Uso intensivo — múltiplas iterações e ângulos por tarefa |
| Crítico | GPT-5.5 | $3/semana | Críticas são outputs curtos — custo menor que o Worker |
⚠️ Loop runaway — o risco financeiro real
Um loop runaway é um loop Worker-Crítico que não converge — continua iterando indefinidamente porque o Crítico nunca aprova ou o Worker nunca resolve o problema. Sem orçamento definido, um loop overnight pode consumir centenas de dólares antes de ser detectado manualmente.
Conceitos-chave
Cada modelo do Triad tem orçamento independente — evita que um papel consuma tudo
Alerta quando o uso semanal atinge 80% do orçamento — tempo para investigar antes de bloquear
Loop sem convergência que consome créditos indefinidamente sem produzir resultado
Manter 20% do orçamento para experimentos e tarefas fora do Triad padrão
🔔 Alertas de custo no OpenRouter — configurando limites
O que é
Alertas automáticos são o sistema de proteção que funciona enquanto você dorme. Sem eles, você pode acordar com uma conta inesperada de um loop que ficou rodando além do planejado.
Por que aprender
Acessar Spend Alerts
No OpenRouter: Settings → Billing → Spend Alerts. Aqui você configura alertas por email para gastos diários e limites hard mensais.
Configurar alerta de gasto diário
Defina um limite de gasto diário. Quando atingido, você recebe email. Para um orçamento de $20/semana, um limite de $4/dia é razoável.
Definir limite hard mensal
O OpenRouter bloqueia novas chamadas automaticamente quando o limite mensal é atingido. Isso é o freio final — mais conservador que alertas de email.
Criar chaves de API separadas por projeto
Para projetos de equipe ou múltiplas iniciativas: crie uma chave de API por projeto. Isso permite monitorar custo por iniciativa no dashboard do OpenRouter.
Conceitos-chave
Configuração nativa — Settings → Billing → Spend Alerts
Bloqueia automaticamente quando atingido — o freio final e mais confiável
Monitoramento de custo granular por iniciativa ou cliente
O objetivo é que o sistema proteja você enquanto você dorme — não depender de monitoramento manual
🆓 Quando usar free tier vs pago — a decisão certa
O que é
Usar free tier nas situações erradas resulta em trabalho interrompido e estados inconsistentes — muitas vezes mais custoso em tempo do que a economia em dinheiro.
Por que aprender
✓ Free tier é adequado para
- ✓Testes de configuração de novos prompts
- ✓Exploração de novos ângulos ou abordagens
- ✓Tarefas de baixa prioridade onde velocidade não importa
- ✓Verificações rápidas de configuração (menos de 5 chamadas)
✗ Free tier NÃO é adequado para
- ✗O Triad em produção (rate limits muito baixos)
- ✗Tarefas overnight (risco de interrupção no meio)
- ✗Loops de mais de 5 iterações
- ✗Qualquer tarefa que vai levar mais de 10 minutos
💡 Regra prática
Se a tarefa vai levar mais de 10 minutos de execução ou produzir mais de 10 chamadas de API, use tier pago com BYOK. O custo de uma interrupção em produção (retrabalho, estado inconsistente, diagnóstico) supera qualquer economia no free tier.
Conceitos-chave
Exploração e validação de prompts sem risco financeiro, mas com risco de interrupção
Tier pago com BYOK garante limites altos e confiabilidade para loops de produção
Acima de 10 chamadas, o overhead de gerenciar limites do free tier não vale a pena
Retrabalho por interrupção custa mais em tempo do que a diferença de preço free vs pago
✂️ Otimizando prompts para reduzir tokens sem perder qualidade
O que é
Reduzir tokens sem perder qualidade é o que permite fazer mais com o mesmo orçamento. Cada técnica tem impacto mensurável no custo sem afetar a profundidade do output.
Por que aprender
Remover exemplos redundantes do system prompt
Um exemplo claro vale mais que três mediocres. Exemplos redundantes aumentam o custo de cache sem adicionar informação nova.
Usar listas em vez de parágrafos nas instruções
Listas são mais densas em informação por token que parágrafos. Instruções em prosa usam 30–50% mais tokens para o mesmo conteúdo.
Separar constantes (system) de variáveis (user)
Instruções constantes no system prompt se beneficiam de cache (10% do preço). Instruções variáveis no prompt do usuário são sempre fresh. Nunca misture os dois.
Briefing estruturado de 5 seções em vez de prosa
O formato estruturado (Objetivo / Critérios / Restrições / Contexto / Ângulos) usa menos tokens e é mais fácil de auditar antes de despachar.
Pedir ao Worker raciocínio em bullets, não parágrafos
Bullets são mais densos e mais fáceis de avaliar pelo Crítico. Parágrafos longos aumentam o custo de output sem aumentar a qualidade da análise.
Conceitos-chave
Instruções constantes cacheadas reduzem custo de input em 90%
Listas usam 30–50% menos tokens para transmitir a mesma instrução
Formato de 5 seções é mais econômico e mais fácil de auditar que prosa
Output mais denso e mais útil para o Crítico — menos tokens, mais informação
✅ Resumo do Módulo
Próximo Módulo:
3.3 — Monitoramento, logs e saúde do sistema