Qué anunció Google y cuál es la fecha que debe vigilarse
La documentación de Gemini API registra el lanzamiento de `antigravity-preview-09-2026` el 17 de septiembre de 2026 y lo presenta como sustituto de `antigravity-preview-05-2026`, que queda marcado para retirada. El cambio importa especialmente a equipos que construyen agentes con ejecución de herramientas, no solo a quienes solicitan una respuesta de texto al modelo.
La tabla de retiradas de Google sitúa el 5 de octubre de 2026 como la fecha más temprana de apagado de `antigravity-preview-05-2026` y recomienda migrar a `antigravity-preview-09-2026`. La formulación es relevante: la tabla no equivale necesariamente a una confirmación de la hora concreta en que dejará de estar disponible cada cuenta o entorno. Google indica que comunicará la fecha exacta con antelación.
Por tanto, la lectura operativa no debería ser que existe tiempo garantizado hasta el final de ese día, sino que conviene completar las pruebas antes de esa referencia. También conviene comprobar el estado vigente de la documentación de retiradas justo antes del despliegue, por si hubiera una actualización, un aplazamiento o precisiones de disponibilidad que no consten en la información revisada.
La sustitución no demuestra por sí misma una mejora de calidad, seguridad, coste, latencia o autonomía. Las fuentes describen un cambio de versión y cambios de interfaz de herramientas; no aportan una comparación experimental entre ambas versiones en esos aspectos. Esa distinción evita convertir una migración de compatibilidad en una afirmación de rendimiento no verificada.
Dos rutas de migración según cómo se consuma la respuesta
Google diferencia explícitamente un caso de transición sencilla: un flujo ejecutado en sandbox remoto que solo consume `output_text` o `model_output`. En ese supuesto, la documentación indica que puede bastar con cambiar la cadena que identifica al agente. Es una condición acotada: presupone que la aplicación no interpreta ni ejecuta por su cuenta las llamadas a herramientas que aparezcan durante la interacción.
El segundo caso reúne a las integraciones con mayor riesgo de incompatibilidad: agentes que trabajan en un entorno local, aplicaciones que reciben o procesan `function_call`, sistemas que reconstruyen una traza de acciones, o plataformas que validan argumentos antes de autorizar una operación. En ellas, el identificador de versión es solo una parte de la migración. El consumidor debe aceptar el contrato de herramientas de la versión nueva.
También hay situaciones intermedias. Un servicio puede usar entorno remoto y, aun así, almacenar eventos para auditoría, generar métricas por nombre de herramienta, aplicar políticas de permisos o hacer pruebas con respuestas simuladas. Si cualquiera de esos componentes depende de nombres o argumentos anteriores, debe tratarse como una integración sensible a la traza, aunque el producto final muestre principalmente texto.
Antes de clasificar el caso como simple, el equipo debería localizar dónde se leen `output_text`, `model_output`, llamadas de función y resultados de herramientas. Esta revisión debe incluir adaptadores de SDK, colas de eventos, registros, evaluadores automáticos y paneles internos. La ausencia de errores en la interfaz conversacional no prueba que no haya dependencias en servicios auxiliares.
Decisión inicial de migración
| Patrón de integración | Cambio inicial | Riesgo principal | Validación mínima |
|---|---|---|---|
| Sandbox remoto; la aplicación solo usa salida textual | Actualizar el identificador del agente | Dependencias indirectas en trazas o telemetría | Ejecutar escenarios representativos y verificar la salida consumida |
| Entorno local o consumo de `function_call` | Actualizar versión y adaptar el intérprete de herramientas | Esquemas, nombres y argumentos incompatibles | Comparar trazas y ejecutar herramientas reales en un entorno aislado |
| Salida textual con auditoría, mocks o políticas basadas en eventos | Tratar como integración de traza | Fallos en observabilidad, validación o pruebas | Revisar productores y consumidores de eventos |
| Uso no inventariado o acceso mediante otra plataforma | No asumir equivalencia | Alcance y disponibilidad no confirmados | Confirmar el canal de acceso y documentar el contrato efectivo |
Qué cambios de contrato pueden romper una integración
La nota de lanzamiento describe cambios en las herramientas de sistema de archivos. Entre ellos figuran cambios de nombre y una convención PascalCase para argumentos documentados. Para un consumidor que compara literales, deserializa contra un esquema estricto o deriva permisos de los nombres de campos, esta modificación puede producir rechazos aunque la solicitud al agente siga siendo válida.
La edición de archivos es un punto de ruptura específico. La documentación de la versión nueva describe sustituciones mediante rangos de línea, mientras que la versión anterior utilizaba reescrituras completas. Un ejecutor local que espere recibir el contenido íntegro de reemplazo puede no saber aplicar una edición acotada. A la inversa, transformar una edición por rango en una reescritura total sin controles puede sobrescribir modificaciones concurrentes o alterar finales de línea.
La actualización también incorpora herramientas de búsqueda de archivos. Su presencia no obliga a que todas las aplicaciones las usen, pero sí puede afectar a listas permitidas de herramientas, mecanismos de autorización y mocks que solo contemplen las operaciones existentes en la versión anterior. Un sistema que deniegue por defecto una herramienta desconocida puede detener una tarea que antes completaba con otra secuencia de acciones.
Los nombres exactos y la capitalización no deben inferirse desde ejemplos antiguos ni normalizarse sin una prueba. La guía técnica actual muestra las herramientas de filesystem como llamadas de función. En una integración local, el contrato debe revisarse de extremo a extremo: evento recibido, validación, autorización, ejecución, serialización del resultado y reanudación de la interacción.
Incompatibilidades que conviene comprobar
| Área | Cambio documentado | Componente que puede romperse | Prueba recomendada |
|---|---|---|---|
| Creación, lectura y listado de archivos o directorios | Cambios de nombres y argumentos con convención PascalCase | Parser, esquema JSON, listas permitidas y métricas | Capturar llamadas reales y validarlas contra el adaptador actualizado |
| Edición de archivos | Sustituciones por rangos de línea en lugar de reescritura completa | Aplicador local, control de concurrencia y pruebas de diffs | Editar archivos cortos, largos y modificados concurrentemente |
| Búsqueda de archivos | Nuevas herramientas de búsqueda | Políticas de autorización, mocks y registros | Autorizar o denegar explícitamente y comprobar el resultado |
| Resultados de herramientas | La ejecución se representa como llamadas de función | Serializador, correlación de eventos y reanudación del agente | Completar una tarea de varias llamadas con trazas inspeccionables |
Pruebas para detectar fallos que una respuesta textual no revela
La prueba más útil no es preguntar al agente si puede realizar una tarea, sino ejecutar tareas representativas y revisar cada paso. Una suite mínima debería contener creación de archivos, lectura de contenido, listado de directorios, edición localizada y búsqueda. Si el producto permite modificaciones, añada casos de permisos insuficientes, rutas inválidas, archivos ausentes y conflictos de edición. Los resultados esperados deben abarcar tanto la salida al usuario como los eventos y el estado final del entorno.
Capture trazas de una muestra equivalente con ambas versiones cuando el entorno de prueba lo permita. No se trata de exigir que la secuencia sea idéntica: las nuevas herramientas pueden hacer que cambie. El objetivo es comprobar que el adaptador puede interpretar y ejecutar toda llamada autorizada, que los resultados vuelven al agente con el formato esperado y que la tarea llega a un estado correcto.
Los mocks merecen una revisión separada. Suelen codificar el contrato anterior de forma implícita: nombres de función, casos de campos, estructura de argumentos o contenido total de un archivo. Un mock que siga aceptando solo el contrato antiguo puede ocultar fallos; uno excesivamente laxo puede aprobar llamadas que el ejecutor real rechazará. Conviene derivar las simulaciones de trazas capturadas y mantener casos negativos.
La instrumentación debe registrar la versión solicitada, el tipo de entorno, las llamadas recibidas, la decisión de autorización y el resultado de ejecución, evitando almacenar contenido sensible innecesario. Esta información permite distinguir un problema de contrato de una denegación de permisos, un fallo del entorno o una respuesta inesperada del modelo.
Checklist de migración en 30 minutos
- 01Inventarie servicios, trabajos y entornos que aún solicitan `antigravity-preview-05-2026`.
- 02Clasifique cada integración: solo salida textual remota, o consumo directo o indirecto de llamadas a herramientas.
- 03Capture una traza representativa y localice validadores, listas permitidas, esquemas, mocks y permisos dependientes de herramientas.
- 04Actualice el identificador y adapte el intérprete a los nombres, argumentos y edición por rangos documentados para 09-2026.
- 05Ejecute tareas de creación, lectura, listado, edición y búsqueda en un entorno no productivo.
- 06Revise la salida final, las llamadas emitidas, los resultados devueltos y el estado persistente de archivos.
- 07Si es viable, compare ejecución paralela y establezca un criterio claro de reversión o de bloqueo del despliegue.
- 08Antes de liberar, revise la documentación de retiradas para confirmar el calendario vigente.
Coste, disponibilidad y límites de lo que puede concluirse
La documentación de precios de Gemini Developer API indica que Antigravity Agent factura la inferencia, incluidos los tokens intermedios de los bucles agénticos, conforme a las tarifas estándar de Gemini. También indica que, durante la vista previa, el cómputo del entorno no se factura. Esto no permite calcular el coste de una carga de trabajo concreta: dependerá de los modelos, el volumen de tokens, la duración y el comportamiento efectivo de las tareas.
Tampoco debe extrapolarse esta información a canales de acceso que las fuentes aportadas no describen como equivalentes. La información revisada se refiere a Gemini API y no demuestra que la disponibilidad, las cuotas, las condiciones de uso o el calendario sean idénticos en Vertex AI u otras vías. Los equipos con una capa de abstracción multicanal deben confirmar el proveedor real de cada despliegue antes de aplicar esta noticia como norma general.
La documentación analizada sí permite concluir que hay una ruta de cambio sencillo para un caso remoto muy concreto y que hay modificaciones de interfaz relevantes para los consumidores de herramientas. No permite concluir que todos los agentes remotos sean inmunes al cambio, que una migración local sea mecánica, ni que ambas versiones ofrezcan resultados funcionales equivalentes en cada tarea.
Como medida de servicio, la prioridad es tratar esta sustitución como una migración de contrato. Cambiar el nombre de la versión puede ser suficiente cuando solo se consume la salida textual en el escenario remoto descrito por Google. En cualquier integración que observe, valide o ejecute herramientas, la decisión debería basarse en trazas y pruebas de regresión, no en la aparente continuidad de la conversación.
Qué sigue abierto
- La fecha exacta y la hora efectiva de retirada pueden requerir confirmación posterior en el aviso oficial.
- Las fuentes aportadas no establecen disponibilidad ni condiciones equivalentes para Vertex AI u otros canales de acceso.
- No se aportan comparativas oficiales de calidad, latencia, seguridad, autonomía o coste total entre 05-2026 y 09-2026.
- La suficiencia de cambiar solo el identificador depende de que la integración cumpla realmente el supuesto de sandbox remoto y consumo exclusivo de texto.
Continúa explorando
Fuentes consultadas
Correcciones y transparencia
Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.
Proponer una corrección