Google Antigravity SDK Adds Support for Local Models to Run Agents Without Sending Code to the Cloud

Google announced on October 14, 2026, that the Antigravity SDK now supports local AI models, making it possible to build and run agent workflows directly on the developer's machine. The update doesn't rule out the cloud: local models can be mixed with cloud models depending on how much processing power a task requires. According to InfoQ, the practical result is more control over data privacy, inference cost, network dependency, and distribution of computational load.

For developers in Brazil, this addresses three familiar pain points at once: the dollar-denominated token costs that fluctuate with the exchange rate, the requirement to keep sensitive code out of third-party services (relevant under LGPD, Brazil's data protection law, in client projects with confidentiality clauses), and the connection instability that still penalizes those working outside major urban centers. An agent that runs mostly locally doesn't stop working just because the internet went down in the middle of a long task.

How the Hybrid Architect-Builder Works

The SDK's core capability is called hybrid agent orchestration, an adaptation of the Architect-Builder pattern that Google itself had already proposed, now designed for a mixed local and cloud computing environment. The pattern splits the work into two roles:

• Architect: the primary, high-context agent that maintains the system's big picture: dependencies, architectural guardrails, specifications, and the implementation plan.
• Builders: multiple specialized agents that work in parallel, in isolated environments, executing narrow tasks defined by the architect's specification.

In the Antigravity SDK implementation, the architect runs in the cloud and defines the strategy by breaking the task into smaller units using only file names and task descriptions, without needing to access the source code itself. The builders run locally and do the work that actually touches the code: reproducing security vulnerabilities, proposing fixes, reviewing candidate patches, and running regression tests. Additional local agents validate the proposed changes against the provided test suites, keeping the code-intensive steps on the device itself.

The Number Google Uses to Sell the Idea

In a demonstration involving the auditing and fixing of three vulnerable Python modules, Google reported that only 95 of the roughly 3,400 tokens used were processed in the cloud, solely for planning. The other 97.2% stayed on the local device. The company also states that no source code was sent to the cloud during the process.

In short: the architect decides what to do by looking only at file names and descriptions; the builder decides how, with the entire code right under its nose, without it ever leaving the machine.

Which Models Run Locally

The initial implementation of local support focuses on Gemma 4 26B A4B running via LiteRT, Google's own inference technology. But the SDK doesn't lock the developer into this model: there's also support for local inference servers compatible with the OpenAI API through LocalOpenAIAgentConfig, which opens the door to:

• Ollama
• LM Studio
• vLLM

This means that anyone who already has a local stack set up with any of these three projects doesn't need to switch tools to take advantage of hybrid orchestration: they just point the configuration to the existing local endpoint.

What the Community Is Already Questioning

The reception in forums, according to InfoQ's reporting, mixes enthusiasm with technical skepticism. A user identified as ambassadortim highlighted the gain in control: companies now get to decide when to switch AI models, instead of depending solely on what the cloud provider offers.

The user FollowingTop3534, meanwhile, questioned whether the token metric tells the whole story:

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, Reddit user

The point is relevant for anyone considering adopting this in Brazil: a GPU with 24 GB of VRAM or more, or equivalent unified memory, is still a significant investment in local hardware, and the price in reais for cards with that capacity hasn't followed the general decline in consumer component prices. Saving on cloud tokens may mean spending more upfront on the machine.

A third user, Latter_Crazy, took the opposite view, stating that the tool makes it possible to do things that previously ran into cloud usage rules, and that cost, speed, and quality are all improving at the same time: in his view, this is just the beginning.

The SDK Is Not the Same Thing as the Antigravity IDE

One clarification Google itself made a point of stating: the Antigravity SDK should not be confused with the Antigravity IDE. The two share the same agent infrastructure under the hood, but serve different purposes. The IDE is a ready-made tool for coding tasks; the SDK is the layer that allows developers to build their own agents programmatically, using that same hybrid Architect-Builder engine as a foundation.

For platform teams or security teams that already have internal code review processes, this distinction matters: hybrid orchestration can be incorporated into proprietary CI/CD pipelines or internal vulnerability triage tools, without depending on Google's IDE as the interface.

What Remains Open

As of InfoQ's coverage, Google had not published execution time (wall time) or energy consumption benchmarks comparing the hybrid flow to a fully cloud-based flow: exactly the gap pointed out by FollowingTop3534. The source also doesn't detail cost in dollars per task, nor does it compare patch quality between running the builder locally with Gemma 4 26B A4B versus running everything in the cloud with a larger model.

For those evaluating adoption, the reduction in cloud tokens is a real, documented data point, but it doesn't replace running your own test on your available stack and hardware before deciding to migrate sensitive workflows to local mode.