Empiezas una refactorización a las cuatro de la tarde y cierras el portátil a las seis. A la mañana siguiente, la ejecución ha terminado, sigue en marcha o se detuvo a las 21:40 para hacer una pregunta que nadie estaba allí para responder. Tres situaciones muy distintas que, desde fuera, parecieron idénticas durante toda la noche.
Anthropic afirma que Claude Opus 5.5 puede mantenerse enfocado en una tarea durante 18 horas o más. Tómate eso al pie de la letra. Una ejecución iniciada al final de una jornada laboral no habrá terminado cuando empiece la siguiente. Habrá estado tomando decisiones durante once horas sin ti, y lo único que se interpone entre ella y una mala decisión es lo que hayas dejado escrito antes de irte.
Una ejecución que cabe dentro de tu jornada laboral se supervisa. A una que se prolonga más allá, simplemente se regresa al día siguiente. Son sistemas completamente distintos, y la mayoría de los equipos sigue utilizando el primero.
En resumen
Una ejecución prolongada de un agente es aquella que continúa más allá del momento en que hay una persona presente, por lo que cada decisión que no pueda tomar debe quedar en espera como un estado registrado, en lugar de como una pregunta en una terminal que nadie está leyendo. Para que esto sea seguro, deben cumplirse tres condiciones: una condición de parada que el agente aplique sin ti, un estado de espera de intervención humana visiblemente diferenciado de los estados en progreso o fallido, y una bandeja de entrada que una persona asignada revise por la mañana. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan el rumbo, otorgan autorización y aceptan el resultado. Sharkly reúne las tres en la Tarea.
Qué cambió el 22 de septiembre de 2026
Dos laboratorios lanzaron novedades el mismo día y, entre ambos, transformaron tanto la duración como el coste de una ejecución.
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| ID de API | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| Entrada / salida por millón de tokens | 4 $ / 20 $ | 2 $ / 10 $ | 0,10 $ / 0,50 $ |
| Entrada en caché | 0,20 $ lectura, 5 $ escritura | 90 % de descuento en lecturas | 90 % de descuento en lecturas |
| Contexto | 1M | 872k | 1M |
Anthropic afirma que ejecutar Opus 5.5 cuesta un 40 % menos que Opus 5, genera respuestas cerca de un 30 % más rápido, cuenta con una salida máxima de 128k y puede mantenerse trabajando en una tarea durante 18 horas o más. OpenAI indica que Sol y Luna son un 50 % más económicos que el precio promocional de GPT-5.6; «promocional» es la propia palabra que usa OpenAI, por lo que la comparación se hace frente a una tarifa con descuento y no frente al precio oficial. OpenAI también anuncia un 90 % de descuento en las lecturas de entradas en caché para GPT-6 y señala que modificar el nivel de razonamiento o la disponibilidad de herramientas ya no invalida la caché, algo crucial precisamente para las ejecuciones que duran toda la noche.
De este modo, una ejecución ahora puede ser prolongada y económica a la vez. Sin embargo, la jornada laboral no se ha ampliado para adaptarse a ello, ni tampoco la capacidad humana para asimilar los resultados.
La revisión se invierte
Cuando observas una ejecución en directo, tú actúas como su controlador de errores. Ves que abre el archivo equivocado y la interrumpes. Esa corrección nunca llega a registrarse en ningún log, porque nunca hizo falta que lo hiciera.
Durante la noche, nada de eso existe. Cualquier corrección que habrías hecho en el momento se convierte en una regla predefinida que el agente ya conoce o en una parada obligatoria. No hay una tercera opción. Un agente de larga duración no es simplemente un agente desatendido que ha completado su trabajo; es un agente que llegará a un punto de decisión que tú deberás tomar mientras duermes. Diseña para la parada, no para el final.
Anthropic también reporta un 85 % menos de intentos exitosos de eludir límites en Opus 5.5. Sin embargo, unas probabilidades más bajas no equivalen a una condición de parada. Un modelo al que resulte más difícil desviar de sus instrucciones sigue necesitando un lugar donde dejar una pregunta a las dos de la madrugada.
Tres condiciones imprescindibles
1. Una condición de parada que el agente pueda aplicar sin ti
Consta de dos partes: un límite estricto impuesto por la plataforma y condiciones escritas que el propio agente aplica.
El límite máximo es cuestión de configuración. Un Agent en Sharkly admite un número máximo de Tasks en ejecución paralela y un tiempo límite (timeout) por Task, definido en el propio Agent y no por ejecución individual. Establece ese timeout por encima de la ejecución más larga que desees y por debajo de la más larga que estés dispuesto a pagar. Funciona como un disyuntor, no como una programación horaria.
Las condiciones escritas son la mitad que los equipos suelen pasar por alto. Un agente que nunca se detiene no es diligente: está desatendido.
Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.
When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.
Utiliza un tiempo límite prolongado cuando la Task sea un cambio bien delimitado con pruebas capaces de indicar al agente si ha terminado. Limítalo a una o dos horas cuando la Task sea exploratoria, cuando los criterios de aceptación sean aún una frase sujeta a debate o cuando la ejecución pueda modificar aspectos que no querrías cambiar sin revisión previa. Las puertas de aprobación definen los puntos en los que un agente debe detenerse, incluso cuando tiene plena seguridad.
2. Un estado de espera claramente diferenciado de estar trabajando
En Sharkly, el estado del ciclo de vida de la Task y el estado de trabajo del Agent son registros independientes. Una Task puede figurar como In Progress mientras el Agent está en Working, Waiting for human reply, Waiting for human review o Error. La ejecución subyacente tiene a su vez sus propios estados: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.
Esto puede parecer una simple cuestión administrativa hasta que tienes ocho ejecuciones nocturnas. Sin esta distinción, a las nueve de la mañana el panel mostrará In Progress tanto para un agente que está editando código como para otro que se detuvo hace once horas a la espera de una respuesta. Y te verás obligado a abrir las ocho para averiguar cuál es cuál.
| Lo que ves | Lo que significa | El coste de ignorarlo |
|---|---|---|
| Working | El Runtime está trabajando activamente en la Task | Nada por el momento |
| Waiting for human reply | El agente se detuvo e hizo una pregunta | Cada minuto es capacidad desaprovechada |
| Waiting for human review | El trabajo ha concluido pero no ha sido aceptado | El cambio no se despliega |
| Error / Failed | La ejecución terminó con errores | Un reintento que aún no has puesto en marcha |
El registro de ejecución hace comprensible una parada a la mañana siguiente: por qué se puso en cola una ejecución, cuándo se inició y terminó, las llamadas a herramientas y eventos del Runtime, el origen del activador y los detalles del fallo o cancelación. Eso es lo que revisas en frío, sin acordarte de lo que habías pedido. Consulta estados, registros y señales de fallo para saber qué información registrar si decides implementar esto por tu cuenta.
3. Una bandeja de entrada que revise una persona específica
Un estado de espera sin un responsable asignado espera indefinidamente. Las ejecuciones nocturnas fallan de forma silenciosa, a diferencia de las diurnas, porque no hay nadie presente para advertir el silencio.
El Inbox de Sharkly es una cola personalizada de la actividad de las tareas, y la vista Principal reúne las notificaciones que requieren intervención humana: esperas de tu respuesta, solicitudes de revisión, trabajo fallido o bloqueado, menciones directas y asignaciones. Los fallos de ejecución y las alertas de bloqueo se dirigen a la persona asignada en lugar de a todos los suscriptores; de ese modo, una ejecución que falla a las tres de la madrugada recae sobre alguien concreto en lugar de sobre todo el mundo, lo cual equivale a nadie.
Dos vistas guardadas salvan la mañana: las tareas pendientes de revisión y las tareas asignadas a agentes que se encuentran bloqueadas. Asigna con nombre y apellido a la persona encargada de abrirlas. «El equipo» como tal nunca abre una bandeja de entrada.
La revisión matutina
El orden importa, y no es el que propone el panel por defecto.
- Primero, lo que espera una respuesta humana. Responder reactiva a un agente detenido; revisar, en cambio, no pone nada en marcha. Si la tarea SH-312 lleva esperando desde las 21:40, lo más rápido y productivo que puedes hacer en todo el día es responder con un comentario, lo que pondrá en cola una ejecución de seguimiento en la misma Task.
- Segundo, lo fallido y bloqueado. Lee el título del registro de ejecución y los detalles técnicos antes de reintentar. Un simple código de estado HTTP es solo una pista, no un diagnóstico.
- Tercero, lo que espera revisión. Esta es la cola real de trabajo acumulado, y es la que más crece cuando las ejecuciones se vuelven más baratas.
- Por último, lo que sigue en ejecución. Deja que continúe o cancélalo. Una ejecución cancelada no se reanuda en el mismo punto, pero la Task y su historial se conservan, así que cancélala sin contemplaciones si el rumbo es incorrecto. Eso sí: revisa primero el log.
Lo que esto no resuelve
Las ejecuciones más prolongadas no reducen la necesidad de revisión: la concentran. Una ejecución de 18 horas devuelve un único resultado que condensa toda una noche de decisiones, y una persona sigue teniendo que leerlo, evaluarlo y aceptarlo. Los propios investigadores de OpenAI demuestran a dónde conduce esto: un investigador promedio gasta más de 600 $ al día en inferencia a precios de API, y en el percentil 90 se superan los 7000 $ diarios, mientras que el número de personas disponibles para analizar esos resultados sigue siendo exactamente el mismo. Hicimos los cálculos cuando OpenAI lo publicó, y nada en este lanzamiento altera el denominador.
Unas ejecuciones más baratas y largas permiten hacer más intentos en paralelo, pero no reducen las decisiones que hay que tomar. La revisión humana es el cuello de botella, y una bajada de precios agrava el problema antes de aliviarlo. La automatización se detiene donde entra en juego el criterio del equipo y, cuando lo hace, entrega el trabajo con un contexto completo y evidencias que se pueden auditar.
Preguntas frecuentes
¿De cuánto debería ser el tiempo límite (timeout) por Task para un modelo de 18 horas? Más largo que la ejecución que deseas y más corto que la que lamentarías pagar. Empieza con unas pocas horas para tareas habituales y auméntalo por Agent en aquellas Tasks que realmente requieran toda la noche. El timeout detiene una ejecución que ha entrado en bucle; no define cuánto tiempo requiere un trabajo bien hecho.
¿Qué ocurre con una pregunta que el agente hace a las 2:00 de la madrugada? Debería convertirse en un estado de espera de respuesta humana y en un elemento en el Inbox de la persona asignada, no en una simple línea perdida en el historial de la terminal. Si tu entorno actual la pierde, soluciona esa carencia antes de ampliar cualquier tiempo límite.
Qué significa esto para ti
Ningún proveedor ofrece la pieza verdaderamente importante de este rompecabezas, porque lo crucial es dónde va a parar esa parada y quién asume la responsabilidad por la mañana. El dilema es exactamente el mismo en Claude Code, Codex y cualquier otra herramienta, motivo por el cual la responsabilidad debe recaer en la tarea y no dentro de la sesión de un proveedor concreto.
Si ya dejas agentes ejecutándose por la noche, la prueba es sencilla: abre tu panel a las nueve de la mañana y comprueba si distingue entre un agente que está procesando y otro que lleva esperando desde la noche anterior. Si no lo hace, eso es lo primero que debes corregir, y es justo la capa en la que opera Sharkly: la Task contiene el objetivo, el estado de ejecución, el factor de bloqueo, el resultado y la decisión humana, desde la solicitud inicial hasta el lanzamiento.
