Modelos locais do Google Antigravity SDK levam agentes para o modo offline, mas o hardware define os limites

O Google adicionou modelos locais ao Antigravity SDK, permitindo que desenvolvedores executem fluxos de trabalho baseados em agentes sem chave de API ou conexão com a internet pela primeira vez.

A rota otimizada inicial combina Gemma 4 26B A4B com o runtime LiteRT do Google AI Edge. O Google recomenda pelo menos 24 GB de VRAM ou memória unificada. Essa exigência coloca a experiência completa além do alcance de muitos notebooks convencionais, apesar da promessa de execução local.

Este lançamento desloca uma fronteira importante. Os desenvolvedores não precisam mais enviar cada prompt, arquivo-fonte ou resultado de ferramenta por meio de um modelo hospedado. No entanto, agentes na nuvem ainda oferecem implantação mais simples, maior capacidade de modelo e menos restrições de hardware.

Assim, o Google desafia o modelo de agentes exclusivamente em nuvem sem abandoná-lo. Sua própria demonstração usa um planejador Gemini na nuvem ao lado de vários trabalhadores locais do Gemma. A história mais importante não é a substituição total da nuvem, mas o controle sobre onde cada parte de um agente é executada.

Modelos locais do Antigravity SDK levam o ciclo do agente ao dispositivo

O Google transferiu as chamadas de modelo, o ciclo de ferramentas e o contexto de trabalho do agente para um hardware controlado pelo desenvolvedor.

O Google anunciou o suporte a modelos locais em 23 de setembro de 2026. A empresa afirma que o Antigravity SDK agora oferece suporte a fluxos de trabalho locais em vários modelos e opções de execução.

O SDK expõe, por meio de Python, os recursos de agentes por trás do Google Antigravity. Esses recursos incluem interação com modelos, ferramentas, políticas, espaços de trabalho, hooks e subagentes.

Antes, os desenvolvedores associavam esses fluxos de trabalho à inferência remota. A nova configuração permite que um agente opere com base em um checkpoint de modelo armazenado e executado na mesma máquina.

O lançamento de modelos locais do Google destaca o Gemma 4 26B A4B como o primeiro modelo otimizado. O LiteRT processa a inferência por meio do hardware de aceleração disponível no dispositivo.

O caminho compatível usa LiteRTAgentConfig, que direciona o agente a um checkpoint .litertlm. O SDK inicia um servidor de loopback, ou seja, um serviço disponível apenas pela interface de rede local da máquina.

Esse serviço local fica entre o agente Antigravity e o runtime do modelo. Ele permite que o framework mais amplo do agente se comunique com o checkpoint sem chamar um endpoint público de modelo.

Segundo o Google, o fluxo de trabalho resultante pode ser executado sem chave de API ou conexão com a internet. Essa é uma distinção relevante em relação a produtos que apenas armazenam arquivos selecionados localmente.

Uma execução totalmente offline significa que as entradas do modelo, os tokens gerados e as interações com ferramentas podem permanecer no dispositivo. O resultado exato em termos de privacidade ainda depende das ferramentas e integrações ativadas pelo desenvolvedor.

Um agente que chama um serviço de busca na web não está completamente offline. O mesmo vale para um agente conectado a bancos de dados remotos, sistemas de análise ou servidores hospedados do Model Context Protocol.

O SDK também oferece suporte a servidores locais externos por meio de LocalOpenAIAgentConfig. Essa rota se conecta a softwares que expõem uma API compatível com OpenAI na máquina ou rede privada do desenvolvedor.

O Google cita Ollama, LM Studio e vLLM como exemplos. Essa compatibilidade é importante porque usuários de IA local já organizam modelos e automações em torno desses servidores.

As duas rotas atendem a necessidades diferentes. O LiteRT oferece um caminho gerenciado pelo Google e otimizado em torno de seu runtime, enquanto servidores compatíveis dão às equipes mais controle sobre a hospedagem do modelo.

O guia de execução local do Google documenta ambas as configurações. Ele também confirma suporte a Apple Silicon Metal, Nvidia CUDA e backends de aceleradores detectados automaticamente.

Isso é mais do que outro seletor de modelos dentro de um editor. O SDK permite que desenvolvedores incorporem inferência local em seus próprios scripts, serviços, sistemas de avaliação e fluxos de trabalho especializados com agentes.

