Conclusión en 5 segundos: No se puede demostrar que el autor, Nagano, dibuje de verdad más rápido cuando la historia se pone peligrosa. Pero sí hubo épocas, en arcos largos e inquietantes o en momentos clave, en las que el intervalo entre publicaciones en X se acortó de golpe. Entonces se puede hacer un bot no oficial que vigile la velocidad de publicación como serie temporal y muestre un "índice de peligro de Chiikawa" solo cuando vaya anormalmente más rápido que en el pasado. Y como en septiembre de 2026 la API de X cobra por uso, si vigilas una sola cuenta puedes empezar en pequeño.
🍣. Al día siguiente, otra vez 🍣. Y al otro, otra actualización.
Llegados a este punto, la alarma que suena en la cabeza de los lectores es casi siempre la misma.
"¿Nagano no está actualizando un poco rápido últimamente?"
Y cuando en Chiikawa parece que las actualizaciones van más rápido, lo siguiente que se te pasa por la cabeza, curiosamente, es "¿alguien debería salir corriendo?".
En este artículo convertimos ese instinto lector, tosco pero difícil de tirar, en números. Y además partimos de un PC que ni siquiera tiene Python instalado y llegamos hasta el análisis de datos históricos, la prueba en seco (ejecutar sin publicar nada de verdad), la publicación automática en X y el funcionamiento 24 horas con GitHub Actions. No hace falta descifrar el contenido de ningún ZIP. Basta con copiar y pegar tal cual los 7 archivos del final del artículo.
¿De verdad se actualiza más rápido cuando la cosa se pone fea?
Si miras el historial público, hay bastantes motivos para sentirlo así. En el tramo final del arco de las Sirenas (Seiren), en noviembre de 2023, según el registro público hubo publicaciones 5 días seguidos del 5 al 9 de noviembre, 6 días seguidos del 13 al 18 y 6 días seguidos del 21 al 26. El 26 de noviembre incluso hubo varias publicaciones el mismo día.
El comienzo del arco del Mundo Paralelo, en marzo de 2024, también tuvo publicaciones todos los días del 1 al 8 de marzo, con 2 el día 8.
Pero lo único que se puede decir a partir de eso es que "subió la velocidad de publicación". No significa que el autor lo dibujara ese mismo día. Puede que publicara de golpe material ya dibujado, o que, al ser un arco largo, la publicación se agrupara sin más.
Por eso la pregunta del bot es más estrecha.
No predice los giros peligrosos de la trama, sino que detecta cuán anormal es la velocidad de publicación actual comparada con el propio pasado de Chiikawa.
No es un laboratorio. Es una alarma de Chiikawa.
¿Qué mira el índice de peligro?
Básicamente solo tres cosas.
- Número de publicaciones de los últimos 3 días
- Número de publicaciones de los últimos 7 días
- Cuántos días seguidos lleva publicando
Cada una se compara con la distribución de todo el pasado y se convierte en un percentil: "qué tan arriba está en la historia". Los pesos iniciales son 35 % para las publicaciones de 3 días, 45 % para las de 7 días y 20 % para los días seguidos. Además, si se publica el mismo texto corto o emoji varias veces seguidas, como 🍣🍣, se suma una corrección de broma de +5 por cada repetición extra, hasta un máximo de +15.
Ese +5 no tiene ninguna base académica. Es simplemente la implementación de "si siguen saliendo sushis, da un poco de miedo".
Los tramos iniciales de la pantalla son estos.
- 0 a 54: 🟢 Normal
- 55 a 69: 🟡 Acelerando
- 70 a 84: 🟠 Alerta
- 85 a 100: 🚨 Rapidísimo
¿Cuánto cuesta la API de X?
En la página oficial de precios (Pricing) a fecha de 3 de septiembre de 2026, las tarifas vigentes principales son estas.
| Operación | Tarifa actual |
|---|---|
| Post Read | $0.005 / publicación obtenida |
| Counts: Recent | $0.005 / solicitud |
| Counts: All | $0.010 / solicitud |
| Content Create | $0.015 / publicación |
| Content Create (con URL) | $0.200 / publicación |
Para el análisis histórico no se leen los textos de miles de publicaciones: con Post Counts solo se pide el número de publicaciones por franja horaria. Los Counts del archivo completo se paginan cada 31 días, así que desde el 1 de enero de 2020 hasta el 3 de septiembre de 2026, unos 2,437 días, salen unas 79 solicitudes, es decir, unos $0.79. No es "un centavo por solicitud, así que toda la historia cuesta un centavo". Esa es la pequeña trampa.
La vigilancia en vivo usa Recent Search con since_id y lee solo las publicaciones más nuevas que la última vez. Con 30 publicaciones nuevas, la lectura cuesta unos $0.15. Si emites 10 alertas al mes sin URL, la escritura cuesta otros $0.15. En cambio, una publicación con URL cuesta ahora $0.200, así que la configuración inicial usa INCLUDE_SOURCE_URL=0. Si por amabilidad pones la URL siempre, la factura se convierte de repente en el jefe final.
Los precios pueden cambiar. Antes de usarlo en serio, vuelve a revisar el Pricing oficial y configura un Spending limit (límite de gasto) en el Developer Console.
Si no tengo PC en absoluto, ¿por dónde empiezo?
Necesitas un PC con Windows o macOS, una cuenta de X, una X Developer App, una cuenta de GitHub si quieres que funcione 24 horas, y Python. No hace falta tener Git instalado en local.
Windows
- Instala Python desde su sitio oficial. En el Windows actual también puedes usar el Python Install Manager.
- Abre PowerShell.
- Escribe
py --versionpara comprobar que Python arranca. - Crea la carpeta
chiikawa-danger-bot. - Con el Bloc de notas o VS Code, guarda los 7 archivos del final del artículo con el nombre exacto. Si usas el Bloc de notas, cuida que no se guarde como
bot.py.txt.
macOS
- Instala la versión de macOS desde el sitio oficial de Python.
- Abre la Terminal.
- Comprueba con
python3 --version. - Crea la carpeta
chiikawa-danger-bot. - Guarda los 7 archivos con VS Code, con TextEdit en modo texto plano o con
nano.
¿Cómo se configura X Developer?
Entra en console.x.com con tu cuenta de X, revisa el Developer Agreement (acuerdo de desarrollador) y crea una App. Las credenciales que aparecen al crearla puede que no se vuelvan a mostrar, así que guárdalas en un lugar seguro.
Para leer se usa el Bearer Token. Como el bot publica por sí mismo, esta implementación usa también OAuth 1.0a User Context. Los App permissions deben estar en Read and write.
Necesitas cinco valores.
X_BEARER_TOKENX_API_KEYX_API_SECRETX_ACCESS_TOKENX_ACCESS_TOKEN_SECRET
Si cambiaste de Read only a Read and write, vuelve a generar el Access Token / Secret después del cambio. Si usas un token anterior al cambio de permisos, te saldrá un error 403.
Los valores reales van solo en .env y en GitHub Actions Secrets. Nunca los pegues en un artículo, en un GitHub público ni en capturas de pantalla.
¿Cómo se ejecuta el análisis de datos históricos?
Cuando hayas guardado los 7 archivos del final, en Windows ejecuta esto en PowerShell.
py -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
mkdir data
copy danger_periods.example.csv data\danger_periods.csv
copy .env.example .env
notepad .env
En macOS es así.
python3 -m venv .venv
./.venv/bin/python -m pip install -r requirements.txt
mkdir -p data
cp danger_periods.example.csv data/danger_periods.csv
cp .env.example .env
nano .env
Pega tu Bearer Token real a la derecha de X_BEARER_TOKEN= en .env. Después, en Windows ejecuta
.\.venv\Scripts\python.exe history_analysis.py
y en macOS
./.venv/bin/python history_analysis.py
Verás page=1... avanzando y, si se crea data/history_features.csv, ha salido bien. Ese CSV es la referencia histórica del índice de peligro.
En danger_periods.example.csv he puesto, para comprobar la hipótesis, el final del arco de las Sirenas y el comienzo del arco del Mundo Paralelo. No son "etiquetas de la respuesta correcta sobre el peligro", sino etiquetas manuales para ver si el índice de verdad es distinto entre los periodos peligrosos y los normales.
¿Cómo evitar publicar en X de buenas a primeras?
Aunque ya hayas puesto las otras 4 credenciales en .env, al principio deja BOT_DRY_RUN=1.
Windows:
.\.venv\Scripts\python.exe bot.py
macOS:
./.venv/bin/python bot.py
La primera vez lee los últimos 7 días aproximadamente y solo crea data/state.json; no publica nada en absoluto. Por ejemplo, en pantalla sale algo así.
Índice de peligro de Chiikawa 82/100 🟠 Alerta
Últimos 3 días: 3 publicaciones / 7 días: 6 publicaciones / 3 días seguidos publicando
Mismo marcador "🍣" 2 veces seguidas +5
* No oficial. Es un indicador de broma basado en la frecuencia de actualización.
Y así queda completo ese método de lectura de Chiikawa, absurdamente técnico: Nagano publica varias veces seguidas → Python: "anomalía en la serie temporal" → lectores: "huid".
¿Cómo lo dejo funcionando 24 horas con GitHub Actions?
Crea un nuevo Repository de GitHub en el navegador y sube esto.
bot.pyhistory_analysis.pyrequirements.txt.env.example.gitignoredata/history_features.csv- Si hace falta,
data/danger_periods.csv
Nunca subas .env.
En Settings → Secrets and variables → Actions → New repository secret del Repository, registra las cinco credenciales con los mismos nombres.
Luego, con Add file → Create new file, crea .github/workflows/chiikawa-danger.yml y pega el YAML del final. El valor inicial es BOT_DRY_RUN: "1". Ejecútalo a mano desde la pantalla de Actions y comprueba que termina bien.
Solo cuando pases a producción pon BOT_DRY_RUN: "0". Con POST_MODE: "alert" solo publica cuando la banda de peligro sube un nivel. Con every publica con cada novedad, así que aumentan tanto el coste como la presión sobre la línea de tiempo.
¿Qué hay que respetar como bot automático?
Las Automation Rules de X exigen evitar el spam, la automatización repetitiva y cosas parecidas. Las cuentas automáticas pueden llevar la Automated account label (etiqueta de cuenta automatizada) y dejar clara su relación con la cuenta gestionada por una persona.
En el perfil, indica claramente "bot de fans no oficial" e "indicador de broma hecho con la frecuencia de actualización", y no imites lo oficial. Este ejemplo no da "me gusta" automáticos, no sigue cuentas automáticamente ni responde en masa.
Además, el "índice de peligro" no afirma nada sobre la salud del autor, su velocidad real de dibujo, sus condiciones de trabajo ni lo que pasará en la historia. Lo único que se observa es el patrón de horarios de las publicaciones públicas.
¿Y si quiero complicarlo todavía más?
También se pueden añadir correcciones por día de la semana, clasificar los avisos y los capítulos de la historia, usar características de las imágenes, entrenar con etiquetas hechas a mano, hacer un backtest (comprobación con datos pasados) de cuántos días después de una alerta llegó un capítulo inquietante, o buscar periodos parecidos como el "tipo final de las Sirenas" o el "tipo Mundo Paralelo". Eso sí, aumentan la cantidad de datos y el coste.
Al principio basta con la hora de publicación. En cuanto un bot de broma acaba siendo detección de anomalías en series temporales, ya es suficientemente absurdo.
Entonces, ¿qué se predice al final?
No es "quién lo pasará mal la próxima vez".
Cuán anormal es la velocidad de actualización actual comparada con el Chiikawa del pasado.
Eso es todo.
Pero como en el final del arco de las Sirenas y el comienzo del arco del Mundo Paralelo las publicaciones de verdad se apretaron, ya resulta lo bastante divertido para automatizar esa intuición lectora de "ya está yendo rápido otra vez".
Índice: 85 puntos.
La máquina: "Está en lo más alto de la historia".
Los lectores: "que alguien huya"
