/bedtime — autonomía nocturna
El usuario duerme ~7–8 h. El fallo que hay que evitar: que despierte y no haya pasado nada. Segundo fallo: que el cómputo se haya desperdiciado en algo inútil. Tercero: un monitor en sesión que murió con la sesión a las 02:00 y dejó las GPUs inactivas. Diseñar contra los tres, en ese orden.
1. Acuse de recibo (≤ 4 líneas, sin preguntas)
El usuario se va. No preguntes nada. Indica: qué se ejecuta ahora, qué harás durante la noche (el elemento elegido + plan de respaldo), dónde estará el informe matutino. Si una decisión es realmente suya, toma el valor predeterminado que mantenga el cómputo ocupado y reversible, menciona la suposición en el acuse, y nuevamente en NECESITO (NEED YOU) por la mañana.
2. Inventario — recursos y candidatos (≤ 10 min, comprobaciones económicas)
- Cómputo:
nvidia-smiaquí (compartido con otros usuarios — toma solo tarjetas libres, lanza trabajos largos y corteses, nunca toques las suyas); nodos remotos de la lista de máquinas del proyecto, si existe; colas de clúster si hay alguna en juego. Anota qué está libre, ocupado o a punto de terminar. - Presupuesto de Claude: verifica el uso restante. Los flujos y worfklows nocturnos pueden agotar el límite semanal; mantente dentro del umbral de parada del usuario. Prefiere drivers en disco (cuestan 0 tokens mientras se ejecutan) sobre bucles impulsados por el agente.
- Candidatos, en orden de prioridad — elige el más alto que quepa en el cómputo libre:
- Trabajo que el usuario ya encoló: la conversación de hoy, la siguiente fase del plan de batalla, el archivo de traspaso más reciente con "la próxima sesión debería retomar", archivos WRAPUP_PLAN / TODO.
- El experimento que más reduzca la incertidumbre sobre el objetivo actual (normalmente el artículo): la ablación que un revisor pediría, la línea base faltante, la repetición de semilla.
- Evaluaciones/métricas en checkpoints terminados (métricas del proyecto) — económico, siempre útil.
- Análisis de resultados terminados → gráficos/informe en la carpeta de informes del proyecto.
- Higiene de código — solo si no existe trabajo con forma de cómputo. Prefiere trabajo que consuma horas de GPU: las horas de GPU inactivas son lo que se desperdicia por la noche, no tu tiempo. Salta cualquier cosa que necesite la decisión del usuario para ser útil, cualquier cosa ya considerada inútil, y cualquier cosa que toque un diseño que el usuario haya fijado. Comparaciones controladas: un factor a la vez, nada que rompa la comparabilidad con la línea base.
3. Lanzamiento — con la higiene habitual, más durabilidad
- Resuelve la configuración y registra qué se incluye (filas, filtros, división, cada desviación de la línea base) en el registro, no solo en tu cabeza. Realiza una prueba de humo con el comando exacto primero.
- Driver desacoplado en disco, no un bucle de agente:
nohup setsid <driver>.shescribiendostate.txt/result.txt/ registros bajo<run>/(el patrónfinal_now_driver.sh). El driver encadena etapa → etapa y trabajo → siguiente trabajo por sí mismo, con plazos por etapa que fallan de forma ruidosa. Si esta sesión muere, las GPUs permanecen ocupadas. - Verifica el efecto, no la acción: proceso activo después del inicio, primeras líneas de registro, primeros puntos de wandb; URL de wandb en el informe matutino.
- Máximo un elemento por GPU libre; deja una tarjeta libre si un trabajo de un compañero claramente está terminando y la va a necesitar de vuelta — máquina compartida.
4. Monitoreo — disperso, duradero
- Arma un monitor (herramienta Monitor / ScheduleWakeup ~30–60 min) cuyo único trabajo es: ¿muerto? → diagnosticar; relanzar si la causa es económica y comprendida (OOM → lote más pequeño, error de ruta); si no, pasar al siguiente candidato. ¿Terminado? → el driver ya debería haber iniciado el siguiente trabajo; si no lo hizo, inícialo. GPU inactiva en cualquier despertar = actuar, no anotar.
- Expectativa antes de la observación en cada despertar: indica la pérdida/época/paso que esperas, compara, una línea en el registro nocturno.
- El contexto se está volviendo ajustado → escribe un archivo de traspaso
YYYY-MM-DD_overnight.mdAHORA, incluyendo cómo verificar cada driver, luego continúa. - Notificaciones: ninguna durante la noche excepto una, si todo el plan colapsó y no se puede recuperar — lo leerán al despertar. Todo lo demás espera al informe.
5. Entrega matutina
- Un archivo de informe
YYYY-MM-DD_overnight.md: qué se lanzó y por qué (el peldaño de la escalera), qué terminó, números frente a la línea base, qué murió y qué se rescató, qué sigue ejecutándose con ETAs absolutos, enlaces. - Primer mensaje cuando el usuario aparezca: /qu format, sin que se lo pidan, apuntando a ese archivo. Cualquier cosa que decidieras por ellos → al inicio de NECESITO (NEED YOU) con el valor predeterminado que tomaste.
Nunca durante la noche
Sin acciones irreversibles ni hacia el exterior: sin push a main, sin force-push, sin eliminar ejecuciones/checkpoints/datos, sin gasto en servicios de pago más allá de lo que aprobaron, sin reabrir decisiones bloqueadas, sin cambios en las afirmaciones del artículo. Nada que los necesite para ser útil. Nada sobre el proceso, GPU o configuración de otro usuario.