Cómo se calcula la predicción

1. Intervalos. Se toman los intervalos en horas entre los días de reinicio global más recientes (hasta 8), no parciales ni Banked. Los créditos Banked se excluyen por completo de esta lista: un Banked Reset se acredita a una cuenta y lo canjea el usuario cuando quiere, no es algo que Anthropic aplique a todos al mismo tiempo, así que no es un dato sobre el ritmo de los reinicios globales. Los días sin hora exacta de anuncio se anclan a las 12:00 UTC. avg_gap_h = su media. Menos de 3 intervalos → predicción no disponible.
2. Línea base B = clamp(24 / avg_gap_h, 0.06, 0.55) — qué fracción de un "día de reinicio" representan 24 horas, dado el intervalo típico.
3. Término de ritmo — dos variantes, elegidas por backtesting. Este sitio prueba dos formas de convertir la línea base en una probabilidad para el mismo día, y usa la que realmente haya obtenido mejor puntuación frente al historial (ver abajo), no una elección fija:
   • cooldown — C = clamp(hours_since_last / (avg_gap_h × 0.55), 0.18, 1.75), cad24 = clamp(B × C, 0, 1). Baja justo después de un reinicio, y sube cuanto más tiempo pasa — asume que los reinicios se vuelven más probables cuanto más se espera.
   • memoryless — cad24 = 1 − e−24/avg_gap_h, la probabilidad de que un proceso de Poisson con intervalo medio avg_gap_h produzca al menos una llegada en las próximas 24h. Sin ningún término de cooldown: la misma probabilidad cada día, sin importar cuánto tiempo haya pasado desde el último reinicio (deliberadamente no es solo B — es una curva distinta, no simplemente la línea base sin multiplicar).
   Seleccionado actualmente: memoryless — elegido automáticamente porque obtuvo una puntuación Brier más baja (mejor) en el backtest que la otra variante (ver el historial de rendimiento abajo); en caso de empate se elegiría memoryless. Esto no es una elección de estilo: nuestro propio backtest hacia adelante del historial de reinicios de Claude, más un backtest publicado por un competidor y un benchmark de un tercero, coincidieron en que el multiplicador cooldown no supera de forma fiable a un modelo memoryless — así que la fórmula ahora lo comprueba en cada build en lugar de asumir que cooldown es correcto.
4. Señales (cada una entre 0 y 1, con decaimiento de vida media de 24h, descartadas después de 7 días):
   • Official (peso 0.55) — la publicación candidata con mayor puntuación: negada ("no habrá reinicio"/"won't reset") = 0; tiempo futuro con una palabra temporal específica (un día de la semana, "hoy", una hora concreta) = 1.0; solo tiempo futuro = 0.6; en cualquier otro caso 0.
   • Status (peso 0.25) — suma de los pesos de impacto de incidentes relevantes abiertos/recientes (menor 0.35, mayor 0.7, crítico 1.0), cada uno con su propio decaimiento según su antigüedad, con un tope de 1. Nunca se ha sometido a backtest (el de abajo solo evalúa el término de ritmo) — se mantiene como una heurística fijada a mano, no probada contra el historial.
   • Issues (peso 0, solo contexto — no se usa en la predicción) — aumento de issues en GitHub: clamp((recent_24h / max(baseline_per_day, 0.5) − 1) / 3, 0, 1), sin decaimiento temporal. Se sigue mostrando en Estado y en la franja de señales de la página principal, pero ya no alimenta S — ver la nota de abajo.
   S = 0.55·official + 0.25·status (el peso de issues es 0, y los dos pesos restantes no se renormalizan para sumar 1 — 0.55+0.25=0.80 a propósito).
5. Combinar. p24 = clamp(1 − (1−cad24)(1−S), 0.01, 0.95). Es una composición de probabilidades, no un aumento multiplicativo: con cad24 cerca de cero (por ejemplo, justo después de un reinicio), una forma multiplicativa (B×C×(1+S)) haría que incluso una señal en vivo fuerte apenas moviera el número. Combinarlas como probabilidades casi independientes mantiene el significado de una señal real sin importar en qué punto esté el término de ritmo.
6. 48h. p24′ = la misma fórmula evaluada 24h a partir de ahora (cooldown más avanzado, señales más decaidas). p48 = clamp(1 − (1−p24)(1−p24′), p24, 0.95) — nunca menor que p24.

Hasta el 2026-09-23, el aumento de issues de GitHub aportaba el 20% de la señal combinada S. Ya no es así — su peso es 0, y no se renormaliza para compensarlo. Hicimos un backtest hacia adelante de la señal de issues frente a reinicios globales reales, usando una muestra mucho mayor de la que Claude tiene por sí solo: el historial de 385 días de openai/codex, con 46 reinicios globales. Resultados, en nuestras propias palabras:

