Antigravity SDK Now Runs Gemma 4 on Your GPU

Google’s developer blog dated the local-model support for the Antigravity SDK as Sept. 23, 2026. Sachin Kotwani and Taylor Mullen wrote it. The useful part is not the privacy slogan. It is a concrete path: install the SDK, pull Gemma 4 26B A4B as a LiteRT file, and point LiteRTAgentConfig at a path on disk. A recorded hybrid run in the same post spent 95 tokens in the cloud and kept 3,322 tokens, 97.2 percent of the run, on the machine.

If you already compared API list prices or walked through Claude’s compaction controls, this is a different bill. Those posts are about what a vendor charges when the prompt leaves the building. This one is about a path that does not leave.

The hardware line in the post is easy to skip and expensive to ignore. They recommend a machine with more than 24GB of VRAM or unified memory. If you are on a laptop with 16GB shared with the display, stop at this paragraph. The rest of the steps will install. They will not run the 26B model at a speed you will wait for.

What the Sept. 23 post actually added

The post’s own reasons for local runs are cost, privacy, offline use, and a hybrid split. Cost means no API meter and no rate limit on the local leg. Privacy, in their wording, means code and requests stay on the machine, which matters if your employer already forbids pasting a repo into a chat window. Offline means the agent loop still runs when the network does not. Hybrid means a cloud model can plan while a local model does the work that touches files.

A local 26B model will not match a frontier cloud model on a hard planning task. The post does not claim it will. The design they demo is the opposite: Gemini 3.8 Flash plans, Gemma 4 26B executes on the GPU. If you wanted one model to do both, this tutorial is the wrong shape. Read the hybrid section before you spend an evening downloading weights.

There is a second on-ramp the post names and does not fully specify. LocalOpenAIAgentConfig is the class for any OpenAI-compatible server: Ollama, LM Studio, or vLLM. The blog says your agent orchestration, tools, and workflows stay the same while the inference backend changes. It does not print the constructor arguments in the text we could extract cleanly. The anchor they point at is the Python SDK README section on local models. Use that page for the Ollama path. This article sticks to the LiteRT sample, because that is the one with a full file in the post.

A note on dates, because the feeds disagree. Tavily’s index stamped the URL as Sept. 24. The page itself says SEPT. 23, 2026. Cite the page.

Install the Antigravity SDK and the weights

The backslashes are line continuations, and the duplicated litert-lm is the next command glued to the pip line. What follows is that reconstruction, not a second source. If a flag differs when you open the post, the post wins.

Create the virtualenv and activate it the usual way:

python3 -m venv .venv
source .venv/bin/activate

Install the SDK and the LiteRT downloader, then import the GPU build of Gemma 4 26B A4B from the LiteRT community repo. The last argument is the local alias the sample later expects, gemma4-26b.

pip install google-antigravity litert-lm
litert-lm import \
  --from-huggingface-repo=litert-community/gemma-4-26B-A4B-it-litert-lm \
  gemma-4-26B-A4B-it-gpu.litertlm \
  gemma4-26b

That alias matters. The sample does not search Hugging Face at runtime. It opens a file:

~/.litert-lm/models/gemma4-26b/model.litertlm

If the import finishes and that path is missing, do not debug the agent. Debug the import. ls the models directory. The post also points at the LiteRT-LM overview for how these packages run on the edge. You need it only if the import succeeds and inference then fails on a GPU the installer did not mention.

Disk space is the other silent requirement. A 26B LiteRT file is not a pip wheel. If the import dies halfway, you do not have a partial model the SDK will politely explain. You have a short file and a long stack trace. Check free space before you start, then check the path after.

The sample file, including the import it does not use

The post says to create agy_sample.py in the project directory and paste a short async script.

import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig
from google.antigravity.hooks import policy

MODEL_PATH = os.path.expanduser("~/.litert-lm/models/gemma4-26b/model.litertlm")

async def main():
    print(
        f"Using local LiteRT model: {MODEL_PATH}. "
        "Please wait for local inference to complete. "
        "This could take several minutes."
    )
    config = LiteRTAgentConfig(model_path=MODEL_PATH).lightweight()
    async with Agent(config) as agent:
        response = await agent.chat("What files are in the current directory?")
        async for token in response:
            print(token, end="", flush=True)

