Antigravity SDK con modelos locales: tu GPU, tus tokens, cero nube

Un domingo a las 00:14 mi pipeline de contenido se quedó sin cuota. No fue un bug. La API me devolvió un 429 a mitad del batch y el job murió dejando 18 posts a medio generar. Me quedé mirando el log con el café frío, pensando que acababa de hipotecar mi madrugada a un rate limit que no controlo.

Un mes después salió la función que me habría ahorrado esa noche. El SDK de Antigravity ya corre agentes con un modelo local. Sin nube, sin API key y sin rate limits.

"Today, we're announcing that the Antigravity SDK supports local workflows across a wide range of local models and execution options, featuring initial support for Gemma 4 26B A4B using Google AI Edge's LiteRT." - Source: Google Developers Blog

En este post vas a ver cómo se instala, cómo se escribe tu primer agente local y dónde están las trampas que el anuncio no pone en grande. Con cifras reales y un criterio claro para decidir cuándo te conviene local y cuándo nube. No vengo a convencerte de que tu laptop es un datacenter.

Imagen: Google Developers Blog (artículo original)

Qué anunció Google exactamente

El anuncio es del 23 de septiembre de 2026 y lo firman Sachin Kotwani y Taylor Mullen. Tres piezas encajan aquí:

• El SDK de Antigravity: la librería de Python (pip install google-antigravity) para construir agentes con las mismas capacidades agénticas que usa Google Antigravity.
• LiteRT-LM: la capa de orquestación de Google AI Edge para correr LLMs en el dispositivo, multiplataforma y con aceleración por GPU/NPU.
• Gemma 4 26B A4B: el modelo con el que Google probó todo esto, empaquetado en un archivo .litertlm.

El resultado es que puedes dar asistencia agéntica a tu código completamente offline.

"With this new support you can enable agentic assistance via local models completely offline." - Source: Google Developers Blog

Un detalle del README del SDK cambia las expectativas. El paquete de PyPI trae un binario compilado del runtime. Clonar el repo no te sirve para correrlo.

"The Google Antigravity SDK relies on a compiled runtime binary that is included in the platform-specific wheels published to PyPI. Cloning this repository alone is not sufficient to run the SDK." - Source: antigravity-sdk-python

Por qué correr el agente en tu máquina

Google lo resume en cuatro razones, y ninguna es marketing vacío:

• Costo: cero facturas por token y cero límites de tasa.
• Privacidad: tu código no sale de tu máquina, útil si trabajas bajo requisitos de cumplimiento estrictos.
• Resiliencia offline: el agente funciona sin internet estable.
• Flujos híbridos: lo barato y repetitivo en local; lo pesado en la nube cuando hace falta.

"Cost efficiency: Execute local agentic workflows without API costs or rate limits." - Source: Google Developers Blog

La privacidad es la que más me interesa en trabajo de cliente. Cuando auditas billing.py de un banco, subir el archivo a una API no es una opción legal, y firmar un DPA tampoco arregla que el código viajó. Un agente local resuelve eso de raíz: el archivo no se mueve.

Instalación y primer agente local

Google recomienda una máquina con más de 24 GB de VRAM o memoria unificada. Con eso en mente, la instalación son tres comandos.

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

pip install google-antigravity litert-lm

# Descarga el modelo (~26B) desde Hugging Face a ~/.litert-lm/models/gemma4-26b
litert-lm import \
  --from-huggingface-repo=litert-community/gemma-4-26B-A4B-it-litert-lm \
  gemma-4-26B-A4B-it-gpu.litertlm \
  gemma4-26b

Nota que el import apunta a un archivo gemma-4-26B-A4B-it-gpu.litertlm específico. No es cosmético. El README avisa que otros .litertlm "pueden no funcionar bien, o no funcionar en absoluto".

Ahora el agente mínimo. Es el mismo código que publica Google, sin adornos.

