Runway Solaris, anunciado el 31 de agosto de 2026, es el primero de lo que Runway llama Interface World Models. La versión en una línea: en lugar de construir el software como código y luego ejecutarlo, Solaris genera la propia interfaz, fotograma a fotograma, en vivo, mientras interactúas con ella. No hay HTML, ni CSS, ni código debajo. La imagen en tu pantalla es la aplicación.
Está construido sobre el modelo de vídeo Gen-4.5 de Runway, combina un modelo de lenguaje (que decide qué debe pasar) con un modelo de mundo (que renderiza cómo se ve) y apunta a interacción en tiempo real a 720p. En el estudio con usuarios de la propia Runway, la gente prefirió Solaris a una interfaz con código creada por Claude Opus 5 por 61 % a 24 % en seguir instrucciones y por 71 % a 21 % en comportarse de forma natural.
El problema: es una vista previa de investigación, no un producto. No hay precios, ni API pública, y el acceso es solo bajo solicitud. Todas las reacciones hasta ahora son a un vídeo de demostración, no a un uso real, y los escépticos más agudos ya plantean dos preguntas razonables: si los costes de generación en streaming hacen viable un modelo de negocio y si se puede confiar en el resultado. Esa cuestión de confianza es la que más importa si trabajas en soporte, y es exactamente el problema que un compañero de IA para tu helpdesk debe resolver antes de tocar a un cliente real.
Qué es realmente Runway Solaris
Conviene aclarar esto primero, porque la mayoría de las opiniones del día del lanzamiento lo difuminan: Solaris no es otra herramienta de texto a vídeo, ni tampoco un creador de apps al estilo Lovable en el que la IA escribe el código por ti. Es más extraño que ambas cosas.
Runway, la empresa más conocida por la generación de vídeo con IA, se describe ahora como "building foundational Real-World Intelligence that can understand, simulate and act in the world". Solaris es el primer modelo de una nueva familia que llama Interface World Models, y la premisa con la que abre es un verdadero "qué pasaría si": ¿qué ocurre cuando un sistema operativo genera apps y sitios web mientras los usas?
En una app normal, la idea de un diseñador se traduce a código, el código se publica y, desde entonces, la app solo puede hacer lo que alguien anticipó y escribió. El argumento de Runway es que este paso de traducción pierde información, es "a lossy compression of the space of possible interactions, frozen before any user arrives." Solaris se lo salta. No hay representación intermedia. El modelo renderiza directamente la capa de interfaz, y "every frame is synthesized as you interact, allowing the interface to respond continuously to your actions."
Los ejemplos de la demo lo hacen concreto. Una tienda de ropa virtual donde arrastras una camiseta sobre una foto tuya para probártela. Una ensalada que preparas arrastrando ingredientes a un bol. Una demostración de combustión que reacciona con resultados físicamente plausibles. Y mi planteamiento favorito del post, "redefining the mouse", donde haces clic en un gato y su pelaje se convierte en tu pincel, o haces clic en una pintura y dibujas con su estilo. Ninguna de esas interacciones se programó. El modelo las aprendió.
Si has seguido la investigación de Runway, este es el siguiente peldaño lógico después de GWM-1, su modelo de mundo general, y encaja en un linaje real: Gen-4, luego Gen-4.5, luego GWM-1 y ahora Solaris. No es un cambio de marca de un modelo antiguo.
Cómo funciona Solaris: dos modelos, una pantalla
Esta es la parte que me parece más interesante, porque es una reutilización inteligente de cosas que ya existen y no una arquitectura nueva y misteriosa.
Hay dos modelos que hacen dos trabajos. Un modelo de lenguaje interpreta tu petición, decide si una acción modifica la escena actual o pasa a una nueva, y produce los prompts que guían el renderizado. Un modelo de mundo, construido sobre Gen-4.5, genera entonces cómo se ve realmente ese comportamiento. En palabras de Runway: "one decides what the application should do next, while the other generates how that behaviour appears."
El truco que lo hace interactivo en lugar de un clip pregrabado es cómo trata tu entrada. Los clics, arrastres y ediciones se introducen como condicionamiento para el siguiente fotograma, igual que lo haría un texto o una imagen. El modelo solo ve interacciones que ya han ocurrido, así que aprende la relación entre una acción y su resultado visual sin que nadie programe esa relación.
Para que un modelo de vídeo fuera lo bastante rápido como para sentirse en vivo hicieron falta tres movimientos: enseñarle a generar fotogramas de forma autorregresiva, de modo que cada fotograma dependa solo de los anteriores; destilar el lento proceso de eliminación de ruido de muchos pasos a unos pocos; y después entrenar esa versión rápida con sus propias salidas para que la calidad se mantenga en una sesión larga. Runway fijó su listón en el punto donde las interacciones "stop feeling interactive somewhere around half a second of delay," y afirma que el trabajo en tiempo real también hizo que Solaris fuera varios órdenes de magnitud más barato de ejecutar que un modelo de difusión de vídeo estándar. Conviene señalar lo que no se revela: ni tasa de fotogramas, ni número de parámetros, ni longitud de contexto, ni tamaño del modelo. Conocemos los objetivos de diseño, no los comprobantes.
La demo a la que todos reaccionan
Como Solaris salió como informe de investigación con pruebas limitadas, la reacción es una reacción a la demo, y se divide con claridad entre asombro y una ceja levantada.
Del lado del asombro, los creadores que pasan el día en herramientas generativas entendieron enseguida lo que hace Solaris:
"Very cool work by Runway. Feels like the best of both worlds -- fine grain control of a WYSIWYG editor with the creativity & speed of generative models."
El CTO de Runway, Anastasis Germanidis, publicó el hilo de lanzamiento, que reunió unos mil me gusta y se convirtió en el centro de gravedad de la discusión. En Hacker News, un comentarista lo llamó "one of the most innovative and coolest AI model demos I've seen this year", que es un listón alto en un año sin escasez de demos.
Pero las opiniones más útiles son las que buscan las costuras. Un diseñador en r/UXDesign señaló que la interacción de "mostrar, no explicar" es una idea antigua, los investigadores llevan décadas escribiendo sobre la programación por demostración, así que la novedad es el renderizado, no el modelo de interacción. Y la pregunta analítica más aguda llegó de Hacker News, la que yo sigo recordando:
"So, instead of inferring intent from an information-dense input (text), they do it w/ just mouse-based gestures? ... I would love to see how this holds up in practice."
Ese "cómo se sostiene en la práctica" carga con mucho peso y es el instinto correcto. Un vídeo de demo es un camino ideal cuidadosamente elegido. Lo interesante es el minuto diez de una sesión real, no los primeros treinta segundos.
Solaris frente a una interfaz con código: qué dicen las cifras
Runway no se limitó a publicar un vídeo y buenas sensaciones. Realizó dos estudios, y las cifras son lo más sólido del anuncio.
El estudio principal enfrentó a Solaris con una interfaz con código construida por Claude Opus 5, un modelo de última generación, con la misma imagen inicial y las mismas peticiones de interacción. Con 250 participantes y unos 7.500 juicios por pares, este fue el resultado:
| Pregunta | Se prefiere Solaris | Interfaz con código | Equivalente |
|---|---|---|---|
| ¿Cuál sigue mejor la instrucción? | 61 % | 24 % | 13 % |
| ¿Cuál se comporta de forma más natural dentro de la escena? | 71 % | 21 % | 6 % |
El segundo estudio, que Runway llama "the cost of translation,", es el que explica la filosofía. Probó con qué fidelidad los modelos multimodales, incluidos GPT-4o, Gemini 2.5 Pro y Claude Fable 5, podían reconstruir una interfaz a partir de una sola captura de pantalla, en 30 interfaces. El hallazgo: todos los modelos pierden información en la traducción, y empeora a medida que aumenta la complejidad visual. Esa es toda la tesis de Runway en un experimento: el código es un paso intermedio con pérdidas, así que se elimina.
Dos salvedades honestas. Son estudios de la propia Runway, no pruebas de referencia independientes, y todavía no hay una cifra de terceros con la que contrastarlos. Y "preferido en una comparación de demo por pares" no es lo mismo que "lo bastante fiable para lanzarlo", que es la brecha que rondan los escépticos.
Dónde tienen razón los escépticos
Quiero ser justo con Solaris, porque es una investigación real y las demos impresionan. Pero dos críticas son lo bastante fuertes como para ponerlas justo al lado del bombo.
La primera es la economía. El mejor comentario crítico que encontré vino de r/accelerate, y merece leerse completo:
"I like this a lot but I'm skeptical that people are going to want to pay ongoing generation costs for their app to function versus just having a coded app... if it requires your company stream dolla dolla bills directly to runway at all times to run your app I'm not seeing this as a feasible business model. Your economics would scale up with engagement, not a good situation to be in."
Runway sí dice que el trabajo en tiempo real hizo a Solaris mucho más barato que la difusión de vídeo estándar y que "the cost curve continues to improve." Pero "más barato que generar vídeo" es un listón bajo cuando la alternativa es código que se ejecuta prácticamente gratis. El coste es uno de los tres retos de ingeniería que la propia Runway nombra, junto con la velocidad y la coherencia a lo largo de una sesión larga.
La segunda es la confianza, y es la que Runway reconoce con más franqueza. Su propia sección de limitaciones lo dice sin rodeos: "a convincing wrong answer is worse than no answer." Una interfaz generada puede renderizar algo que parece correcto pero no lo es: un precio, un detalle de producto, un botón que no hace lo que aparenta. Runway dice que mantener a Solaris anclado a contexto verificado a medida que avanza una sesión es "an active research focus", que es la forma educada en investigación de decir que aún no está resuelto. Alguien en Hacker News lo expresó de forma más directa, comparándolo con demos anteriores de modelos de mundo:
"it looks cool at first but really quickly you'll start to see the gaps"
Qué significa Solaris si gestionas atención al cliente
Aquí esto deja de ser una historia de vídeo con IA y pasa a ser relevante para cualquiera que ponga IA delante de usuarios reales.
Runway plantea un caso de uso que cae de lleno en la experiencia del cliente: una tienda que se convierte en un entorno generado, que preserva la identidad de marca mientras adapta productos, diseños y recomendaciones a cada visitante en tiempo real. Es una imagen realmente emocionante de hacia dónde podrían ir las interfaces. Pero fíjate en que el problema sin resolver más difícil de Solaris, anclar la salida en datos verificados para que no muestre con seguridad algo erróneo, es exactamente el problema que ha definido la IA para soporte desde el primer día.
Llevo años construyendo agentes de IA para el helpdesk, y la lección más importante es la que Runway acaba de escribir en su propia sección de limitaciones. Un bot de soporte que suena seguro y se equivoca hace más daño que uno que dice "deja que busque a una persona". Por eso las alucinaciones de la IA en soporte son lo primero contra lo que se diseña, no lo último, y por eso simulamos cada despliegue con miles de tickets históricos reales de una empresa antes de que responda a un cliente en vivo. No descubres en producción si la respuesta está fundamentada; lo descubres con tickets cuya resolución ya conoces.
Así que mi lectura de Solaris, y de modelos como él, es esta: es una infraestructura fascinante, un nuevo sustrato para cómo se podrían generar las interfaces. Pero la infraestructura no es un empleado. Un modelo que puede renderizar cualquier cosa sigue necesitando las barreras, el anclaje y el contexto del dominio para confiarle un trabajo concreto, y eso es una disciplina distinta a hacer que los píxeles se muevan.
Prueba eesel
Esa es la brecha que eesel está diseñado para cerrar. Mientras Runway construye la capa de modelo, eesel es el compañero de IA que contratas para un trabajo, y hoy ese equipo es un compañero de IA para helpdesk y un redactor de blog con IA. Cada uno llega con las habilidades, integraciones y contexto de empresa para su función, en lugar de ser un generalista en bruto que tienes que conectar tú mismo.
En soporte en concreto, el compañero de helpdesk se conecta a las herramientas que ya usas, Zendesk, Freshdesk, Gorgias, Slack, aprende de tus tickets anteriores y tu centro de ayuda y, lo más importante, te permite simularlo con tickets históricos reales antes de que responda a un solo cliente. Ese es el problema de confianza que Solaris apenas empieza a nombrar, resuelto para el único trabajo que no puede permitirse una respuesta equivocada pero convincente. Es gratis probarlo, y puedes verlo redactar respuestas reales con tus propios tickets en unos minutos.