Grok 4.7 no terminal: vale a pena deixar o modelo conduzir uma sessão longa de linha de comando?

Fala aí, beleza? A SpaceXAI acabou de soltar o Grok 4.7 vendendo a ideia de sessão de codificação de várias horas, e isso muda a pergunta que a gente faz sobre um modelo

Não é mais "ele escreve um código bonito?"

É "eu posso abrir o terminal, dar uma tarefa e ir tomar um café sem voltar pra um repositório destroçado?"

A página oficial de anúncio subiu hoje, 21/09/2026, e o preço de entrada chamou atenção geral. Mas antes de sair trocando teu setup, vale separar o que está confirmado do que é hype de thread. Bora?

O que a SpaceXAI anunciou no Grok 4.7

O fato mais duro primeiro: a página Introducing Grok 4.7 está no ar, publicada em 21/09/2026

E sim, a empresa que faz o Grok hoje se apresenta como SpaceXAI. O nome substituiu a marca xAI nas páginas oficiais em x.ai e docs.x.ai, então se tu procurar por "xAI" e estranhar a assinatura, é isso mesmo

O posicionamento do lançamento é codificação e knowledge work, com destaque pra codificação de várias horas. A cobertura independente saiu no mesmo dia em veículos como Neowin, unite.ai e the-decoder

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O número que veio junto: US$ 2 por milhão de tokens de entrada na API

Esse é o preço que virou manchete, e ele é agressivo frente aos concorrentes

Só que, sendo honesto: dentro da própria casa o número não é novidade. É exatamente o mesmo piso de entrada que o Grok 4.6 já cobra em prompt abaixo de 200 mil tokens. O que mudou foi o modelo por trás, não a etiqueta

Agora a parte que quase ninguém escreve: não existe medição pública independente do modelo novo até agora. As páginas vivas do Artificial Analysis listam até o Grok 4.6, e não tem página de modelo pro 4.7 nesta data

Então qualquer ranking, score ou comparação numérica com Claude ou GPT que tu ver circulando hoje não tem de onde sair. Eu acho zoado botar número por achismo, então aqui não vai ter 😉

A herança do Grok 4.6: tarefas longas e o pedágio dos 200 mil tokens

Por que falar do antecessor num post sobre o modelo novo?

Porque a linha já vinha apontada pra esse lado, e porque a estrutura de preço do 4.6 é a melhor referência que existe hoje de quanto uma sessão longa pesa no bolso

O Grok 4.6 foi lançado em 12/08/2026 com foco declarado em agentes de longa duração, descrito como um modelo que permanece em tarefas complexas ao longo de muitos passos

Na API ele aparece como ID grok-4.6, com janela de contexto de 500 mil tokens

E aqui vem o detalhe que muita gente só descobre na fatura: a cobrança é por faixa de tamanho de prompt

Repara no pulo

Quando a requisição cruza os 200 mil tokens, a requisição inteira passa pra faixa de cima, não só o excedente

E o que é uma sessão longa de terminal, na prática? É um contexto que só cresce: cada comando rodado, cada saída de teste, cada stack trace, cada arquivo lido vai empilhando ali dentro

Ou seja, a sessão de várias horas é justamente o cenário que empurra o prompt pra faixa cara. Tome cuidado com isso ao fazer conta de guardanapo

Sobre o 4.7 eu não vou chutar: se ele cobra por faixa igual, qual é o preço de saída dele e qual é a janela de contexto, nada disso apareceu confirmado até agora. O único número oficial na mesa é o US$ 2 de entrada

O que muda quando o modelo conduz o loop sozinho no terminal

Tira a mística da coisa por um segundo

O ganho de uma sessão conduzida não é o modelo escrever código melhor. É ele rodar o comando, ler a saída e decidir o próximo passo sem tu no meio

Se você já usou qualquer agente de terminal, conhece o ritmo: ele edita, roda a suíte, três testes quebram, ele lê o erro, corrige, roda de novo

É como contratar alguém bom, mostrar o critério de aceite e virar as costas. Funciona enquanto o critério de aceite existir

E é aí que mora a diferença entre economizar duas horas e voltar pro computador com um commit gigante que ninguém entende

O preço disso, além do token, é atenção invertida: tu para de revisar linha e passa a revisar o resultado final e o diff

Pra não se ferrar, o que precisa estar pronto ANTES de largar a sessão rodando:

• Um teste que falha alto: suíte verde ou vermelha, sem "mais ou menos". Se o sinal de sucesso for você olhando a tela, não é sessão autônoma, é babá
• Git limpo: branch separada, nada de trabalho não commitado no caminho. Misturar tua mudança com a do agente na mesma árvore vira garimpo chato depois, e não tem coisa mais sem graça que ficar separando o que era teu do que era dele
• Escopo fechado: "migrar essa dependência mantendo a suíte verde" é escopo. "melhorar o projeto" não é
• Limite de tempo e de gasto: sessão longa sem teto é fatura surpresa

git checkout -b migracao-agente
git status

Branch nova e árvore limpa. Parece básico, mas é o que separa "deu ruim, joguei fora" de "deu ruim, perdi a tarde"

Um ponto que ninguém lembra: sessão de várias horas depende do serviço estar de pé o tempo todo. Se a coisa cair no meio, vale saber como checar o status do Grok antes de sair culpando teu código

