¿Está Grok Bot caído? Cuatro fallos que parecen una interrupción del servicio y qué comprobar primero.

Si tu Grok Bot dejó de responder esta mañana, lo más probable es que no se trate de una caída de la plataforma, y la razón es estructural. Grok Bot es el agente siempre activo de SpaceXAI, lanzado el 11 de agosto de 2026, y funciona como una pequeña flota de bots con nombre en una computadora en la nube asignada a tu cuenta. Casi todas las formas en que falla producen el mismo síntoma —silencio— mientras la plataforma está perfectamente sana. Así que la primera respuesta honesta a «¿está caído?» es que no puedes saberlo solo por el síntoma, y hay un orden de comprobación que te lleva a la respuesta en unos tres minutos.

Una advertencia antes de la lista de verificación: la documentación de Bot de SpaceXAI, tal como la leemos, ofrece un informe de uso a nivel de cuenta y registros de ejecución por rutina, pero ningún feed público de disponibilidad ni de incidentes. No hay ninguna página que puedas actualizar para saber si el servicio está degradado. Esa ausencia es la razón por la que existe este artículo en lugar de un enlace a una página de estado.

Los cuatro fallos, en el orden en que realmente ocurren

Uno: la cuenta agotó el uso incluido. El caso más común, y el que imita un apagón de forma más convincente, porque un bot que ha alcanzado su límite simplemente se detiene. El acceso de Grok Bot está incluido en los planes de pago de Cursor y en los niveles de SuperGrok, y el medidor que describe la documentación es el uso incluido semanal de la cuenta, no por bot. Esa distinción es toda la trampa: un solo bot parlanchín puede agotar la asignación que comparten cinco bots y, desde fuera, parece que toda la flota murió a la vez. Usage & Billing muestra el uso incluido semanal y el uso bajo demanda para las cuentas elegibles, con una lectura semanal en el menú de la cuenta, y un plan que agota su uso incluido puede añadir gasto bajo demanda facturado a partir del coste del modelo y de los tokens. Una línea de esas mismas preguntas frecuentes vale la pena conocer si pagas por ambos: si tienes una suscripción a Cursor y una suscripción a SuperGrok, el Bot usa la que tenga más uso.

Segundo: la rutina está en pausa, no rota. Las rutinas son la forma en que un bot se ejecuta según un horario o después de un evento, y no se garantiza que sigan funcionando durante tu ausencia. La documentación señala que Grok Bot puede preguntar si se deben mantener las rutinas en funcionamiento tras una ausencia prolongada y pausarlas si no respondes. Un bot que se quedó en silencio después de unas vacaciones, un fin de semana largo o un aviso sin leer probablemente se encuentra justo en ese estado.

Tres: el equipo se restableció y tus instalaciones se perdieron con él. Todos los bots de tu cuenta comparten un único equipo, con una superficie Linux persistente, un navegador, una línea de comandos y un espacio de trabajo compartido en code>/workspace/code>. La documentación indica explícitamente que los directorios temporales, los paquetes instalados manualmente y el estado de la aplicación sin confirmar deben tratarse como reemplazables — y que las dos rutas de recuperación difieren: Reset restaura la última instantánea guardada, mientras que Recreate "elimina las aplicaciones y paquetes que los miembros instalaron por su cuenta". Si tu bot depende de algo que instalaste manualmente — un agente de programación de terceros, una CLI, una biblioteca —, una recuperación puede eliminarlo y dejar un bot que responde pero no puede hacer su trabajo. Eso parece una interrupción parcial cuando en realidad falta un binario.

Cuatro: el modelo detrás del bot cambió o se degradó. Cursor gestiona la selección del modelo. La respuesta de la documentación a «¿dónde elijo entre Grok 4.7 y otro modelo?» es rotunda: no hay selector de modelo, ni ajuste por bot, ni por rutina, ni por habilidad. El 7 de octubre, Elon Musk dijo públicamente que Grok Bot dejaría de estar limitado a los modelos propios de SpaceXAI y buscaría «el mejor modelo de back end para cualquier tarea dada» —una declaración sin lista de precios, sin entrada en el registro de cambios y sin medición externa adjunta. Así que el motor es una decisión del lado de la plataforma que no puedes ver. Cuando cambia, lo que observas no es un mensaje de error; es la calidad de salida, la latencia y el costo desviándose en las mismas tareas. Un bot que de repente escribe peor o tarda más no necesariamente se ha caído.

La comprobación de tres minutos

Ejecútalos en orden y detente en el primero que explique lo que ves:

• Primero, el uso de la cuenta. Abre el menú de la cuenta y consulta la cifra de uso incluido semanal antes de tocar cualquier otra cosa. Si está agotado o casi agotado, todo lo que viene después —cada bot, cada rutina— está fallando por una sola razón, y por mucho que depures el bot no servirá de nada. El gasto bajo demanda es la palanca, y es una decisión de facturación, no técnica.

• Los registros de ejecución en segundo lugar. Cada rutina conserva los 20 registros de ejecución más recientes. Se trata de un historial de auditoría deliberadamente superficial, y aun así basta para responder a la pregunta que importa: ¿la rutina se ejecutó y falló, o nunca llegó a iniciarse? Una rutina sin registros recientes está en pausa o nunca se activó; una rutina con registros que terminan en fallo es un problema del bot; una rutina con registros exitosos pero sin salida visible es un problema de entrega de la salida.

