Qué es /goal de Claude Code: cómo usarlo, cómo escribir las condiciones y resultados de probarlo en trabajo real

El comando /goal de Claude Code sirve para escribir una condición que defina cuándo se da por terminado el trabajo, y Claude sigue trabajando por su cuenta hasta llegar a ella. Cada vez que termina un turno (una respuesta de Claude), un modelo pequeño y separado comprueba si se ha cumplido la condición. Si no se ha cumplido, Claude pasa al siguiente paso. Este artículo explica cómo usarlo y cuándo se detiene, según la documentación oficial (comprobada el 24 de octubre de 2026), y recoge los resultados de probarlo en trabajos reales de este sitio, incluido el consumo de tokens y la revisión del resultado final.

1. Qué es /goal: diferencia con una petición normal, /loop y los hooks Stop

Cuando pides un trabajo de forma normal, Claude se detiene cuando considera que ha terminado y espera tu siguiente instrucción. Al definir un /goal, se hace una comprobación al final de cada turno (una respuesta de Claude). Si la condición todavía no se cumple, el siguiente turno empieza aunque no envíes nada. La documentación oficial pone como buenos ejemplos estos trabajos más grandes, en los que el estado final se puede comprobar:

• Migrar un módulo a una API nueva, hasta que todas las llamadas compilen y las pruebas pasen
• Implementar un documento de diseño, hasta que se cumplan todos los criterios de aceptación
• Dividir archivos grandes, hasta que cada archivo tenga un tamaño igual o menor al establecido
• Resolver una lista de incidencias etiquetadas hasta que la lista esté vacía

Hay tres mecanismos parecidos. La documentación oficial explica que conviene elegir según «qué inicia el siguiente turno».

En esencia, /goal es un «hook Stop que juzga mediante un prompt», y solo funciona dentro de esa conversación. Un hook Stop se escribe en un archivo de configuración y se aplica a todas las conversaciones. /goal se escribe en el momento y solo se aplica a esa conversación.

Fuente: Keep Claude working toward a goal (documentación oficial de Claude Code, comprobada el 24 de octubre de 2026).

2. Cómo usarlo: configurar, ver el estado y cancelar

Una conversación puede tener un solo objetivo. El mismo /goal sirve para configurar, consultar y cancelar, según lo que escribas a continuación.

1. Configurar: escribe /goal seguido de la condición Ejemplo: /goal las pruebas de test/auth pasan todas y el lint también queda limpio. Al configurarlo, el turno empieza de inmediato y la propia condición sirve como instrucción, así que no hace falta enviar otra petición. Si ya había un objetivo, la nueva condición lo reemplaza. Las condiciones pueden tener hasta 4.000 caracteres.
2. Ver el estado: escribe solo /goal Aparecen la condición, el tiempo transcurrido, el número de evaluaciones, los tokens usados y el motivo de la evaluación más reciente. El número y el motivo aparecen desde la primera evaluación.
3. Detener: /goal clear Elimina el objetivo antes de que se haga una evaluación. stop, off, reset, none y cancel tienen el mismo efecto. Empezar una conversación nueva con /clear también elimina el objetivo.

Si reanudas una conversación, vuelve a aparecer un objetivo que todavía no había terminado. La condición se mantiene, pero los contadores de turnos, tiempo y tokens empiezan de nuevo. Funciona en la aplicación de escritorio, en sesiones remotas y en ejecuciones automáticas con claude -p. claude -p "/goal …" sigue ejecutándose en una sola ejecución hasta terminar el objetivo, así que si quieres ver el progreso, añade --output-format stream-json --verbose.

3. Cómo funciona la evaluación y cuándo se detiene

Cada vez que termina un turno, Claude Code envía la condición y la conversación hasta ese momento a un «modelo pequeño y rápido». El juicio tiene tres resultados, cada uno con un motivo breve. En el entorno de este sitio, el evaluador fue Claude Haiku 5.5 (confirmado en los registros de la conversación).

El evaluador no usa herramientas y juzga solo con lo que aparece en la conversación. No vuelve a leer archivos ni ejecuta pruebas por su cuenta. Si Claude responde al evaluador sin usar ninguna herramienta durante varios turnos seguidos, Claude Code detiene el bucle, muestra una advertencia y te devuelve el control, con el objetivo todavía activo.

