IA Sostenible: Cómo Convertí OpenClaw en Orquestador y Claude Code en Ejecutor para un Flujo de Trabajo que Dura

El vibecoding tiene un problema que nadie menciona en los tutoriales: es insostenible por diseño. No porque las herramientas sean malas — son extraordinarias. Sino porque los modelos de uso y pricing actuales están pensados para sesiones cortas y ocasionales, no para el desarrollo agéntico continuo que prometen habilitar. Cuando intentas usarlas de verdad, a diario, en proyectos reales, chocas contra rate limits, facturas impredecibles y flujos de trabajo que se interrumpen en el peor momento. Este post es sobre cómo construí una arquitectura que resuelve ese problema de raíz.

El Estado Real de los Límites de Uso en 2026

Permíteme ser específico, porque los números importan.

Claude Code ($20/mes)

Con la suscripción Pro de $20 USD al mes, Claude Code es sin duda la herramienta de coding más capaz que existe hoy. También es la que más rápido te deja sin acceso. En sesiones de trabajo intenso, el usage se agota en aproximadamente una hora de trabajo real. Después de eso: cuatro horas de espera. Y eso asumiendo que no hayas agotado el límite semanal, que existe y es igual de frustrante. El flujo de trabajo se convierte en trabajar 30 minutos, esperar 4 horas, trabajar 30 minutos, esperar 4 horas. Matemáticamente, estás pagando $20 por una herramienta que puedes usar 2-3 horas al día en el mejor caso.

Codex (OpenAI)

La situación es aún más dramática. El tier gratuito de Codex se agota en aproximadamente 5 prompts de OpenClaw. No es hipérbole: cinco interacciones del agente y estás fuera. El tier de pago mejora la situación pero no la resuelve para flujos de trabajo agénticos donde un solo task puede generar docenas de llamadas al modelo.

Gemini CLI (por API)

Gemini tiene la ventaja de ofrecer acceso por API sin límites de mensaje, lo que en teoría lo hace más sostenible para flujos agénticos. En teoría. El mes pasado, usando Gemini CLI con acceso por API para mis proyectos, la factura llegó a 11,000 pesos mexicanos. Para un desarrollador independiente en México, eso no es un costo de herramienta. Es el presupuesto de toda la operación del mes.

El patrón es consistente en todas las plataformas: o te limitan por mensajes (Claude Code, Codex), o te cobran por token de forma que el uso agéntico intensivo vuelve la factura impredecible y frecuentemente inaceptable (Gemini, APIs directas). Las herramientas están diseñadas para demos y uso casual. Para desarrollo real y continuo, son una trampa económica.

La Pregunta Que Nadie Hace en los Tutoriales

Todos los tutoriales de vibecoding asumen que tienes acceso ilimitado al mejor modelo. Ninguno habla de qué pasa cuando el rate limit te corta a la mitad de una refactorización compleja, cuando pierdes el contexto porque tuviste que esperar cuatro horas para continuar, o cuando a fin de mes la factura de API supera con creces lo que esperabas gastar.

Un flujo de trabajo de IA verdaderamente sostenible no es el que funciona en una demo de 20 minutos. Es el que puedes mantener encendido semanas, meses, sin que los costos escalen fuera de control ni los rate limits fragmenten tu concentración. Las plataformas actuales no están optimizadas para eso — están optimizadas para impresionar en primeros usos. La sostenibilidad requiere arquitectura, no solo suscripciones.

Lo que necesitaba era un sistema donde el modelo caro hiciera solo lo que solo él puede hacer, y todo lo demás lo manejara algo local, rápido y sin costo marginal.

La Solución: OpenClaw como Orquestador, Claude Code como Ejecutor

El insight central es una división de trabajo inspirada en el post sobre vibecoding económico de este mismo blog, pero llevada más lejos. En lugar de usar DeepSeek para planificar y Claude Haiku para ejecutar, el nuevo sistema usa:

• OpenClaw con MiniMax-M1 vía OllamaCloud como orquestador: toma decisiones, analiza el contexto, descompone tareas, decide qué necesita capacidad de frontier y qué no. MiniMax-M1 corriendo en OllamaCloud no tiene límites de mensaje, no tiene rate limits que interrumpan el trabajo, y el costo es predecible.
• Claude Code como ejecutor especializado: solo recibe las tareas concretas que el orquestador ya descompuso y contextualizó. No gasta tokens analizando el problema. Llega a ejecutar.

La clave técnica que hace posible esta separación es el bridge que construí: cc_bridge.

cc_bridge: Un Proxy OpenAI-Compatible en Go

