BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Google Antigravity SDK Adds Local Model Support for Greater Token Efficiency and Code Privacy

Google Antigravity SDK Adds Local Model Support for Greater Token Efficiency and Code Privacy

Listen to this article -  0:00

Google has introduced support for local models in the Antigravity SDK, enabling developers to build and execute agentic workflows directly on their own machines, while retaining the flexibility to mix in cloud-based models for higher-level tasks. This approach gives developers greater control over data privacy, inference costs, network dependencies, and computational workload distribution.

One of the most compelling capabilities of the Antigravity SDK is hybrid agent orchestration, which adapts Google's proposed Architect-Builder pattern to a mixed cloud-local compute environment.

According to the Architect-Builder pattern, one primary, high-context AI agent, the architect, holds the macro-level system view, including dependencies, architectural guardrails, and detailed specifications or implementation plans. Once the architect has defined a plan, several parallel, multiple specialized AI agents, the builders, work independently in isolated environments to execute discrete, narrow tasks mapped out by the specification.

Google says that the Antigravity SDK enables the architect to operate in the cloud, devising a strategy and breaking the task into smaller units using filenames and task descriptions, without requiring access to the source code itself. The builders, instead, run locally and perform tasks such as reproducing security vulnerabilities, proposing code fixes, reviewing candidate patches, and running regression tests. Additional specialized local agents can validate proposed changes against the provided test suites, keeping the code-intensive stages of the workflow on-device.

In a demonstration involving the auditing and patching ot three vulnerable Python modules, Google reports that only 95 out of approximately 3400 tokens were used on the cloud for planning, while the remaining 97.2% were spent locally. Google also states that no source code was uploaded to the cloud.

The initial implementation focuses on running Gemma 4 26B A4B through Google's LiteRT technology. However, developers are not limited to LiteRT exclusively, as the Antigravity SDK also supports OpenAI-compatible local inference servers through LocalOpenAIAgentConfig, including Ollama, LM Studio, and vLLM.

Commenting on the announcement, Reddit user ambassadortim highlighted that "companies can have more control over their AI model and when to change or at least have more control over that". In a separate discussion, FollowingTop3534 questioned whether the cloud-token share metrics 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.

As a final note from the community, user Latter_Crazy expressed enthusiasmfor the new capabilities:

it can do things I could not do before with the cloud rules. Cost, speed, quality are all going up and this is just the start. Highly recommend looking into this.

The Antigravity SDK should not be confused with the Antigravity IDE, which is an IDE powered by the Antigravity SDK. They share the same underlying agent infrastructure, but serve different purposes, with the SDK letting you build your own AI agents programmatically rather than simply using them for coding tasks.

About the Author

Rate this Article

Adoption
Style

BT