Essa programabilidade cria a tensão central do artigo. Mover a inferência para o dispositivo melhora o controle, mas também transfere a responsabilidade pela infraestrutura do Google para o usuário.

Agentes offline pressionam fluxos de trabalho exclusivamente em nuvem

O lançamento pressiona plataformas de agentes exclusivamente em nuvem ao tornar a localização dos dados uma escolha arquitetural, em vez de uma limitação do produto.

A inferência na nuvem continua sendo o padrão para a maioria dos agentes de programação. Ela dá aos usuários acesso imediato a modelos grandes sem exigir uma GPU de nível profissional ou longos downloads de modelos.

Essa conveniência tem um custo que vai além das taxas de uso. Código-fonte, prompts, documentos recuperados e saídas de ferramentas precisam entrar em um ambiente de processamento remoto.

As políticas dos provedores podem limitar a retenção e o uso para treinamento. Contratos empresariais podem acrescentar controles mais rigorosos. Ainda assim, algumas organizações não podem enviar material sensível para fora de uma máquina ou rede aprovada.

Ambientes de desenvolvimento isolados da internet apresentam o caso mais claro. Esses sistemas intencionalmente não têm acesso direto à internet porque contêm informações reguladas, sigilosas ou comercialmente sensíveis.

Um agente exclusivamente em nuvem não pode operar normalmente nesse cenário. Um agente Antigravity offline pode, desde que seu modelo e suas dependências de software cheguem por um processo de transferência aprovado.

A mesma vantagem se aplica a desenvolvedores que trabalham com produtos ainda não lançados, relatórios de segurança, documentos jurídicos e algoritmos proprietários. A execução local reduz o número de sistemas que recebem seu contexto.

Ela também altera a disponibilidade do serviço. Um fluxo de trabalho local não para porque um provedor de modelos enfrenta uma indisponibilidade, muda uma cota ou remove um endpoint.

Essa independência pode importar durante tarefas de longa duração. Um agente que audita um repositório pode executar muitas interações com o modelo enquanto lê arquivos, planeja mudanças, executa testes e revisa erros.

A latência também se comporta de forma diferente. A inferência local evita atrasos de rede de longa distância, mas a geração de tokens depende inteiramente do hardware disponível e da otimização do runtime.

Uma estação de trabalho bem equipada pode oferecer tempos de resposta previsíveis. Uma máquina próxima da recomendação mínima de memória pode proporcionar uma experiência muito mais lenta, especialmente com cargas de trabalho simultâneas.

As plataformas em nuvem mantêm vantagens claras. Elas podem fornecer modelos maiores, capacidade elástica, monitoramento centralizado e atualizações gerenciadas sem consumir memória local.

Elas também permitem que as equipes padronizem o desempenho entre funcionários que usam computadores diferentes. Uma abordagem que prioriza o local transforma as especificações dos dispositivos em parte do plano de implantação.

Portanto, este lançamento não estabelece uma disputa simples entre IA local e IA na nuvem. Ele pressiona plataformas que não oferecem uma escolha significativa entre esses ambientes de execução.

A vantagem estratégica pertence a frameworks capazes de encaminhar o trabalho de acordo com sensibilidade, complexidade e capacidade computacional disponível. O SDK do Google agora oferece suporte a esse padrão mais amplo.

Para empresas, a decisão se torna mais granular. Uma equipe pode reservar modelos hospedados para planejamento exigente, mantendo a análise repetitiva de arquivos em hardware controlado.

Desenvolvedores individuais ganham outra forma de autonomia. Eles podem continuar usando um fluxo de trabalho com agentes mesmo quando não querem que todas as tarefas dependam de autenticação remota ou limites de consumo.

A limitação é o acesso a hardware adequado. O Google recomenda pelo menos 24 GB de VRAM ou memória unificada para o checkpoint Gemma em destaque.

Muitos computadores convencionais ficam abaixo desse limite. Algumas máquinas o atingem tecnicamente, mas precisam compartilhar essa memória com o sistema operacional, editor, navegador e ferramentas de compilação.

Provedores exclusivamente em nuvem podem argumentar razoavelmente que a inferência gerenciada continua sendo a rota mais acessível. Agentes locais aumentam a autonomia, mas não eliminam os custos computacionais.

A pressão é, portanto, mais forte entre equipes preocupadas com segurança e tecnicamente maduras. Esses compradores podem valorizar o controle local o suficiente para aceitar o trabalho de configuração e os requisitos de hardware.