cc_bridge es un servidor HTTP escrito en Go que expone una API completamente compatible con el estándar OpenAI (/v1/chat/completions, /v1/models). Cualquier herramienta que pueda hablarle a OpenAI puede hablarle a cc_bridge. Incluyendo OpenClaw.

El repositorio está en github.com/andyeswong/cc_bridge y el código es público.

Cómo Funciona el Ruteo

El bridge hace una cosa elegante: rutea las requests al backend correcto basándose en el modelo que se especifica en la llamada.

Modelo con prefijo "ollama/"  →  Ollama local
cualquier otro modelo         →  Claude Code CLI

Ejemplos:
"ollama/minimax-m1"    →  OllamaCloud / Ollama local
"claude-code"          →  Claude Code CLI (tu suscripción)
"claude-sonnet-4-6"    →  Claude Code CLI (tu suscripción)

Para OpenClaw, esto significa que puede llamar al bridge con el modelo que necesite en cada momento. Para análisis, planificación y orquestación usa ollama/minimax-m1. Para ejecución de código compleja donde necesita la capacidad de Claude, usa claude-code y el bridge lo rutea al CLI.

Instalación y Configuración

El bridge se compila con Go 1.22+ y requiere tener Claude Code CLI instalado y autenticado:

# Clonar y compilar
git clone https://github.com/andyeswong/cc_bridge
cd cc_bridge
go mod tidy
go build -o claude-bridge .

# Ejecutar con configuración completa
PORT=8080 \
CLAUDE_WORKDIR=/ruta/a/tu/proyecto \
CLAUDE_SKIP_PERMS=true \
OLLAMA_URL=http://localhost:11434 \
./claude-bridge

Una vez corriendo, cualquier cliente OpenAI-compatible puede apuntar a http://localhost:8080 y hablar con él. OpenClaw, Cline, cualquier script que uses para automatización.

Sesiones con Estado

Una característica importante para el patrón orquestador-ejecutor es el soporte de sesiones con estado. Pasando el header X-Session-ID, el bridge mantiene el contexto de conversación entre llamadas:

// Para Claude: mapea tu session ID al session ID interno de Claude
// usando --session-id / --resume en el CLI

// Para Ollama: mantiene el historial de conversación en memoria
// e inyecta el contexto en cada request

X-Session-ID: mi-sesion-proyecto-autenticacion

Esto permite que el orquestador delegue una tarea multi-paso a Claude Code manteniendo el hilo de la conversación a través de múltiples llamadas, sin que el contexto se pierda entre requests.

Tracking de Uso con Dashboard

El bridge incluye tracking automático en SQLite de cada request: modelo, proveedor, tokens, duración, errores. El dashboard en http://localhost:8080/dashboard se auto-refresca cada 30 segundos y muestra exactamente cuánto estás usando de cada backend:

GET /v1/usage

[
  {
    "model": "claude-code",
    "provider": "claude",
    "requests": 42,
    "prompt_tokens": 18400,
    "completion_tokens": 6200,
    "total_tokens": 24600,
    "avg_duration_ms": 3200
  },
  {
    "model": "ollama/minimax-m1",
    "provider": "ollama",
    "requests": 380,
    "prompt_tokens": 142000,
    "completion_tokens": 89000,
    "total_tokens": 231000,
    "avg_duration_ms": 890
  }
]

Esta visibilidad es lo que me permitió confirmar el resultado: El orquestador absorbe la gran mayoría de las llamadas. Claude Code solo ve las tareas que realmente necesitan su nivel de capacidad.

El Patrón de Delegación en la Práctica

El flujo concreto de trabajo con este sistema es el siguiente. OpenClaw con MiniMax-M1 actúa como orquestador: lee el contexto del proyecto desde el servidor MCP de embeddings, consulta ProjectHub para el estado de tareas, analiza el problema, descompone la tarea en pasos concretos, y decide cuáles requieren Claude Code.

Para las subtareas que delega a Claude Code, el bridge recibe una llamada con este patrón:

POST http://localhost:8080/v1/chat/completions
{
  "model": "claude-code",
  "messages": [
    {
      "role": "system",
      "content": "[briefing: contexto del usuario, proyecto, rutas absolutas relevantes]"
    },
    {
      "role": "user",
      "content": "[tarea concreta y acotada]"
    }
  ],
  "stream": false
}

El system prompt que arma el orquestador ya contiene todo el contexto necesario para que Claude Code ejecute sin necesidad de explorar el codebase. No gasta tokens descubriendo la arquitectura porque el orquestador ya hizo ese trabajo. Claude Code llega a hacer lo que mejor hace: escribir y modificar código con precisión quirúrgica.

Por Qué MiniMax-M1 como Orquestador

