Runway Solaris: How a Video Model Became an Operating System

Runway Solaris generates the screen, not the code that produces the screen. That sentence sounds like a distinction without a difference until you look at what is underneath a running session: no HTML document, no stylesheet, no DOM tree, no event handlers. The button you click is a region of pixels the model drew. The model has learned what happens to regions that look like buttons when they are clicked, so the frame it generates next shows the pressed state, and the frames after that show whatever the button was supposed to do.

The whole thing runs at 720p and responds to input in real time, which is the part that makes it feel like software rather than a video. Clicking, dragging and typing all condition what comes next. Nothing is retrieved from a database and drawn into a template; every pixel of every frame is model output.

This is also the line that separates it from the tools it will be compared to all week. v0, Lovable and Bolt are code generators with a preview pane attached: you describe an interface, a language model writes React and CSS, a browser runs that code, and what you keep at the end is a repository. The interface those tools produce outlives the model that wrote it — you can read it, fork it, deploy it, and the model never has to run again. Solaris keeps nothing between frames except the model.

That has a consequence worth sitting with, because it is the part most of the launch commentary skipped. In a conventional application, state is a thing you can point at: a row in a table, a value in memory, a field in a form that either holds the string you typed or does not. In a generated interface, state is whatever the model still remembers about the frames it has already drawn. The two behave the same right up until they do not, and the failure is not an error message — it is a screen that looks completely normal and is quietly wrong.

Because generating a coherent interface turns out to be the same problem as generating a coherent shot. Runway Solaris builds on Gen-4.5, Runway's video model — a system whose entire training budget went into one constraint: the object in frame sixty has to still be the object that was in frame one. A mug does not become a different mug halfway through a pan. A shadow that falls to the left keeps falling to the left. It also continues a line of work Runway started with GWM-1, its general world model, though the announcement describes that as the path Solaris follows rather than a component inside it.

Interfaces need exactly that discipline and almost nothing else. A panel that is open has to stay open. A number typed into a field has to still be there after the sidebar collapses. Temporal consistency is the hard part of video generation, and it is also most of what makes a screen feel like a screen rather than a hallucination that resets every second.

What changes is the steering. A video model predicts the next frame given the previous frames and a prompt; the prompt is the only thing driving the sequence forward. Solaris swaps that signal for your input. Click a row in a table and the next frame is the expanded row. Drag a slider and the following frames show the value moving. Same machinery, different steering wheel — the sequence is no longer authored in advance, it is negotiated one frame at a time with whoever is holding the mouse.

The second architectural decision is the split between reasoning and rendering. Language models are good at deciding what should happen and bad at drawing it; world models are good at producing a frame that looks right and have no particular opinion about what the frame ought to contain. Runway keeps the two apart: inference sits with the language model, rendering sits with the world model. That separation is why the system can be reasoned about at all — it is also, uncomfortably, the seam where most of the current failure modes live.

Runway points at three uses: generative storefronts, interactive tutorials, and training environments for agents. They share a property worth naming, because it explains the choice better than the individual examples do.

A generative storefront is a shop that assembles itself around the person looking at it, with no template to fill and no product grid to lay out in advance. An interactive tutorial is a lesson that can improvise the interface it is teaching, including states a real product would take a sprint to build. A training environment is a place to let an agent click through ten thousand variations of an application without anyone having to write ten thousand applications.

The common thread: all three are cases where the visible surface matters more than the durable state behind it. Nobody needs the storefront to still exist tomorrow, and nobody needs to open the tutorial in a code editor. That is a real category — it is just narrower than "this replaces front-end development," which is what the launch coverage settled on within about six hours.

Runway is unusually direct about the limits, and the four it names are the four you would predict from the architecture: legible text, trusting what the interface tells you, coherence across long sessions, and integration with assistive technology such as screen readers.

Text rendering is the one users will notice first. Generated glyphs drift; an interface is mostly words, and a label that subtly reshapes itself between frames is a much bigger problem in a settings panel than in a video. Long-session consistency is the same failure stretched over time — the further a session gets from its first frame, the more room the model has to quietly redecorate. Trust is the seam between the two halves of the architecture: the world model draws a plausible number in a plausible cell, and plausible is not the same as correct — Runway's own framing is that a convincing wrong answer costs more than no answer at all. Accessibility is arguably the hardest of the four, because screen readers consume a semantic tree, and a stream of frames does not have one to expose.

The 720p ceiling belongs on the same list, even though Runway frames it as a spec rather than a limitation. Video tolerates it because video is mostly large moving shapes. Interfaces are the opposite: dense, static, full of nine-pixel labels and hairline borders that only read correctly when they land on exact pixels. A dashboard at 720p on a laptop display is not a scaled-down dashboard, it is a blurred one, and the elements that blur first are the ones carrying the information.

Then there is the consequence that follows from having no source code at all. Nothing to put under version control, nothing to review in a pull request, nothing to run a linter or a static analyzer against, no way to diff what changed between Tuesday and Wednesday. The limits of Runway Solaris as it stands are not only about output quality — they are also about everything a team normally does to an application that is a file rather than a performance.

No. Runway Solaris is not publicly available. Access is limited to an early access request form, and Runway has said it is working toward wider availability with selected partners.

There is no announced public release date, no published pricing of any kind, and no public API — no endpoints, no parameters, no SDK. Any pricing figure, launch date or code sample circulating for Solaris right now was invented by whoever published it. Anyone offering to sell you access, move you up a queue, or hand you an API key is selling something that does not exist yet, and this site has no ability to provide, broker or accelerate access either.

Last verified: 2026-09-02. See the changelog at the bottom of this page for what has changed since publication.

Different category, and worth being blunt about it: nothing below generates an interface. Runway Solaris is an interface model; the tools on this site are video generators. If what you came for is a screen that draws itself in response to clicks, none of this is a substitute and you will have to wait like everyone else.

What they do share is the layer underneath. Solaris exists because video models got good enough at temporal coherence to be pointed at something other than video, and that layer is not gated behind a request form. If the interesting part for you was frame-by-frame generation with a model that keeps track of what things are, you can run that today:

Does Solaris generate HTML or CSS?

No. There is no markup, stylesheet or DOM underneath a Solaris session. The model generates the rendered frames directly, which means there is no source file to export, inspect, diff or host somewhere else.

Is Solaris the same thing as Gen-4.5?

No. Gen-4.5 is the video model Runway Solaris builds on, and it is also a product you can use on its own. Gen-4.5 generates video clips from a prompt; Solaris generates an interface that reacts to input.

How is this different from Genie 2?

Both generate an interactive world frame by frame instead of rendering one from code, but they point at different targets. Genie 2 generates game-like environments you move through; Solaris generates application interfaces you click, drag and type into.

Can I self-host or fine-tune Solaris?

Runway has not published anything about self-hosting, fine-tuning or model weights. With access limited to an early access request and no public API, neither is possible today.

• 2026-09-02Page published, checked against Runway's announcement. Runway Solaris status at the time of writing: early access only, no announced public release date, no published pricing, no public API.