🔀 Mix de Providers: Pi/Kimi + Claude
A primeira e mais impactante alavanca de custo que Cole demonstra e nao usar o mesmo modelo para tudo. No dashboard do Agent Control Plane, ele roda o orchestrator inteiro com Kimi (via Pi), reservando Claude apenas para a implementacao real de codigo.
"I'm driving everything with Pi. So I'm actually using my Kimi subscription with Kimi K 2.6, now Kimi K 2.7 to drive all of these workflows. So yes, it is a lot of tokens, but I'm not using Opus for everything, but I'm still getting really good results because of the harness that I built here that elevates the model."
🧩 O Principio: Harness Eleva o Modelo
A sacada de Cole e que um harness bem construido (workflow deterministico, state externo, validacao por step) permite usar modelos mais baratos sem sacrificar qualidade final. O harness compensa as limitacoes do modelo ao fornecer contexto preciso e steps bem definidos.
Orchestrator
Kimi K 2.7 / Pi
Planejamento, decisao de rounds
Implementation
Claude Code
Escrita de codigo real
Review
Codex / modelo leve
Validacao e code review
📊 Model Routing: Modelo Certo para Cada Tarefa
Model routing vai alem do mix de providers: e sobre rotear cada tarefa especifica para o modelo mais adequado em termos de custo-beneficio. Cole demonstra isso no Archon, onde cada node do workflow pode usar um modelo diferente.
"Every single node in this Archon workflow, I can actually decide what model am I going to use. So for example, with the classify step, we can use a small model, like maybe using Haiku or Minimax M3, Kimi K 2.7."
🎯 Routing por Complexidade
Classificacao (barato)
Decidir se uma issue e bug ou feature. Haiku, Minimax M3 ou Kimi K 2.7. Raciocinio simples, tokens baratos.
Exploracao e pesquisa (medio)
Investigar o codebase, entender dependencias. Kimi K 2.7 com contexto longo. Precisa de raciocinio, mas nao de precisao maxima.
Implementacao (caro)
Escrever codigo real que vai virar PR. Claude Code. Aqui a qualidade importa, e voce paga por ela.
💡 O Anti-Pattern do Modelo Unico
Cole aponta diretamente: "one of the other big issues I see with using slash goal or routines or loops in Cloud Code is you're just using one model for pretty much everything. That's part of the problem of why it's so expensive." Usar Opus para classificar bug vs feature e como usar um caminhao para ir a padaria.
💾 State Externo: Evitar Context Bloat
Context bloat e o assassino silencioso de loops. Quando voce roda /loop na mesma sessao do Claude Code, cada round acumula contexto no context window do LLM. Depois de muitos rounds, o modelo fica sobrecarregado e a qualidade despenca. A solucao e manter estado fora do LLM.
"If you loop for a while, you're going to completely bloat your context for your LLM and overwhelm it. And so we need a system where we can distribute the work actually between different coding agent sessions."
Sem State Externo
- ✗Context window cresce a cada round
- ✗Qualidade degrada progressivamente
- ✗Se a sessao cair, perde tudo
- ✗Custo de tokens cresce exponencialmente
Com State Externo (Postgres)
- ✓Cada sessao comeca limpa
- ✓Orchestrator le so o que precisa do banco
- ✓Crash? Retoma do ultimo state gravado
- ✓Custo de tokens estavel por round
O Paradigma: Context Window como Cache
A mudanca mental e tratar o context window do LLM como cache temporario, nao como storage permanente. O banco (Postgres/Neon) e o storage. Cada sessao do agente carrega do banco o que precisa, executa, e grava de volta. O context window nunca acumula historico de rounds anteriores.
🌳 Worktrees para Isolamento de Sessoes Paralelas
Quando voce escala loops para processar multiplas tarefas em paralelo, os agentes nao podem compartilhar o mesmo working directory. Git worktrees criam copias isoladas do repositorio onde cada agente trabalha sem interferir nos outros.
"Work trees are also a really important part of loop engineering. Boris talks about this as well. If we're having many different agents handling tasks in a loop, we need to make sure they're running in isolation so they're not stepping on each other's toes."
Isolamento em Tres Camadas
1. Codigo: Git Worktrees
Cada worker roda em um worktree separado com seu proprio branch. Mudancas em um worker nao afetam os outros. Merge acontece so apos validacao.
2. Dados: Neon Database Branching
Neon permite criar branches do banco de dados, assim como Git faz com codigo. Cada worker pode ter seu proprio branch de dados para testes sem afetar producao.
3. Portas: Conflict Avoidance
Quando multiplos agentes rodam servidores de dev, cada um precisa de portas diferentes. Sem gerenciamento de portas, agentes em paralelo conflitam e crasham.
⏱ Batch vs Real-Time: Quando Cada Um Vale a Pena
Nem todo loop precisa rodar em tempo real. Acumular tarefas e processar em batch pode ser significativamente mais barato do que processar cada tarefa imediatamente. A escolha depende da urgencia e do volume.
Batch (lotes)
- ✓Quando: GitHub issues acumuladas, manutencao noturna, code reviews pendentes
- ✓Vantagem: orchestrator planeja uma vez para N tarefas, amortizando custo de planejamento
- ✓Trade-off: maior latencia, resultados nao sao imediatos
Real-Time (imediato)
- ✓Quando: bug critico em producao, feature blocker, hotfix urgente
- ✓Vantagem: resposta imediata, resultado rapido
- ✓Trade-off: custo mais alto por tarefa, orchestrator planeja para cada uma
🎯 Ponto de Reflexao
Cole demonstra o padrao batch ao despachar 4 workflows de GitHub issues simultaneamente. O orchestrator planeja uma vez, despacha todos, e valida depois. Isso e mais eficiente que processar cada issue individualmente, porque o custo de planejamento do orchestrator e amortizado entre as 4 tarefas.
❓ Questionamentos e Metricas Essenciais
Otimizar custos sem metricas e adivinhar. Cole construiu cost tracking no dashboard exatamente para ter dados concretos sobre onde o dinheiro esta indo. Tres metricas sao o minimo necessario para qualquer setup de loop.
📐 As Tres Metricas Essenciais
1. Tokens por tarefa
Quantos tokens cada tarefa individual consome, incluindo o overhead do orchestrator. Se uma tarefa simples consome 100k tokens, algo esta errado. Comparar entre tarefas similares revela anomalias.
2. Custo por round
O custo de cada ciclo orchestrator-workers. Se esta subindo round apos round, indica context bloat ou orchestrator ineficiente. Se esta estavel, o sistema e saudavel.
3. Taxa de sucesso
Percentual de workers que completam com sucesso vs falham. Se a taxa cai abaixo de 80%, o custo efetivo por tarefa util dispara porque voce esta pagando por trabalho jogado fora.
Vale a pena otimizar?
Depende do volume. Se voce roda 1 loop por semana, otimizacao de custo nao e prioridade. Se roda dezenas por dia como Boris, cada centavo por token importa. A decisao de investir em otimizacao deve ser proporcional ao volume de uso.
O custo vai cair naturalmente?
Modelos ficam mais baratos com o tempo. Kimi K 2.7 ja e dramaticamente mais barato que Opus para muitas tarefas. Mas "mais barato" nao significa "barato". 1M tokens mesmo com modelo barato ainda e um custo real. As tecnicas desse modulo importam independente do preco por token.
A regra final de custo
Cole sintetiza a abordagem: "you got to have the right system. Otherwise, things are going to completely fall apart." Custo nao e so dinheiro, e confiabilidade. Um loop barato que produz lixo e mais caro que um loop caro que entrega valor.
📋 Resumo do Modulo
Proximo Modulo:
4.1 - Loop Simples: Task Runner - receita pronta com prompt copiavel e template de plan.md