Google Antigravity SDK Local Models Bring Agents Offline, but Hardware Sets the Boundary

Google has added Antigravity SDK local models, letting developers run agentic workflows without an API key or internet connection for the first time.

The initial optimized route combines Gemma 4 26B A4B with Google AI Edge’s LiteRT runtime. Google recommends at least 24 GB of VRAM or unified memory. That requirement places the full experience beyond many ordinary laptops, despite the promise of local execution.

This release shifts an important boundary. Developers no longer need to send every prompt, source file, or tool result through a hosted model. However, cloud agents still offer easier deployment, greater model capacity, and fewer hardware constraints.

Google is therefore challenging the cloud-only agent model without abandoning it. Its own demonstration uses a Gemini cloud planner alongside several local Gemma workers. The more important story is not total cloud replacement, but control over where each part of an agent runs.

Antigravity SDK Local Models Move the Agent Loop On-Device

Google has moved the agent’s model calls, tool loop, and working context onto hardware controlled by the developer.

Google announced local model support on September 23, 2026. The company says the Antigravity SDK now supports local workflows across multiple models and execution options.

The SDK exposes the agent capabilities behind Google Antigravity through Python. Those capabilities include model interaction, tools, policies, workspaces, hooks, and subagents.

Developers previously associated these workflows with remote inference. The new configuration allows an agent to operate against a model checkpoint stored and executed on the same machine.

Google’s local model release highlights Gemma 4 26B A4B as the first optimized model. LiteRT handles inference through the device’s available acceleration hardware.

The supported path uses LiteRTAgentConfig, which points the agent toward a .litertlm checkpoint. The SDK starts a loopback server, meaning a service available only through the local machine’s network interface.

That local service sits between the Antigravity agent and the model runtime. It lets the broader agent framework communicate with the checkpoint without calling a public model endpoint.

According to Google, the resulting workflow can run without an API key or an internet connection. That is a meaningful distinction from products that merely store selected files locally.

A fully offline run means model inputs, generated tokens, and tool interactions can remain on the device. The precise privacy outcome still depends on the tools and integrations enabled by the developer.

An agent that calls a web search service is not completely offline. Neither is an agent connected to remote databases, analytics systems, or hosted Model Context Protocol servers.

The SDK also supports external local servers through LocalOpenAIAgentConfig. This route connects to software that exposes an OpenAI-compatible API on the developer’s machine or private network.

Google names Ollama, LM Studio, and vLLM as examples. That compatibility matters because local AI users already organize models and automation around those servers.

The two routes serve different needs. LiteRT offers a Google-managed path optimized around its runtime, while compatible servers give teams more control over model hosting.

Google’s local execution guide documents both configurations. It also confirms support for Apple Silicon Metal, Nvidia CUDA, and automatically detected accelerator backends.

This is more than another model selector inside an editor. The SDK allows developers to place local inference inside their own scripts, services, evaluation systems, and specialized agent workflows.

That programmability creates the article’s central tension. Moving inference onto the device improves control, but it also transfers infrastructure responsibility from Google to the user.

Offline Agents Put Cloud-Only Workflows Under Pressure

The release pressures cloud-only agent platforms by making data locality an architectural choice instead of a product limitation.

Cloud inference remains the default for most coding agents. It gives users immediate access to large models without requiring a workstation-class GPU or lengthy model downloads.

That convenience has a cost beyond usage fees. Source code, prompts, retrieved documents, and tool outputs must enter a remote processing environment.

Provider policies can limit retention and training use. Enterprise agreements can add stronger controls. Even so, some organizations cannot send sensitive material outside an approved machine or network.

Air-gapped development environments present the clearest case. These systems intentionally lack direct internet access because they contain regulated, classified, or commercially sensitive information.

A cloud-only agent cannot operate normally in that setting. An offline Antigravity agent can, provided its model and software dependencies arrive through an approved transfer process.

The same advantage applies to developers working with unreleased products, security reports, legal documents, and proprietary algorithms. Local execution reduces the number of systems that receive their context.

It also changes service availability. A local workflow does not stop because a model provider has an outage, changes a quota, or withdraws an endpoint.

That independence can matter during long-running tasks. An agent auditing a repository may execute many model turns while reading files, planning changes, running tests, and reviewing errors.

Latency also behaves differently. Local inference avoids wide-area network delays, but token generation depends entirely on the available hardware and runtime optimization.