• La computadora, en tercer lugar. Pregúntale directamente al bot qué puede ver — code>/workspace/code> contenido, si una herramienta instalada todavía existe, si un inicio de sesión ha sobrevivido. Como la computadora es una sola máquina para toda la cuenta y los archivos son visibles para todos los bots, esto también te dice si algo que hizo otro bot ha afectado a este.

• El disparador, en cuarto lugar. Si el bot se ejecuta por eventos en lugar de según un calendario, revisa la amplitud del disparador. La documentación advierte contra los escuchadores amplios, como "cada mensaje nuevo", que generan ruido, consumen cuota de uso y actúan sobre entradas irrelevantes. Un bot que se activa constantemente y nunca de forma útil, o lo contrario, normalmente es un problema de delimitación del disparador y no un problema del servicio.

Solo después de que las cuatro estén limpias es «la plataforma» una hipótesis razonable — e incluso entonces, la evidencia que tienes es circunstancial, porque no hay un feed de estado con el que confirmarla.

Por qué el ordenador compartido hace que esto sea más difícil de lo que debería ser

El diseño de un solo ordenador es lo más trascendente de Grok Bot y lo menos evidente hasta que algo falla. Se asigna un ordenador a tu cuenta, en lugar de a cada bot individual; las pantallas que ve cada bot se describen como «superficies de trabajo separadas, no fronteras de seguridad separadas»; cualquier secreto puede utilizarse en la conversación de cualquier compañero de equipo en un Team Bot. Eso tiene dos consecuencias para el diagnóstico.

En primer lugar, un fallo rara vez es local. Un archivo escrito por tu bot de investigación puede ser leído por tu bot de prospección, y un paquete eliminado durante un restablecimiento afecta a todos los bots que lo utilizaban. En segundo lugar, la recuperación está acotada a la cuenta. Eliminar un bot suprime el perfil activo, la conversación y las rutinas, mientras que los archivos del ordenador y los inicios de sesión no están aislados por bot y pueden persistir. Ocultar un bot es la alternativa reversible; eliminar una rutina es inmediato y no se puede deshacer.

Si estás depurando a las 2 de la madrugada, esa asimetría importa más que cualquier registro: las operaciones que parecen de limpieza son las que no tienen vuelta atrás.

Lo que "status" realmente requeriría

Una verdadera respuesta de estado necesita tres cosas que Grok Bot actualmente no te ofrece, y vale la pena nombrarlas porque son la diferencia entre un producto que puedes operar y uno que solo puedes observar:

• Un medidor por bot. El uso se mide a nivel de cuenta, por lo que una flota que falla en conjunto no puede descomponerse para determinar qué bot lo causó.

• Un historial de ejecuciones más profundo. Veinte registros por rutina bastan para detectar un fallo esta semana, pero no para detectar una desviación a lo largo de un mes — el tipo de fallo que cuesta dinero en silencio en lugar de hacerlo de forma ruidosa.

• Un feed de incidentes. Sin uno, «el servicio está degradado» es una inferencia a partir de cuatro ausencias en lugar de una observación.

Nada de eso es una crítica al diseño del producto, que es coherente para lo que es: un agente de suscripción que configuras hablándole. Sí significa que la carga de la prueba recae sobre ti cada vez que el bot se queda callado, y el orden de verificación anterior es la forma más económica de asumirla.

Dónde encaja un router y dónde no

Grok Bot es un producto de suscripción, no algo que puedas enrutar a través de un endpoint de terceros, y ninguna guía honesta debería sugerir lo contrario. La cuestión que plantea el problema de selección de modelo es diferente: si necesitas elegir el motor a propósito —por coste, por licencia, por reproducibilidad de un resultado—, ese requisito no puede expresarse dentro del bot en absoluto. Tiene que residir en la capa inferior.

Esa capa es lo que vendemos. OrcaRouter es un único endpoint compatible con OpenAI para más de 200 modelos, sin recargo sobre el precio de lista del proveedor, así que una rebaja de precio de un proveedor está activa el mismo día. Grok 4.6 está disponible en él a la tarifa publicada por SpaceXAI de $2.00 por millón de tokens de entrada y $6.00 por millón de tokens de salida, con una ventana de contexto de 500,000 tokens y un tiempo medio (p50) medido hasta el primer token de 1.65 segundos. Las piezas que importan cuando falla un paso no probado son las que evitan que un fallo se convierta en un incidente: conmutación automática por error entre proveedores cuando uno se degrada, un DSL de enrutamiento que combina varios modelos en una sola llamada y fusión de modelos para paneles que responden juntos.

El movimiento práctico para cualquiera que esté leyendo esto porque su bot se quedó en silencio es el aburrido. Escribe la habilidad, ejecútala una vez a mano contra el modelo en el que ibas a confiar y solo entonces automatízala. Un bot que se ha validado contra un modelo al que puedes llamar directamente es un bot cuyos fallos puedes atribuir — y la atribución, no el tiempo de actividad, es lo que realmente pregunta "¿está caído?".