La revisión 1.6 es la más reciente. Si hoy comienza un proyecto de razonamiento encarnado contra la API de Gemini de Google, esta es la que evaluar; 1.5 se mantiene principalmente porque algunas bases de código de investigación la anclan. El mismo dominio —robótica, planificación anclada en escenas, traducción de intención a plan— diferente revisión, diferente perfil práctico.
El cambio principal en 1.6 frente a 1.5 es la ventana de contexto. Google pasó de una ventana de 1 048 576 tokens a 131 072. Eso parece una regresión y en las especificaciones brutas lo es, pero en la práctica el caso de uso de ER rara vez ejercita el contexto de un millón de tokens, y la ventana más pequeña viene con un recuerdo notablemente mejor y un tiempo de respuesta más rápido. Intercambio obtenido.
Qué es diferente en 1.6
Contexto más ajustado, atención más aguda. La ventana de 128K es suficiente para un buffer de percepción de varios segundos, varios turnos de memoria de escena y una especificación de objetivo exhaustiva. La calidad de recuerdo y anclaje a lo largo del span es más sólida que en 1.5, que es el reequilibrio que Google buscaba.
Mejor seguimiento de instrucciones en planes de múltiples pasos. El modelo 1.5 frecuentemente producía primeros pasos razonables y luego derivaba en pasos posteriores cuando se encadenaban: 1.6 es más consistente en horizontes de plan más largos.
Salida estructurada más limpia. El cumplimiento de esquemas JSON en las salidas del plan es más fiable. Los equipos que construyeron adaptadores validados por esquema alrededor de 1.5 reportaron tasas de reintento más bajas después de pasar a 1.6.
Patrones de prompt diferentes. Los patrones de prompts recomendados de Google en torno a la descripción de escenas, la declaración del espacio de acción y la especificación de restricciones cambiaron entre revisiones. La documentación que funcionaba para 1.5 necesita revisión al portar a 1.6.
Qué no ha cambiado
El modelo sigue siendo de tier de vista previa. Las formas de salida pueden cambiar entre revisiones; la postura de producción debe asumir deriva.
Sigue sin ser un bucle de control. ER vive por encima de la planificación de movimiento, no dentro de ella. El suelo de latencia de clase 100ms hace eso inevitable.
Sigue especializado en razonamiento encarnado. Las tareas de propósito general producirán una salida peor que la que gemini-pro-latest daría para el mismo prompt.
El coste de integración sigue siendo alto. El formateador de percepción a prompt, el adaptador de plan a controlador y el verificador de seguridad siguen siendo trabajo de construcción propio.
Para qué sirve
Las mismas tres categorías que justificaban 1.5 aplican.
Investigación. Laboratorios de IA encarnada haciendo benchmarking frente a modelos frontier, evaluaciones de seguimiento de instrucciones en simulación (Habitat, RoboCasa, BEHAVIOR), trabajo de manipulación a largo horizonte.
Despliegues piloto industriales donde la capa de percepción es madura y la variación está dirigida por objetivos. Recogida y colocación por encima de la automatización con scripts. Recogida de cajas donde los artículos varían pero la celda de trabajo no.
Telerobotica y control con humano en el bucle. Los operadores expresan intención en lenguaje natural; el modelo convierte a restricciones contra las que la capa de autonomía puede planificar.
Dónde falla
Encarnaciones novedosas. Entrenado en una mezcla de datos de robótica curada que se inclina hacia morfologías de brazo y pinza. Cuadrúpedos, humanoides, robots blandos: la calidad cae, a veces silenciosamente.
Escenas dinámicas de múltiples agentes. Almacenes concurridos, cocinas con humanos moviéndose, cualquier lugar donde la escena cambia más rápido de lo que el bucle de percepción lo reporta: los planes del modelo asumen más determinismo del que la realidad ofrece.
Seguridad. Igual que 1.5: nada en el modelo limita formalmente la salida. El verificador está en su stack, no en el de Google.
Portabilidad entre plataformas. Los planes se expresan en un espacio de coordenadas generalizado que necesita código adaptador por robot. Las demos ocultan esto.
Riesgo del tier de vista previa. Google ha retirado endpoints de vista previa con aviso limitado en otras líneas de Gemini. Planifique una migración cuando llegue 1.7 o su sucesor no de vista previa.
Cuándo usar 1.6 frente a 1.5
Use 1.6 por defecto para trabajo nuevo. Las mejoras en la consistencia del horizonte de plan y la fiabilidad de la salida estructurada importan más en la práctica de lo que importaba el techo de 1M tokens. Quédese en 1.5 solo si:
- Su base de código lo ancla y el coste de migración supera la diferencia de calidad.
- Tiene un caso de uso específico que genuinamente ejercita la ventana de un millón de tokens (raro en robótica).
- La reproducibilidad frente a resultados de investigación publicados requiere la revisión más antigua.
Cuándo no usar ER en absoluto
Si la tarea no es encarnada —objetivos del mundo físico, entradas de sensores, salidas de acciones— use gemini-pro-latest u otro modelo de propósito general. ER es peor que Pro en todo lo que no es robótica, por diseño.
Si el despliegue es crítico para la seguridad y no puede aceptar cambios de comportamiento del tier de vista previa, busque alternativas auto-alojadas donde controle la versión del modelo. OpenVLA es el punto de partida obvio; los modelos de Physical Intelligence si puede acceder a ellos a través de asociaciones.
Si necesita inferencia en dispositivo o cerca del dispositivo por razones de latencia en un bucle adyacente al control, ER es la forma equivocada. Los modelos VLA destilados que corren en un Jetson o acelerador de borde equivalente son la conversación.
Alternativas que vale la pena mencionar
OpenVLA: 7B parámetros, pesos abiertos, ejecutable en una sola H100, entrenado en el conjunto de datos Open X-Embodiment. La línea base de referencia de código abierto para investigación de VLA.
La familia pi0 de Physical Intelligence: la alternativa propietaria más sólida discutida públicamente en amplitud de manipulación.
NVIDIA Project GR00T: modelos fundacionales para robótica humanoide; diferente enfoque de morfología, enfoque técnico superpuesto.
Helix de Figure: modelo cerrado de Figure, demostrado en su plataforma humanoide. No es una oferta de API comparable, pero vale la pena seguir como marcador de capacidad.
Notas prácticas
Relea la guía de prompts al pasar de 1.5 a 1.6. El formato recomendado de descripción de escenas y el esquema del espacio de acción cambiaron.
Revalide su adaptador de salida estructurada. Incluso con las mejoras en el seguimiento de esquemas, los casos extremos que funcionaban en 1.5 pueden producir formas diferentes en 1.6.
Registre la revisión del modelo con cada llamada. Cuando Google rota el endpoint de vista previa, la correlación entre el cambio de comportamiento y el cambio de revisión es la única forma de depurar.
El resumen honesto: Robotics-ER 1.6 Preview es la mejor de las dos revisiones de vista previa para nuevo trabajo en robótica, con las mismas advertencias sobre especialización, riesgo del tier de vista previa y coste de integración que aplican en toda la familia.
Última revisión técnica: 2026-05-22 — Tokonomix.ai
