Actualizar costo estimado tras bajar el timer a 60 min

17 corridas/día en vez de 68. Nota importante: el costo por corrida
sube al perder la ventaja del cache tibio de Claude Code (~1h TTL,
corridas espaciadas 60 min lo pierden casi siempre) -- el ahorro real
es ~1.5-2x, no 4x. También documenta el trade-off de latencia de
detección (~70 min en vez de ~25 min hasta detectar un problema).

workloads/docs-portal/docs/arquitectura/agente-monitoreo.md

@@ -9,7 +9,8 @@ autoriza al agente a actuar sin intervención humana, y debe poder
 auditarse.
 
 Estado: **timer de systemd ACTIVO desde 2026-08-26** (`lab-agent.timer`,
-usuario `devops`, cada 15 min entre 06:00–23:00 hora local). Script,
+usuario `devops`, cada 60 min entre 06:00–23:00 hora local — bajado de
+15 a 60 min el mismo día para reducir costo). Script,
 Telegram y las unidades systemd, todo validado en vivo antes de
 activar.
 
@@ -228,7 +229,7 @@ como lo primero que hace tras inicializar logging — si está fuera de
 horario, sale **antes** de tocar `kubectl`/`docker`/`curl` o invocar
 `claude -p`, así que la pausa ahorra el costo completo de la corrida,
 no solo la notificación. El timer de systemd además solo dispara dentro
-de esa ventana (`OnCalendar=*-*-* 06..22:00/15:00`) — la doble
+de esa ventana (`OnCalendar=*-*-* 06..22:00:00`) — la doble
 verificación es deliberada: si alguien edita la unidad de systemd sin
 tocar `lab-agent.env` (o corre el script a mano), el chequeo interno
 sigue protegiendo.
@@ -245,19 +246,31 @@ Pendiente de decisión: mover la ventana de `medusa-deploy` a que caiga
 dentro del horario activo, o aceptar que ese recurso queda cubierto
 solo por diagnóstico/notificación manual.
 
-**Estimación de costo mensual:**
+**Estimación de costo mensual — actualizada 2026-08-26, frecuencia
+bajada de 15 a 60 min explícitamente para reducir costo:**
 
 | | |
 |---|---|
-| Corridas/día (17h activas ÷ 15 min) | 68 |
+| Corridas/día (17h activas ÷ 60 min) | 17 |
-| Costo por corrida (medido en la prueba e2e, Sonnet) | ~US$0.018–0.045 con cache tibia; ~US$0.12 en frío (primera corrida del día, tras 7h de pausa el cache de prompt ya expiró) |
+| Costo por corrida | ~US$0.04–0.12 — **más alto por corrida que a 15 min**: el cache de prompt de Claude Code dura ~1h, y con corridas espaciadas 60 min casi siempre expira entre una y la siguiente, así que la mayoría de las corridas pagan cache "fría" en vez de "tibia" |
-| Estimado diario (1 corrida fría + 67 tibias) | ~US$2.10 |
+| **Estimado mensual (× 30 días)** | **~US$20–60** (punto medio ~US$35) |
-| **Estimado mensual (× 30 días)** | **~US$60–65** (rango US$35–90 según variación real de cache) |
 
-Basado en solo ~7 corridas reales medidas durante la prueba — no es un
+Ojo con la intuición: bajar la frecuencia 4× (68→17 corridas/día) NO
-promedio estadísticamente robusto, es una primera estimación para
+baja el costo 4× — el ahorro real es más cercano a 1.5–2× frente a la
-decidir si el timer se activa. Revisar el costo real después de la
+estimación anterior (~US$60–65/mes), porque cada corrida individual
-primera semana en producción y ajustar frecuencia/modelo si hace falta.
+sale más cara al perder la ventaja del cache tibio. Sigue siendo menos
+costo total, solo que no linealmente. Basado en pocas corridas reales
+medidas — revisar el costo real después de la primera semana en
+producción (Telegram/Gitea Actions no cambian este número, el costo es
+100% de la API de Claude).
+
+**Trade-off de latencia de detección:** con corridas cada 60 min en vez
+de 15, un problema que recién cruza el umbral de 10 minutos puede
+tardar hasta ~70 min en ser detectado y potencialmente corregido (antes
+era hasta ~25 min). Aceptado a cambio del ahorro de costo — si en la
+práctica resulta muy lento para algún incidente real, la frecuencia se
+puede volver a subir sin tocar nada más (`OnCalendar` en
+`lab-agent.timer`).
 
 ## Activación del timer (2026-08-26)