Google's Antigravity SDK Now Runs Local Models Offline

Google’s Antigravity SDK can now use local AI models for agent workflows. The September 23 announcement gives developers a way to keep inference on their own machine, including when the network is unavailable. That creates a useful option for code and documents that should stay local, provided the tools around the model follow the same boundary.

Written October 1, 2026 from information published by September 26, 2026. Later product developments are outside this article’s scope.

Google’s launch post highlights Gemma 4 26B A4B through LiteRT and recommends more than 24 GB of VRAM or unified memory for that setup. It also identifies OpenAI-compatible local servers through LocalOpenAIAgentConfig. This is SDK support: it does not mean every Antigravity editor session has switched to local inference.

An SDK is a library used to build an application. The model produces responses, while the surrounding agent code decides how to call tools and continue the task. Moving the model changes where those responses are generated. It does not automatically decide which files a tool can read or where a tool can send results. For the wider product context, see our Antigravity desktop overview.

Google demonstrates a hybrid workflow in which a cloud planner receives filenames and task descriptions while local workers handle source code. That is a vendor demonstration, not proof that an arbitrary hybrid application keeps every sensitive detail local. We have not run an independent performance or privacy benchmark of it.

The design question is concrete: which exact fields cross the boundary? A filename can expose a customer name. An error message can include a path, a query or a fragment of a document. A “summary only” return value can still disclose the content it summarizes. Review the outbound payload rather than treating the absence of a full source file as sufficient evidence.

For a hybrid pilot, use synthetic filenames and a disposable repository. Capture the requests sent to the cloud planner and inspect them before using real work. If the organization cannot authorize even that limited transfer, choose the fully local path instead of trying to phrase a prompt that promises privacy.

The official Python SDK repository is the implementation reference linked by Google’s launch post. Record the package version, model artifact and runtime used for your pilot. A later package install can change behavior, so “we used the SDK” is not enough detail to reproduce the result.

Use Google’s dated setup instructions for the exact installation and configuration syntax. The LiteRT route uses LiteRTAgentConfig; the compatible-server route uses LocalOpenAIAgentConfig. Check that the endpoint you configure is actually local. A localhost address inside a container refers to that container, which may not be where the model server runs.

Start with reading a small test directory and producing a summary. Add file writing only when that simple loop behaves as expected. Keep the first write task recoverable: a generated report or a patch in a throwaway checkout. The purpose is to establish that configuration, inference and tool execution work together before evaluating a larger task.

A local model can operate on valuable files if its tools can reach them. Our sandbox and filesystem boundary guide explains why a working directory alone should not be treated as an access-control guarantee. Give the runtime only the files and credentials the task needs.

Keep secrets out of the test environment. Review mounted directories, environment variables and inherited credentials, then check whether a permitted command can invoke another program with broader access. For a truly offline requirement, verify network behavior at the runtime or operating-system boundary. A promise in the prompt is not a network policy.

Compare a fixed set of tasks with your existing process. For each, record whether the result passed, how long it took, peak memory use and the time a reviewer spent fixing it. Add the cost of hardware and operations to the decision, even though local inference avoids a per-request cloud API charge. An idle machine you already own and a new dedicated workstation have different economics.

Start with a task whose correctness is observable, such as making a small change that must pass an existing test. Avoid ranking the setup by how quickly it begins producing text. The useful result is the accepted patch or report, including any retries. Our model-routing guide covers that workload-based comparison; our AI transformation service helps teams design the evaluation.

Moving the model onto the workstation changes one thing, where responses are generated, and the guide’s sections exist because teams assume it changes more. The illustrative pilots below each assume one thing too many. They are design examples drawn from the announcement’s own boundaries, not deployments we have run.

Each pilot would have passed a quick demonstration and failed the requirement that motivated it. The record in the next section writes the requirement down first and checks the rest against it.

The four also mark the difference between a demonstration and a pilot. Google’s launch post shows what the SDK can do, with a hybrid workflow and a resource-monitor example that are built to be clear rather than to be your configuration. A pilot takes those examples as starting points, replaces the parts written for clarity with the parts your boundary requires, and records what changed, which is how a later reader can tell which of the two they are looking at.

The guide asks for the data boundary first, a reproducible environment, explicit permissions and a measured evaluation, and a record per pilot holds all four. The boundary, as a sentence that can be tested: which of task descriptions, filenames, results and source may leave the machine, and for a hybrid design exactly which fields go to the planner. The configuration: the SDK package version, the model artifact and its location, the runtime route, LiteRT or a compatible server, and the endpoint confirmed to be local from where the SDK runs rather than from inside a container. The permissions: the directories mounted, the environment variables and credentials present, and the policy replacing the demonstration’s allow-all. The tasks: each with pass or fail, elapsed time, peak memory and reviewer correction time, starting from a change that must pass an existing test. For a hybrid pilot, the captured outbound requests, inspected before real work replaced the synthetic filenames. And the decision, with the hardware and operations cost beside the avoided API charge.

An illustrative record for a code-summary pilot reads: boundary, nothing leaves the workstation, including filenames; configuration, the pinned SDK version, the Gemma 4 26B A4B artifact through LiteRT on a machine above the recommended memory, the endpoint confirmed local; permissions, one disposable checkout mounted, no credentials in the environment, read-only until the summary loop behaved; tasks, a directory summary passed, a small patch in a throwaway checkout passed its test on the second attempt with one correction, times and memory recorded; outbound capture, not applicable; decision, continue to a second task class on the owned idle machine.

The record is also what makes the evaluation section’s comparison fair over time. A later SDK release or a different model artifact is a different experiment, and the record is where that difference is visible when the numbers move.