Antigravity 2.0: licenciamento, quota e migração do Gemini CLI sem susto
Guia validado sobre Antigravity 2.0: quatro superfícies, quota compartilhada, limites por compute, planos individuais, uso corporativo via Google Cloud e migração do Gemini CLI.
Fabiano Brito
CEO & Founder
Antigravity 2.0 deixou de ser apenas “um editor com IA” e virou uma família de superfícies para desenvolvimento agêntico: app desktop, IDE, CLI e SDK. A mudança que mais afeta orçamento, porém, não é visual. É operacional: o consumo passa a ser governado por quota compartilhada e limites baseados em compute, então cada decisão de modelo, modo de raciocínio e ferramenta chamada entra na conta.
O susto de muitos times vem de três mudanças juntas. Primeiro, a Google separou a experiência em superfícies diferentes. Segundo, os planos de IA passaram a comunicar limites por compute e não apenas por contagem simples de prompts. Terceiro, a transição do Gemini CLI para o Antigravity CLI colocou data no calendário: 18 de junho de 2026 para usuários individuais migrarem o fluxo legado.
Este artigo usa o post do Medium enviado como referência de pauta, mas não como fonte primária. Onde há afirmação factual, a base é documentação, anúncio ou página oficial da Google.
As quatro superfícies do Antigravity 2.0
O erro comum é procurar “o Antigravity” como se ainda fosse uma única janela. A arquitetura ficou mais modular: uma superfície coordena, outra edita, outra automatiza e outra embute agentes em sistemas próprios.
Antigravity Desktop
Central para acompanhar agentes, sessões e tarefas longas. Faz sentido quando o trabalho já passou de “chat no editor” para múltiplas execuções em paralelo.
Antigravity IDE
O editor de código. É a superfície para refatorar, revisar diffs, rodar testes e trabalhar com chat contextual ao lado do repositório.
Antigravity CLI agy
Interface de terminal para quem quer scripts, automação e migração de fluxos do Gemini CLI sem depender da IDE aberta.
Antigravity SDK
Camada para construir agentes customizados e integrá-los à infraestrutura da empresa, com controle de identidade, logs, deploy e dados.
Essa separação é saudável para times técnicos. IDE é uma coisa; orquestração de agentes é outra; automação de terminal é outra; runtime corporativo é outra. Misturar tudo em uma experiência única parecia simples, mas escondia custos e permissões.
O Antigravity 2.0 não deve ser comprado como editor; deve ser governado como uma superfície de execução de agentes.
O que mudou na quota: compute virou unidade de conversa
A parte mais sensível é o consumo. A Google descreve nos planos de IA uma transição para limites baseados em compute, com atualização recorrente até um limite semanal. Na prática, isso muda a conversa de “quantos prompts tenho?” para “qual trabalho este prompt está pedindo do sistema?”.
Uma pergunta simples em modelo leve não tem o mesmo peso de uma tarefa que lê um repositório inteiro, planeja passos, chama ferramenta, gera patch e reavalia testes. Para FinOps, isso significa que prompts longos, agentes com loops e modos de raciocínio altos precisam de regra explícita.
| Decisão | Impacto na quota | Política recomendada |
|---|---|---|
| Modelo padrão | Modelos mais capazes tendem a consumir mais compute por tarefa. | Use modelo econômico para triagem, busca e edição simples; escale só quando a tarefa exigir. |
| Modo de raciocínio | Raciocínio alto custa mais porque o modelo planeja e verifica mais antes de responder. | Reserve para bugs difíceis, desenho arquitetural, incidentes e migrações críticas. |
| Contexto anexado | Mais arquivos, logs e histórico aumentam o volume processado. | Anexe o menor contexto suficiente e prefira buscas direcionadas no repositório. |
| Loops de agente | Cada iteração pode chamar modelo, ferramenta, teste e nova análise. | Defina limite de passos, checkpoint humano e orçamento por tarefa. |
O ponto operacional é simples: quota compartilhada pune desperdício invisível. Se uma automação barata roda em modo caro o dia inteiro, ela consome o mesmo orçamento que deveria estar reservado para trabalho realmente complexo.
Planos individuais vs. operação corporativa
Para pessoa física e pequenos times, planos individuais podem fazer sentido: o usuário compra capacidade, usa no editor e controla o próprio ritmo. O problema aparece quando a empresa tenta administrar dezenas ou centenas de assinaturas soltas. Aí o custo deixa de ser “mensalidade” e vira governança: identidade, auditoria, política de dados, billing e controle de acesso.
Uso individual
Bom para teste, aprendizado, protótipos e desenvolvedor solo. O risco é baixo porque o escopo de dados e pessoas é pequeno.
- Controle
- Conta do usuário
- Billing
- Assinatura
Time técnico
Exige política de modelos, limites de uso, revisão de código assistido por IA e separação entre protótipo e produção.
- Controle
- Política de equipe
- Billing
- Centro de custo
Empresa regulada
Precisa de identidade corporativa, termos empresariais, trilha de auditoria, controle de dados e cobrança consolidada via cloud.
- Controle
- IAM / Cloud Identity
- Billing
- Google Cloud
Para uso corporativo, a discussão correta não é “qual plano é mais barato?”. É “qual modelo de acesso reduz risco e permite medir custo por produto, squad ou fluxo?”. Em empresas, agentes de código tocam propriedade intelectual, segredos, dependências, dados de cliente e pipelines. Isso exige termos, logs e permissões compatíveis.
A migração do Gemini CLI para o agy
A transição mais concreta é a do Gemini CLI para o Antigravity CLI. A Google publicou um aviso específico para usuários individuais: a migração para o agy precisa ser feita até 18 de junho de 2026. Depois dessa data, o fluxo legado deixa de ser o caminho suportado para esse perfil.
O comando de migração de plugins é direto:
agy plugin import geminiIsso não deve ser tratado como “trocar binário”. Faça como migração de ferramenta de engenharia. Inventarie scripts, aliases, hooks, plugins, variáveis de ambiente, permissões e documentação interna que ainda chamam o CLI antigo.
Busque usos de Gemini CLI em scripts, READMEs, CI local, aliases de shell e templates de projeto.
Rode agy plugin import gemini e valide se os fluxos críticos ainda conseguem ler contexto, chamar ferramentas e gerar patches.
Depois da migração, monitore consumo por tipo de tarefa; não assuma que o padrão antigo tem o mesmo custo operacional.
Defina quando usar IDE, desktop, CLI e SDK; sem isso, cada dev cria um padrão próprio de consumo e risco.
O pulo do gato: roteie tarefas por custo e risco
O melhor uso do Antigravity 2.0 não é “usar sempre o modelo mais forte”. É criar uma matriz simples: tarefa barata em modo econômico; tarefa incerta com mais contexto; tarefa crítica com raciocínio alto e revisão humana.
| Tarefa | Configuração inicial | Quando escalar |
|---|---|---|
| Explicar arquivo ou função | Modelo econômico, contexto mínimo, sem loop longo. | Se envolver decisão arquitetural ou risco de segurança. |
| Refatoração localizada | IDE com diff pequeno, testes unitários e limite de passos. | Se mexer em contrato público, schema ou autenticação. |
| Bug intermitente | Raciocínio médio com logs selecionados. | Use raciocínio alto quando houver hipótese concorrente e alto custo de erro. |
| Migração grande | Plano dividido em etapas, checkpoints humanos e orçamento explícito. | Escalar modelo e contexto por etapa, não para o repositório inteiro de uma vez. |
Essa política reduz desperdício sem travar produtividade. O desenvolvedor continua usando IA no fluxo normal, mas a empresa evita que tarefas triviais drenem a quota que deveria estar disponível para incidentes, arquitetura e entregas críticas.
Checklist para adotar sem perder controle
Antes de liberar Antigravity 2.0 para um time inteiro, resolva cinco decisões:
Defina IDE para código, desktop para orquestração, CLI para automação e SDK para produto interno.
Descreva qual modelo e qual reasoning usar em triagem, edição simples, debugging e arquitetura.
Classifique o que pode entrar no prompt: código público, código privado, logs, dados pessoais e segredos.
Acompanhe consumo por equipe, tipo de tarefa, modelo e resultado entregue.
Toda mudança gerada por agente precisa passar por testes e revisão proporcional ao risco.
Conclusão
Antigravity 2.0 é uma boa notícia para engenharia, mas uma notícia exigente para governança. Ele separa melhor as superfícies de trabalho, melhora o caminho de terminal com o agy e aproxima agentes de desenvolvimento de fluxos corporativos reais. Em troca, força a empresa a abandonar o improviso: quota compartilhada, compute, reasoning e acesso a código precisam virar política explícita.
Quem tratar a ferramenta como assinatura individual vai descobrir o custo depois. Quem tratar como plataforma de execução de agentes consegue capturar produtividade sem abrir mão de controle.
Quer liberar agentes de código sem perder governança?
Ajudamos times a desenhar política de uso, migração de CLI, observabilidade de consumo e esteiras seguras para agentes de engenharia.
Leia também
- Antigravity e Managed Agents: fatos para times técnicos
- Agents CLI: o Google transforma seu editor em especialista ADK
- Google AI Ultra em 2026: o que muda para orçamento de IA
- Segurança de agentes de IA: prompt injection em produção
Fontes primárias: Google I/O 2026 developer highlights; Transitioning Gemini CLI to Antigravity CLI; Google AI subscriptions; Google Cloud generative AI security and privacy terms.