A well-equipped workstation can provide predictable response times. A machine near the minimum memory recommendation may deliver a much slower experience, especially under concurrent workloads.

Cloud platforms retain clear advantages. They can provide larger models, elastic capacity, centralized monitoring, and managed updates without consuming local memory.

They also let teams standardize performance across employees using different computers. A local-first approach makes device specifications part of the deployment plan.

This release therefore does not establish a simple contest between local and cloud AI. It pressures platforms that offer no meaningful choice between those execution environments.

The strategic advantage belongs to frameworks that can route work according to sensitivity, complexity, and available compute. Google’s SDK now supports that broader pattern.

For enterprises, the decision becomes more granular. A team can reserve hosted models for demanding planning while keeping repetitive file analysis on controlled hardware.

Individual developers gain another form of leverage. They can continue using an agent workflow even when they do not want every task tied to remote authentication or consumption limits.

The limitation is access to suitable hardware. Google recommends at least 24 GB of VRAM or unified memory for the featured Gemma checkpoint.

Many mainstream computers fall below that threshold. Some machines technically meet it but must share that memory with the operating system, editor, browser, and build tools.

Cloud-only providers can reasonably argue that managed inference remains the more accessible route. Local agents improve autonomy, but they do not eliminate computing costs.

The pressure is therefore strongest in security-conscious and technically mature teams. Those buyers can value local control enough to accept setup work and hardware requirements.

LiteRT and Gemma 4 Explain How the Offline Workflow Works

The mechanism depends on a sparse Gemma model, a local inference runtime, and an agent framework that can keep its control loop nearby.

Gemma 4 26B A4B uses a mixture-of-experts architecture. This design routes each token through only part of the model instead of activating every parameter.

Google lists 25.2 billion total parameters and 3.8 billion active parameters for the model. The A4B label refers to roughly four billion parameters being active during inference.

That distinction matters for local execution. The model can draw from a larger parameter pool without requiring dense computation across all 25.2 billion parameters for every token.

It does not mean the checkpoint occupies only four billion parameters in storage or memory. The full collection of experts must remain available for routing.

Google says the LiteRT-formatted checkpoint downloads approximately 16.8 GB. The recommended 24 GB memory level leaves additional capacity for inference state and other processes.

The Gemma 4 model card lists a context window of up to 256,000 tokens for the 26B A4B model. It also supports text and image inputs.

A large advertised context window does not guarantee that every local machine can use it comfortably. Longer contexts increase memory requirements and processing time during real workloads.

Gemma 4 also includes native function calling. Function calling lets a model request a structured action, such as reading a file or invoking a developer-defined tool.

That capability is essential for an agent. A conventional chatbot only produces responses, while an agent alternates between reasoning, actions, observations, and revised decisions.

Antigravity supplies the surrounding control system. It manages the workspace, available tools, execution policies, and communication with the local model.

LiteRT supplies the inference layer. Google designed the runtime for on-device machine learning across supported hardware backends.

The LiteRT model guide describes Gemma variants intended for devices ranging from phones to consumer GPUs and workstations. Hardware targets vary considerably across the family.

For the Antigravity integration, developers install the SDK and litert-lm package. They then import the model into LiteRT’s checkpoint format.

The agent receives the model path through its configuration. When the program starts, the SDK creates the local model service and streams generated tokens back to the application.

That architecture keeps the integration relatively familiar. Developers still instantiate an agent and send it a task, rather than building an inference server and tool loop independently.

The alternative OpenAI-compatible configuration broadens the model options. A team can point Antigravity toward an existing Ollama, LM Studio, or vLLM deployment.

An OpenAI-compatible interface standardizes common request and response formats. It does not imply that the underlying model came from OpenAI.

This distinction lets Antigravity sit above several inference stacks. The agent framework can remain stable while the selected local server or model changes.

Compatibility also reduces lock-in at the runtime layer. Teams already using vLLM on an internal server do not need to adopt LiteRT for every workflow.

LiteRT still receives special attention because Google optimized the initial Gemma 4 path around it. That pairing gives Google control over both the model format and execution runtime.

The architecture supports more than fully local operation. It also allows hybrid orchestration, where a cloud model plans work and local agents perform bounded tasks.

That hybrid option is the clearest explanation for Google’s timing. Local models have become capable enough to handle useful coding work without replacing the strongest hosted planners.

Google’s Hybrid Demo Reveals the Real Strategy