LiteRT e Gemma 4 explicam como funciona o fluxo de trabalho offline

O mecanismo depende de um modelo Gemma esparso, um runtime de inferência local e um framework de agentes capaz de manter seu ciclo de controle por perto.

O Gemma 4 26B A4B usa uma arquitetura de mistura de especialistas. Esse projeto encaminha cada token por apenas uma parte do modelo, em vez de ativar todos os parâmetros.

O Google lista 25,2 bilhões de parâmetros totais e 3,8 bilhões de parâmetros ativos para o modelo. O rótulo A4B se refere a aproximadamente quatro bilhões de parâmetros ativos durante a inferência.

Essa distinção é importante para a execução local. O modelo pode recorrer a um conjunto maior de parâmetros sem exigir computação densa em todos os 25,2 bilhões de parâmetros para cada token.

Isso não significa que o checkpoint ocupe apenas quatro bilhões de parâmetros em armazenamento ou memória. A coleção completa de especialistas precisa permanecer disponível para o roteamento.

O Google afirma que o checkpoint formatado para LiteRT tem download de aproximadamente 16,8 GB. O nível de memória recomendado de 24 GB deixa capacidade adicional para o estado de inferência e outros processos.

O cartão do modelo Gemma 4 lista uma janela de contexto de até 256.000 tokens para o modelo 26B A4B. Ele também oferece suporte a entradas de texto e imagem.

Uma grande janela de contexto anunciada não garante que todas as máquinas locais consigam usá-la confortavelmente. Contextos mais longos aumentam os requisitos de memória e o tempo de processamento em cargas de trabalho reais.

O Gemma 4 também inclui chamadas nativas de funções. A chamada de funções permite que um modelo solicite uma ação estruturada, como ler um arquivo ou invocar uma ferramenta definida pelo desenvolvedor.

Essa capacidade é essencial para um agente. Um chatbot convencional apenas produz respostas, enquanto um agente alterna entre raciocínio, ações, observações e decisões revisadas.

O Antigravity fornece o sistema de controle ao redor. Ele gerencia o espaço de trabalho, as ferramentas disponíveis, as políticas de execução e a comunicação com o modelo local.

O LiteRT fornece a camada de inferência. O Google projetou o runtime para aprendizado de máquina no dispositivo em backends de hardware compatíveis.

O guia de modelos LiteRT descreve variantes Gemma destinadas a dispositivos que vão de telefones a GPUs de consumo e estações de trabalho. Os alvos de hardware variam consideravelmente em toda a família.

Para a integração com Antigravity, os desenvolvedores instalam o SDK e o pacote litert-lm. Em seguida, importam o modelo para o formato de checkpoint do LiteRT.

O agente recebe o caminho do modelo por meio de sua configuração. Quando o programa é iniciado, o SDK cria o serviço local de modelo e transmite os tokens gerados de volta ao aplicativo.

Essa arquitetura mantém a integração relativamente familiar. Os desenvolvedores ainda instanciam um agente e enviam uma tarefa a ele, em vez de criar independentemente um servidor de inferência e um ciclo de ferramentas.

A configuração alternativa compatível com OpenAI amplia as opções de modelos. Uma equipe pode direcionar o Antigravity para uma implantação existente de Ollama, LM Studio ou vLLM.

Uma interface compatível com OpenAI padroniza formatos comuns de solicitação e resposta. Isso não implica que o modelo subjacente tenha vindo da OpenAI.

Essa distinção permite que o Antigravity fique acima de várias pilhas de inferência. O framework de agentes pode permanecer estável enquanto o servidor local ou modelo selecionado muda.

A compatibilidade também reduz a dependência de fornecedor na camada de runtime. Equipes que já usam vLLM em um servidor interno não precisam adotar o LiteRT para todos os fluxos de trabalho.

O LiteRT ainda recebe atenção especial porque o Google otimizou o caminho inicial do Gemma 4 em torno dele. Esse emparelhamento dá ao Google controle tanto sobre o formato do modelo quanto sobre o runtime de execução.

A arquitetura oferece suporte a mais do que operações totalmente locais. Ela também permite orquestração híbrida, na qual um modelo em nuvem planeja o trabalho e agentes locais realizam tarefas delimitadas.

