Si Gemini 3.8 Flash va lento en Antigravity, lo primero es mirar qué sigue avanzando. Una respuesta que aún no ha empezado, un comando esperando permiso y una aplicación que tarda en cambiar de conversación pueden parecer el mismo problema, pero no se resuelven igual. Si el agente repite acciones sin producir un resultado nuevo, detén la ejecución y revisa los cambios antes de volver a intentarlo. Si aparece un error de capacidad del servidor, reenviar una y otra vez el proyecto completo no es una buena prueba.
Ha habido quejas documentadas, una respuesta de resolución y nuevos testimonios posteriores. Eso permite explicar síntomas y proponer comprobaciones; no demuestra que el servicio esté caído ahora para todos ni que todos los problemas hayan desaparecido. Esta guía recoge fuentes consultadas el 21 de septiembre de 2026, sin mediciones propias de velocidad.
Identifica dónde se pierde el tiempo
Antes de tocar ajustes, observa la última acción visible. ¿Todavía no hay respuesta? ¿Se están abriendo archivos? ¿Hay un comando pendiente? ¿El panel entero responde con retraso? Usa esa diferencia para elegir la primera comprobación.
| Lo que ves en Antigravity | Qué conviene distinguir | Primera acción útil |
|---|---|---|
| Una petición breve permanece sin respuesta | Espera hasta la primera respuesta frente a trabajo complejo | Prueba una sola petición corta, sin herramientas, en una conversación nueva. |
| El agente lee archivos o ejecuta pasos diferentes | Trabajo que progresa frente a una herramienta bloqueada | Mira el último paso y comprueba si espera un permiso, una entrada o un proceso. |
| Vuelve a ejecutar el mismo comando sin aportar nada | Bucle frente a un reintento con una causa y un resultado nuevos | Detén la tarea y revisa lo que ya ha modificado. |
Aparece 503, UNAVAILABLE o MODEL_CAPACITY_EXHAUSTED | Capacidad del servidor frente a cuota personal | Guarda el error y evita encadenar reenvíos del mismo trabajo. |
| Cambiar de conversación o manejar los paneles resulta lento | Rendimiento de la aplicación frente a espera del modelo | Comprueba qué cliente y versión utilizas y si hay una actualización aplicable. |
Estas comprobaciones son una forma de acotar el problema, no soluciones verificadas para todas las cuentas. No hay en las fuentes citadas un tiempo máximo oficial a partir del cual una respuesta deba considerarse bloqueada. Decide cuánto puedes esperar según la tarea, y fíjate sobre todo en si aparece información nueva.
Si ni siquiera responde a una petición corta
Una tarea de programación larga mezcla demasiadas cosas: historial, archivos, razonamiento, permisos y comandos. Para saber si la espera empieza antes de todo eso, abre una conversación nueva y envía una petición mínima, por ejemplo: «Responde solo con la palabra listo. No uses herramientas». Confirma que no se ha iniciado ninguna herramienta; la instrucción por sí sola no lo demuestra.
Anota el modelo seleccionado, el nivel de razonamiento, la hora y si aparece algún error. Mantén la misma cuenta y conexión durante esta comparación. Si la petición corta también tarda mucho en arrancar, el tamaño del trabajo original pierde fuerza como explicación. Si responde con normalidad, vuelve a la conversación anterior y localiza el primer paso que dejó de avanzar. Una sola comparación orienta; no mide por sí misma el estado general del servicio.
Puedes probar la misma petición breve con otro modelo que aparezca disponible en tu selector, incluido Gemini 3.7 si tu cuenta lo ofrece. En el hilo sobre lentitud del 15 de septiembre, algunos usuarios describieron una mejora al cambiar a 3.7 y otros dijeron que también les iba lento. Por eso cambiar de modelo sirve como prueba o alternativa temporal, sin garantizar una reparación.
Si otro modelo funciona de forma aceptable, continúa con una tarea pequeña y bien delimitada antes de encargarle todo lo pendiente. Si ambos se quedan esperando, conserva el resultado de la comparación y deja de alternarlos continuamente: eso añade intentos, pero apenas aclara qué está fallando.
Cuándo tiene sentido bajar el razonamiento
Reducir el nivel de razonamiento puede ser útil para una tarea sencilla que esté empleando más trabajo del necesario. Google explica que Gemini 3.8 Flash puede dar más pasos de razonamiento y hacer llamadas iterativas a herramientas en tareas complejas, con mayor consumo de tokens, especialmente con un esfuerzo alto. También presenta el esfuerzo reducido y Gemini 3.7 como opciones de eficiencia. Véanse el anuncio del modelo y su incorporación a Antigravity.
Eso explica por qué una tarea que sí avanza puede tardar más. No permite atribuir a «demasiado razonamiento» cualquier espera sin respuesta ni un error 503. Si reduces el esfuerzo, cambia solo ese ajuste y comprueba también que la respuesta siga siendo suficiente para el trabajo. Una respuesta más rápida pero incompleta no resuelve la tarea.
Si ya ha empezado, revisa las herramientas y los bucles
Cuando el agente está leyendo archivos, ejecutando pruebas o esperando un comando, el tiempo total incluye esas operaciones. Mira la última herramienta que aparece y su resultado. Un permiso sin conceder, un terminal esperando una respuesta o un proceso que sigue abierto requieren atención en ese punto; abrir otra conversación no elimina necesariamente la causa.
Si una herramienta tarda, comprueba primero qué intenta hacer y si el proceso puede terminar por sí mismo. En una tarea remota, revisa también si el equipo donde se ejecuta sigue accesible. No supongas que un silencio del terminal significa que el modelo está pensando.
Un bucle se reconoce mejor por la ausencia de avance que por el número de llamadas. Repetir una prueba después de corregir un archivo puede ser razonable. Ejecutar la misma orden, obtener el mismo resultado y volver a ejecutarla sin cambiar nada merece detenerse. Un testimonio del 18 de septiembre describe bucles de comandos y lentitud incluso en conversaciones nuevas y con distintos niveles de razonamiento. Es el relato de un usuario, no una demostración de que todos los casos tengan esa causa.
Para retomar una tarea que se ha repetido sin avanzar:
- Cancela la ejecución del agente y verifica si queda algún comando activo.
- Revisa los archivos modificados y los resultados que sí se han producido. No des por hecho que cancelar revierte el trabajo.
- Guarda el estado que quieras conservar antes de reiniciar la aplicación o iniciar otro intento.
- Formula un siguiente paso pequeño: inspeccionar un error concreto, explicar el resultado de una prueba o proponer una corrección antes de ejecutarla.
Evita pedir otra vez «hazlo todo» sin revisar lo anterior. Puedes acabar repitiendo operaciones y dificultando la identificación del punto donde se atasca. Borrar el proyecto o limpiar indiscriminadamente sus archivos tampoco es un paso necesario para esta comprobación.
Qué significa el error 503 de capacidad
En el hilo del 15 de septiembre se publicó un error con 503 UNAVAILABLE, el motivo MODEL_CAPACITY_EXHAUSTED y un mensaje que indicaba que no había capacidad disponible en el servidor. Ese mensaje apunta a capacidad del servicio; no prueba que hayas agotado tu cuota personal. El mismo registro incluía gemini-3.8-flash-medium, pero una cadena que aparece dentro de un diagnóstico no debe tratarse como un identificador público documentado para la API de Gemini. Fuente del registro publicado.
Con ese error, guarda la hora y el texto completo, comprueba lo que muestra tu cuenta sobre uso o cuota y evita reenviar repetidamente una tarea larga. Si tienes otra opción disponible en el selector, puedes probarla con una petición mínima. Si no hay una alternativa que responda, lo razonable es interrumpir los intentos y retomarlos más adelante, conservando el estado del proyecto.
Antigravity 2.0 documentó en sus ajustes de modelos una distinción entre cuota usada y restante; los nombres y la ubicación pueden variar según el cliente. Consulta lo que muestra tu propia aplicación y conserva una captura si vas a comunicar una discrepancia. El registro de cambios oficial documenta esa distinción, pero no establece que una suscripción concreta garantice capacidad inmediata.
Tampoco hay aquí una comprobación de cargos por peticiones fallidas, un reembolso confirmado ni una cuota restablecida para todas las cuentas. El testimonio del 18 de septiembre mezcla síntomas de Antigravity con una reclamación sobre llamadas externas a la API. Son datos que hay que contrastar por separado con el historial de uso correspondiente; no permiten deducir la política de cobro de Antigravity.
Cuando la lentitud está en la propia aplicación
Si puedes ver respuestas o resultados pero cambiar de conversación tarda, el problema puede estar en la interfaz o en el estado local de la aplicación. La versión 2.15.0 de Antigravity 2.0, publicada el 18 de septiembre, incluyó mejoras de rendimiento al cambiar de conversación desde la barra lateral y una corrección para entradas de permisos duplicadas que engordaban los archivos de conversación y ralentizaban la aplicación. Google indica que las versiones se distribuyen gradualmente durante varios días. Notas oficiales de la versión.
Comprueba primero el nombre del cliente y su versión instalada. Si se trata de Antigravity 2.0 y hay una actualización aplicable, guarda el trabajo, detén las tareas activas y actualiza mediante el mecanismo de la aplicación. Después verifica por separado si mejora el manejo de las conversaciones y si cambia la espera hasta la primera respuesta.
La referencia a 2.15.0 no es una instrucción universal para cualquier IDE o CLI que lleve el nombre Antigravity. Tampoco convierte una corrección de la interfaz en una solución para la falta de capacidad del servidor. Ambos problemas pueden coincidir en la misma sesión.
«Ya está resuelto» y nuevos casos: cómo leer las fechas
En el hilo del 15 de septiembre, una respuesta de soporte en el foro indicó que el equipo de ingeniería conocía la degradación y la estaba investigando. Otra respuesta del mismo día la dio por resuelta. Después hubo usuarios que siguieron describiendo lentitud entre el 16 y el 18 de septiembre.
La fecha de un aviso importa tanto como su contenido. Una resolución de aquel episodio no garantiza que tu sesión actual funcione bien, y una queja posterior tampoco demuestra una caída general el día que la lees. Para decidir si puedes continuar, combina esos antecedentes con lo que acabas de comprobar en tu cuenta: petición corta, modelo alternativo, estado de las herramientas y respuesta de la interfaz.
Si necesitas comunicar el problema, prepara un informe que permita reproducirlo sin entregar todo tu proyecto:
- Cliente, sistema operativo y versión instalada.
- Modelo y nivel de razonamiento seleccionados.
- Fecha, hora y zona horaria de la incidencia.
- Una petición mínima y si llega a iniciarse la respuesta.
- Última herramienta ejecutada, si la hubo, y qué esperaba o repetía.
- Texto del error y resultado de la comparación con otro modelo, ocultando credenciales y contenido privado.
La decisión práctica es sencilla: continúa si hay avance verificable, acota la tarea si una herramienta la retiene, detén los bucles y guarda los errores de capacidad para comunicarlos. Así puedes volver al trabajo con una acción concreta, sin confundir cada minuto de espera con el mismo fallo.
