A local coding agent is not automatically a private, cheap, or safe one. Here is how to give it the right jobs, a tight workspace, and a clear path to human review.
The most expensive AI request is often the one that should never have left a developer laptop. A repository scan, a test-failure summary, or a narrow patch review may not need a cloud model, an API key, or a round trip through a vendor service. Yet “run it locally” can become its own kind of wishful thinking. Local models have smaller context windows, uneven tool use, real hardware limits, and the same ability to damage a checkout if you hand them broad permissions.
Google’s new local-model support in the Antigravity SDK makes the option more concrete. The SDK can run Gemma through LiteRT on-device or connect to an existing OpenAI-compatible local server such as Ollama, LM Studio, or vLLM. That is useful because it brings an agent harness — sessions, tools, policies, workspaces, and compaction — to a local model instead of asking developers to bolt together a chat loop and shell access.
The practical opportunity is not to replace every cloud agent. It is to build a local lane for bounded work, then deliberately escalate the work that needs more context, stronger reasoning, web access, or a human decision. This guide shows how to make that lane useful without confusing “offline” with “risk-free.”
Teams usually begin by asking whether a local model is good enough to code. That is the wrong first question. A better question is: what evidence must this task read, what may it change, and what proves the result? Those answers determine whether the work belongs in a local lane.
Good first jobs are narrow, repeatable, and easy to verify. Examples include searching a repository for deprecated calls, summarizing a failed test run, classifying logs, proposing a patch inside one module, creating a test matrix, or reviewing a diff for a known policy. These jobs can be given a small file set, a fixed command allowlist, and a clear acceptance check.
Keep cloud or human review in the loop for ambiguous architecture, unfamiliar domains, broad migrations, customer-impacting changes, external research, credentialed systems, and anything that needs a judgment call about product behavior. Local execution is a routing choice, not a quality claim.
A simple rule: use a local agent when the task can be expressed as “inspect this bounded evidence, make this limited proposal, and prove it with these checks.” Escalate when the task depends on open-ended discovery or a decision with costly consequences.
Antigravity SDK has two useful local paths. LiteRTAgentConfig is the on-device route. It manages a loopback server for a LiteRT checkpoint, including the current Gemma 4 26B A4B path. Google recommends a machine with at least 24 GB of VRAM or unified memory and notes that the checkpoint download is large. Treat that as a deployment requirement, not a footnote: slow paging or an undersized machine will turn an otherwise good workflow into a frustrating one.
LocalOpenAIAgentConfig is the integration route. It lets the same agent harness talk to a local OpenAI-compatible endpoint, including Ollama, LM Studio, or vLLM. Choose it when a team already operates a local serving stack or wants to compare several local models without changing the surrounding agent code.
Both paths benefit from the SDK’s lightweight configuration. Local models should not receive the same huge instruction bundle and tool catalog you might give a frontier cloud model. The LiteRT configuration applies a lightweight preset that trims the prompt, limits built-in tools to core coding work, and uses a compaction threshold suited to a smaller local context cache. That is a design lesson worth keeping even when you use another runtime: make the local lane smaller on purpose.
import asyncioimport osfrom google.antigravity import Agent, LiteRTAgentConfig
MODEL_PATH = os.path.expanduser( "~/.litert-lm/models/gemma4-26b/model.litertlm")
python
async def main(): config = LiteRTAgentConfig(model_path=MODEL_PATH) async with Agent(config) as agent: response = await agent.chat( "Summarize the failing tests in this workspace. Do not edit files." ) print(await response.text())
asyncio.run(main())
This small example is intentionally read-only. It establishes the first thing to verify: that the model can inspect the right evidence and return a usable answer before it receives edit or command capability.
“Use local when possible” is too vague for people and useless for an agent router. Write a routing contract that names the allowed tasks, the evidence boundary, the output shape, and the escalation trigger. Put it next to the code that chooses the model, not in a slide deck.
For example, a local inspection worker might receive only a service directory, the last 200 lines of an error log, and a task to return three fields: likely cause, evidence paths, and next command. A local patch worker might receive one issue, one package, and an instruction to change no more than three files. A cloud planner can then consume that compact result if the repair spans services.
A useful contract has four parts:
Local-first does not mean cloud-never. It means the default path has a reason, a boundary, and an escape hatch.
An offline agent can still make a destructive local change. A model that never sends code over the network can still overwrite a migration, scan a parent directory, or run an expensive command if the harness allows it. Privacy and execution authority are separate controls.
Start read-only. Permit file reads in one workspace and a few harmless commands such as the project formatter or a focused test target. Add writes only after you have a patch review step. Keep package installation, network tools, secret-bearing environment variables, Git push, and broad shell commands out of the first version.
Antigravity configurations support workspaces and tool policies. The important part is not copying a permissive example into production; it is defining the smallest policy that can complete the job. A local patch worker should be confined to an explicit project path. If it needs a second path, that is an escalation event, not a reason to grant the home directory.
from pathlib import Pathfrom google.antigravity import Agent, LiteRTAgentConfig# Import the policy helpers supplied by your SDK version.
workspace = str(Path("./services/billing").resolve())
config = LiteRTAgentConfig( model_path=MODEL_PATH, workspaces=[workspace], # Attach a narrow policy here: allow reads, approved test commands, # and reviewed writes only inside workspace.)
The exact policy helper can evolve with the SDK, so verify the current reference before shipping. The stable principle is more important: a prompt saying “do not edit outside this folder” is advice; a workspace and policy are enforcement.
Local agents need a cleaner runway than large cloud models. Give them the goal, the allowed area, the evidence to inspect first, the permitted tools, the definition of done, and the stop condition. Do not bury those instructions below a page of company lore.
A strong local task prompt looks like this:
Goal: explain why the billing parser test fails.Scope: read only services/billing and tests/billing_parser_test.py.Evidence first: run the named test, then inspect its fixture and parser.Allowed actions: read files and run that single test command.Return: probable cause, two evidence pointers, and one minimal fix option.Stop: do not edit files; escalate if the fault crosses service boundaries.
That prompt lowers the chance of aimless search. It also creates a response that another agent or a human can verify. Notice what it does not contain: an inflated persona, every tool in the organization, or a promise that the agent must solve any problem at all costs.
The most practical local model workflow is often a hybrid one. Let a cloud planner break a large issue into bounded investigations. Send each sensitive or repetitive investigation to a local worker. Return only the worker’s evidence bundle to the planner. Then require human review before a merge.
Google’s local-model documentation includes a Hybrid Gauntlet example that pairs a cloud Gemini planner with local Gemma workers for on-device code auditing and patching. The pattern generalizes well. A cloud model can be better at broad synthesis while a local worker limits data movement for repository inspection. The division should follow evidence needs and risk, not vendor loyalty.
Be explicit about what crosses the boundary. A safe local worker can return a changed-file list, test output, line references, a small patch, and redacted error categories. It does not need to upload an entire proprietary repository, raw logs with customer identifiers, or a secrets file so that a planner can “have context.”
Local model discussions often skip straight to dramatic savings or sweeping quality claims. Those numbers are not portable. Hardware, model size, quantization, prompts, tool latency, task mix, and developer review time all change the result. Measure the work you actually intend to route.
Create a small fixture set from completed tickets. Include a read-only diagnosis, a one-file test repair, a narrowly scoped refactor, and a task the local agent should decline. Run the same prompts through the candidate local lane and your existing workflow. Record whether the correct files were identified, whether the patch stayed in scope, whether tests passed, how long it took, how much reviewer rework it created, and whether the escalation was appropriate.
One metric matters more than a polished demo: accepted work per reviewer minute. A local agent that produces a smaller but well-scoped evidence bundle may be more valuable than a faster one that generates a large diff someone must untangle. Track failure modes too: wandering scope, tool misuse, missing evidence, incorrect claims, and unsafe escalation.
First, do not treat a local model as an air gap when its tools can browse, call a remote MCP server, or read credentials from the environment. Map the complete execution path. The model may be local while the task still sends information elsewhere.
Second, do not expose a whole monorepo because the agent occasionally needs one extra file. Add a retrieval step, a narrower fixture, or an escalation route. A giant workspace turns a bounded worker back into an unbounded investigator.
Third, do not use a permissive tool policy as a debugging shortcut. If a read-only workflow fails, fix the task contract or add one specific capability. “Allow all until it works” trains the team to accept authority they cannot later explain.
Finally, do not compare a local worker with a cloud model using a single clever prompt. Include tasks it should refuse, noisy evidence, failed tests, and one task just beyond its boundary. The best local route is not the one that answers every request; it is the one that succeeds predictably and declines safely.
This sequence is intentionally boring. That is a feature. It gives a team evidence about their own workload before the local agent gains more reach.
Antigravity SDK local models are interesting because they make the agent harness portable across cloud and on-device inference. Developers can keep a consistent approach to sessions, tools, workspaces, and review artifacts while choosing a local model for the work that benefits from it. That is more durable than treating local AI as a separate hobby stack.
The winning workflow will not be “replace every cloud call.” It will be a clear traffic pattern: local workers inspect bounded private evidence, cloud systems handle broader synthesis when authorized, and people approve consequential changes. Build that pattern with small tasks, enforced boundaries, and fixtures that prove the lane is helping.
For implementation details, verify the current Antigravity local-model documentation and Google’s local-model launch announcement; both are evolving preview-era surfaces.
Yes, the LiteRT local-model path is designed for on-device execution without an API key or internet connection. You still need to meet the local model, runtime, and hardware requirements.
No. Route bounded, verifiable tasks locally. Escalate open-ended design, broad investigation, external research, and high-consequence decisions to an authorized cloud workflow or a human reviewer.
LiteRTAgentConfig runs a compatible local checkpoint through Google AI Edge’s LiteRT runtime. LocalOpenAIAgentConfig connects the SDK harness to an existing OpenAI-compatible local server such as Ollama, LM Studio, or vLLM.
No. Local execution can reduce data egress, but filesystem writes and shell commands still need workspace boundaries, tool policies, tests, and human review.
Google’s current local-model documentation recommends at least 24 GB of VRAM or unified memory for the Gemma 4 26B A4B checkpoint. Validate performance on the exact machines your team will use.
Evaluate it on representative fixtures and measure scoped success, passing checks, reviewer rework, correct escalation, latency, and accepted work per reviewer minute. Avoid relying on generic benchmark claims.
Antigravity SDK Local Models: Build Offline Coding Agents That Stay Useful was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.