Cuando se detiene por un error

Cuando hay subagentes o trabajo en segundo plano

Si al terminar un turno todavía se está ejecutando un subagente o un comando en segundo plano, la evaluación de ese turno se aplaza. Cuando llegan los resultados, llegan a Claude como un nuevo turno. Si pasan 30 minutos de espera, se ejecuta una «comprobación intermedia». Lee la salida del trabajo en curso y, si avanza, espera; si está atascado, pide a Claude que lo corrija o lo detenga. Por defecto, el intervalo se duplica a los 30 minutos, a la hora y a las 2 horas, y después se repite cada 2 horas. Puedes cambiar el primer intervalo con la variable de entorno CLAUDE_CODE_GOAL_CHECKIN_MINUTES. Si la pones en 0, se detienen tanto las comprobaciones intermedias como los reintentos automáticos.

Cuándo no se puede usar y coste

El evaluador forma parte del mecanismo de hooks, así que, como ocurre con los hooks, no se puede usar en carpetas que no hayas marcado como de confianza. Tampoco se puede usar cuando disableAllHooks está en true en la configuración, ni cuando allowManagedHooksOnly está activado en la configuración del administrador. En esos casos se muestra el motivo. Los tokens de la evaluación se facturan a la tarifa del modelo pequeño y rápido. La documentación oficial dice que suelen ser «muy pocos comparados con el trabajo principal». Puedes cambiar el modelo evaluador con ANTHROPIC_DEFAULT_HAIKU_MODEL, pero este ajuste también afecta a otros procesos que usan el modelo pequeño, como el resumen de conversaciones.

Fuente: Keep Claude working toward a goal (comprobada el 24 de octubre de 2026).

4. Cómo escribir una condición

El evaluador solo lee la conversación, así que escribe la condición de forma que la propia salida de Claude pueda demostrarla. La documentación oficial menciona tres elementos de una condición que se mantienen bien en ejecuciones largas.

Si quieres limitar cuánto tiempo se ejecuta, escríbelo dentro de la condición, por ejemplo «o detenerse tras 20 turnos». La documentación oficial no tiene un ajuste dedicado como el presupuesto de tokens de /goal de Codex.

Una advertencia que aprendimos al probar en este sitio: escribe lo que quieres que se mantenga en la propia condición, no en un archivo de instrucciones aparte. El evaluador juzga de forma literal según la condición, así que una instrucción puesta en otro archivo puede contar como «cumplido» aunque no se haya seguido. Esto ocurrió de verdad en el experimento de este sitio (ver capítulo 5).

5. Resultados de dos pruebas con /goal (comparadas con una petición normal)

Usamos /goal para una tarea de este sitio: igualar los puntos finales de las oraciones. En los artículos en japonés había 1.035 casos en los artículos existentes donde el punto final estaba presente o ausente (contados con el script de revisión de puntos finales de este sitio). Como la regla de corrección estaba definida y el estado final estaba claro, «0 casos en la revisión», la elegimos como tarea adecuada para /goal. Ejecutamos /goal dos veces con alcances distintos y, como referencia, colocamos al lado una petición normal.

La prueba de referencia fue una ejecución en la que pegamos la condición de una vez mientras intentábamos /goal; como se describe en la precaución del capítulo 2, no funcionó como comando y se ejecutó como una petición normal. La incluimos en la tabla como valor de referencia para el mismo tipo de tarea pedida de forma normal (el alcance y los recuentos difieren, así que no es una comparación estricta). En las dos ejecuciones con /goal, escribimos /goal a mano, lo seleccionamos y confirmamos la línea «Goal set:». Las ejecuciones se hicieron el 23 de octubre de 2026, en la aplicación de escritorio de Windows con Claude Code 2.1.308, con Claude Opus 5.5 como modelo de trabajo y auto como modo de permisos.

