Multi-CLI MCP: Claude, Codex y Gemini en un agente
TL;DR: Un MCP server dedicado conecta Claude Code, Codex y Gemini CLI para que el agente que estés usando pueda llamar a los otros como herramientas, sin cambiar de terminal. Claude destaca en refactorizaciones complejas (80,8% en SWE-bench Verified), Gemini aporta 1 millón de tokens de contexto y 1.000 peticiones gratuitas al día, y Codex encaja mejor en pipelines CI/CD. En este artículo verás cómo instalar el patrón Multi-CLI MCP, qué proyectos lo implementan y cuándo enrutar cada tarea a cada modelo.
El problema de gestionar tres CLIs por separado
Claude Code puntúa 80,8% en SWE-bench Verified frente al 63,8% de Gemini 2.5 Pro, según datos de febrero de 2026. En la práctica, eso significa que Claude tiene éxito en aproximadamente 1 de cada 6 tareas donde Gemini falla, especialmente en refactorizaciones con 5 o más archivos interdependientes.
Sin embargo, Gemini tiene 1 millón de tokens de contexto y 1.000 peticiones gratuitas al día. Codex encaja bien en flujos CI/CD y soporta entrada multimodal. Ninguno de los tres gana en todo.
El flujo habitual de quien usa los tres modelos es gestionar terminales separados y copiar y pegar resultados entre ellos. Ese problema tiene solución desde hace pocas semanas: dos repositorios publicados de forma independiente el mismo día implementan el mismo patrón, lo que indica que la comunidad llegó a la misma conclusión por caminos distintos.
¿Qué es el patrón Multi-CLI MCP?
Multi-CLI MCP es una arquitectura de integración que conecta Claude Code, Codex y Gemini CLI mediante el Model Context Protocol. El agente activo puede invocar a los otros como herramientas nativas, sin salir de la sesión ni abrir terminales adicionales.
El funcionamiento es directo: el MCP server detecta qué CLIs tienes instalados en el sistema, registra herramientas para los modelos alternativos (excluyendo al modelo que hace la llamada para evitar loops), y cuando una herramienta se invoca ejecuta el CLI correspondiente como proceso hijo y devuelve el resultado al contexto activo.
El resultado práctico: desde Claude Code puedes escribir "analiza el repositorio completo con Gemini y dame un resumen de dependencias circulares", y Gemini lee los archivos con su ventana de 1M tokens mientras Claude gestiona la sesión principal.
MCP dedicado frente a Skills: por qué importa la diferencia
La primera pregunta razonable es si no bastaría con un skill de Claude Code que ejecute el CLI del modelo alternativo. La respuesta corta: funciona, pero tiene fricciones importantes.
Un skill requiere invocación explícita y configuración por proyecto. No se autodescubre ni se registra automáticamente como herramienta disponible en la sesión del agente. El agente no "sabe" que puede llamar a Gemini a menos que se lo indiques en el contexto. Con un MCP server, la herramienta aparece registrada desde el inicio de la sesión y el modelo puede decidir usarla de forma autónoma cuando la tarea lo requiere.
Otro límite de los Skills para este caso: no gestionan bien el flujo de retorno de streams largos ni la ejecución en background. Algunos de los proyectos que veremos a continuación resuelven esto ejecutando los CLI como procesos hijo y devolviendo únicamente el resultado final al contexto principal, lo que mantiene limpia la ventana de contexto activa.
Si ya usaste VS Code Agent Mode para orquestar Claude, Codex y Gemini, el patrón Multi-CLI MCP es el equivalente para flujos de terminal: sin IDE de por medio, routing programático, y el agente decide qué modelo usar sin que se lo indiques en cada tarea.
El ecosistema de proyectos que implementan este patrón
En pocas semanas han emergido varios proyectos con distintos énfasis. La tabla siguiente resume los más relevantes:
| Proyecto | Enfoque principal | Ideal para |
|---|---|---|
| multicli (osanoai) | Bridge simple, auto-detect, self-maintaining vía CI nocturno | Setup rápido sin configuración manual |
| ai-cli-mcp (mkXultra) | Ejecución en background desde cualquier cliente MCP | Tareas largas o paralelas sin bloquear la sesión |
| PAL MCP Server (BeehiveInnovations) | Subagentes con clink, delegación de contexto limpia |
Revisiones pesadas, code review en contexto fresco |
| claude-octopus (nyldn) | Roles diferenciados, consenso del 75%, modo Dark Factory | Proyectos críticos con revisión cruzada entre modelos |
| all-agents-mcp (Dokkabei97) | Añade Copilot CLI al mix, invoca binarios oficiales | Equipos con GitHub Copilot ya instalado |
Para la mayoría de casos, multicli es el punto de entrada más directo. Un job de CI nocturno comprueba las últimas versiones estables de cada CLI y publica automáticamente si algo cambia: los modelos nuevos se recogen en menos de 24 horas y los obsoletos se eliminan. Sin intervención manual.
Instalación paso a paso con multicli
Prerrequisitos: tener instalados y autenticados los CLIs que quieras conectar. Cada uno gestiona su propia autenticación: Claude con ANTHROPIC_API_KEY, Codex con cuenta OpenAI, Gemini con cuenta de Google. Multi-CLI no añade capas de autenticación adicionales.
Opción 1: instalador automático
# Detecta qué CLIs tienes instalados y los configura todos
curl -fsSL https://raw.githubusercontent.com/osanoai/multicli/main/install.sh | bash
El script detecta los CLIs en tu PATH y los configura para usarse entre sí. No requiere variables de entorno adicionales ni archivos de configuración manuals.
Opción 2: configuración manual por CLI
# Añadir Multi-CLI como MCP server en Claude Code
claude mcp add Multi-CLI -- npx -y @osanoai/multicli@latest
# Añadir Multi-CLI como MCP server en Gemini CLI
gemini mcp add --scope user Multi-CLI npx -y @osanoai/multicli@latest
El flag @latest garantiza que el servidor use siempre la versión más reciente. No es necesario actualizar manualmente: el CI del repositorio lo gestiona.
Verificación del setup
# Desde Claude Code, verificar que las herramientas están disponibles:
# El agente debería tener acceso a ask_gemini y ask_codex
# (no ve ask_claude porque él ya es Claude)
# Prueba básica: pedir a Claude que delegue a Gemini
# "Usa Gemini para leer src/ completo y listar las dependencias circulares"
# Desde Gemini, verificar que ve ask_claude y ask_codex:
# "Pídele a Claude que revise esta función para posibles race conditions"
Si las herramientas no aparecen, el motivo más frecuente es que el CLI objetivo no está en el PATH del proceso padre. Ejecuta which gemini y which codex desde el mismo shell antes de iniciar la sesión.
Routing: cuándo usar cada modelo
Tener los tres disponibles no significa usarlos indiscriminadamente. Cada modelo tiene un perfil de fortalezas claro y el routing debería reflejarlo:
| Tipo de tarea | Modelo recomendado | Motivo |
|---|---|---|
| Refactorización multi-archivo | Claude | 80,8% en SWE-bench, razonamiento contextual profundo |
| Análisis de codebase completo | Gemini | 1M tokens de contexto, lee el repo entero en una sola llamada |
| Debug de tests en CI | Codex | Integración nativa con pipelines, patrones de error frecuentes |
| Búsqueda web combinada con código | Gemini | Google Search integrada como herramienta nativa |
| Scripts de automatización CI/CD | Codex | Multimodal, modo aprobación automática para scripts |
| Diseño de arquitectura | Claude | Síntesis y planificación a largo plazo |
claude-octopus implementa este routing con roles explícitos: Codex para profundidad de implementación, Gemini para amplitud de ecosistema y contexto grande, Claude para síntesis y entrega final. Antes de que cualquier salida se envíe, requiere un consenso del 75% entre los modelos. Para tareas donde el coste de un error es alto, ese overhead de latencia se justifica.
El patrón de revisión multi-agente con Claude en producción aplica directamente aquí: Claude implementa, Gemini analiza el contexto completo del repositorio y Codex valida en el entorno de CI. Con Multi-CLI MCP, ese flujo ocurre en una sola sesión.
En producción
Hay cuatro aspectos que cambian cuando pasas del entorno local a un uso real sostenido.
Costes reales. Gemini ofrece 1.000 peticiones gratuitas al día con una ventana de contexto generosa. Para flujos individuales, eso cubre la mayor parte de consultas de análisis y revisión. Claude Code en tareas complejas puede costar entre 2 y 12 € por sesión según el volumen de tokens. Codex sigue su propio modelo de precios por tokens consumidos. La estrategia "free-first" tiene sentido: Gemini para análisis de contexto grande, Claude cuando la precisión en el cambio importa.
Latencia acumulada en cadenas. Cuando el agente delega (Claude llama a Gemini que devuelve el resultado), la latencia se acumula. En tareas interactivas esto es perceptible. Para análisis en background, usa ai-cli-mcp, que ejecuta los procesos de forma asíncrona y devuelve el resultado cuando termina sin bloquear la sesión principal.
Autenticación en servidores remotos. Cada CLI necesita sus credenciales en el entorno donde se ejecuta. Si despliegas esto en un VPS o en un pipeline CI, configura las variables de entorno correspondientes antes de iniciar el MCP server. El mecanismo de fallback que vimos en el artículo sobre pipelines resilientes ante caídas de API aplica aquí: si una API no responde, el agente debe poder enrutar la tarea a otro modelo sin interrumpir el flujo.
Degradación por límites de uso. Cuando Gemini alcanza el límite diario de peticiones, la herramienta ask_gemini devuelve un error que el agente puede capturar y redirigir a Claude. Sin instrucciones de fallback explícitas en el system prompt, el agente puede quedarse esperando una respuesta que no llega. Añade una instrucción del tipo "si ask_gemini falla por límite de cuota, usa ask_codex o responde directamente" para que el flujo sea predecible.
Para contextos grandes, el complemento natural de este setup es la compresión de output de terminal antes de que llegue al agente: reducir el ruido que cada CLI devuelve antes de que entre en el contexto del modelo orquestador evita consumir tokens innecesariamente en el modelo principal.
Errores comunes y cómo resolverlos
Error: las herramientas ask_gemini o ask_codex no aparecen en la sesión.
Causa: el CLI objetivo no está en el PATH del proceso que ejecuta el MCP server.
Solución: ejecuta which gemini y which codex desde el mismo shell donde iniciaste la sesión. Si no devuelven ruta, instala o añade al PATH antes de iniciar.
Error: timeout al invocar un modelo externo.
Causa: la tarea delegada requiere más tiempo del que el cliente MCP espera por defecto.
Solución: usa ai-cli-mcp para tareas largas, que ejecuta los CLI en background y devuelve el resultado cuando termina, sin bloquear la sesión principal.
Error: loop de delegación entre modelos.
Causa: sin protección, un agente puede delegar a otro que a su vez intenta delegar de vuelta.
Solución: multicli lo evita por diseño (excluye las herramientas del modelo activo). Si usas otro servidor, añade una instrucción explícita en el system prompt que prohíba al agente delegarse tareas a sí mismo a través de herramientas externas.
Error: resultados inconsistentes entre sesiones con el mismo prompt.
Causa: los CLIs secundarios inician una sesión nueva sin el contexto de la sesión principal.
Solución: pasa el contexto relevante explícitamente al invocar la herramienta. PAL MCP Server gestiona esto con clink, que pasa el contexto de forma estructurada al subagente y recibe únicamente el resultado final.
¿Necesito pagar por los tres modelos para usar este setup?
No. Puedes empezar con Gemini CLI, que es gratuito hasta 1.000 peticiones al día, y añadir Claude Code o Codex solo para las tareas donde necesitas su precisión adicional. El instalador automático de multicli trabaja con los CLIs que tengas instalados: si solo tienes Gemini y Claude, registra solo esas dos herramientas.
¿Qué diferencia hay con usar un skill de Claude Code para llamar a Gemini?
Un skill requiere invocación explícita y configuración por proyecto. Un MCP server registra las herramientas automáticamente al inicio de cada sesión, y el agente puede decidir usarlas sin que se lo indiques. La diferencia práctica: con MCP el routing puede ser autónomo. El agente evalúa la tarea y decide qué modelo usar basándose en el tipo de tarea y el tamaño del contexto.
¿Funciona con Cursor, VS Code u otros clientes MCP?
Sí. El protocolo MCP es estándar y multicli funciona con cualquier cliente que lo soporte: Cursor, VS Code con la extensión correspondiente, Claude Desktop. La instalación varía según el cliente, pero el servidor es el mismo. PAL MCP Server lo lista explícitamente entre sus clientes soportados, incluyendo Claude Code, Gemini CLI, Codex CLI y Cursor.
Un modelo para cada tipo de tarea
El patrón Multi-CLI MCP no reemplaza a ninguno de los tres agentes: los conecta para que cada uno haga lo que mejor hace. La decisión de routing entre Claude, Codex y Gemini deja de ser manual cuando el MCP server está activo, y el agente puede tomar esa decisión en función del tipo de tarea, el tamaño del contexto y los recursos disponibles.
El punto de entrada más directo es multicli: una instalación, sin configuración adicional, con actualizaciones automáticas. Si necesitas ejecución en background o delegación de contexto limpia, PAL y ai-cli-mcp cubren esos casos. Para revisión cruzada con consenso entre modelos, claude-octopus implementa ese patrón con una capa de validación adicional que tiene sentido en proyectos críticos.
Si ya tienes los tres CLIs instalados, el coste de probar este setup es literalmente un comando. ¿Has encontrado casos donde un solo modelo no era suficiente para la tarea? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. El siguiente tema que exploraré va en esta misma dirección: cómo estructurar pipelines de revisión automática con múltiples modelos directamente en CI/CD.