Google Antigravity SDK ganha suporte a modelos locais para rodar agentes sem enviar código à nuvem

A Google anunciou em 14 de outubro de 2026 que o Antigravity SDK passou a suportar modelos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → locais, permitindo construir e executar workflows de agentes direto na máquina do desenvolvedor. A novidade não exclui a nuvem: dá para misturar modelos locais com modelos em nuvem conforme a tarefa pede mais ou menos poder de processamento. Segundo a InfoQ, o resultado prático é mais controle sobre privacidade de dados, custo de inferência, dependência de rede e distribuição de carga computacional.

Para quem desenvolve no Brasil, isso ataca três dores conhecidas ao mesmo tempo: o custo de tokens em dólar que varia com o câmbio, a exigência de manter código sensível fora de serviços de terceiros (relevante sob a LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI → em projetos de clientes com cláusula de confidencialidade) e a instabilidade de conexão que ainda penaliza quem trabalha fora dos grandes centros. Um agente que roda majoritariamente local não para de funcionar porque a internet caiu no meio de uma tarefa longa.

Como funciona o Architect-Builder híbrido

A capacidade central do SDK se chama orquestração híbrida de agentes, uma adaptação do padrão Architect-Builder que a própria Google já havia proposto, agora pensado para um ambiente misto de computação local e em nuvem. O padrão divide o trabalho em dois papéis:

• Architect: agente primário, de alto contexto, que mantém a visão macro do sistema — dependências, guardrails de arquitetura, especificações e plano de implementação.
• Builders: múltiplos agentes especializados que trabalham em paralelo, em ambientes isolados, executando tarefas estreitas definidas pela especificação do architect.

Na implementação do Antigravity SDK, o architect roda na nuvem e define a estratégia quebrando a tarefa em unidades menores usando apenas nomes de arquivo e descrições de tarefa, sem precisar acessar o código-fonte em si. Os builders rodam localmente e fazem o trabalho que de fato toca o código: reproduzir vulnerabilidades de segurança, propor correções, revisar patches candidatos e rodar testes de regressão. Agentes locais adicionais validam as mudanças propostas contra as suítes de teste fornecidas, mantendo as etapas intensivas em código no próprio dispositivo.

O número que a Google usa para vender a ideia

Em uma demonstração envolvendo auditoria e correção de três módulos Python vulneráveis, a Google reportou que apenas 95 dos aproximadamente 3.400 tokens usados foram processados na nuvem, só para o planejamento. Os outros 97,2% ficaram no dispositivo local. A empresa também afirma que nenhum código-fonte foi enviado à nuvem durante o processo.

Em resumo: o architect decide o quê fazer olhando só nomes de arquivo e descrições; o builder decide o como, com o código inteiro debaixo do seu nariz, sem que ele saia da máquina.

Quais modelos rodam localmente

A implementação inicial do suporte local foca no Gemma 4 26B A4B rodando via LiteRT, a tecnologia de inferência da própria Google. Mas o SDK não trava o desenvolvedor nesse modelo: também há suporte a servidores de inferência local compatíveis com a API da OpenAI através do LocalOpenAIAgentConfig, o que abre a porta para:

• Ollama
• LM Studio
• vLLM

Isso significa que quem já tem uma stack local montada com qualquer um desses três projetos não precisa trocar de ferramenta para aproveitar a orquestração híbrida — só aponta a configuração para o endpoint local já existente.

O que a comunidade já está questionando

A recepção nos fóruns, segundo o relato da InfoQ, mistura entusiasmo com ceticismo técnico. Um usuário identificado como ambassadortim destacou o ganho de controle: empresas passam a decidir quando trocar de modelo de IA, em vez de depender só do que o provedor de nuvem oferece.

Já o usuário FollowingTop3534 questionou se a métrica de tokens conta a história toda:

Eu mediria a taxa de aceitação de patches, o tempo de execução e o consumo de energia junto com a fatia de tokens na nuvem. 97,2% dos tokens rodarem localmente é interessante, mas não diz se a execução foi mais rápida ou mais barata no seu hardware, e os 24 GB ou mais de VRAM (ou memória unificada) recomendados são uma barreira real.

I'd benchmark patch acceptance, wall time, and energy alongside the cloud-token share. '97.2% of tokens ran locally' is interesting, but it doesn't tell you whether the run was faster or cheaper on your hardware, and the recommended 24GB+ VRAM or unified memory is a real gate.FollowingTop3534, usuário no Reddit

O ponto é relevante para quem pensa em adotar isso no Brasil: uma GPU com 24 GB de VRAM ou mais, ou memória unificada equivalente, ainda é um investimento considerável em hardware local, e o preço em reais de placas com essa capacidade não acompanhou a desvalorização geral de componentes de consumo. Economizar em tokens de nuvem pode significar gastar mais upfront em máquina.

Um terceiro usuário, Latter_Crazy, foi na direção oposta, afirmando que a ferramenta permite fazer coisas que antes esbarravam nas regras de uso da nuvem, e que custo, velocidade e qualidade estão todos melhorando ao mesmo tempo — na visão dele, só o começo.

SDK não é a mesma coisa que o Antigravity IDE

Vale um esclarecimento que a própria Google fez questão de registrar: o Antigravity SDK não deve ser confundido com o Antigravity IDE. Os dois compartilham a mesma infraestrutura de agentes por baixo do capô, mas servem a propósitos diferentes. O IDE é uma ferramenta pronta para tarefas de codificação; o SDK é a camada que permite construir agentes próprios de forma programática, usando esse mesmo motor híbrido Architect-Builder como base.

Para equipes de plataforma ou times de segurança que já têm processos internos de revisão de código, essa distinção importa: dá para incorporar a orquestração híbrida em pipelines próprios de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → ou em ferramentas internas de triagem de vulnerabilidades, sem depender do IDE da Google como interface.

O que ainda fica em aberto

A Google não publicou, até a cobertura da InfoQ, benchmarks de tempo de execução (wall time) ou consumo de energia comparando o fluxo híbrido com um fluxo totalmente em nuvem — exatamente a lacuna apontada por FollowingTop3534. Também não há, na fonte, detalhamento de custo em dólares por tarefa, nem comparação de qualidade de patch entre rodar o builder localmente com o Gemma 4 26B A4B versus rodar tudo na nuvem com um modelo maior.

Para quem avalia adoção, a redução de tokens na nuvem é um dado real e documentado, mas não substitui um teste próprio na stack e no hardware disponível antes de decidir migrar workflows sensíveis para o modo local.

Fonte: InfoQ