Nos últimos dias, o Antigravity CLI recebeu oito atualizações com diversas novidades. Os novos comandos do agy organizam o trabalho em agentes paralelos, Tasks, modos de execução e políticas de permissão. Neste post vou cobrir as principais novidades dessas atualizações. Se quiser as novidades em vídeo, também tenho um resumo que publiquei em meu canal.
Em junho de 2026, tivemos a descontinuação do Gemini CLI, Antigravity se tornou a alternativa para os órfãos do Gemini CLI.
O que mudou do Gemini CLI para o Antigravity CLI
O Antigravity CLI mantém conceitos conhecidos: uma TUI interativa, prompts em linguagem natural, slash commands, MCP e arquivos de contexto do projeto. No entanto, o novo fluxo coloca a execução assíncrona no centro da experiência.
Em vez de esperar uma investigação terminar, o agente principal pode delegar partes do trabalho. Enquanto isso, você continua escrevendo prompts, revisando diffs ou acompanhando outras tarefas.
As principais mudanças práticas são:
- Execução paralela: subagents trabalham em contextos separados sem bloquear a conversa principal.
- Tasks em background: comandos de shell e processos longos continuam rodando enquanto você usa a TUI.
- Custom Agents: agentes reutilizáveis podem ser definidos em Markdown ou empacotados em plugins.
- Modos de execução:
default,accept-editseplancontrolam como o CLI trata análise e escrita de arquivos. - Permissões granulares: regras como
command(git)ewrite_file(src/)limitam ações sensíveis. - Automação estruturada: o modo
-ppode retornarjsonoustream-jsone validar respostas com JSON Schema.
Isso não transforma toda tarefa em um caso de multi-agent. Para uma mudança pequena, uma conversa direta é mais rápida. O ganho aparece quando há etapas independentes, processos demorados ou muito output intermediário.
Subagents e Tasks: dois tipos de trabalho em background
O Antigravity CLI separa as sessões agênticas dos processos comuns.
Subagents são agentes independentes, cada um com contexto, instruções e ferramentas próprias. Eles podem pesquisar um codebase, editar arquivos, executar testes ou revisar uma implementação. O agente principal cria sessões temporárias com invoke_subagent ou reutiliza Custom Agents definidos em Markdown.
Tasks são processos de background não-agênticos. Um build, uma suíte de testes ou um comando persistente pode continuar rodando sem abrir uma nova conversa com o agente.
Perguntas paralelas iniciadas com /btw também aparecem no fluxo de Tasks. Esses recursos já estavam presentes, assim como outras ferramentas como o Claude Code e o Codex, e agora estão disponíveis no antigravity CLI.
A regra prática é simples:
| Necessidade | Recurso indicado |
|---|---|
| Pesquisar arquitetura e devolver uma conclusão | Subagent |
| Implementar partes independentes de uma feature | Subagents paralelos |
Rodar npm test ou acompanhar um servidor | Task |
| Fazer uma pergunta lateral sem interromper o raciocínio | /btw |
| Reutilizar um especialista em vários projetos | Custom Agent |
O post sobre subagents no Claude Code e no Antigravity CLI explica como criar Custom Agents, limitar ferramentas e escolher o modelo de cada especialista.
Principais comandos do Antigravity CLI
Digite / no prompt para abrir o seletor. A tabela abaixo reúne os comandos mais úteis no fluxo atual:
| Comando | Quando usar |
|---|---|
/agents | Selecionar Custom Agents e monitorar subagents ativos, concluídos ou com erro |
/tasks | Ver processos em background, abrir logs e encerrar uma Task |
/btw <pergunta> | Fazer uma pergunta paralela sem interromper a conversa principal |
/fork ou /branch | Clonar a conversa para experimentar outro caminho |
/resume | Reabrir ou trocar de conversa no workspace atual |
/rewind ou /undo | Voltar o histórico para um ponto anterior |
/diff | Revisar mudanças do workspace, de cada turno ou de commits |
/artifact | Abrir o painel de revisão de Artifacts |
/permissions | Criar e editar regras de acesso a comandos, arquivos, URLs e MCP |
/model | Escolher o modelo usado pela sessão |
/effort | Ajustar o nível de raciocínio do modelo atual |
/codesearch ou /cs | Buscar código com regex, texto literal e filtros de arquivo |
/copy <n> | Copiar uma resposta recente pelo índice |
/skills | Inspecionar Agent Skills disponíveis |
/mcp | Gerenciar MCP servers e autenticação |
/hooks | Inspecionar hooks carregados pelo CLI |
/context | Visualizar como a janela de contexto está sendo usada |
/credits | Consultar créditos G1 em builds compatíveis |
/usage ou /quota | Consultar a quota dos modelos |
Alguns comandos merecem contexto adicional. /fork preserva o histórico até o turno atual e cria uma conversa separada. Assim, você pode testar uma arquitetura sem misturar as decisões com a sessão principal. Já /rewind volta a conversa, mas não deve substituir Git para recuperar arquivos.
O /diff também evoluiu. O painel atual separa mudanças do workspace, alterações por turno e histórico de commits. Além disso, você pode comentar linhas e devolver esse feedback ao agente.
/agents: monitoramento e controle
O painel /agents serve para duas tarefas. Primeiro, ele permite alternar entre o agente padrão e Custom Agents instalados. Em segundo lugar, mostra os subagents criados durante a conversa.
Cada sessão exibe o estado, o papel e a atividade atuais. Pressione Enter para abrir os detalhes e k para encerrar um subagent em execução. Se uma ferramenta solicitar autorização, você pode aprovar ou bloquear a ação diretamente no painel.
Dois atalhos reduzem a troca de contexto:
Alt+Jleva até o próximo subagent aguardando uma confirmação.Ctrl+Kaprova a ação pendente exibida acima do prompt.
/tasks: logs de processos em background
Use /tasks para acompanhar comandos e processos não-agênticos. O painel lista as Tasks, abre o stdout completo e permite encerrar um processo que ficou preso.
Essa separação evita criar um agente apenas para aguardar um build. O subagente fica reservado para trabalhos que exigem análise e tomada de decisão.
/codesearch: busca progressiva no workspace
A versão 1.1.3 adicionou /codesearch, com os aliases /cs e /search. A busca interpreta a consulta como regex por padrão. Use -F ou --literal para texto exato e f: ou file: para incluir ou excluir caminhos.
Na versão 1.1.6, os resultados passaram a aparecer durante o carregamento. Você também pode cancelar uma pesquisa longa com Esc.
/codesearch register_rest_route f:*.php
/codesearch -F wp_enqueue_script file:src/**
Os dois exemplos foram validados na TUI da versão 1.1.10. Para um termo literal sem espaços, não use aspas. Na versão testada, as aspas foram interpretadas como parte do termo e a busca não encontrou o resultado.
Modos de execução: default, accept-edits e plan
Os comandos legados /fast e /planning foram removidos na versão 1.1.0. No fluxo atual, pressione Shift+Tab para alternar entre três modos:
| Modo | Comportamento | Melhor uso |
|---|---|---|
default | Pede revisão antes de criar ou modificar arquivos | Desenvolvimento normal e mudanças sensíveis |
accept-edits | Aprova automaticamente operações de escrita | Protótipos e alterações controladas |
plan | Analisa e organiza os passos antes de editar | Refatorações e arquitetura desconhecida |
Você também pode definir o modo ao iniciar o CLI:
agy --mode=plan
agy --mode=accept-edits
Para um prompt específico, use /plan antes da instrução. Desde a versão 1.1.4, também é possível combinar comandos no início do mesmo prompt. Por exemplo, uma Skill pode trabalhar em conjunto com uma instrução de planejamento.
O modo de execução não substitui as permissões. Mesmo em accept-edits, comandos de terminal e acessos externos continuam seguindo as regras configuradas em /permissions.
Permissões e Terminal Sandbox
O Antigravity CLI representa operações sensíveis no formato ação(alvo). As três listas possíveis são:
deny: bloqueia a operação;ask: exige confirmação;allow: executa sem perguntar.
A ordem de precedência é deny, depois ask e, por fim, allow. Portanto, uma regra ampla em ask pode sobrepor uma permissão mais específica.
Este exemplo libera comandos comuns do projeto e bloqueia alvos perigosos. Todas as ações não configuradas continuam pedindo confirmação pelo comportamento padrão:
{
"enableTerminalSandbox": true,
"permissions": {
"allow": [
"command(git)",
"command(npm run (build|lint|test))",
"read_file(/var/log/app)",
"write_file(src/)"
],
"deny": [
"command(rm -rf)",
"command(sudo)",
"write_file(.git/)"
]
}
}Code language: JSON / JSON with Comments (json)
O Terminal Sandbox adiciona uma camada de isolamento aos comandos locais. Ele vem desativado por padrão e não torna um comando automaticamente seguro. Por isso, mantenha regras estreitas e evite curingas como command(*) em projetos sensíveis.
Desde a versão 1.1.10, o Terminal Sandbox monta o diretório .git como somente leitura. A proteção reduz o risco de alteração dos metadados do repositório no sandbox, mas não elimina a necessidade de regras explícitas.
Consulte a documentação oficial sobre modos de execução e permissões do CLI antes de copiar políticas para um ambiente de produção.
Artifacts e revisão de diffs
Artifacts são entregáveis estruturados, como planos, diffs e diagramas. No modo default, o CLI pausa antes de escrever arquivos e mostra uma prévia da mudança. Isso cria um ponto claro de revisão antes de alterar o workspace.
Abra /artifact ou pressione Ctrl+R para entrar no painel de revisão. Já o /diff oferece uma visão mais ampla das mudanças que chegaram ao workspace.
Use os dois recursos com objetivos diferentes:
- Revise a proposta e o plano no Artifact;
- revise a alteração concreta no
/diff; - Execute os testes antes de aceitar o trabalho como concluído.
Automação headless com JSON e Agent Skills
A maior novidade para scripting chegou nas versões 1.1.8 e 1.1.9. O modo -p agora suporta três formatos de saída:
text: resposta comum para leitura humana;json: resultado estruturado ao final da execução;stream-json: eventos NDJSON emitidos durante o processamento.
Um comando simples para CI pode retornar JSON:
agy -p "Revise o diff e devolva riscos, arquivos e prioridade" --output-format jsonCode language: JavaScript (javascript)
Para acompanhar a execução em tempo real, use stream-json. O fluxo inclui eventos init, step_update e result. Chamadas de ferramentas trazem tool_info, enquanto delegações podem incluir subagent_info com identificadores e logs.
agy -p "Rode os testes e explique qualquer falha" --output-format stream-jsonCode language: JavaScript (javascript)
O --json-schema aplica um contrato à resposta final. Ele aceita um schema inline ou o caminho de um arquivo:
Salve este exemplo como schemas/code-review.json:
{
"type": "object",
"properties": {
"risks": {
"type": "array",
"items": { "type": "string" }
},
"priority": {
"type": "string",
"enum": ["low", "medium", "high"]
}
},
"required": ["risks", "priority"],
"additionalProperties": false
}Code language: JSON / JSON with Comments (json)
agy -p "Classifique os riscos deste diff e devolva risks e priority" \
--output-format json \
--json-schema ./schemas/code-review.jsonCode language: JavaScript (javascript)
Com --output-format json, a resposta inclui o objeto validado em structured_output. No teste, um array vazio e a prioridade low respeitaram o contrato e o processo terminou com código zero.
Desde a versão 1.1.9, o modo headless também expande os slash commands e os Agent Skills. Assim, um pipeline pode chamar uma Skill reutilizável diretamente:
agy -p "/security-review analise este diff" --output-format stream-jsonCode language: JavaScript (javascript)
O exemplo pressupõe que a Skill security-review já esteja instalada. Além disso, o modo headless não abre prompts de autorização: uma ferramenta sem regra prévia é bloqueada e o CLI informa a permissão necessária no stderr. Configure somente os alvos exigidos pela Skill em permissions.allow. Evite liberar todas as ferramentas apenas para fazer a automação passar.
Se o texto começar com / mas não deve ser interpretado como comando, adicione --disable-slash-commands. Os exemplos de plan, accept-edits, json, stream-json e JSON Schema foram executados com sucesso nas versões 1.1.9 e 1.1.10 em 3 de agosto de 2026.
Novidades das versões 1.1.3 a 1.1.10
As release notes oficiais mostram como o CLI ganhou recursos em ciclos curtos:
| Versão | Mudança com impacto no fluxo |
|---|---|
| 1.1.3 | /codesearch, carregamento assíncrono de Skills, timeouts de MCP e correções para Linux headless |
| 1.1.4 | Combinação de slash commands e políticas do settings.json respeitadas no modo headless |
| 1.1.5 | /effort, slugs de modelos, modelo por Custom Agent e melhorias de MCP |
| 1.1.6 | Custom Agents em Markdown, /copy <n> e busca progressiva |
| 1.1.7 | Permissões para comandos compostos e correções de plugins e OAuth em MCP |
| 1.1.8 | json, stream-json, JSON Schema e telemetria de tokens e subagents |
| 1.1.9 | Agent Skills e slash commands no modo -p, MCP em background e permissões persistentes |
| 1.1.10 | Login empresarial, .git somente leitura no sandbox, correção de --model e --effort e encerramento completo de árvores de subagents |
Nem toda mudança precisa virar um post separado. /copy <n>, copyOnSelect e correções isoladas de hooks funcionam melhor como notas dentro de um guia maior. Por outro lado, Custom Agents e automação estruturada mudam a arquitetura do fluxo e justificam exemplos completos.
Boas práticas para workflows multi-agent
1. Delegue apenas trabalho independente
Paralelismo ajuda quando as tarefas não disputam os mesmos arquivos. Pesquisar documentação, mapear testes e analisar segurança podem rodar juntos. Editar a mesma função em três sessões cria conflitos e retrabalho.
2. Use plan em mudanças amplas
Antes de uma refatoração, peça um mapa de dependências e um plano verificável. Depois, revise o Artifact e só então permita a escrita.
3. Transforme rotinas em Custom Agents e Skills
Se você repete o mesmo prompt, salve o comportamento. Use Custom Agents para papéis especializados e Agent Skills para procedimentos reutilizáveis. Plugins ajudam a distribuir os dois junto de MCP servers e hooks.
4. Dê ao agente um loop de verificação
Inclua comandos de teste, lint e build no prompt ou no arquivo de contexto do projeto. O agente precisa conseguir provar que a mudança funciona.
Implemente a correção, rode npm test e resuma as falhas restantes. Não altere os testes apenas para obter um resultado verde.Code language: JavaScript (javascript)
5. Comece com permissões estreitas
Libere apenas os comandos e diretórios necessários. Um subagente de pesquisa não precisa escrever arquivos. Da mesma forma, uma pipeline de revisão não deve receber acesso irrestrito ao sistema.
6. Use saída estruturada em automações
Não faça parsing de texto livre no CI. Prefira json ou stream-json e valide o resultado com --json-schema. Dessa forma, uma resposta inesperada falha explicitamente.
7. Acompanhe custo e contexto
Use /context, /usage e /credits para entender consumo e limites. Para reduzir desperdício, veja também as dicas sobre tokens e créditos no Antigravity.
Conclusão
Os comandos do Antigravity CLI fazem mais sentido quando você entende a arquitetura por trás deles. /agents controla sessões agênticas, /tasks acompanha processos e /permissions define os limites. Já -p, stream-json e JSON Schema levam o mesmo fluxo para scripts e pipelines.
Se você vem do Gemini CLI, comece com três hábitos: use Shift+Tab para escolher o modo certo, revise mudanças com /diff e delegue apenas tarefas independentes. Depois, transforme rotinas estáveis em Custom Agents ou Agent Skills.
O CLI acelera o trabalho, mas não substitui revisão, testes e critérios de segurança. Quanto maior a autonomia, mais claros precisam ser os limites e os mecanismos de validação.

Deixe um comentário