Claude Code 29 herramientas vs Codex 7 herramientas: filosofías de diseño completamente opuestas

Me cansé de seguir las actualizaciones semanales de Claude Code y Codex, así que volví a los fundamentos. Abrí cada definición de tipo del SDK, cada system prompt, cada esquema de configuración que pude encontrar. Quería entender no solo qué hace cada herramienta, sino por qué la cantidad de herramientas diverge de forma tan dramática.

Claude Code expone 29 herramientas. Codex expone 7. Esa proporción no me dejaba de dar vueltas en la cabeza, porque no puede ser simplemente una brecha de funciones. Dos equipos bien financiados con ingenieros de primer nivel no llegan accidentalmente a una proporción 4:1. La diferencia es intencional, y el razonamiento detrás revela dos filosofías genuinamente distintas sobre cómo debería interactuar la IA con tu entorno de desarrollo.

La granularidad de herramientas es una decisión de seguridad

La diferencia más notable es cómo cada herramienta maneja las operaciones de archivos. Claude Code divide la manipulación de archivos en cuatro herramientas separadas: Read, Write, Edit y MultiEdit. La búsqueda también tiene sus propias herramientas dedicadas, con Grep y Glob completamente independientes de Bash. Esto significa que podés configurar settings.json para permitir Read pero bloquear Write. Podés dejar que el agente busque en tu codebase sin darle nunca permiso para modificar un solo archivo. El control de permisos ocurre a nivel de herramienta.

Codex toma un camino distinto. Le da al agente shell, apply_patch y file_read como primitivas principales. Todo lo demás pasa por el shell. ¿Querés buscar archivos? Es un comando de shell. ¿Querés listar directorios? Shell de nuevo. La seguridad no viene de permisos a nivel de herramienta sino de reglas execpolicy que aplican pattern-matching sobre comandos de shell específicos, clasificándolos en categorías de allow, prompt o block.

Ningún enfoque es incorrecto. El modelo de Claude Code te da cerraduras más finas pero requiere mantener una superficie de herramientas más grande. El modelo de Codex es más simple de razonar pero traslada la aplicación de seguridad al string-matching sobre comandos de shell, lo que se vuelve frágil cuando los comandos se ponen creativos. He visto casos donde una cadena de pipes bien armada bypassea una regla execpolicy que estaba escrita para la versión directa del mismo comando.

El desglose completo:

• Claude Code (29 herramientas): 4 herramientas de archivos (Read/Write/Edit/MultiEdit), 3 herramientas de búsqueda (Glob/Grep/LS), 2 herramientas web, 3 herramientas cron, 4 herramientas MCP, Bash, y más
• Codex (7 herramientas): shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl

El despliegue de Skills divide el ecosistema

Ambas herramientas adoptaron el estándar abierto Agent Skills, donde un único archivo SKILL.md define el comportamiento de un skill. La estructura es idéntica. El modelo de distribución no lo es.

Codex construyó un sistema de distribución centralizado. Ejecutar $skill-installer descarga skills curados del repositorio oficial de skills de OpenAI. Pasando una URL de GitHub también podés instalar skills de terceros. Incluso existe $skill-creator para generar nuevos skills de forma interactiva a través de la conversación. La experiencia se siente como npm: un comando, un registro, disponibilidad inmediata.

Claude Code fue en la dirección opuesta. Creás archivos SKILL.md en .claude/skills/ manualmente, o instalás bundles desde repositorios git a través de /plugin marketplace add. No hay un registro oficial único. Los skills se descubren a través de repositorios de la comunidad, links compartidos y el boca a boca.

Al principio preferí el modelo centralizado de Codex porque la discoverability es mejor. Pero después de usar ambos durante varias semanas, el enfoque descentralizado tiene una ventaja real: puedo editar un archivo de skill a mitad de sesión y los cambios se aplican de inmediato sin reiniciar. Con los skills instalados de Codex, los cambios requieren reinstalación. Cuando estás iterando sobre un workflow personalizado, esa diferencia importa más de lo que esperaba.

Comparación de un vistazo:

• Invocación: Claude Code usa /skill-name, Codex usa $skill-name
• Almacenamiento: .claude/skills/ vs .agents/skills/
• Skills incorporados: Claude Code incluye /simplify, /batch, /loop, /claude-api; Codex incluye $skill-installer, $skill-creator
• Distribución: Marketplace descentralizado vs repositorio centralizado

Los diagnósticos de sesión es donde la brecha se hace real

Ambas herramientas comparten los básicos: /model, /plan, /review, /clear, /fast. La divergencia aparece en la introspección de sesión.

Claude Code invirtió mucho en permitirte entender qué está pasando dentro de tu sesión. /compact dispara manualmente la compresión de contexto. /context muestra qué está cargado. /cost rastrea el gasto de tokens en tiempo real. /doctor diagnostica problemas de configuración. /rewind revierte a un estado de conversación anterior. /insights analiza un mes de patrones de uso y sugiere mejoras. /usage muestra el consumo acumulado entre sesiones. Son siete comandos dedicados únicamente a entender y gestionar el estado de la sesión.

Codex se enfocó en otro lado. /personality ajusta el estilo de comunicación del agente. /theme cambia la apariencia visual. /apps gestiona las aplicaciones conectadas. Estas son funciones de personalización de UX, no herramientas de diagnóstico.