• A primera vista, las quejas sí parecían aumentar antes de un reinicio — pero resultó ser dos tendencias no relacionadas que crecían al mismo tiempo (el volumen de issues creció alrededor de 6× interanual, y además los reinicios se agruparon más en los últimos tiempos). Al mezclar las fechas de reinicio dentro del mismo mes, el efecto aparente desapareció (p=0.40).
• Evaluado honestamente, fuera de muestra, avanzando día a día: añadir la señal de issues no mejoró las predicciones a 24h, y empeoró de forma medible las predicciones a 48h (peor) (puntuación Brier +0.0038, IC del 95% [+0.0010, +0.0072] — todo el intervalo de confianza está del lado "peor" de cero).
• El propio historial de Claude (12 días de reinicio global) era una muestra demasiado pequeña para mostrar nada por sí solo — esto no es "Claude se comportó distinto", es "no hay datos suficientes para saberlo".

Reconsideraremos esto cuando Claude tenga 30 o más reinicios globales con marcas de tiempo precisas: repetiremos el mismo backtest con los datos propios de Claude, y solo reincorporaremos la señal de issues si tanto la mejora del Brier score como la del log-loss son con confianza mejores que cero (intervalo de confianza enteramente del lado "mejor") y una prueba placebo de ruido aleatorio sale limpia (p<0.05). Hasta entonces se sigue rastreando y mostrando como contexto, sin usarse para calcular nada.

La señal de status (incidentes abiertos) tampoco se ha sometido nunca a backtest — se mantiene como una heurística fijada a mano, no porque se haya demostrado que funciona, sino porque nada ha demostrado que no funcione.

• Intervalo promedio14.0 días
• Horas desde el último reinicio446.0
• Modelo de ritmo en usomemoryless
• Línea base B0.0712
• Cooldown Cn/d (modelo memoryless)
• Término de ritmo cad240.0687
• Señal official0.0
• Señal status0.2683
• Señal issues0.0528
• Señal combinada S0.0671
• p2413%
• p4822%

La confianza es baja ahora mismo. No existe un nivel "alto". Media requiere todo lo siguiente: al menos 10 intervalos históricos no parciales, no Banked (globales), que la variante de ritmo seleccionada (memoryless) supere a la línea base climatology en el backtest, y que las dos fuentes de señal que realmente usa la predicción — official y status — se hayan obtenido en las últimas 6 horas sin fallos. (Issues se rastrea pero ya no forma parte de la predicción, así que un fallo al obtenerla no afecta esto.) De lo contrario es baja.

• el modelo de ritmo seleccionado (memoryless) todavía no supera la línea base climatology en el backtest

Historial de rendimiento (solo término de ritmo)

Backtest hacia adelante sobre 95 días UTC históricos: para cada día se calcularon cuatro predicciones candidatas usando solo los días de reinicio conocidos antes de ese día, y se puntuaron frente a si realmente hubo un reinicio, usando el puntuación Brier (más bajo es mejor). Solo cooldown y memoryless se usan para calcular una predicción en vivo — el que de los dos obtenga menor puntuación aquí es el que se usa en vivo (arriba); en caso de empate se elige memoryless. naive y climatology son solo líneas base de referencia, nunca candidatas que el sitio vaya a servir; por construcción aquí son la misma tasa de "días de reinicio hasta ahora / días observados hasta ahora" — naive conserva el nombre de la especificación original por continuidad, climatology es contra lo que se compara la confianza.

• cooldown0.0722
• memoryless (seleccionado)0.0691
• línea base naive0.0691
• línea base climatology0.0691

La variante de ritmo seleccionada actualmente no supera a la línea base climatology. Esta comparación es nuestro propio backtest del historial de reinicios de Claude, no cifras de terceros. Solo se hace backtest del término de ritmo — las señales en vivo (official/status/issues) no tienen registro histórico de cómo se veían en días pasados, así que nunca se someten a backtest, solo se explican arriba.

• Intervalo mediano10 días
• Intervalo medio14.1 días
• Intervalo más corto3 días
• Intervalo más largo47 días

Calidad de los datos: 9 de 11 días de reinicio global registrados provienen del archivo público de claude-resets.com (sin publicación original, sin hora exacta — se cuentan como las 12:00 UTC de ese día, ver Acerca de). El tramo más largo sin ningún reinicio registrado dura 47 días, 2026-07-16 → 2026-09-01 — eso podría ser un hueco en lo registrado en lugar de un periodo realmente tranquilo, lo que inflaría el avg_gap_h de arriba y, con él, todo el término de ritmo.

• Muestra pequeña. Claude ha tenido hasta ahora un puñado de reinicios registrados — cada estadística aquí puede variar mucho con un solo dato más.
• Los reinicios son discrecionales. Anthropic los anuncia de forma puntual, a menudo ligados a un lanzamiento o un incidente — no hay un calendario subyacente que una fórmula pueda estar estimando realmente.
• Los pesos se fijan a mano, no se ajustan. Los pesos de señal 0.55 (official) y 0.25 (status), y cada clamp de arriba, son heurísticas elegidas, no el resultado de ajustar un modelo a los datos.
• Sin backtest de la parte de señales. Solo el término de ritmo se comprueba contra el historial (arriba) — la contribución de las señales en vivo no se ha probado contra el pasado.