Los modelos locales de Google Antigravity SDK llevan los agentes sin conexión, pero el hardware marca el límite
Google ha añadido modelos locales a Antigravity SDK, lo que permite a los desarrolladores ejecutar flujos de trabajo agénticos sin una clave de API ni conexión a internet por primera vez.
La ruta optimizada inicial combina Gemma 4 26B A4B con el entorno de ejecución LiteRT de Google AI Edge. Google recomienda al menos 24 GB de VRAM o memoria unificada. Ese requisito sitúa la experiencia completa fuera del alcance de muchos portátiles convencionales, pese a la promesa de ejecución local.
Esta versión desplaza una frontera importante. Los desarrolladores ya no necesitan enviar cada prompt, archivo fuente o resultado de herramienta a través de un modelo alojado. Sin embargo, los agentes en la nube siguen ofreciendo un despliegue más sencillo, mayor capacidad de modelo y menos restricciones de hardware.
Por tanto, Google desafía el modelo de agentes exclusivamente en la nube sin abandonarlo. Su propia demostración utiliza un planificador Gemini en la nube junto con varios trabajadores Gemma locales. La historia más importante no es el reemplazo total de la nube, sino el control sobre dónde se ejecuta cada parte de un agente.
Los modelos locales de Antigravity SDK trasladan el bucle del agente al dispositivo
Google ha trasladado las llamadas al modelo del agente, el bucle de herramientas y el contexto de trabajo a hardware controlado por el desarrollador.
Google anunció la compatibilidad con modelos locales el 23 de septiembre de 2026. La empresa afirma que Antigravity SDK ahora admite flujos de trabajo locales con varios modelos y opciones de ejecución.
El SDK expone mediante Python las capacidades de agente detrás de Google Antigravity. Estas capacidades incluyen interacción con modelos, herramientas, políticas, espacios de trabajo, hooks y subagentes.
Anteriormente, los desarrolladores asociaban estos flujos de trabajo con la inferencia remota. La nueva configuración permite que un agente opere con un checkpoint de modelo almacenado y ejecutado en la misma máquina.
La publicación de Google sobre modelos locales destaca Gemma 4 26B A4B como el primer modelo optimizado. LiteRT gestiona la inferencia mediante el hardware de aceleración disponible en el dispositivo.
La ruta compatible utiliza LiteRTAgentConfig, que dirige al agente a un checkpoint .litertlm. El SDK inicia un servidor de loopback, es decir, un servicio disponible únicamente a través de la interfaz de red de la máquina local.
Ese servicio local se sitúa entre el agente de Antigravity y el entorno de ejecución del modelo. Permite que el marco de agentes más amplio se comunique con el checkpoint sin llamar a un endpoint público de modelos.
Según Google, el flujo de trabajo resultante puede ejecutarse sin una clave de API ni conexión a internet. Esta es una distinción significativa frente a productos que simplemente almacenan localmente archivos seleccionados.
Una ejecución totalmente sin conexión significa que las entradas del modelo, los tokens generados y las interacciones con herramientas pueden permanecer en el dispositivo. El resultado exacto en materia de privacidad sigue dependiendo de las herramientas e integraciones habilitadas por el desarrollador.
Un agente que llama a un servicio de búsqueda web no está completamente sin conexión. Tampoco lo está un agente conectado a bases de datos remotas, sistemas de analítica o servidores alojados de Model Context Protocol.
El SDK también admite servidores locales externos mediante LocalOpenAIAgentConfig. Esta ruta se conecta a software que expone una API compatible con OpenAI en la máquina o red privada del desarrollador.
Google menciona Ollama, LM Studio y vLLM como ejemplos. Esta compatibilidad es importante porque los usuarios de IA local ya organizan modelos y automatización en torno a esos servidores.
Las dos rutas cubren necesidades distintas. LiteRT ofrece una ruta gestionada por Google y optimizada para su entorno de ejecución, mientras que los servidores compatibles dan a los equipos más control sobre el alojamiento de modelos.
La guía de ejecución local de Google documenta ambas configuraciones. También confirma compatibilidad con Apple Silicon Metal, Nvidia CUDA y backends de aceleradores detectados automáticamente.
Esto es más que otro selector de modelos dentro de un editor. El SDK permite a los desarrolladores incorporar inferencia local en sus propios scripts, servicios, sistemas de evaluación y flujos de trabajo de agentes especializados.
Esa programabilidad crea la tensión central del artículo. Trasladar la inferencia al dispositivo mejora el control, pero también transfiere la responsabilidad de infraestructura de Google al usuario.
Los agentes sin conexión presionan a los flujos de trabajo exclusivamente en la nube
La versión presiona a las plataformas de agentes exclusivamente en la nube al convertir la localidad de los datos en una decisión arquitectónica en lugar de una limitación de producto.
La inferencia en la nube sigue siendo la opción predeterminada para la mayoría de los agentes de programación. Ofrece a los usuarios acceso inmediato a modelos grandes sin requerir una GPU de nivel estación de trabajo ni largas descargas de modelos.
Esa comodidad tiene un coste más allá de las tarifas de uso. El código fuente, los prompts, los documentos recuperados y las salidas de herramientas deben entrar en un entorno de procesamiento remoto.
Las políticas de los proveedores pueden limitar la retención y el uso para entrenamiento. Los acuerdos empresariales pueden añadir controles más estrictos. Aun así, algunas organizaciones no pueden enviar material sensible fuera de una máquina o red aprobada.
Los entornos de desarrollo aislados de internet presentan el caso más claro. Estos sistemas carecen intencionalmente de acceso directo a internet porque contienen información regulada, clasificada o comercialmente sensible.
Un agente exclusivamente en la nube no puede operar normalmente en ese entorno. Un agente Antigravity sin conexión sí puede hacerlo, siempre que su modelo y dependencias de software lleguen mediante un proceso de transferencia aprobado.
La misma ventaja se aplica a desarrolladores que trabajan con productos no lanzados, informes de seguridad, documentos legales y algoritmos propietarios. La ejecución local reduce el número de sistemas que reciben su contexto.
También cambia la disponibilidad del servicio. Un flujo de trabajo local no se detiene porque un proveedor de modelos tenga una interrupción, cambie una cuota o retire un endpoint.
Esa independencia puede importar durante tareas de larga duración. Un agente que audita un repositorio puede ejecutar muchos turnos de modelo mientras lee archivos, planifica cambios, ejecuta pruebas y revisa errores.
La latencia también se comporta de forma distinta. La inferencia local evita retrasos de redes de área amplia, pero la generación de tokens depende por completo del hardware disponible y de la optimización del entorno de ejecución.
Una estación de trabajo bien equipada puede ofrecer tiempos de respuesta predecibles. Una máquina cercana a la recomendación mínima de memoria puede brindar una experiencia mucho más lenta, especialmente con cargas de trabajo simultáneas.
Las plataformas en la nube conservan ventajas claras. Pueden proporcionar modelos más grandes, capacidad elástica, supervisión centralizada y actualizaciones gestionadas sin consumir memoria local.
También permiten a los equipos estandarizar el rendimiento entre empleados que utilizan diferentes ordenadores. Un enfoque local primero convierte las especificaciones del dispositivo en parte del plan de despliegue.
Por tanto, esta versión no establece una competencia simple entre la IA local y la de nube. Presiona a las plataformas que no ofrecen una elección significativa entre esos entornos de ejecución.
La ventaja estratégica corresponde a los marcos que pueden enrutar el trabajo según la sensibilidad, la complejidad y la capacidad de cómputo disponible. El SDK de Google ahora admite ese patrón más amplio.
Para las empresas, la decisión se vuelve más granular. Un equipo puede reservar modelos alojados para la planificación exigente mientras mantiene el análisis repetitivo de archivos en hardware controlado.
Los desarrolladores individuales obtienen otra forma de autonomía. Pueden seguir utilizando un flujo de trabajo de agentes incluso cuando no quieren que cada tarea dependa de autenticación remota o límites de consumo.
La limitación es el acceso a hardware adecuado. Google recomienda al menos 24 GB de VRAM o memoria unificada para el checkpoint Gemma destacado.
Muchos ordenadores convencionales quedan por debajo de ese umbral. Algunas máquinas lo cumplen técnicamente, pero deben compartir esa memoria con el sistema operativo, el editor, el navegador y las herramientas de compilación.
Los proveedores exclusivamente en la nube pueden argumentar razonablemente que la inferencia gestionada sigue siendo la ruta más accesible. Los agentes locales mejoran la autonomía, pero no eliminan los costes computacionales.
Por tanto, la presión es más fuerte en equipos conscientes de la seguridad y técnicamente maduros. Estos compradores pueden valorar el control local lo suficiente como para aceptar el trabajo de configuración y los requisitos de hardware.
LiteRT y Gemma 4 explican cómo funciona el flujo de trabajo sin conexión
El mecanismo depende de un modelo Gemma disperso, un entorno de ejecución de inferencia local y un marco de agentes capaz de mantener cerca su bucle de control.
Gemma 4 26B A4B utiliza una arquitectura de mezcla de expertos. Este diseño enruta cada token a través de solo una parte del modelo en lugar de activar cada parámetro.
Google indica 25.200 millones de parámetros totales y 3.800 millones de parámetros activos para el modelo. La etiqueta A4B se refiere a aproximadamente cuatro mil millones de parámetros activos durante la inferencia.
Esa distinción es importante para la ejecución local. El modelo puede recurrir a un conjunto mayor de parámetros sin requerir computación densa en los 25.200 millones de parámetros para cada token.
No significa que el checkpoint ocupe solo cuatro mil millones de parámetros en almacenamiento o memoria. La colección completa de expertos debe permanecer disponible para el enrutamiento.
Google afirma que el checkpoint con formato LiteRT tiene una descarga de aproximadamente 16,8 GB. El nivel de memoria recomendado de 24 GB deja capacidad adicional para el estado de inferencia y otros procesos.
La tarjeta de modelo de Gemma 4 indica una ventana de contexto de hasta 256.000 tokens para el modelo 26B A4B. También admite entradas de texto e imagen.
Una ventana de contexto amplia anunciada no garantiza que todas las máquinas locales puedan utilizarla cómodamente. Los contextos más largos aumentan los requisitos de memoria y el tiempo de procesamiento durante cargas de trabajo reales.
Gemma 4 también incluye llamadas a funciones nativas. Las llamadas a funciones permiten que un modelo solicite una acción estructurada, como leer un archivo o invocar una herramienta definida por el desarrollador.
Esta capacidad es esencial para un agente. Un chatbot convencional solo produce respuestas, mientras que un agente alterna entre razonamiento, acciones, observaciones y decisiones revisadas.
Antigravity proporciona el sistema de control circundante. Gestiona el espacio de trabajo, las herramientas disponibles, las políticas de ejecución y la comunicación con el modelo local.
LiteRT proporciona la capa de inferencia. Google diseñó el entorno de ejecución para aprendizaje automático en el dispositivo a través de backends de hardware compatibles.
La guía de modelos LiteRT describe variantes de Gemma destinadas a dispositivos que van desde teléfonos hasta GPU de consumo y estaciones de trabajo. Los objetivos de hardware varían considerablemente dentro de la familia.
Para la integración con Antigravity, los desarrolladores instalan el SDK y el paquete litert-lm. Luego importan el modelo al formato de checkpoint de LiteRT.
El agente recibe la ruta del modelo a través de su configuración. Cuando el programa se inicia, el SDK crea el servicio de modelo local y transmite los tokens generados de vuelta a la aplicación.
Esa arquitectura mantiene la integración relativamente familiar. Los desarrolladores siguen creando una instancia de un agente y enviándole una tarea, en lugar de construir de forma independiente un servidor de inferencia y un bucle de herramientas.
La configuración alternativa compatible con OpenAI amplía las opciones de modelos. Un equipo puede dirigir Antigravity hacia un despliegue existente de Ollama, LM Studio o vLLM.
Una interfaz compatible con OpenAI estandariza formatos habituales de solicitudes y respuestas. No implica que el modelo subyacente proceda de OpenAI.
Esta distinción permite que Antigravity se sitúe por encima de varias pilas de inferencia. El marco de agentes puede mantenerse estable mientras cambia el servidor local o modelo seleccionado.
La compatibilidad también reduce la dependencia en la capa de entorno de ejecución. Los equipos que ya utilizan vLLM en un servidor interno no necesitan adoptar LiteRT para cada flujo de trabajo.
LiteRT sigue recibiendo atención especial porque Google optimizó la ruta inicial de Gemma 4 en torno a él. Ese emparejamiento otorga a Google control tanto sobre el formato del modelo como sobre el entorno de ejecución.
La arquitectura admite más que una operación completamente local. También permite una orquestación híbrida, en la que un modelo en la nube planifica el trabajo y agentes locales realizan tareas acotadas.
Esa opción híbrida es la explicación más clara del momento elegido por Google. Los modelos locales se han vuelto lo bastante capaces para realizar trabajo de programación útil sin sustituir a los planificadores alojados más potentes.
La demostración híbrida de Google revela la verdadera estrategia
El propio ejemplo de Google muestra que los agentes locales se están convirtiendo en una capa de fuerza de trabajo, mientras que los modelos en la nube conservan el papel de planificación.
La empresa demostró un patrón Arquitecto-Constructor que utiliza Gemini 3.8 Flash como arquitecto en la nube. Instancias locales de Gemma 4 26B actuaron como constructores.
La demostración asignó al sistema tres módulos Python vulnerables llamados auth.py, billing.py y database.py. Los trabajadores locales se encargaron de la auditoría y la aplicación de parches en el dispositivo.
El planificador en la nube coordinó el proceso más amplio. Esta división mantuvo gran parte del trabajo del repositorio en local, al tiempo que preservó el acceso a un modelo alojado de mayor tamaño para la orquestación.
Es un diseño más creíble que afirmar que un único checkpoint local puede igualar a todos los modelos en la nube. Las distintas etapas de una tarea de agente tienen diferentes necesidades de precisión, privacidad y capacidad de cómputo.
La planificación suele beneficiarse de un razonamiento más potente sobre un contexto amplio. La inspección, edición y verificación repetitivas pueden distribuirse entre trabajadores más pequeños.
El modelo se parece a la arquitectura informática convencional. Los sistemas centralizados programan trabajos, mientras que las máquinas especializadas ejecutan tareas cerca de los datos relevantes.
Para los equipos de software, un flujo de trabajo híbrido práctico podría comenzar con un modelo alojado que descomponga una migración. Después, los agentes locales podrían inspeccionar módulos individuales y proponer ediciones.
Una revisión final podría volver al planificador en la nube después de minimizar los detalles sensibles. Como alternativa, una persona podría revisar las salidas locales sin realizar otra llamada remota.
El beneficio de privacidad depende de ese límite. Si el planificador en la nube recibe archivos fuente completos, los constructores locales no impiden la exposición remota de datos.
Los desarrolladores deben decidir qué contexto cruza el límite, qué resúmenes se comparten y qué herramientas pueden acceder a servicios externos. El SDK no puede tomar esas decisiones de política automáticamente.
El sistema de políticas de Google ofrece a los desarrolladores un lugar para aplicar límites. Sin embargo, las configuraciones de ejemplo permisivas no deberían convertirse en valores predeterminados de producción sin revisión.
El ejemplo básico de la empresa utiliza un agente local para inspeccionar archivos en el directorio actual. Un ejemplo más avanzado permite que el agente cree una herramienta de monitorización y ejecute comandos.
Estas capacidades hacen útil al agente, pero también aumentan el riesgo. Un modelo equivocado o manipulado puede modificar archivos, invocar procesos o exponer información mediante herramientas conectadas.
La inferencia local no vuelve inofensivo a un agente. Cambia dónde se realiza el cómputo del modelo, no si las acciones generadas requieren supervisión.
La ejecución híbrida también introduce complejidad operativa. Los equipos deben supervisar tanto las llamadas remotas como los entornos de ejecución locales, al tiempo que comprenden los fallos a través de ese límite.
Un planificador en la nube puede producir una descomposición de tareas defectuosa. Los constructores locales pueden ejecutar después ese plan de manera consistente, propagando un único error a varios archivos.
La concurrencia crea otra limitación. Ejecutar varias instancias de Gemma 4 puede exigir más memoria de la que proporciona una única configuración recomendada.
Google no ha publicado benchmarks independientes y específicos de cargas de trabajo para la integración de Antigravity. Por tanto, el anuncio establece disponibilidad, no rendimiento universal.
La demostración sigue indicando una dirección clara de producto. Google está posicionando los modelos locales como trabajadores complementarios dentro de un sistema de agentes más amplio.
Esta estrategia presiona a otros frameworks de agentes para que admitan un enrutamiento similar. Los clientes preguntarán cada vez más si una tarea puede permanecer local antes de aceptar una respuesta exclusivamente en la nube.
También ofrece a Google una forma de abarcar ambos mercados. Los servicios Gemini siguen siendo relevantes para una orquestación exigente, mientras que Gemma y LiteRT cubren la ejecución privada o sensible a los costes.
La recomendación de 24 GB es la primera prueba de realidad
La operación sin conexión elimina la dependencia de un endpoint remoto, pero sustituye esa dependencia por restricciones de hardware, mantenimiento y calidad del modelo.
Google recomienda una máquina con al menos 24 GB de VRAM o memoria unificada para Gemma 4 26B A4B. La formulación describe una recomendación, no una garantía universal.
La VRAM es memoria gráfica dedicada utilizada por GPU discretas. La memoria unificada es un conjunto compartido utilizado por procesadores y hardware gráfico en sistemas como los Mac con Apple Silicon.
Estas configuraciones se comportan de forma diferente bajo presión. Una GPU discreta puede ofrecer un alto rendimiento de inferencia, mientras que la memoria unificada puede aportar flexibilidad entre tareas de CPU y gráficos.
La capacidad disponible importa más que el total anunciado. Una máquina de 24 GB que ejecuta contenedores, navegadores, compilaciones y varios agentes puede tener muy poco margen restante.
La descarga del checkpoint de 16.8 GB también crea una carga de despliegue. Las organizaciones deben distribuir, verificar, actualizar y almacenar ese artefacto en las máquinas aprobadas.
La procedencia del modelo se convierte en una preocupación operativa. Los equipos deben confirmar de dónde procede un checkpoint, cómo se convirtió y si su licencia permite el uso previsto.
Según la documentación de Google, Gemma 4 cuenta con una licencia Apache 2.0. Los fine-tunes externos y los checkpoints convertidos pueden introducir condiciones o cuestiones de seguridad independientes.
La calidad del modelo plantea una incertidumbre mayor. Google publica resultados de benchmarks para Gemma 4, incluidas evaluaciones orientadas a programación y agentes.
Esos benchmarks describen el modelo subyacente bajo condiciones de prueba definidas. No establecen con qué fiabilidad Antigravity completa tareas largas y guiadas por herramientas en el repositorio de un desarrollador.
La fiabilidad de los agentes acumula errores a lo largo de los pasos. Un pequeño malentendido puede afectar a la selección de archivos, la ejecución de comandos, la interpretación de pruebas y el parche final.
Los modelos locales también pueden carecer de las últimas mejoras alojadas. Los proveedores de nube pueden actualizar centralmente los sistemas de inferencia, mientras que los despliegues locales requieren actualizaciones deliberadas y pruebas de regresión.
Los equipos pueden preferir esa estabilidad. Un checkpoint fijo produce un entorno más controlado y evita cambios inesperados de comportamiento tras una actualización remota del modelo.
Sin embargo, fijo no significa determinista. Los ajustes de muestreo, los resultados de las herramientas, el estado del espacio de trabajo y la concurrencia aún pueden cambiar los resultados.
Los equipos de seguridad también deben examinar el servidor local. Una dirección de loopback limita la exposición, pero una configuración deficiente aún puede abrir puertos u otorgar acceso excesivamente amplio al sistema de archivos.
Los servidores compatibles con OpenAI requieren un escrutinio similar. La documentación de servicio de vLLM muestra cómo los endpoints locales o privados imitan las API de modelos comunes.
La compatibilidad mejora la portabilidad, pero puede ocultar diferencias significativas. Los modelos varían en el formato de llamadas a herramientas, el manejo del contexto, el comportamiento de seguridad y el soporte de salidas estructuradas.
Por ello, los desarrolladores deben probar todo el ciclo del agente, no solo las respuestas a prompts. Un modelo que escribe buen código aún puede tener dificultades para seleccionar herramientas de forma fiable.
La recomendación de hardware de Google limita el público inmediato. Las estaciones de trabajo con GPU Nvidia de alta memoria y los sistemas Apple Silicon mejor equipados son los puntos de partida naturales.
Los modelos Gemma más pequeños pueden ampliar el acceso, pero el anuncio de Google centra su flujo de trabajo optimizado en el checkpoint 26B A4B. Esa es la versión que respalda la afirmación de lanzamiento más sólida.
La brecha entre «se ejecuta localmente» y «se ejecuta bien en mi máquina» sigue sin resolverse. El rendimiento variará según el hardware, el tamaño del contexto, el uso de herramientas y la complejidad de la tarea.
Tampoco existe aún evidencia de que los agentes Antigravity sin conexión igualen a los principales sistemas alojados en tareas completas de ingeniería de software. Google no ha hecho esa afirmación más amplia.
La interpretación responsable es más limitada. Antigravity ahora puede ejecutar flujos de trabajo de agentes relevantes de forma local, con una configuración documentada y una recomendación sustancial de memoria.
Esta capacidad es importante incluso antes de alcanzar la paridad de rendimiento. Ofrece a los equipos una opción desplegable donde antes la inferencia remota estaba prohibida o resultaba indeseable.
Tres señales mostrarán si los agentes locales se convierten en una opción predeterminada
La próxima prueba es si la ejecución local se vuelve habitual más allá de los experimentos sensibles a la privacidad y las estaciones de trabajo de desarrolladores con mucha memoria.
La primera señal es un soporte más amplio de modelos y hardware. Los desarrolladores necesitan opciones prácticas para máquinas por debajo de la recomendación de 24 GB.
Las variantes más pequeñas de Gemma podrían hacer que los agentes sin conexión sean accesibles para más portátiles. Checkpoints optimizados adicionales también podrían permitir a los equipos intercambiar capacidad por velocidad y uso de memoria.
El soporte por sí solo no bastará. Google debe publicar datos claros de rendimiento en Apple Silicon, GPU Nvidia y otros aceleradores compatibles.
Las mediciones útiles incluyen velocidad de generación, tiempo hasta el primer token, uso máximo de memoria y finalización de tareas de extremo a extremo. Los benchmarks de agentes deberían cubrir herramientas y recuperación en varios pasos.
Si esos resultados muestran un rendimiento aceptable en hardware común, la ruta local se convertirá en algo más que una función para especialistas. Resultados débiles reforzarían la inferencia en la nube como opción predeterminada.
La segunda señal es la evidencia procedente de despliegues en producción. Las primeras demostraciones prueban que el software funciona, pero no revelan la fiabilidad cotidiana.
Los equipos tendrán que informar de cómo los agentes locales gestionan repositorios grandes, sesiones largas, trabajadores concurrentes y suites de evaluación repetibles.
La adopción centrada en la seguridad merece especial atención. Las organizaciones aisladas de la red tienen un fuerte motivo para aceptar un rendimiento más lento si el flujo de trabajo satisface los controles internos.
Los comentarios de los desarrolladores también revelarán fricciones prácticas. Los fallos de instalación, problemas de conversión de checkpoints, límites térmicos y errores en llamadas a herramientas pueden superar los beneficios arquitectónicos.
La tercera señal es la respuesta competitiva. Otros frameworks de agentes ya se conectan a servidores de modelos locales, pero la profundidad de integración varía considerablemente.
La comparación importante no es si un producto incluye Ollama como opción. Es si los modelos locales pueden usar las mismas herramientas, políticas, espacios de trabajo y funciones de orquestación.
Los competidores pueden responder con un enrutamiento local más potente, inferencia alojada para empresas o selección automática entre modelos remotos y en el dispositivo.
Una respuesta rápida respaldaría el juicio subyacente de Google de que la ubicación de ejecución se está convirtiendo en un criterio de compra. Una respuesta limitada sugeriría que la demanda sigue concentrada entre entusiastas.
El patrón híbrido de Google también merece escrutinio. Puede ofrecer un equilibrio práctico, pero solo si los desarrolladores pueden verificar qué información llega al planificador en la nube.
Los registros claros, los controles de políticas y el enrutamiento trazable importarán tanto como el soporte de modelos. Las empresas necesitan evidencia de que los límites declarados se aplican durante cada turno del agente.
El lanzamiento también debería fomentar un diseño de tareas más disciplinado. Los desarrolladores pueden reservar los agentes locales para trabajo acotado en lugar de esperar que un sistema gestione de forma autónoma un proyecto completo.
Los ejemplos incluyen clasificar documentos privados, revisar un módulo acotado, generar pruebas o resumir notas técnicas locales. Cada tarea tiene entradas y salidas medibles.
Este enfoque encaja en un flujo de trabajo de IA más amplio, en el que el contexto sensible permanece cerca del usuario. La revisión humana sigue rigiendo las acciones importantes.
Los modelos locales del SDK Antigravity hacen ahora de la ejecución de agentes sin conexión un flujo de trabajo documentado de Google, en lugar de una solución alternativa no oficial. El lanzamiento no resuelve las cuestiones de calidad ni accesibilidad.
Pero sí cambia lo que los desarrolladores pueden exigir a una plataforma de agentes. El acceso a la nube ya no tiene por qué ser el precio inevitable de la automatización.
El siguiente paso más útil es hacer pruebas concretas. Elige una tarea privada y acotada, registra el uso de memoria y la calidad de finalización, y compara las ejecuciones locales con las alojadas.
¿El agente local protege el contexto que importa y, al mismo tiempo, completa suficiente trabajo como para justificar el hardware? La respuesta determinará si Google ha creado una arquitectura predeterminada o una excepción valiosa.