Google’s own example shows that local agents are becoming a workforce layer, while cloud models retain the planning role.

The company demonstrated an Architect-Builder pattern using Gemini 3.8 Flash as the cloud architect. Local Gemma 4 26B instances acted as builders.

The demonstration assigned the system three vulnerable Python modules named auth.py, billing.py, and database.py. Local workers handled auditing and patching on the device.

The cloud planner coordinated the broader process. This division kept much of the repository work local while preserving access to a larger hosted model for orchestration.

It is a more credible design than claiming one local checkpoint can match every cloud model. Different stages of an agent task have different accuracy, privacy, and compute needs.

Planning often benefits from stronger reasoning across a broad context. Repetitive inspection, editing, and verification can be distributed to smaller workers.

The model resembles conventional computing architecture. Centralized systems schedule jobs, while specialized machines execute tasks close to the relevant data.

For software teams, a practical hybrid workflow might begin with a hosted model decomposing a migration. Local agents could then inspect individual modules and propose edits.

A final review could return to the cloud planner after sensitive details have been minimized. Alternatively, a human could review local outputs without another remote call.

The privacy benefit depends on that boundary. If the cloud planner receives complete source files, local builders do not prevent remote data exposure.

Developers must decide what context crosses the boundary, which summaries are shared, and which tools can access external services. The SDK cannot make those policy decisions automatically.

Google’s policy system gives developers a place to enforce limits. However, permissive sample configurations should not become production defaults without review.

The company’s basic example uses a local agent to inspect files in the current directory. A more advanced example lets the agent create a monitoring tool and run commands.

Those capabilities make the agent useful, but they also increase risk. A mistaken or manipulated model can modify files, invoke processes, or expose information through connected tools.

Local inference does not make an agent harmless. It changes where model computation happens, not whether generated actions require supervision.

Hybrid execution also introduces operational complexity. Teams must monitor both remote calls and local runtimes while understanding failures across the boundary.

A cloud planner can produce a flawed task decomposition. Local builders can then execute that plan consistently, spreading one error across several files.

Concurrency creates another constraint. Running multiple Gemma 4 instances may demand more memory than a single recommended configuration provides.

Google has not published independent, workload-specific benchmarks for the Antigravity integration. The announcement therefore establishes availability, not universal performance.

The demo still signals a clear product direction. Google is positioning local models as complementary workers within a broader agent system.

That strategy pressures other agent frameworks to support similar routing. Customers will increasingly ask whether a task can remain local before accepting a cloud-only answer.

It also gives Google a way to span both markets. Gemini services remain relevant for demanding orchestration, while Gemma and LiteRT cover private or cost-sensitive execution.

The 24 GB Recommendation Is the First Reality Check

Offline operation removes dependence on a remote endpoint, but it replaces that dependency with hardware, maintenance, and model-quality constraints.

Google recommends a machine with at least 24 GB of VRAM or unified memory for Gemma 4 26B A4B. The wording describes a recommendation, not a universal guarantee.

VRAM is dedicated graphics memory used by discrete GPUs. Unified memory is a shared pool used by processors and graphics hardware on systems such as Apple Silicon Macs.

Those configurations behave differently under pressure. A discrete GPU can offer high inference throughput, while unified memory can provide flexibility across CPU and graphics tasks.

Available capacity matters more than the advertised total. A 24 GB machine running containers, browsers, builds, and multiple agents may have little room left.

The 16.8 GB checkpoint download also creates a deployment burden. Organizations must distribute, verify, update, and store that artifact across approved machines.

Model provenance becomes an operational concern. Teams should confirm where a checkpoint originated, how it was converted, and whether its license permits the intended use.

Gemma 4 carries an Apache 2.0 license according to Google’s documentation. External fine-tunes and converted checkpoints can introduce separate terms or security questions.

Model quality presents a larger uncertainty. Google publishes benchmark results for Gemma 4, including coding and agent-oriented evaluations.

Those benchmarks describe the underlying model under defined test conditions. They do not establish how reliably Antigravity completes long, tool-driven tasks on a developer’s repository.

Agent reliability compounds errors across steps. A small misunderstanding can affect file selection, command execution, test interpretation, and the final patch.

Local models can also lack the latest hosted improvements. Cloud providers can update inference systems centrally, while local deployments require deliberate upgrades and regression testing.