Essa opção híbrida é a explicação mais clara para o timing do Google. Modelos locais se tornaram capazes o suficiente para executar tarefas úteis de programação sem substituir os planejadores hospedados mais robustos.

A Demonstração Híbrida do Google Revela a Estratégia Real

O próprio exemplo do Google mostra que agentes locais estão se tornando uma camada de força de trabalho, enquanto modelos em nuvem mantêm o papel de planejamento.

A empresa demonstrou um padrão Architect-Builder usando Gemini 3.8 Flash como arquiteto em nuvem. Instâncias locais de Gemma 4 26B atuaram como construtores.

A demonstração atribuiu ao sistema três módulos Python vulneráveis chamados auth.py, billing.py e database.py. Trabalhadores locais realizaram a auditoria e a correção no dispositivo.

O planejador em nuvem coordenou o processo mais amplo. Essa divisão manteve grande parte do trabalho no repositório em ambiente local, preservando o acesso a um modelo hospedado maior para orquestração.

É um desenho mais crível do que afirmar que um único checkpoint local pode equiparar-se a todos os modelos em nuvem. Diferentes etapas de uma tarefa de agente têm necessidades distintas de precisão, privacidade e computação.

O planejamento frequentemente se beneficia de raciocínio mais robusto em um contexto amplo. Inspeção, edição e verificação repetitivas podem ser distribuídas entre trabalhadores menores.

O modelo se assemelha à arquitetura de computação convencional. Sistemas centralizados agendam trabalhos, enquanto máquinas especializadas executam tarefas próximas aos dados relevantes.

Para equipes de software, um fluxo de trabalho híbrido prático pode começar com um modelo hospedado decompondo uma migração. Agentes locais poderiam então inspecionar módulos individuais e propor edições.

Uma revisão final poderia retornar ao planejador em nuvem após a minimização de detalhes sensíveis. Como alternativa, uma pessoa poderia revisar as saídas locais sem outra chamada remota.

O benefício de privacidade depende dessa fronteira. Se o planejador em nuvem receber arquivos-fonte completos, os construtores locais não impedem a exposição remota de dados.

Os desenvolvedores precisam decidir qual contexto cruza essa fronteira, quais resumos são compartilhados e quais ferramentas podem acessar serviços externos. O SDK não pode tomar essas decisões de política automaticamente.

O sistema de políticas do Google oferece aos desenvolvedores um local para impor limites. No entanto, configurações de exemplo permissivas não devem se tornar padrões de produção sem revisão.

O exemplo básico da empresa usa um agente local para inspecionar arquivos no diretório atual. Um exemplo mais avançado permite que o agente crie uma ferramenta de monitoramento e execute comandos.

Essas capacidades tornam o agente útil, mas também aumentam o risco. Um modelo equivocado ou manipulado pode modificar arquivos, invocar processos ou expor informações por meio de ferramentas conectadas.

A inferência local não torna um agente inofensivo. Ela muda onde a computação do modelo ocorre, não se as ações geradas exigem supervisão.

A execução híbrida também introduz complexidade operacional. As equipes precisam monitorar tanto chamadas remotas quanto runtimes locais, entendendo falhas através dessa fronteira.

Um planejador em nuvem pode produzir uma decomposição de tarefas falha. Os construtores locais podem então executar esse plano de forma consistente, espalhando um único erro por vários arquivos.

A concorrência cria outra restrição. Executar várias instâncias de Gemma 4 pode exigir mais memória do que uma única configuração recomendada fornece.

O Google não publicou benchmarks independentes e específicos de carga de trabalho para a integração com Antigravity. Portanto, o anúncio estabelece disponibilidade, não desempenho universal.

Ainda assim, a demonstração sinaliza uma direção clara de produto. O Google está posicionando modelos locais como trabalhadores complementares dentro de um sistema de agentes mais amplo.

Essa estratégia pressiona outros frameworks de agentes a oferecer roteamento semelhante. Os clientes perguntarão cada vez mais se uma tarefa pode permanecer local antes de aceitar uma resposta exclusivamente em nuvem.

Ela também dá ao Google uma forma de abranger ambos os mercados. Os serviços Gemini permanecem relevantes para orquestração exigente, enquanto Gemma e LiteRT cobrem a execução privada ou sensível a custos.

A Recomendação de 24 GB É o Primeiro Teste de Realidade