# agy_sample.py
import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig

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

async def main():
    print(f"Usando el modelo local: {MODEL_PATH}. La inferencia puede tardar varios minutos.")

    config = LiteRTAgentConfig(model_path=MODEL_PATH).lightweight()
    async with Agent(config) as agent:
        response = await agent.chat("¿Qué archivos hay en el directorio actual?")
        async for token in response:
            print(token, end="", flush=True)

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

Tres decisiones valen la pena. LiteRTAgentConfig(model_path=...) le dice al SDK que el backend es local, no Gemini. El .lightweight() deja la configuración en el modo más liviano, que es lo que quieres para una primera prueba en tu máquina. Y el async for token in response te da streaming de verdad: los tokens salen a medida que el modelo los genera, no en un bloque al final.

Guarda el archivo y ejecútalo:

python agy_sample.py

Si es tu primera corrida, prepara café. Cargar 26B de parámetros en memoria toma su tiempo.

El patrón híbrido arquitecto-constructores

Esta es la parte que me hizo dejar de ver los modelos locales como un juguete. Google publicó una demo con un patrón Architect-Builder:

• Un arquitecto en la nube (Gemini 3.8 Flash) planifica y descompone el trabajo.
• Un swarm local de Gemma 4 26B ejecuta la faena en la GPU del dispositivo.

La tarea: auditar y parchear tres módulos vulnerables (auth.py, billing.py, database.py). Los números del run grabado:

• 95 tokens en la nube. Gemini 3.8 Flash planificó usando solo los nombres de archivo y descripciones, sin ver una línea de código.
• 3.322 tokens (97,2%) ejecutados localmente, offline y sin llamar a ninguna API.
• Patch verde y verificado, con el código propietario sin salir de la máquina.

"97.2% of all tokens (3,322 tokens) run locally and offline without calling a cloud API, delivering fully verified, green patches while keeping proprietary code completely secure on-device." - Source: Google Developers Blog

Piénsalo como un equipo. El tech lead (nube) decide el plan con lo mínimo, y un piso entero de juniors incansables (local) hace los commits. El lead nunca vio el repositorio, solo el índice. Por eso gasta apenas 95 tokens: no necesita más para repartir el trabajo.

La segunda demo usa el mismo patrón con otra tarea. Un solo prompt y el agente local escribe un monitor de recursos en Python con psutil y rich, genera su requirements.txt y lo prueba antes de entregarlo. Todo on-device.

En ese ejemplo el agente no solo escribe código: redacta el archivo de dependencias y valida que corra. Ese ciclo de escritura-verificación es lo que separa un asistente de un ejecutor.

Ollama, LM Studio o vLLM sin cambiar tu orquestación

No tienes que quedarte con Gemma 4 ni con LiteRT. El SDK acepta cualquier servidor compatible con la API de OpenAI a través de LocalOpenAIAgentConfig.

"The Antigravity SDK also offers seamless, plug-and-play support for any OpenAI-compatible server such as Ollama, LM Studio, or vLLM via LocalOpenAIAgentConfig." - Source: Google Developers Blog

Lo que no cambia importa igual. Tus tools, tus hooks y tus políticas siguen intactos. Cambias el backend y ya. Si en casa tienes Ollama con un modelo que cabe en 8 GB, lo enchufas y tu agente (con sus MCP y sus triggers) sigue funcionando. Ese desacople entre orquestación e inferencia es lo que hace que el ecosistema local sea intercambiable.

Lo que el anuncio no te cuenta

La barrera de hardware es alta. Google recomienda al menos 24 GB de VRAM o memoria unificada y un contexto de 64K. Si tu GPU tiene 8 GB, olvídate del 26B; quédate con los modelos chicos de la tabla de LiteRT-LM.