Esto refleja una división filosófica más profunda. Claude Code trata la sesión como algo que deberías monitorear y dirigir activamente. Codex la trata como algo que debería simplemente funcionar en segundo plano mientras vos te enfocás en personalizar la experiencia. Después de meses de uso, me encuentro queriendo los dos. Los diagnósticos me salvan cuando una sesión se descarrila, pero también valoro poder ajustar la personalidad cuando cambio entre trabajo de arquitectura detallado y arreglos rápidos de bugs.

• Claude Code (~35 comandos + 4 skills incluidos): fuerte en diagnósticos de sesión como /compact, /context, /cost, /doctor, /rewind, /insights, /usage
• Codex (~19 comandos): más fuerte en personalización de UX con /personality, /theme, /copy, /apps, /skills, /agent, /tools

Las arquitecturas de equipo parten de supuestos distintos

Cómo maneja cada herramienta la colaboración multiagente revela quizás la diferencia de diseño más profunda.

Los Agent Teams de Claude Code usan comunicación peer-to-peer. Los agentes se envían mensajes directamente entre sí sin pasar por un agente líder. Comparten una lista de tareas y se coordinan de forma autónoma. Podés ejecutar de 2 a 16 agentes, y van a negociar entre sí quién maneja qué. Lo probé con tres agentes en una tarea de refactoring, y el consumo de tokens fue de 3 a 7 veces mayor que una sesión individual haciendo el mismo trabajo. El overhead de coordinación es real. Pero cuando la tarea genuinamente se beneficia de la exploración en paralelo (como debuggear una race condition donde querés agentes probando hipótesis distintas simultáneamente), el modelo P2P encuentra respuestas más rápido.

Codex usa un modelo hub-spoke. Los agentes hijos reportan solo al padre. No hay comunicación lateral. El comando spawn_agents_on_csv crea agentes en masa desde un archivo CSV, optimizado para tareas paralelizables donde cada unidad de trabajo es independiente. Pensá en: “aplicar esta migración a 200 archivos” o “ejecutar esta verificación contra cada endpoint de esta lista.”

P2P no es universalmente mejor. Desperdicié tokens significativos en una tarea de batch directa porque los agentes de Claude Code seguían discutiendo su trabajo superpuesto entre sí. El hub-spoke de Codex habría sido la elección correcta para ese trabajo en particular.

• Claude Code: mensajería P2P con lista de tareas compartida, 2 a 16 agentes, soporte de tmux split-pane
• Codex: arquitectura hub-spoke, creación masiva de agentes por CSV vía spawn_agents_on_csv

La granularidad de hooks determina la profundidad de automatización

Claude Code te permite interceptar la ejecución de herramientas en múltiples puntos del ciclo de vida. PreToolUse se dispara antes de que corra una herramienta, permitiéndote validar o modificar la llamada. PostToolUse se dispara después, para que puedas adjuntar un formateador que corra automáticamente en cada guardado de archivo. Los hooks Notification capturan comunicaciones del agente. PreCompact se dispara antes de la compresión de contexto, dándote la oportunidad de preservar información crítica. Los HTTP Hooks pueden hacer POST de JSON a URLs externas, conectando Claude Code con pipelines de CI, Slack o dashboards personalizados.

Codex lo mantiene simple. Un archivo execpolicy con reglas de allow/prompt/block aplicadas a comandos de shell. Esa es toda la superficie de extensibilidad para controlar el comportamiento del agente.

Configuré un hook PostToolUse que ejecuta Prettier después de cada operación Write. Me llevó cinco minutos y eliminó toda una categoría de prompts de seguimiento relacionados con el formato. Ese tipo de automatización quirúrgica no es posible en el modelo de Codex, donde tendrías que incluir “y ejecutá prettier después de escribir” en cada prompt o construirlo dentro de un skill.

Pero la simplicidad de Codex también tiene valor. Nunca rompí accidentalmente mi configuración de Codex con un hook mal configurado. Lo hice dos veces con Claude Code, una con un hook PreToolUse que bloqueaba silenciosamente lecturas de archivos legítimas y causó veinte minutos de debugging confuso.

• Claude Code: PreToolUse, PostToolUse, Notification, PreCompact y HTTP Hooks
• Codex: archivo de reglas execpolicy con tres niveles (allow/prompt/block)

Elegí la arquitectura, no la lista de funciones

La comparación 29 vs 7 no se trata de que una herramienta sea más capaz que la otra. Se trata de dos respuestas distintas a la misma pregunta de diseño: ¿cuánto debería descomponer un agente de IA sus capacidades en unidades individualmente controlables?

Claude Code dice “todo”. Cada operación tiene su propia herramienta, su propia superficie de permisos, sus propios puntos de hook. Esto te da el máximo control al costo de complejidad de configuración. Codex dice “solo lo esencial”. Las operaciones principales tienen herramientas dedicadas; todo lo demás fluye por el shell con guardianes basados en políticas. Esto te da simplicidad al costo de granularidad.

Cuando elijo qué herramienta usar para un proyecto determinado, la lista de funciones casi no importa. Lo que importa es si el proyecto necesita control de permisos fino (codebase regulada, múltiples contribuidores con distintos niveles de acceso) o simpleza liviana (proyecto solo, iteración rápida, configuración mínima). La arquitectura sobre la que construís moldea cada decisión de workflow que sigue.