Las cifras se sumaron a partir de los registros de cada conversación (los archivos JSONL que guarda Claude Code). El coste equivalente es lo que Claude Code calculó y registró a tarifa de API; no se factura en el uso con suscripción. Cada resultado procede de una sola ejecución, y el alcance y los recuentos varían entre ellas. Las cifras cambiarían con otro tipo de tarea o modelo. Las escrituras en caché del evaluador corresponden a la cantidad de conversación cargada para juzgar. El coste equivalente es el total del trabajo y del evaluador.

Las condiciones que escribimos realmente

Estas son las condiciones escritas después de /goal en las dos ejecuciones. Los nombres propios de este sitio (el script de revisión, el archivo de notas de trabajo y las herramientas que actualizan los registros) se sustituyeron por palabras que describen qué hacen. Los pasos detallados del trabajo (los precedentes de corrección y los archivos que no deben tocarse) se escribieron en un archivo de notas de trabajo (un archivo Markdown), y la condición apuntaba a ese archivo.

# Ejecución pequeña
En el texto japonés de los artículos 200 a 209 (9 artículos), el script de revisión de puntos finales de oración devuelve 0 casos (muestra en la conversación el resultado de la revisión de cada uno de los 9 artículos), y commit y push están completados siguiendo los pasos de las notas de trabajo. Detenerse tras 30 turnos.

# Ejecución grande
En el texto japonés de los artículos 100 a 199, el script de revisión de puntos finales devuelve 0 casos. Se debe respetar: seguir los pasos de las notas de trabajo (corregir solo la puntuación, según los precedentes decididos; no cambiar palabras, significado, traducciones, metadatos ni herramientas). Al final de cada turno, escribir una línea que diga «quedan ○ casos (○ artículos)». Al final, mostrar en la conversación los resultados de revisión de los 48 artículos incluidos, la lista de archivos modificados (solo el texto y los registros de coherencia), una comprobación de etiquetas superada y el resultado de actualizar los registros de coherencia, y después completar commit y push por ruta. No desplegar. Detenerse tras 40 turnos.

En la ejecución pequeña, «escribir el número restante en cada turno» estaba solo en las notas de trabajo. Claude terminó sin escribirlo, y el evaluador juzgó el objetivo como «cumplido», indicando en su motivo que «la instrucción del procedimiento no se siguió, pero la condición no lo exige». Incorporamos esta lección (capítulo 4) en la condición de la ejecución grande.

Revisión del resultado final

No dimos por bueno sin más el «cumplido» del evaluador. En cada caso revisamos las diferencias línea a línea en otra conversación y repetimos las comprobaciones.

6. Lo aprendido: tareas adecuadas y no adecuadas

Las tareas mecánicas terminan en un turno

Todas las ejecuciones terminaron su trabajo en un turno. Dentro de un turno, Claude puede usar herramientas decenas de veces (la ejecución grande usó Bash 32 veces), así que una tarea que un script puede resolver termina de una vez, incluso con 321 elementos. Por eso la ventaja principal de /goal, «si hace falta más, continuar en el siguiente turno», nunca llegó a aplicarse en este tipo de trabajo. Los resultados vienen de una ejecución por alcance, pero entre la referencia de petición normal y las dos ejecuciones con /goal no vimos una diferencia grande en tiempo ni en calidad final. El coste añadido fue una evaluación por ejecución, y cada evaluación tardó 5,6 segundos y 9,0 segundos (el trabajo completo tardó unos 6 minutos y unos 10 minutos).

El evaluador lee toda la conversación

En la ejecución grande, el evaluador leyó 114.410 tokens, que eran toda la conversación de trabajo transmitida tal cual. Cuanto más larga es la conversación, más pesada es cada evaluación. En trabajos que duran muchos turnos, o si empiezas /goal en mitad de una conversación ya larga, es probable que el coste de la evaluación sea mayor que en esta ejecución.

El evaluador comprueba si se cumple la condición

El evaluador comprobó con precisión los elementos de la condición, como los resultados de la revisión o la existencia de un commit. En cambio, no comprueba cualidades que no aparecen en números, como si una frase se lee con naturalidad. «Cumplido» significa que lo escrito en la condición apareció en la conversación. No sustituye la revisión del resultado final.

Este experimento solo probó los «trabajos que terminan en un turno». A continuación separamos los ejemplos de la documentación oficial de nuestra propia opinión sobre las tareas adecuadas.

7. Diferencias con /goal de Codex

