Claudex Loop parte de una idea que tiene sentido: el modelo que propone una solución no debería ser el único que la evalúa. Cruza Claude Code y Codex para revisar decisiones, endurecer un plan y examinar el código resultante. El truco está en saber cuándo esa segunda opinión compensa el tiempo y el consumo que añade.
- El proyecto reúne varias skills: revisión puntual, selección de flujo, planificación y construcción.
- El flujo completo necesita ambos CLI instalados y autenticados, además de Python 3.10 o superior.
- La instalación como plugin usa comandos con el prefijo /claudex-loop:.
- Dos modelos de acuerdo pueden seguir estando equivocados. Los resultados necesitan pruebas.
Esta herramienta forma parte del recopilatorio vivo Skills para Claude Code, Codex y otros agentes de código →
Qué hemos revisado
Hemos contrastado el README actual, los problemas publicados en GitHub y la demostración de Chase AI. No hemos ejecutado una comparativa propia de productividad o coste. Las cifras de hallazgos que aparecen en demostraciones del proyecto no prueban cuánto te ahorrará en tu repositorio.
No todo tiene que pasar por el bucle largo
La documentación distingue claudex-route, que ayuda a elegir un recorrido, de claudex-loop, que desarrolla el proceso completo. También incluye codex-review y codex-build. Es una diferencia importante: cambiar un texto y diseñar una migración de datos no requieren la misma ceremonia.
En el recorrido largo se inspecciona el contexto, se resuelven requisitos, se escribe el plan, el otro proveedor lo revisa y se implementa con comprobaciones posteriores. El README vincula las aprobaciones al contenido revisado mediante huellas del plan y del código. Si cambia aquello que se aprobó, la revisión anterior deja de acreditar la nueva versión. Documentación oficial.
| Caso | Qué probaría primero | Qué mediría |
|---|---|---|
| Cambio pequeño y bien definido | Una revisión puntual | Tiempo extra frente a errores útiles detectados |
| Nueva funcionalidad con varias decisiones | Reconocimiento y revisión del plan | Supuestos que cambian antes de programar |
| Migración, permisos o datos delicados | Plan, pruebas de aceptación e inspección final | Fallos reproducibles y criterios que siguen pendientes |
Instalación: el detalle que evita comandos que no existen
La vía de plugin que publica el autor es esta:
/plugin marketplace add chaseai-yt/claudex-loop
/plugin install claudex-loop@claudex-loopDespués, el comando del flujo completo es /claudex-loop:claudex-loop; el selector es /claudex-loop:claudex-route. La instalación manual tiene otras rutas y alias. Mezclar instrucciones de ambos métodos es una forma bastante tonta de perder media hora.
El proyecto indica que no hacen falta claves API separadas: utiliza la autenticación de los CLI. Eso NO hace gratuitas las rondas. Consumen el uso disponible de las cuentas o la facturación configurada en cada herramienta. La reseña anterior confundía esas dos cosas.
El autor lo muestra en vídeo
La demostración de Chase AI, en inglés, comienza en el minuto 3:50. Es especialmente útil para ver cómo el sistema formula preguntas antes de seguir. Chase mantiene el repositorio: este vídeo explica su propuesta, no es una valoración independiente.
Lo que cuentan quienes lo han llevado a un proyecto
«The loop stops when Codex does.»
Describe un problema de disponibilidad: quedarse sin uso de Codex puede interrumpir una revisión ya empezada. Propone alternativas desde su fork. Su experiencia sirve para mirar los límites de ambos proveedores antes de iniciar una tarea larga; no acredita que esa solución esté integrada en la versión principal.
«Three issues found running claudex-loop on macOS»
El informe publicado relata problemas de prerrequisitos y rutas durante una ejecución en macOS. El propio autor indica que el diagnóstico fue redactado por Claude. Lo tratamos como un reporte pendiente de contraste, no como tres fallos que hayamos reproducido.
ujconsulting publicó además una revisión de un fork derivado, con observaciones sobre cómo restringir comandos. Su primera aclaración importa: parte de lo encontrado pertenece a ese fork, no a este repositorio. Trasladar esas conclusiones sin leer el contexto sería acusar al proyecto de código que no tiene.
Qué puede salir mal aunque los dos modelos aprueben
Si ambos reciben un requisito equivocado, pueden perfeccionar la solución equivocada. Si nadie comprueba una integración real, pueden dar por buena una simulación. Y si cuentan como éxito cualquier objeción nueva, el proceso puede hacerse más largo sin mejorar el resultado.
Por eso elegiría una tarea ya conocida y guardaría cuatro cosas: el plan inicial, los cambios que provocó la revisión, las pruebas que realmente se ejecutaron y el consumo. Después clasificaría los hallazgos: error demostrado, decisión útil o preferencia de estilo. El número bruto de objeciones dice bastante menos de lo que parece.
Tampoco confundiría un worktree con una barrera de seguridad. Aislar los archivos de trabajo ayuda a organizar cambios; los permisos de los procesos determinan a qué más pueden acceder. Para una prueba inicial, usa un repositorio de ejemplo y revisa la configuración efectiva de ambos CLI.
Mi veredicto
Claudex Loop resulta más convincente cuando te obliga a concretar lo que habría sido caro descubrir después. Una condición de migración, un límite de permisos, un requisito que nadie había escrito. Ahí una segunda mirada puede pagar varias rondas.
No lo convertiría en una religión. Para un cambio pequeño, empieza por la revisión puntual. Para algo importante, conserva pruebas y decide tú qué hallazgos merecen cambiar el plan. Dos modelos discutiendo no sustituyen a alguien que entienda el objetivo.
