Antigravity brings local models to its agent SDK

You move the coding model onto a workstation, but its shell still has a cloud credential and its planner may still run elsewhere. Google's Antigravity SDK offers another way to choose where model computation happens. Following the rest of the connections explains what that local choice does, and what still leaves the machine.

Google's September 23 announcement introduces Gemma 4 26B A4B through LiteRT and recommends more than 24 GB of VRAM or unified memory. It also describes OpenAI-compatible local servers such as Ollama and vLLM. The demonstrated hybrid setup still sends filenames and task descriptions to a cloud planner, even though execution is local.

Follow a request through the pieces. The model proposes text or an action; its runtime performs the computation; tools read files or execute commands. Moving the model changes one location. It does not automatically change the access already granted to those tools.

Local inference and the tools around it

In a hypothetical repository audit, the agent reads local code and prepares a patch. Its shell inherited a cloud credential from the developer. A command can still use that credential to reach an external service. Local inference and limited tool access are separate properties.

Think of an ordinary script on that laptop: local computation has never meant it cannot contact another machine. The inherited credential is still a route out, whether a person, a script or a model-selected command invokes it.

Suppose the agent’s proposed next step is to check the fix against a cloud service. Our audit permits reading code and preparing a patch, not that additional operation. The inherited cloud account may nevertheless make it possible. The production-agent guide explains why task permission must be explicit: reading a repository does not authorize changing production, writing a ticket or using every inherited account. Review what the tools can do when choosing the local setup.

The SDK README documents read-only defaults and policies to deny, allow or require approval for tools. For this audit, those controls need to make the extra cloud operation unavailable or subject to the required approval, rather than relying on the model not to suggest it. Installation has another practical boundary: the published package supplies a runtime binary, so a repository clone alone is not a complete environment.

A repository audit with visible file and network access

In a disposable repository, give the audit a known defect and synthetic secrets rather than a real account to use. Suppose the proposed patch looks right but the existing test still fails. An independent check of the defect helps distinguish a persuasive diff from a repair. Separately, the available tools, accessed files and contacted destinations show how the agent worked. A quiet attempt would not prove that an inherited credential, if available in another setup, was appropriately restricted. These are proposed observations, not a hands-on result from this article.

The repository itself makes the local-versus-hybrid choice less abstract. If its filenames or task descriptions cannot leave the machine, the demonstrated cloud-planning route is unsuitable even before any source code is sent. A checked fully local route needs suitable hardware and dependencies; otherwise this use case waits. A convenient hybrid planner does not change that information rule.

Once the patch survives the defect check, there is still no automatic permission to publish it. The team can decide where it may be shared using the patch and the account of files, tools and outbound access together. “The model ran here” now answers one useful question. “What did this audit read, contact and repair?” answers the larger one the repository owner actually needed.