A operação offline elimina a dependência de um endpoint remoto, mas a substitui por restrições de hardware, manutenção e qualidade do modelo.

O Google recomenda uma máquina com pelo menos 24 GB de VRAM ou memória unificada para Gemma 4 26B A4B. A formulação descreve uma recomendação, não uma garantia universal.

VRAM é memória gráfica dedicada usada por GPUs discretas. Memória unificada é um pool compartilhado usado por processadores e hardware gráfico em sistemas como Macs com Apple Silicon.

Essas configurações se comportam de maneira diferente sob pressão. Uma GPU discreta pode oferecer alta taxa de inferência, enquanto a memória unificada pode proporcionar flexibilidade entre tarefas de CPU e gráficos.

A capacidade disponível importa mais do que o total anunciado. Uma máquina de 24 GB executando contêineres, navegadores, builds e vários agentes pode ter pouco espaço restante.

O download de checkpoint de 16,8 GB também cria uma carga de implantação. As organizações precisam distribuir, verificar, atualizar e armazenar esse artefato em máquinas aprovadas.

A procedência do modelo se torna uma preocupação operacional. As equipes devem confirmar de onde veio um checkpoint, como ele foi convertido e se sua licença permite o uso pretendido.

Gemma 4 tem licença Apache 2.0, segundo a documentação do Google. Fine-tunes externos e checkpoints convertidos podem introduzir termos ou questões de segurança separados.

A qualidade do modelo apresenta uma incerteza maior. O Google publica resultados de benchmark para Gemma 4, incluindo avaliações voltadas para programação e agentes.

Esses benchmarks descrevem o modelo subjacente em condições de teste definidas. Eles não estabelecem com que confiabilidade Antigravity conclui tarefas longas e orientadas por ferramentas no repositório de um desenvolvedor.

A confiabilidade de agentes acumula erros ao longo das etapas. Um pequeno mal-entendido pode afetar a seleção de arquivos, a execução de comandos, a interpretação dos testes e o patch final.

Modelos locais também podem não contar com as melhorias hospedadas mais recentes. Provedores de nuvem podem atualizar sistemas de inferência centralmente, enquanto implantações locais exigem atualizações deliberadas e testes de regressão.

As equipes podem preferir essa estabilidade. Um checkpoint fixo produz um ambiente mais controlado e evita mudanças inesperadas de comportamento após uma atualização de modelo remoto.

No entanto, fixo não significa determinístico. Configurações de amostragem, resultados de ferramentas, estado do workspace e concorrência ainda podem alterar os resultados.

As equipes de segurança também devem examinar o servidor local. Um endereço de loopback limita a exposição, mas uma configuração inadequada ainda pode abrir portas ou conceder acesso excessivamente amplo ao sistema de arquivos.

Servidores compatíveis com OpenAI exigem escrutínio semelhante. A documentação de serving do vLLM mostra como endpoints locais ou privados imitam APIs de modelos comuns.

A compatibilidade melhora a portabilidade, mas pode ocultar diferenças significativas. Os modelos variam na formatação de chamadas de ferramenta, no tratamento de contexto, no comportamento de segurança e no suporte a saídas estruturadas.

Por isso, os desenvolvedores devem testar todo o ciclo do agente, não apenas as respostas a prompts. Um modelo que escreve bom código ainda pode ter dificuldade para selecionar ferramentas de forma confiável.

A recomendação de hardware do Google restringe o público imediato. Workstations com GPUs Nvidia de alta memória e sistemas Apple Silicon mais bem equipados são os pontos de partida naturais.

Modelos Gemma menores podem ampliar o acesso, mas o anúncio do Google concentra seu fluxo de trabalho otimizado no checkpoint 26B A4B. Essa é a versão que sustenta a alegação de lançamento mais forte.

A diferença entre “roda localmente” e “roda bem na minha máquina” continua sem solução. O desempenho variará com o hardware, o tamanho do contexto, o uso de ferramentas e a complexidade da tarefa.

Também ainda não há evidência de que agentes Antigravity offline se equiparem aos principais sistemas hospedados em tarefas completas de engenharia de software. O Google não fez essa alegação mais ampla.

A interpretação responsável é mais restrita. Antigravity agora pode executar fluxos de trabalho significativos de agentes localmente, com uma configuração documentada e uma recomendação substancial de memória.

Essa capacidade é importante mesmo antes da paridade de desempenho. Ela oferece às equipes uma opção implantável onde a inferência remota era anteriormente proibida ou indesejável.