OpenAI Codex también tiene un comando /goal con el mismo nombre. El concepto (seguir trabajando mientras se mantiene una condición final) es el mismo, pero las operaciones y la forma de establecer los límites son distintas. Para las instrucciones detalladas de Codex, consulta Cómo usar /goal en Codex.

Fuentes: para Claude Code, Keep Claude working toward a goal; para Codex, Using Goals in Codex (OpenAI Cookbook) y «Cómo usar /goal en Codex» de este sitio. Ambas vigentes a 24 de octubre de 2026.

Resumen

• /goal es un comando en el que escribes una condición para el final, y un modelo separado la juzga al final de cada turno, manteniendo a Claude trabajando hasta que se cumpla. El mismo comando sirve para configurar, ver el estado y cancelar.
• El evaluador solo lee la conversación. Escribe la condición de forma que su estado final, la forma de comprobarlo y lo que hay que mantener puedan demostrarse con la salida de Claude, e incluye también el límite.
• El modo de permisos no cambia, así que si quieres delegar el trabajo, combina /goal con auto.
• En el experimento de este sitio, una tarea mecánica terminó en un turno incluso con 321 elementos. Para esta tarea de un solo turno, el coste añadido fue una evaluación. Según la opinión de los autores, el beneficio aparece en trabajos que no pueden terminar en un turno.
• «Cumplido» significa que lo escrito en la condición apareció en la conversación. Revisa por separado la calidad del resultado final, como la naturalidad de las frases.
• Al pegar una condición completa en la aplicación de escritorio, puede que no funcione como comando. Confírmalo con la línea «Goal set:».

Pasos para empezar: cambia al modo auto → escribe la condición con la forma del capítulo 4 (estado final, cómo comprobarlo, lo que hay que mantener, límite) → escribe /goal a mano, pega la condición y confirma «Goal set:» → cuando diga «cumplido», lee tú mismo las diferencias.

FAQ

P. ¿Usar /goal aumenta el coste?

Sí, en la medida de las evaluaciones. Las evaluaciones las realiza un modelo pequeño y rápido, y la documentación oficial dice que el coste suele ser «muy pequeño». En el experimento de este sitio, el trabajo que terminó en un turno tuvo una evaluación y tardó unos segundos. Sin embargo, como el evaluador lee toda la conversación, cuanto más larga es, más pesada es cada evaluación.

P. ¿Cómo lo detengo a mitad de camino?

Elimina el objetivo con /goal clear. stop y cancel funcionan igual. Si lo estás ejecutando con claude -p, deténlo con Ctrl+C. Eliminar el objetivo no deshace los cambios hechos hasta ese momento.

P. ¿Puede el evaluador decir «todavía no» aunque Claude diga que ha terminado?

Sí. Por eso juzga un modelo distinto. Si el evaluador dice «todavía no», el siguiente turno empieza usando su motivo como pista. Por el contrario, en cuanto aparecen en la conversación resultados que cumplen la condición, el objetivo queda «cumplido», así que la calidad que no escribiste en la condición no está garantizada.

P. ¿Después de cuántos turnos se detiene?

No hay un límite fijo. Se detiene cuando se cumple la condición, cuando se juzga que no es alcanzable, cuando aparece un error que hay que corregir o cuando la eliminas. Si quieres un límite, escríbelo en la condición, por ejemplo «o detenerse tras 20 turnos». El evaluador solo lee la conversación, así que conviene incluir en la condición algo como «al final de cada turno, indica el número de turnos transcurridos». (Todas las ejecuciones de este experimento terminaron en un solo turno, así que no probamos la detención por límite).

P. ¿Debo usar /loop o /goal?

Usa /goal cuando el estado final esté definido. Usa /loop cuando quieras comprobar lo mismo a intervalos fijos. Por ejemplo, «revisar cada 5 minutos hasta que termine el despliegue» encaja con /loop, y «corregir hasta que pasen todas las pruebas» encaja con /goal.

Referencias: Keep Claude working toward a goal, Run prompts on a schedule y Hooks guide (documentación oficial de Claude Code); Using Goals in Codex (OpenAI Cookbook). Comprobadas el 24 de octubre de 2026.