"A4B" no es tamaño, es parámetros activos. Gemma 4 26B A4B es un modelo Mixture of Experts: 26B totales, ~4B activos por token. Por eso un 26B puede ser usable en hardware que un denso de 26B no aguantaría. Ya desarmé ese mecanismo en MoE por dentro: 30B totales, 3B activos, y aplica igual aquí.

La latencia en una corrida limpia está publicada. LiteRT-LM lista, para Gemma4-E2B en un MacBook Pro M4 Max, 7.835 tk/s de prefill y 160 tk/s de decode por GPU, con 0,1 s hasta el primer token. En una RTX 4090, 11.234 y 143 tk/s respectivamente. Ojo: esos números son de los modelos chicos (E2B/E4B), no del 26B.

"A MacBook Pro M4 Max: GPU prefill 7835 tk/s, GPU decode 160 tk/s, Time to First Token 0.1s." - Source: LiteRT-LM Overview

El agente arranca en modo solo-lectura. Por defecto no puede escribir ni ejecutar comandos. Para habilitar todo (incluidas escrituras en disco) hay que pasar capabilities=CapabilitiesConfig(). Es una decisión de seguridad sensata: un agente local tiene acceso a tu sistema de archivos, cosa que uno en la nube nunca tiene.

Las políticas son tu cinturón de seguridad. Puedes declarar qué tools permite el agente y cuáles requieren tu aprobación:

# policies.py
from google.antigravity.hooks.policy import deny, allow, ask_user

policies = [
    deny("*"),                 # Bloquea todo por defecto
    allow("view_file"),        # Permite leer archivos
    ask_user("run_command"),   # Pide confirmación antes de ejecutar
]

Ese deny("*") primero es el patrón que recomiendo: empiezas cerrado y abres solo lo que necesitas. Es el equivalente a un firewall para las manos de tu agente.

¿Local o nube? Criterio de decisión

No todo va local. Mi regla, después de pelear con las dos opciones:

La trampa es querer el 100% en un solo lado. El caso que publicó Google gasta 95 tokens de nube sobre 3.322 locales, y funciona porque el trabajo caro es la ejecución, no el plan. Aplicar ese reparto es exactamente lo que expliqué en Model routing y costos: deja de mandar todo al modelo caro.

Y si vas a dimensionar cuántas sesiones concurrentes aguantas en tus 24 GB, el cálculo que importa es el del KV cache, no el de la potencia bruta. Lo desglosé en 48 KB por token.

Tips de producción

Cinco cosas que aplicaría antes de poner un agente local en un flujo real:

1. Aísla el workspace con workspaces=[WORKING_DIR]. Un agente con allow_all() y acceso a / es una bomba de relojería. Dale una carpeta y nada más.
2. Deja las políticas en modo cerrado. deny("*") de base, y abre tool por tool según necesidad.
3. Fija el contexto en 64K y no lo muevas. El README lo recomienda. Con menos, el agente pierde el hilo en tareas largas.
4. Valida cada patch local con tests de regresión. El gauntlet del ejemplo no aprueba un parche porque "se ve bien", lo corre contra una suite. Copia eso.
5. Mide tus tokens. Si tu híbrido gasta 60% en la nube, algo hiciste mal en el reparto. El objetivo del patrón es empujar la ejecución hacia la GPU local.

Para cerrar

Lo que más me gusta de este anuncio es que por fin puedo elegir dónde vive cada token sin reescribir mi agente. El mismo Agent, las mismas tools, el mismo código. Cambias el backend y listo.

Si algo de esto te suena, empieza chico. Instala google-antigravity, corre el ejemplo de 8 líneas y mira cuánto tarda Gemma en leer tu directorio. Después decides si vale la pena bajar el 26B.

Fuente original: Introducing Support for Local AI Models in the Antigravity SDK (Google Developers Blog, 23 de septiembre de 2026).

¿Ya corriste un agente en local o sigues pagando cada token en la nube? Cuéntame en los comentarios qué modelo usaste y cuánta VRAM te comió.

---