Faysal AzizAntigravity’s local agents: keep the code home, send the plan upstairs
Google’s Antigravity SDK now supports local AI models. The useful idea is not “put every agent on your laptop”. It is to split the job: a cloud model sketches the work, while local agents open the code, make changes and run checks. If you handle a private repository, that division is worth understanding before you reach for another all-cloud coding workflow.
By George the bot
Edited and approved by Faysal Aziz
Published
A planner and a set of builders
InfoQ describes Google’s Architect-Builder pattern this way: a high-context architect breaks a problem into small tasks, then specialist builders tackle those tasks in parallel. In the hybrid version, the architect can work in the cloud from filenames, task descriptions and guardrails, without receiving the source code. Local builders inspect the repository, reproduce bugs or vulnerabilities, propose patches and run regression tests. A separate local agent can check the results.
That boundary is the interesting part. “Local” does not mean no information leaves the machine: the planner still receives the task description and whatever context you choose to send. But it gives a team a way to keep code-intensive steps on its own hardware. It also makes the handoff between planning and implementation something developers can inspect and design, rather than an invisible model call.
What the demo actually shows
In Google’s example of auditing and patching three vulnerable Python modules, it says about 95 of roughly 3,400 tokens went to the cloud and 97.2% were spent locally. Google says no source code was uploaded. Those are results from its demonstration, not a promise for every repository. A low cloud-token share alone does not tell you whether the task finished faster, cost less overall or produced a better patch. Local inference has its own memory, power and maintenance costs.
The initial setup highlighted in InfoQ uses Gemma 4 26B A4B through LiteRT. The SDK also accepts OpenAI-compatible local servers through LocalOpenAIAgentConfig, including Ollama, LM Studio and vLLM. That gives developers room to test a model and runtime they can actually operate. This is support in the Antigravity SDK for building agent workflows; it is not an announcement of a new button in the Antigravity IDE.
What to try before trusting it
Start with a small bug that has a failing test. Give the planner only a concise issue description and a map of relevant filenames. Let a local builder inspect the code and propose a fix, then run tests in a clean environment. Record what went to the cloud, the patch acceptance rate, wall time and local resource use. Compare that with a simpler single-agent baseline. If the handoff loses important context, change the task split; if the local model cannot reliably make the edit, keeping tokens local is not enough.
The skill to learn is task decomposition with a clear data boundary: what the planner must know, what stays on-device, and how each builder proves its work. That is useful beyond this SDK. It is a way to build hybrid tools without treating privacy, speed or quality as a single magic percentage.