🔀 Combinación de proveedores: Pi/Kimi + Claude
La primera palanca de costos y la de mayor impacto que demuestra Cole es no usar el mismo modelo para todo. En el dashboard de Agent Control Plane, ejecuta todo el orchestrator con Kimi (a través de Pi) y reserva Claude solo para la implementación real del código.
"Estoy usando Pi para coordinarlo todo. En realidad, uso mi suscripción de Kimi con Kimi K 2.6, ahora Kimi K 2.7, para gestionar todos estos flujos de trabajo. Así que sí, consume muchos tokens, pero no uso Opus para todo y aun así obtengo muy buenos resultados gracias al harness que construí aquí, que potencia el modelo."
🧩 El principio: Harness eleva el modelo
La clave de Cole es que un harness bien construido (workflow determinista, estado externo, validación por paso) permite usar modelos más baratos sin sacrificar la calidad final. El harness compensa las limitaciones del modelo al proporcionar contexto preciso y pasos bien definidos.
Orchestrator
Kimi K 2.7 / Pi
Planificación, decisión de rondas
Implementation
Claude Code
Escritura de código real
Review
Codex / modelo ligero
Validación y code review
📊 Enrutamiento de modelos: el modelo adecuado para cada tarea
El enrutamiento de modelos va más allá de combinar proveedores: se trata de enrutar cada tarea específica al modelo más adecuado en términos de costo-beneficio. Cole lo demuestra en Archon, donde cada nodo del workflow puede usar un modelo diferente.
"En cada nodo de este flujo de trabajo de Archon, puedo decidir qué modelo voy a usar. Por ejemplo, para el paso de clasificación podemos usar un modelo pequeño, como Haiku, Minimax M3 o Kimi K 2.7."
🎯 Enrutamiento por complejidad
Clasificación (económica)
Decidir si un issue es un bug o una feature. Haiku, Minimax M3 o Kimi K 2.7. Razonamiento sencillo, tokens baratos.
Exploración e investigación (medio)
Investigar el codebase y entender las dependencias. Kimi K 2.7 con contexto largo. Requiere razonamiento, pero no la máxima precisión.
Implementación (costosa)
Escribir código real que se convertirá en un PR. Claude Code. Aquí la calidad importa y pagas por ella.
💡 El antipatrón del modelo único
Cole señala directamente: "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 clasificar un bug frente a una feature es como usar un camión para ir a la panadería.
💾 Estado externo: evitar la saturación del contexto
Context bloat es el asesino silencioso de los loops. Cuando ejecutas /loop en la misma sesión de Claude Code, cada ronda acumula contexto en la ventana de contexto del LLM. Después de muchas rondas, el modelo se sobrecarga y la calidad se desploma. La solución es mantener el estado fuera del LLM.
"Si dejas el loop funcionando un rato, vas a inflar muchísimo el contexto de tu LLM y lo vas a saturar. Por eso necesitamos un sistema que distribuya el trabajo entre distintas sesiones de agentes de programación."
Sin state externo
- ✗La ventana de contexto crece en cada ronda
- ✗La calidad se degrada progresivamente
- ✗Si la sesión se cae, se pierde todo
- ✗El costo de los tokens crece exponencialmente
Con estado externo (Postgres)
- ✓Cada sesión comienza limpia
- ✓El orchestrator lee del banco solo lo que necesita
- ✓¿Se bloquea? Retoma desde el último estado guardado
- ✓Costo de tokens estable por ronda
El paradigma: Context Window como caché
El cambio de mentalidad consiste en tratar la ventana de contexto del LLM como caché temporal, no como almacenamiento permanente. La base de datos (Postgres/Neon) es el almacenamiento. Cada sesión del agente carga de la base de datos lo que necesita, lo ejecuta y lo guarda de nuevo. La ventana de contexto nunca acumula el historial de rondas anteriores.
🌳 Worktrees para aislar sesiones paralelas
Cuando escalas los loops para procesar varias tareas en paralelo, los agentes no pueden compartir el mismo working directory. Git worktrees crean copias aisladas del repositorio donde cada agente trabaja sin interferir con los demás.
"Los work trees también son una parte muy importante de la ingeniería con loops. Boris también habla de esto. Si muchos agentes gestionan tareas dentro de un loop, tenemos que asegurarnos de que se ejecuten de forma aislada para que no se estorben entre sí."
Aislamiento en Tres Capas
1. Código: Git Worktrees
Cada worker se ejecuta en un worktree separado con su propia rama. Los cambios de un worker no afectan a los demás. La fusión ocurre solo después de la validación.
2. Datos: Neon Database Branching
Neon permite crear branches de la base de datos, igual que Git con el código. Cada worker puede tener su propio branch de datos para hacer pruebas sin afectar producción.
3. Puertas: Conflict Avoidance
Cuando varios agentes ejecutan servidores de desarrollo, cada uno necesita puertos diferentes. Sin gestión de puertos, los agentes en paralelo entran en conflicto y fallan.
⏱ Batch vs. tiempo real: cuándo vale la pena cada uno
No todos los loops tienen que ejecutarse en tiempo real. Acumular tareas y procesarlas en lote puede ser significativamente más barato que procesar cada tarea de inmediato. La elección depende de la urgencia y del volumen.
Batch (lotes)
- ✓Cuando: Issues de GitHub acumuladas, mantenimiento nocturno, code reviews pendientes
- ✓Ventaja: orchestrator planifica una vez para N tareas, amortizando el costo de planificación
- ✓Trade-off: mayor latencia; los resultados no son inmediatos
En tiempo real (inmediato)
- ✓Cuando: bug crítico en producción, bloqueo de una funcionalidad, hotfix urgente
- ✓Ventaja: respuesta inmediata, resultado rápido
- ✓Trade-off: costo más alto por tarea; el orchestrator planifica cada una
🎯 Punto de reflexión
Cole demuestra el patrón batch al despachar simultáneamente 4 workflows de issues de GitHub. El orchestrator planifica una vez, los despacha todos y valida después. Esto es más eficiente que procesar cada issue individualmente, porque el costo de planificación del orchestrator se distribuye entre las 4 tareas.
❓ Preguntas y métricas esenciales
Optimizar costos sin métricas es adivinar. Cole construyó un seguimiento de costos en el dashboard precisamente para tener datos concretos sobre dónde se está yendo el dinero. Tres métricas son lo mínimo necesario para cualquier configuración de loop.
📐 Las tres métricas esenciales
1. Tokens por tarea
Cuántos tokens consume cada tarea individual, incluido el overhead del orchestrator. Si una tarea simple consume 100k tokens, algo anda mal. Comparar tareas similares permite detectar anomalías.
2. Costo por round
El costo de cada ciclo orchestrator-workers. Si aumenta round tras round, indica context bloat o un orchestrator ineficiente. Si se mantiene estable, el sistema está en buen estado.
3. Tasa de éxito
Porcentaje de workers que completan las tareas con éxito frente a los que fallan. Si la tasa cae por debajo del 80%, el costo efectivo por tarea útil se dispara porque estás pagando por trabajo desperdiciado.
¿Vale la pena optimizar?
Depende del volumen. Si ejecutas 1 loop por semana, optimizar costos no es una prioridad. Si ejecutas decenas al día, como Boris, cada centavo por token importa. La decisión de invertir en optimización debe ser proporcional al volumen de uso.
¿El costo bajará de forma natural?
Los modelos se abaratan con el tiempo. Kimi K 2.7 ya es mucho más barato que Opus para muchas tareas. Pero «más barato» no significa «barato». Incluso 1M tokens con un modelo económico sigue teniendo un costo real. Las técnicas de este módulo importan independientemente del precio por token.
La regla final sobre costos
Cole sintetiza el enfoque: "necesitas el sistema adecuado. De lo contrario, todo se va a desmoronar por completo." El costo no es solo dinero; también es confiabilidad. Un loop barato que produce basura cuesta más que uno caro que aporta valor.
📋 Resumen del módulo
Módulo siguiente:
4.1 - Ciclo simple: Task Runner - receta lista con prompt copiable y plantilla de plan.md