Codex /goal y Claude Code /goal parecen resolver el mismo problema: hacer que un agente siga trabajando hasta alcanzar un objetivo. En la practica, no conviene tratarlos como una funcion intercambiable. La pregunta util no es que agente gana, sino que ciclo debe ser propietario de una tarea larga, que evidencia demostrara que termino y que controles quedan fuera del comando.
Usa Codex /goal cuando la tarea ya vive en Codex, el alcance del repositorio es pequeno y el resultado puede demostrarse con tests, lint, typecheck, snapshot o un diff revisable. Usa Claude Code /goal cuando el trabajo ya esta en Claude Code, importan el workspace local y el modo de permisos, y la condicion de finalizacion puede evaluarse con la evidencia visible en la sesion. Si la tarea requiere criterio humano, cambia mientras se investiga, toca datos de produccion o no tiene regla de parada, no la dejes en un goal loop.
Tablero rapido de decision
| Ruta | Cuando usarla | Prueba antes de empezar | Regla de parada |
|---|---|---|---|
Codex /goal | La tarea encaja en Codex local, CLI o thread flow y debe producir un diff revisable. | Test, lint, typecheck, snapshot o revision de diff pueden probar el cierre. | Pausar, reanudar o limpiar el goal si cambia el objetivo o el diff sale del alcance. |
Claude Code /goal | El trabajo ya esta en Claude Code y el permiso local debe seguir visible. | El evaluador puede juzgar la condicion con outputs, cambios y explicaciones de la sesion. | Limpiar o reemplazar el goal cuando la condicion se vuelva ambigua. |
| Sesion guiada | Hay decisiones de arquitectura, gusto visual, requisitos cambiantes o diagnostico incierto. | Una persona debe decidir despues de cada hallazgo. | Mantener plan/chat mode y no pedir un bucle autonomo. |
| CI / scheduler | La tarea es recurrente, temporal, disparada desde fuera o necesita logs y retry policy. | El workflow, cron o queue tiene su propio estado. | La automatizacion posee el tiempo; el agente solo modifica el workflow. |
Este tablero evita una trampa frecuente en las comparaciones: convertir la decision en un ranking de modelos. Un goal loop sirve cuando el fin puede medirse. Es debil cuando el resultado deseado es estilo, negociacion, investigacion abierta o una migracion amplia que necesita dividirse en unidades revisables.
En resultados en espanol abundan las comparaciones generales entre Claude Code y Codex: quien entiende mejor un repositorio, quien va mas rapido, quien funciona mejor en CLI. Para /goal, el criterio es mas concreto. La pregunta es quien debe seguir iterando, que prueba de finalizacion vera el humano, que acciones estan permitidas y cuando debe detenerse.
Que cambia realmente /goal
La documentacion de OpenAI Codex describe Codex /goal como un slash command experimental ligado a la feature flag de goals. Las formas comprobadas incluyen /goal <objective>, /goal, /goal pause, /goal resume y /goal clear. Por eso no conviene presentarlo como una capacidad permanente e identica en todas las superficies de Codex sin revisar la fuente actual.
La documentacion de Claude Code encuadra /goal como una completion condition. Claude Code sigue trabajando durante varios turnos y, despues de cada turno, un evaluador decide si la condicion se cumple a partir de la evidencia expuesta en la conversacion. Ese detalle importa: la condicion debe poder evaluarse con lo que se ve, no con una esperanza vaga de que el agente ya hizo lo correcto.
La idea compartida es sencilla: escribir una condicion, dejar que el agente avance y recuperar el control cuando parezca satisfecha. El contrato alrededor cambia. Codex puede estar en app, IDE, CLI o cloud routes, cada una con limites de repositorio y revision. Claude Code depende de la sesion, el workspace confiable, permission modes y evidencia visible. La eleccion debe salir de ese contrato operativo, no del nombre del modelo.
Mecanicas que importan antes de alejarte
| Decision | Codex /goal | Claude Code /goal | Por que importa |
|---|---|---|---|
| Activacion | En la fuente comprobada es experimental y usa feature flag. | Requiere version y trusted workspace compatibles. | La disponibilidad es un hecho actual, no una promesa fija. |
| Superficie | App, IDE, CLI y cloud route pueden tener limites distintos. | Sesion de Claude Code, rutas remotas o no interactivas y permisos locales. | El goal no debe asumir otra ruta. |
| Evidencia | Una proof command o diff revisable es lo mas fuerte. | El evaluador mira evidencia visible en la sesion. | Una condicion vaga produce falsa confianza. |
| Permisos | No cambia sandbox, repo access ni approvals. | Permission modes siguen siendo independientes. | Un loop no autoriza acciones. |
| Uso y coste | El trabajo largo puede consumir mas allowance. | Subscription y API-key routing son contratos separados. | Hay que revisar la ruta activa antes de dejarlo correr. |
El error mas facil es escribir un goal como si fuera una orden a un companero humano: arregla todo, mejora el dashboard, termina la migracion. Un agente necesita un contrato mas estrecho. Si la tarea aun es lectura, mapeo o decision, usa plan mode o una sesion normal. Si la tarea debe producir cambios, fija primero branch, setup command, archivos permitidos, proof command y abort rule.
Contrato de objetivo antes de empezar
| Elemento | Suficientemente claro | Demasiado vago |
|---|---|---|
| Estado final | “Los tests de date parsing en packages/billing pasan tras corregir la regresion.” | “Ordena billing.” |
| Comando de prueba | “pnpm test packages/billing -- date pasa.” | “Asegurate de que funciona.” |
| Alcance | “Solo parser, fixtures y regression tests.” | “Cambia lo que haga falta.” |
| Permisos | “Editar codigo esta permitido; comandos destructivos requieren confirmacion.” | “Haz lo necesario.” |
| Control de uso | “Parar tras dos fallos de la proof command.” | “Sigue hasta terminar.” |
| Regla de parada | “Si el problema sale de date parsing, pausa y reporta.” | “Resuelvelo como veas.” |
Un buen goal se parece mas a un acceptance contract que a un prompt. Debe decir que significa terminado, como se prueba, que puede tocarse y cuando debe parar.
hljs textGoal: In Codex CLI, update only checkout discount tests and the rounding helper so pnpm test packages/checkout -- discount passes. Stop if payment provider code must change.
hljs textGoal: In Claude Code, fix heading anchors in docs/api/authentication.md; the goal is complete when docs lint passes. Ask before editing outside docs/api/.
Ambos ejemplos permiten que el revisor vea el exito y el exceso de alcance. Tambien evitan que el agente convierta una tarea pequena en una refactorizacion amplia porque encontro problemas cercanos.
Lo que /goal no sustituye
/goal no sustituye permisos. Si Claude Code esta en un modo que pregunta antes de actuar, el goal no convierte todas las acciones futuras en aprobadas. Si Codex esta bajo sandbox o limites de repo, el goal no amplia ese limite.
/goal no sustituye pruebas. Puedes poner “tests pass” dentro de la condicion, pero las pruebas deben ejecutarse, ser visibles y estar relacionadas con el riesgo. Un test estrecho que pasa no demuestra que una ruta de produccion sea segura.
/goal no sustituye code review. Un diff generado en goal loop sigue siendo un diff. Hay que revisar archivos cambiados, razonamiento, comandos ejecutados y ediciones fuera del alcance. Si el agente hizo trabajo no pedido, el review debe detenerlo.
/goal no limita coste. Una condicion clara puede reducir turnos desperdiciados, pero una tarea larga tambien puede consumir mas allowance. Revisa la ruta activa de Codex o Claude Code, especialmente si hay API key, cloud task o subscription allocation.
/goal no protege secretos ni production data. No metas credenciales, customer records, migraciones irreversibles o cambios de billing en un goal loop. Esas tareas necesitan runbook, backups, staging y aprobacion explicita.
Cuando conviene una sesion normal o CI
Una sesion guiada es mejor cuando el objetivo cambia durante el aprendizaje. Arquitectura, pulido de interfaz, incident triage y planificacion de migraciones necesitan pausas de juicio. Un goal loop puede seguir justo cuando una persona deberia redefinir el problema.
CI, scheduler, queue o repository automation son mejores cuando el problema real es repeticion o tiempo. Una auditoria nocturna de dependencias, un chequeo recurrente de documentacion o una verificacion de despliegue necesitan logs, retry, ownership y alerting. El agente puede escribir el workflow; el workflow debe poseer el bucle.
Si la pregunta sigue siendo que agente adoptar en general, consulta /es/posts/codex-vs-claude-code. Para limites entre Claude subscription y API billing, /es/posts/claude-api-pricing-vs-subscription resuelve otro trabajo. Esta pagina se limita al propietario de /goal.
Patrones practicos de goal
Reparacion de test
hljs textGoal: Fix auth/session-expiry without changing public API behavior. Complete only when pnpm test auth/session-expiry passes and the diff touches only session expiry code and tests.
Funciona porque el fallo tiene frontera conocida, la proof command es estrecha y el diff se puede revisar rapido.
Refactor acotado
hljs textGoal: Rename internal legacyToken helper to sessionToken inside packages/auth only. Complete when typecheck passes and no file outside packages/auth changes.
Puede encajar en Codex si buscas diff revisable, o en Claude Code si ya estas en una sesion local con permission mode claro.
Consistencia de documentacion
hljs textGoal: Update three OAuth setup pages so each includes the same redirect URI warning and docs lint passes. Stop if product behavior must change.
El resultado es limitado y la regla de parada evita que una tarea de docs se convierta en cambio de producto.
Mal goal: mejora amplia
hljs textGoal: Make the dashboard better.
No es una condicion de finalizacion. Primero usa una sesion guiada para listar problemas, luego divide en empty state, focus, loading error o accessibility violation.
Mal goal: riesgo productivo
hljs textGoal: Fix the production billing migration and keep going until it works.
Eso pertenece a un runbook con staging, backup y aprobaciones. Un goal loop no debe poseer riesgo irreversible.
FAQ
Codex /goal y Claude Code /goal son la misma funcion?
No. Comparten la idea de una completion condition, pero el contrato de producto es diferente. Codex /goal aparece como slash command experimental con feature flag; Claude Code /goal se documenta alrededor de una condicion, un evaluador y una sesion.
Cual pruebo primero?
Codex /goal para trabajo bounded dentro de Codex con proof command y diff revisable. Claude Code /goal cuando el trabajo ya esta en Claude Code y los permisos locales importan. Ninguno si el objetivo es vago o riesgoso.
/goal aprueba comandos o ediciones?
No. Finalizacion y aprobacion son controles distintos. Los permission modes de Claude Code siguen importando; sandbox, repo access y review settings de Codex tambien.
/goal reduce coste?
No lo asumas. Un goal claro puede reducir vueltas inutiles, pero un trabajo largo puede gastar mas. Comprueba el plan, la ruta y la API key antes de dejarlo correr.
Que tiene un buen goal?
Estado final medible, proof command o review artifact, alcance estrecho, permission mode conocido, control de uso y abort rule. Si falta algo, pide un plan antes de iniciar el loop.
Cuando CI o scheduler es mejor?
Cuando la tarea es recurrente, temporal, externa o necesita logs, retry y alerting. El agente modifica el workflow; el workflow posee la repeticion.