Que tarefas de linha de comando cabem numa sessão conduzida

O critério de corte é um só, e eu vou repetir até cansar: existe uma forma automática de dizer se deu certo?

Se existe, entra. Se não existe, sai

Entra:

• Migração de dependência ou de framework com suíte verde como gabarito: o teste é o juiz. O modelo tenta, roda, quebra, corrige, e você mede o resultado num comando só
• Refatoração mecânica repetida em muitos arquivos: renomear padrão, trocar assinatura de função, mover import. É chato, é longo, é verificável
• Correção de lint e de tipos em repositório grande: o linter e o type checker dão o veredito. Zero ambiguidade
• Conversão de formato de arquivo em lote: migrar config, transformar estrutura de dados, padronizar arquivo de teste. Dá pra validar comparando saída
• Triagem de build quebrado: o build passa ou não passa. Deixar o modelo caçar a causa raiz enquanto tu faz outra coisa é uso honesto do tempo dele

Sai:

• Decisão de arquitetura: não tem teste que diga se a escolha foi boa. Isso é teu
• Mexida em infraestrutura viva: produção, migration destrutiva, os rm -rf da vida. Autonomia longa em ambiente onde o erro não tem undo é pedir pra chorar
• Qualquer coisa sem forma automática de verificação: se o sucesso depende de alguém olhar e dizer "ficou bom", a sessão longa só produz mais diff pra tu revisar

Vale separar também o que é tarefa de agente e o que é tarefa de automação previsível. Muita coisa que o pessoal joga pro modelo é fluxo fixo que não muda, e aí a discussão vira agente ou automação por workflow, que é outra conversa

Grok Build, grok-cli e grok-build-0.1: quem é quem no terminal

Essa confusão de nomes tem derrubado muita gente, então vamos organizar com o que está documentado

Ou seja: Grok Build é ferramenta, grok-build-0.1 é modelo, grok-cli é projeto da comunidade. Nomes parecidos, coisas diferentes

Sobre o Grok Build, o changelog oficial registra que ele passou a ser movido pelo Grok 4.6, com visão nativa de subagentes, integração com Plan Mode, suporte a mouse e interface de terminal em tela cheia

E aqui cabe um aviso, porque o nome engana feio: apesar de o grok-build-0.1 carregar "build" no ID, quem o changelog aponta como motor do Grok Build é o Grok 4.6. Que papel o grok-build-0.1 cumpre dentro da ferramenta, os docs não explicam, então não dá pra assumir que um é o motor do outro só pela semelhança de nome

Se o 4.7 já virou o padrão dele, isso eu não vi confirmado em lugar nenhum até agora, então não vou afirmar

E se tu não quer sair do teu setup atual: o Grok 4.6 está disponível na API da SpaceXAI, no Grok Build e em superfícies de terceiros como Cursor, OpenRouter, Vercel e Cloudflare. Pro 4.7, a lista de onde ele já chegou ainda não apareceu confirmada

Vale a pena deixar o Grok 4.7 conduzir? Veredito honesto

Deixa eu ser claro antes de qualquer coisa: este post não testou o modelo

O modelo saiu hoje e eu não vou fingir bancada que não existe. O que dá pra fazer é ler os fatos e separar por perfil

Tem motivo pra testar já: quem tem repositório com suíte de testes decente, CI funcionando e uma tarefa longa e chata empacada há semanas

Nesse cenário o risco é baixo (branch separada, teste como juiz) e o preço de entrada de US$ 2 por milhão de tokens é convidativo o bastante pra justificar uma rodada de comparação contra o que tu paga hoje

Deve esperar: quem precisa de número independente pra justificar troca de ferramenta pro time ou pro chefe

Não existe medição pública do 4.7 até agora, o Artificial Analysis lista até o 4.6, e trocar de stack com base em manchete de lançamento é decisão sem chão. Espera aparecer dado

Não deveria nem cogitar por enquanto: quem quer autonomia longa em cima de infra viva ou de tarefa sem verificação automática. Isso não é limitação de modelo, é limitação do formato

O ponto de atenção que fica pra todo mundo é o custo. A sessão de várias horas é exatamente o padrão de uso que faz o contexto inchar, e a referência mais próxima que temos (a tabela por faixa do 4.6) mostra que inchar contexto dobra a conta quando cruza o limite

Próximo passo

O caminho mais barato de avaliar isso não é ler thread, é rodar um experimento controlado 🙂

Escolhe uma tarefa longa e verificável do teu repositório, dessas que ninguém quer pegar na segunda-feira

Cria uma branch separada, deixa a suíte de testes como gabarito e anota duas coisas no fim: quanto tempo levou e quanto custou

Compara com o que tu gasta hoje pra fazer a mesma coisa, seja com outra ferramenta, seja na mão. Sem esse número teu, qualquer benchmark de terceiro é só curiosidade

E fica de olho em duas fontes até aparecer coisa concreta: a documentação oficial em docs.x.ai, que ainda vai listar o ID e a janela de contexto do 4.7, e o Artificial Analysis, que é onde a medição independente costuma pintar

Quando esses dados subirem, a gente volta pra conversa com número na mão

até o próximo post!