if __name__ == "__main__":
    asyncio.run(main())

Run it with the venv active: python agy_sample.py.

Two details in that file are easy to “clean up” and then wonder why the post looked different.

from google.antigravity.hooks import policy is in the sample and never called. The chat example does not register a hook. You can drop the import until you add one. I am leaving it in the listing so you can see what the blog shipped, not a tidied fork. If your linter complains, delete the line. Nothing else in this script depends on it.

.lightweight() is a method on the config, not a comment. The post chains it on LiteRTAgentConfig(model_path=MODEL_PATH). Do not strip it to see if the model “works better.” First run should match the sample. Experiments come after you have one successful token stream.

The prompt is deliberately boring: list files in the current directory. That is a tool-use check, not a benchmark. If the model answers from memory and never looks at the folder, you have learned something about this build before you point it at a repo. If it hangs on “several minutes,” that matches the print statement they shipped. A 26B local model on a machine that only barely clears 24GB will feel like a stuck process. Give it the time the sample asks for before you kill it.

async for token in response is the whole streaming contract in this example. There is no second client. There is no API key in the file. If you are copying habits from a cloud tutorial, do not add a key “just in case.” This path does not want one.

The hybrid run is the part worth copying

The sample above proves the weights load. The post’s hybrid section is the pattern they want you to copy for real work.

In the recorded demo, Gemini 3.8 Flash is the architect. It plans from filenames and task descriptions. It does not receive the source. The post says that planning step spent 95 cloud tokens, and that no source code left the machine. A local swarm of Gemma 4 26B instances then did the file work: three modules named auth.py, billing.py, and database.py. The local loop reproduced vulnerabilities, wrote candidate fixes, critiqued the patches, and checked them against regression tests. Of the tokens in that recorded run, 97.2 percent (3,322 tokens) stayed local.

Read the constraint, not the percentage. The cloud model saw names and a task description. It did not see the files. If your planning prompt includes a paste of auth.py, you have left the demo. The 95-token figure is for a plan built without the code. A plan built with the code is a normal cloud call, and you should price it like one. The Higgsfield writeup is what it looks like when a team does the opposite and ships from a cloud model on purpose. Different job. Do not mix the receipts.

The example project is at goo.gle/47cKYyV. The post says you can run their 3-file gauntlet or point the same setup at your own Python modules and tests. I have not re-run their gauntlet for this article. Treat 95 and 3,322 as their recorded run, not as your expected bill. Your file sizes will move the local count. They should not move the cloud count if you keep source off the wire.

A second example in the same post is smaller and easier to try the same day. The prompt asks the local model to build a terminal dashboard with psutil and rich: CPU, memory, and a table of the top five processes by memory, saved as monitor.py, plus a requirements.txt, then tested. The workspace they use is ~/agy-test, created in the script before the agent runs. Same LiteRTAgentConfig, same model path. This is the one I would run before the security gauntlet. It fails in an obvious way if the model cannot write files, and it does not require you to trust a patch to auth.py.

When to stay on the cloud path

Local is the wrong default if the machine misses the 24GB line, if the task is planning rather than file grinding, or if you need a result in seconds rather than the “several minutes” the sample warns about. The post’s hybrid exists because they already know that. Flash plans. Gemma works. You can invert that and you will have a slow planner plus a cloud bill for the files. That is the expensive version of the same diagram.

LocalOpenAIAgentConfig is the escape hatch if you already run Ollama or vLLM and do not want a second weight format. Open the README anchor, copy their example, and keep the agent loop you already tested against LiteRTAgentConfig. The point of the class, in the post’s words, is that orchestration and tools do not change when the backend does. If your tools assume a cloud client with a key in the environment, they will still assume that. The config swap does not rewrite your tools.

One more limit, because local demos love to skip it. A model that never uploads source can still write a bad patch. The post’s gauntlet includes a critique step and regression tests. If you drop those and apply the first diff, you have a local model with write access and no reviewer. That is not a privacy feature. That is an unreviewed commit that happened to be cheap. Keep the test command in the loop the demo describes, or do not point this at a repo you care about.

The Sept. 23 post is a setup guide with one measured run attached. Install, confirm the .litertlm path, run the directory listing, then decide whether the hybrid split is worth the download. The 97.2 percent figure is an argument for the split. It is not a promise about your repo.