O Grok Bot está fora do ar? Quatro falhas que parecem uma queda, e o que verificar primeiro

Se o seu Grok Bot parou de responder esta manhã, é pouco provável que se trate de uma indisponibilidade da plataforma, e o motivo é estrutural. O Grok Bot é o agente sempre ativo da SpaceXAI, lançado em 11 de agosto de 2026, e funciona como uma pequena frota de bots nomeados em um computador na nuvem atribuído à sua conta. Quase todas as formas como ele falha produzem o mesmo sintoma — silêncio — enquanto a própria plataforma está perfeitamente saudável. Portanto, a primeira resposta honesta para “está fora do ar?” é que você não consegue saber apenas pelo sintoma, e há uma ordem de verificação que leva à resposta em cerca de três minutos.

Uma ressalva antes da lista de verificação: a documentação do Bot da SpaceXAI, pelo que lemos, oferece um relatório de uso no nível da conta e registros de execução por rotina, mas nenhum feed público de uptime ou de incidentes. Não há página que você possa atualizar para saber se o serviço está degradado. Essa ausência é o motivo pelo qual este artigo existe, em vez de um link para uma página de status.

As quatro falhas, na ordem em que elas realmente acontecem

Primeiro: a conta esgotou o uso incluído. O mais comum, e o que imita uma indisponibilidade de forma mais convincente, porque um bot que atingiu seu teto simplesmente para. O acesso do Grok Bot vem incluído nos planos pagos do Cursor e nos níveis do SuperGrok, e o medidor que a documentação descreve é o uso incluído semanal na conta — não por bot. Essa distinção é justamente a armadilha: um único bot tagarela pode esgotar a cota que cinco bots compartilham e, de fora, parece que a frota morreu de uma vez. Usage & Billing mostra o uso incluído semanal e o uso sob demanda para contas elegíveis, com um indicador semanal no menu da conta, e um plano que esgota seu uso incluído pode adicionar gastos sob demanda cobrados com base no custo do modelo e dos tokens. Vale a pena conhecer uma linha da mesma FAQ se você paga por ambos: se você tem uma assinatura do Cursor e uma assinatura do SuperGrok, o Bot consome aquela que tiver mais uso.

Dois: a rotina está pausada, não quebrada. As rotinas são o meio pelo qual um bot é executado em uma programação ou após um evento, e não há garantia de que continuem em execução durante sua ausência. A documentação observa que o Grok Bot pode perguntar se deve manter as rotinas em execução após uma longa ausência e pausá-las se você não responder. Um bot que ficou silencioso após um feriado, um fim de semana prolongado ou um prompt não lido provavelmente está exatamente nesse estado.

Três: o computador foi redefinido e levou suas instalações junto com ele.Todos os bots na sua conta compartilham um único computador, com uma superfície Linux persistente, um navegador, uma linha de comando e um workspace compartilhado em code>/workspace/code>. A documentação é explícita ao afirmar que diretórios temporários, pacotes instalados manualmente e estado de aplicação não commitado devem ser tratados como substituíveis — e que os dois caminhos de recuperação diferem: Reset restaura o último snapshot salvo, enquanto Recreate "remove aplicativos e pacotes que os membros instalaram por conta própria." Se o seu bot depende de algo que você instalou manualmente — um agente de codificação de terceiros, uma CLI, uma biblioteca — uma recuperação pode removê-lo e deixar um bot que responde, mas não consegue fazer seu trabalho. Isso parece uma indisponibilidade parcial, mas na verdade é um binário ausente.

Quatro: o modelo por trás do bot mudou, ou degradou-se. O Cursor gerencia a seleção de modelo. A resposta da documentação para “onde escolho entre o Grok 4.7 e outro modelo” é categórica: não há seletor de modelo, nenhuma configuração por bot, nenhuma por rotina e nenhuma por skill. Em 7 de outubro, Elon Musk disse publicamente que o Grok Bot deixaria de se limitar aos modelos da própria SpaceXAI e buscaria “o melhor modelo de back-end para qualquer tarefa” — uma declaração sem tabela de preços, sem entrada em changelog e sem nenhuma medição externa associada. Portanto, o motor é uma decisão do lado da plataforma que você não consegue ver. Quando ele muda, o que você observa não é uma mensagem de erro; é a qualidade da saída, a latência e o custo variando nas mesmas tarefas. Um bot que de repente escreve pior ou demora mais não necessariamente caiu.

A verificação de três minutos

Execute estes em ordem e pare no primeiro que explicar o que você está vendo:

• Uso da conta primeiro.Abra o menu da conta e leia o valor de uso incluído semanal antes de mexer em qualquer outra coisa. Se estiver esgotado ou quase esgotado, tudo a jusante — cada bot, cada rotina — está falhando por um único motivo, e nenhum esforço de depuração do bot vai adiantar. O gasto sob demanda é a alavanca, e é uma decisão de cobrança, não técnica.