Teams may prefer that stability. A fixed checkpoint produces a more controlled environment and avoids unexpected behavior changes after a remote model update.

However, fixed does not mean deterministic. Sampling settings, tool results, workspace state, and concurrency can still change outcomes.

Security teams must also examine the local server. A loopback address limits exposure, but poor configuration can still open ports or grant overly broad filesystem access.

OpenAI-compatible servers require similar scrutiny. The vLLM serving documentation shows how local or private endpoints mimic common model APIs.

Compatibility improves portability, but it can conceal meaningful differences. Models vary in tool-call formatting, context handling, safety behavior, and support for structured outputs.

Developers should therefore test the entire agent loop, not only prompt responses. A model that writes good code may still struggle to select tools reliably.

Google’s hardware recommendation narrows the immediate audience. Workstations with high-memory Nvidia GPUs and better-equipped Apple Silicon systems are the natural starting points.

Smaller Gemma models can broaden access, but Google’s announcement centers its optimized workflow on the 26B A4B checkpoint. That is the version supporting the strongest launch claim.

The gap between “runs locally” and “runs well on my machine” remains unresolved. Performance will vary with hardware, context size, tool usage, and task complexity.

There is also no evidence yet that offline Antigravity agents match leading hosted systems across full software-engineering tasks. Google has not made that broader claim.

The responsible reading is narrower. Antigravity can now execute meaningful agent workflows locally, with a documented setup and a substantial memory recommendation.

That capability is important even before performance parity. It gives teams a deployable option where remote inference was previously disallowed or undesirable.

Three Signals Will Show Whether Local Agents Become a Default

The next test is whether local execution becomes routine beyond privacy-sensitive experiments and high-memory developer workstations.

The first signal is broader model and hardware support. Developers need practical choices for machines below the 24 GB recommendation.

Smaller Gemma variants could make offline agents accessible to more laptops. Additional optimized checkpoints could also let teams trade capability for speed and memory use.

Support alone will not be enough. Google must publish clear performance data across Apple Silicon, Nvidia GPUs, and other supported accelerators.

Useful measurements include generation speed, time to first token, peak memory use, and end-to-end task completion. Agent benchmarks should cover tools and multi-step recovery.

If those results show acceptable performance on common hardware, the local route becomes more than a specialist feature. Weak results would reinforce cloud inference as the default.

The second signal is evidence from production deployments. Early demonstrations prove that the software runs, but they do not reveal daily reliability.

Teams will need to report how local agents handle large repositories, long sessions, concurrent workers, and repeatable evaluation suites.

Security-focused adoption deserves particular attention. Air-gapped organizations have a strong reason to accept slower performance if the workflow satisfies internal controls.

Developer feedback will also expose practical friction. Installation failures, checkpoint conversion issues, thermal limits, and tool-call errors can outweigh architectural benefits.

The third signal is competitive response. Other agent frameworks already connect to local model servers, but integration depth varies widely.

The important comparison is not whether a product lists Ollama as an option. It is whether local models can use the same tools, policies, workspaces, and orchestration features.

Competitors may answer with stronger local routing, enterprise-hosted inference, or automatic selection between remote and on-device models.

A rapid response would support Google’s underlying judgment that execution location is becoming a purchasing criterion. Limited response would suggest demand remains concentrated among enthusiasts.

Google’s hybrid pattern also deserves scrutiny. It can offer a practical balance, but only if developers can verify what information reaches the cloud planner.

Clear logs, policy controls, and traceable routing will matter as much as model support. Enterprises need evidence that declared boundaries are enforced during every agent turn.

The release should also encourage more disciplined task design. Developers can reserve local agents for constrained work instead of expecting one system to manage an entire project autonomously.

Examples include classifying private documents, reviewing a bounded module, generating tests, or summarizing local technical notes. Each task has measurable inputs and outputs.

That approach fits a broader AI workflow in which sensitive context remains close to the user. Human review still governs consequential actions.

Antigravity SDK local models now make offline agent execution a documented Google workflow rather than an unofficial workaround. The launch does not settle the quality or accessibility questions.

It does change what developers can demand from an agent platform. Cloud access no longer needs to be the unavoidable price of automation.

The most useful next step is concrete testing. Choose one private, bounded task, record memory use and completion quality, then compare local and hosted runs.

Does the local agent protect the context that matters while completing enough work to justify the hardware? That answer will determine whether Google has created a default architecture or a valuable exception.