Três Sinais Mostrarão se Agentes Locais se Tornarão um Padrão

O próximo teste é saber se a execução local se torna rotineira além de experimentos sensíveis à privacidade e workstations de desenvolvedores com muita memória.

O primeiro sinal é um suporte mais amplo a modelos e hardware. Os desenvolvedores precisam de opções práticas para máquinas abaixo da recomendação de 24 GB.

Variantes menores de Gemma poderiam tornar agentes offline acessíveis a mais notebooks. Checkpoints otimizados adicionais também poderiam permitir que as equipes trocassem capacidade por velocidade e uso de memória.

O suporte por si só não será suficiente. O Google precisa publicar dados claros de desempenho em Apple Silicon, GPUs Nvidia e outros aceleradores compatíveis.

Medições úteis incluem velocidade de geração, tempo até o primeiro token, uso máximo de memória e conclusão de tarefas de ponta a ponta. Os benchmarks de agentes devem abranger ferramentas e recuperação em múltiplas etapas.

Se esses resultados mostrarem desempenho aceitável em hardware comum, a rota local se tornará mais do que um recurso para especialistas. Resultados fracos reforçariam a inferência em nuvem como padrão.

O segundo sinal são evidências de implantações em produção. As primeiras demonstrações provam que o software funciona, mas não revelam a confiabilidade diária.

As equipes precisarão relatar como os agentes locais lidam com repositórios grandes, sessões longas, trabalhadores concorrentes e suítes de avaliação repetíveis.

A adoção focada em segurança merece atenção especial. Organizações isoladas da rede têm um forte motivo para aceitar desempenho mais lento se o fluxo de trabalho atender aos controles internos.

O feedback dos desenvolvedores também exporá atritos práticos. Falhas de instalação, problemas de conversão de checkpoint, limites térmicos e erros de chamada de ferramenta podem superar os benefícios arquiteturais.

O terceiro sinal é a resposta competitiva. Outros frameworks de agentes já se conectam a servidores de modelos locais, mas a profundidade da integração varia bastante.

A comparação importante não é se um produto lista Ollama como opção. É se modelos locais podem usar as mesmas ferramentas, políticas, workspaces e recursos de orquestração.

Concorrentes podem responder com roteamento local mais robusto, inferência hospedada para empresas ou seleção automática entre modelos remotos e no dispositivo.

Uma resposta rápida sustentaria o julgamento subjacente do Google de que o local de execução está se tornando um critério de compra. Uma resposta limitada sugeriria que a demanda continua concentrada entre entusiastas.

O padrão híbrido do Google também merece escrutínio. Ele pode oferecer um equilíbrio prático, mas somente se os desenvolvedores puderem verificar quais informações chegam ao planejador em nuvem.

Logs claros, controles de política e roteamento rastreável importarão tanto quanto o suporte a modelos. As empresas precisam de evidências de que os limites declarados são impostos em cada turno do agente.

O lançamento também deve incentivar um desenho de tarefas mais disciplinado. Os desenvolvedores podem reservar agentes locais para trabalho delimitado, em vez de esperar que um sistema administre todo um projeto de forma autônoma.

Entre os exemplos estão classificar documentos privados, revisar um módulo delimitado, gerar testes ou resumir notas técnicas locais. Cada tarefa tem entradas e saídas mensuráveis.

Essa abordagem se encaixa em um fluxo de trabalho de IA mais amplo, no qual o contexto sensível permanece próximo ao usuário. A revisão humana continua a governar ações consequentes.

Os modelos locais do Antigravity SDK agora tornam a execução offline de agentes um fluxo de trabalho documentado pelo Google, em vez de uma solução alternativa não oficial. O lançamento não resolve as questões de qualidade ou acessibilidade.

Mas ele muda o que os desenvolvedores podem exigir de uma plataforma de agentes. O acesso à nuvem não precisa mais ser o preço inevitável da automação.

O próximo passo mais útil é realizar testes concretos. Escolha uma tarefa privada e bem delimitada, registre o uso de memória e a qualidade da conclusão e, em seguida, compare as execuções locais e hospedadas.

O agente local protege o contexto que importa enquanto conclui trabalho suficiente para justificar o hardware? A resposta determinará se o Google criou uma arquitetura padrão ou uma exceção valiosa.