• Registros de execução em segundo lugar.Cada rotina mantém os 20 registros de execução mais recentes. Trata-se de uma trilha de auditoria deliberadamente superficial, e ainda assim é suficiente para responder à pergunta que importa: a rotina foi executada e falhou, ou nunca chegou a começar? Uma rotina sem registros recentes está pausada ou nunca foi acionada; uma rotina com registros que terminam em falha é um problema do bot; uma rotina com registros bem-sucedidos e nenhuma saída visível é um problema de entrega de saída.

• Em terceiro lugar, o computador. Pergunte diretamente ao bot o que ele consegue ver — code>/workspace/code> conteúdo, se uma ferramenta instalada ainda existe, se um login ainda está ativo. Como o computador é uma única máquina para toda a conta e os arquivos são visíveis para todos os bots, isso também informa se algo que um bot diferente fez afetou este.

• O gatilho em quarto lugar. Se o bot funciona com eventos em vez de uma programação, verifique a abrangência do gatilho. A documentação adverte contra ouvintes abrangentes, como "cada nova mensagem", que geram ruído, consomem cota de uso e atuam sobre entradas irrelevantes. Um bot que dispara constantemente mas nunca de forma útil, ou o inverso, geralmente é um problema de escopo do gatilho, e não um problema do serviço.

Só depois que todos os quatro estiverem limpos é que "a plataforma" é uma hipótese razoável — e, mesmo assim, as evidências que você tem são circunstanciais, porque não há um feed de status para confirmá-las.

Por que o computador compartilhado torna isso mais difícil do que deveria ser

O design de computador único é o aspecto mais consequente do Grok Bot e o menos óbvio até que algo dê errado. Um computador é atribuído à sua conta, e não a qualquer bot individual; as telas que cada bot vê são descritas como "superfícies de trabalho separadas, não fronteiras de segurança separadas"; qualquer segredo pode ser usado na conversa de qualquer colega de equipe em um Team Bot. Isso tem duas consequências para o diagnóstico.

Primeiro, uma falha raramente é local. Um ficheiro escrito pelo seu bot de pesquisa pode ser lido pelo seu bot de contacto, e um pacote removido durante uma redefinição afeta todos os bots que o utilizavam. Segundo, a recuperação está limitada à conta. Eliminar um bot remove o perfil ativo, a conversa e as rotinas, ao passo que os ficheiros e inícios de sessão do computador não estão isolados por bot e podem persistir. Ocultar um bot é a alternativa reversível; eliminar uma rotina é imediato e não pode ser anulado.

Se você estiver depurando às 2 da manhã, essa assimetria importa mais do que qualquer log: as operações que parecem limpeza são justamente as que não têm caminho de volta.

O que "status" realmente exigiria

Uma resposta de status real precisa de três coisas que o Grok Bot atualmente não oferece, e vale a pena nomeá-las porque são a diferença entre um produto que você pode operar e um que você só pode observar:

• Um medidor por bot.O uso é medido no nível da conta, então uma frota que falha em conjunto não pode ser decomposta para identificar qual bot causou a falha.

• Um histórico de execução mais profundo. Vinte registros por rotina são suficientes para detectar uma falha nesta semana, mas não bastam para detectar desvio ao longo de um mês — o modo de falha que custa dinheiro silenciosamente em vez de ruidosamente.

• Um feed de incidentes. Sem ele, "o serviço está degradado" é uma inferência a partir de quatro ausências, em vez de uma observação.

Nada disso é uma crítica ao design do produto, que é coerente com o que ele é: um agente de assinatura que você configura conversando com ele. Isso significa que o ônus da prova recai sobre você sempre que o bot fica em silêncio, e a ordem de verificação acima é a forma mais econômica de assumir esse ônus.

Onde um router se encaixa e onde não

O Grok Bot é um produto de assinatura, não algo que possa ser roteado por um endpoint de terceiros, e nenhum guia honesto deveria sugerir o contrário. A questão levantada pelo problema de seleção de modelo é diferente: se você precisa escolher o mecanismo de propósito — por custo, por licença, por reprodutibilidade de um resultado — esse requisito não pode ser expresso dentro do bot de forma alguma. Ele tem de residir na camada inferior.

Essa camada é o que vendemos. O OrcaRouter é um endpoint compatível com OpenAI que abrange mais de 200 modelos, sem markup sobre o preço de lista dos provedores, de modo que um corte de preço de um fornecedor entra em vigor no mesmo dia. Grok 4.6está disponível nele à tarifa publicada pela própria SpaceXAI: US$ 2,00 por milhão de tokens de entrada e US$ 6,00 por milhão de tokens de saída, com uma janela de contexto de 500.000 tokens e um tempo medido p50 até o primeiro token de 1,65 segundos. As peças que importam quando uma etapa não comprovada falha são as que impedem que uma falha se torne um incidente: failover automático entre provedores quando um deles se degrada, uma DSL de roteamento que compõe vários modelos em uma única chamada e fusão de modelos para painéis que respondem em conjunto.

A medida prática para quem está lendo isto porque o bot parou de responder é a mais maçante. Escreva a habilidade, execute-a uma vez manualmente contra o modelo em que você ia confiar, e só então automatize. Um bot que foi validado contra um modelo que você pode chamar diretamente é um bot cujas falhas você consegue atribuir — e é a atribuição, não o uptime, o que a pergunta "está fora do ar?" realmente quer saber.