---
title: "Hybrid Agent Runtime: Antigravity SDK's Local and Cloud Split"
description: "Antigravity SDK's hybrid architecture separates planning from execution: a cloud model plans, local models run most tokens on-device. See how routing, execution, and the data boundary fit together."
---

# Hybrid Agent Runtime: Antigravity SDK's Local and Cloud Split

**Type:** [Architecture](https://yomu.fyi/visual-explainers/category/architecture.md)

![A layered architecture diagram of the Antigravity SDK showing an agent loop on top, a routing layer beneath it, and two side-by-side execution columns, local models on the left and cloud models on the right, separated by a dashed data boundary line.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/c7e73359-067c-49da-831a-d53ddbc3578a/image-ef776abc-e0cc-4c93-af4c-6c94db739228.webp)

> Antigravity SDK's hybrid architecture separates planning from execution: a cloud model plans, local models run most tokens on-device. See how routing, execution, and the data boundary fit together.

## Explanation

Antigravity SDK connects one agent loop to two execution targets: a cloud model that plans, and local models such as Gemma 4 via Google AI Edge's LiteRT that do the bulk of the token work. A routing layer picks the target per request, and any OpenAI-compatible server such as Ollama, LM Studio, or vLLM can serve the local path without changing agent orchestration. The split matters at the data boundary: on-device execution keeps code and requests local and drops API costs and rate limits, while the cloud path buys capability local hardware cannot reach. Treating routing as an architecture decision, not a config flag, is what lets you size GPU memory, place privacy controls, and keep working offline.

## FAQ

### When does routing a request locally actually pay off instead of calling a cloud model?

Local execution removes API costs and rate limits and keeps code and requests on-device, but it wants hardware like 24GB VRAM or unified memory. In the SDK's own code-auditing example, 3,322 of 3,417 tokens ran locally while the cloud model only planned. Short, interactive, context-heavy work favors local; long-horizon reasoning may still need the cloud.

### Does moving execution to a local model mean rewriting agent orchestration?

No. The SDK's LocalOpenAIAgentConfig works with any OpenAI-compatible server such as Ollama, LM Studio, or vLLM, so the agent loop and its tool calls stay unchanged. Only the execution target behind the routing layer changes.

**Tags:** [AI Agents](https://yomu.fyi/topic/ai-agents.md), [AI Gateway](https://yomu.fyi/topic/ai-gateway.md), [Antigravity SDK](https://yomu.fyi/topic/antigravity.md), [Local AI](https://yomu.fyi/topic/local-ai.md), [Model Routing](https://yomu.fyi/topic/model-routing.md), [Privacy](https://yomu.fyi/topic/privacy.md)

## Related reading

### [Bringing Private Processing to Meta AI Glasses](https://yomu.fyi/post/bringing-private-processing-to-meta-ai-glasses.md)
- Company: [Meta](https://yomu.fyi/company/meta.md)
- Author: By Pritam Shah, Oskar Linde
- Published: Sep 24, 2026
- Type: Announcement

Meta AI glasses require cloud processing for advanced AI features like streaming transcription and long-term recall, but traditional cloud architectures expose data during use. Private Processing uses confidential virtual machines with Trusted Execution Environments (TEEs) on CPUs and GPUs to keep data encrypted even while being computed. Before sending context, glasses perform remote attestation, verifying the server’s TEE certificate against a public transparency ledger that records all deployed binary images. Non-targetable routing via blind-signed tokens and third-party OHTTP relays prevents tying requests to specific users, while encrypted storage ensures data is only accessible with user-provided keys. This infrastructure, already proven for WhatsApp and Meta AI, extends to glasses, with security audits by firms like NCC Group and a bug bounty program for independent research.


### [How Concurrence governs clinical AI at a trillion-token scale with Unity Gateway](https://yomu.fyi/post/how-concurrence-governs-clinical-ai-at-a-trillion-token-scale-with-uni.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Ali Khokhar, John Xing, Tony Shi, Kelly Albano
- Published: Sep 23, 2026
- Type: Explainer

Concurrence processes 100.8 billion input tokens and 11.2 million LLM calls every 30 days, at an annualized rate of 1.2 trillion tokens. To govern these workflows, the company consolidates on Databricks with Lakebase for operational state, Unity Catalog for governance, and Unity Gateway for centralized AI access. Patient data is recorded as immutable events in Delta tables, from which a current patient state—called the world model—is computed while preserving provenance. All agents are tested against simulated patients before deployment; simulation traffic is approximately seven times production traffic, using immutable event history to replay states. Concurrence routes all coding-agent traffic through Unity Gateway, attributing each request to the engineer, and enforces compliance-gated model routing where HIPAA requirements are met first.


### [How I massively improved my AI inference performance without buying new hardware](https://yomu.fyi/post/how-i-massively-improved-my-ai-inference-performance-without-buying-ne.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Boaz Ben Shabat
- Published: Sep 23, 2026
- Type: Problem & solution

Default inference configurations for large language models often leave significant performance unused, even on expensive hardware like 16 NVIDIA H200 GPUs across two nodes. The author tested this setup with vLLM and Red Hat AI Inference 3.4 on a CoreWeave Kubernetes cluster, using enterprise RAG workloads with 2,000-token inputs and 100 concurrent users. By systematically comparing aggregated and prefill-decode (PD) disaggregated architectures, and tuning tensor parallelism (TP) and PD split, latency was dramatically reduced. For Qwen3-32B, time-to-first-token (TTFT) on the best aggregated configuration (2xTP8) dropped from 995ms to 304ms, and with optimized routing to 287ms — a 71% improvement without hardware changes. For Llama-70B, TTFT fell from 1,292ms to 463ms, a 64% gain. The author also built ServeIt Studio, an open-source tool that automates the full optimization pipeline on Kubernetes.


### [Introducing Support for Local AI Models in the Antigravity SDK](https://yomu.fyi/post/introducing-support-for-local-ai-models-in-the-antigravity-sdk.md)
- Company: [Google](https://yomu.fyi/company/google.md)
- Author: Sachin Kotwani, Taylor Mullen
- Published: Sep 23, 2026
- Type: Announcement

The Antigravity SDK now supports local AI models, starting with Gemma 4 26B A4B via Google AI Edge’s LiteRT, enabling offline agentic assistance on local GPU and RAM with a recommended machine of 24GB VRAM or unified memory. Local execution eliminates API costs and rate limits while keeping code and requests on-device, offering privacy and offline resiliency. The SDK supports hybrid workflows where a cloud model like Gemini 3.8 Flash plans while local Gemma 4 instances execute, as in a code auditing task where 97.2% of tokens (3,322 of 3,417) ran locally. A built-in example generates a live-updating CLI resource monitor using psutil and rich from a single prompt, with the agent autonomously writing the script, creating requirements.txt, and testing the code entirely offline. The SDK also supports any OpenAI-compatible server like Ollama, LM Studio, or vLLM via LocalOpenAIAgentConfig without changing agent orchestration.


### [JetBrains Air: Building a System of Products for Agentic Software Development](https://yomu.fyi/post/jetbrains-air-building-a-system-of-products-for-agentic-software-devel.md)
- Company: [Jetbrains](https://yomu.fyi/company/jetbrains.md)
- Author: Kirill Skrygan
- Published: Sep 22, 2026
- Type: Announcement

JetBrains Air is a system of products for agentic software development, built on the premise that no single model, agent, or service fits every developer, team, or task. It connects products for individual work, team coordination, organizational control, context, and process automation, while remaining open to tools and agents developers choose, including those JetBrains does not build. This openness lets developers select the agent, model, or service suited to a task without forcing the organization to give up context, visibility, or control. The Post notes that every new model, agent, or service an organization adds reduces visibility into its own development work. Because intelligence does not belong to one model, the benefit can extend across supported agents and services.