La elección de MiniMax-M1 vía OllamaCloud no fue arbitraria. Para la función de orquestación necesitaba un modelo con tres características: capacidad de razonamiento suficiente para descomponer tareas complejas, soporte de context window amplio para leer el estado completo del proyecto, y disponibilidad sin rate limits que interrumpieran el flujo de trabajo.

MiniMax-M1 cubre los tres puntos. No es Claude Sonnet en capacidad de coding, ni pretendo que lo sea. Su rol no es escribir código — es pensar, planificar y delegar. Para eso, es más que suficiente. Y lo más importante: con OllamaCloud, las interacciones de orquestación no consumen el usage de Claude Code. Pueden ser cientos de llamadas al día sin que eso se refleje en el contador de la suscripción de $20.

El Sistema Completo: Una Arquitectura Sostenible

Combinando todo lo que hemos construido a lo largo de los posts anteriores, el stack completo se ve así:

┌─────────────────────────────────────────────────────────┐
│                  CAPA DE PERSISTENCIA                   │
├──────────────────────┬──────────────────────────────────┤
│   ProjectHub LLM     │   MCP Memory Server              │
│   (tareas, eventos)  │   (embeddings en Redis)          │
└──────────────────────┴──────────────────────────────────┘
                             │
                    ┌────────▼────────┐
                    │   OpenClaw      │
                    │   MiniMax-M1    │  ← Orquestador
                    │   (OllamaCloud) │     sin rate limits
                    └────────┬────────┘
                             │ delega tareas complejas
                    ┌────────▼────────┐
                    │   cc_bridge     │  ← Proxy Go
                    │   localhost:8080│     OpenAI-compatible
                    └────────┬────────┘
                             │ rutea por modelo
              ┌──────────────┴──────────────┐
              │                             │
   ┌──────────▼──────────┐    ┌─────────────▼──────────┐
   │   Claude Code CLI   │    │   Ollama local          │
   │   (ejecutor)        │    │   (modelos secundarios) │
   │   uso < 20% semanal │    │                         │
   └─────────────────────┘    └────────────────────────┘

Este stack no es un workaround temporal. Es una arquitectura diseñada para ser sostenible a largo plazo, independiente de los cambios de pricing o política de cualquier plataforma individual.

El Problema Estructural del Desarrollo Agéntico Actual

Hay una tensión de fondo en cómo las plataformas de IA para coding están diseñadas hoy: sus casos de uso más potentes — los flujos agénticos donde el modelo lee el codebase, planifica, itera y ejecuta de forma autónoma — son precisamente los que más rápido agotan los límites de uso. El desarrollador que más necesita la herramienta es el que más rápido choca contra sus restricciones.

El resultado práctico es que el desarrollo agéntico sostenido requiere o bien presupuestos enterprise o bien arquitectura inteligente. No hay término medio en las plataformas actuales. Si dependes exclusivamente de una suscripción de $20 o de llamadas directas a API de modelos frontier, tu flujo de trabajo va a ser intermitente por diseño.

La alternativa es lo que describí en este post: no eliminar las herramientas de frontier, sino usarlas quirúrgicamente. cc_bridge, el servidor MCP de embeddings, ProjectHub, OllamaCloud — son piezas de una arquitectura que hace que el modelo caro solo intervenga cuando realmente marca la diferencia. Todo lo demás lo maneja infraestructura local, predecible y sin rate limits.

Conclusión

El stack que describí en este post no es perfecto. MiniMax-M1 no es Claude Sonnet. OllamaCloud tiene su propia latencia. El bridge requiere mantener un proceso corriendo. Son trade-offs reales que vale la pena conocer antes de adoptarlo.

Pero los números son los que son: menos del 20% del usage semanal de Claude Code, cero facturas sorpresa de API, flujo de trabajo que no se interrumpe cada hora esperando que el rate limit se resetee. Para un desarrollador independiente trabajando en proyectos propios, eso no es un trade-off menor. Es la diferencia entre un flujo de trabajo sostenible y uno que abandona a la tercera semana porque el costo cognitivo y económico se vuelve insoportable.

cc_bridge está en github.com/andyeswong/cc_bridge. Es código abierto, está escrito en Go, y compila con un solo comando. Si estás en la misma situación que yo estaba hace unos meses — pagando demasiado por demasiado poco acceso — es un buen punto de partida.

El vibecoding sostenible no es el que usa el modelo más caro en cada interacción. Es el que puedes mantener encendido todos los días, en proyectos reales, sin que los rate limits dicten tu ritmo de trabajo ni las facturas te obliguen a elegir entre herramientas y rentabilidad.