Runway Solaris Explained: Inside the First Interface World Model

September 2, 2026

Written by

Aerin Kim

Runway Solaris Explained: Inside the First Interface World Model

Runway's Solaris generates full interfaces frame by frame with no code behind them. Here is how the Interface World Model actually works, what its own benchmarks show, and where it still breaks.

On August 31, 2026, Runway published a research post titled "Introducing Solaris" and called it the first Interface World Model: a system that generates operating-system-style interfaces and applications in real time, frame by frame, with no underlying code running behind what you see on screen [1]. That sentence is worth reading twice, because it is not a metaphor. Every app, website, or settings panel you have ever used was assembled from HTML, CSS, JavaScript, Swift, or some other language, compiled or interpreted, then rendered by a browser or operating system that already knows the rules for buttons, text fields, and scroll containers ahead of time. Solaris skips that step entirely. There is no DOM, no view hierarchy, no button object sitting around waiting to fire an onClick handler. There is only a video model predicting what the next frame of pixels should look like, conditioned on the frame before it and on whatever you just clicked, dragged, or typed [1].

This is not an isolated stunt release. Solaris sits on top of Gen-4.5, the video generation model Runway shipped roughly three months earlier, in late 2025, which reached the top of Artificial Analysis's Video Arena leaderboard with 1,247 Elo points and was covered as beating comparable offerings from Google and OpenAI on independent blind comparisons [2] [3] [4]. It is also Runway's second "world model" product in under nine months, following GWM-1 in December 2025, a general world model for 3D environments, talking avatars, and robotics training data [5] [6]. And it lands squarely inside a genuinely competitive race: Google DeepMind's Genie 3, Fei-Fei Li's World Labs with Marble, and Decart and Etched's Oasis are all shipping some version of the same underlying idea, a generative model standing in for a simulation instead of a hand-coded one [8] [10] [12]. Solaris is the first entrant in that group aimed specifically at software interfaces rather than 3D scenes or game worlds, which is a meaningfully different bet than any of its named rivals are making.

This post walks through what that bet actually is: how frame-by-frame interface generation works mechanically, why the diffusion-to-autoregressive conversion trick is the real engineering story here, what Runway's own reconstruction-fidelity and user-preference studies show, where the model still visibly breaks, how Solaris compares to the other named entrants in the world model race, and what you can actually build today using Runway's genuinely public Gen-4.5 API, since Solaris itself has no public API yet.

runway-solaris-interface-world-model-explained-2026-hero.png

If you want to see the core mechanic before reading the technical breakdown, here is a Gen-4.5-style video generation prompt built around exactly how frame-conditioning works, the same underlying idea Solaris extends to interfaces:

A single continuous overhead shot of a blank glowing rectangle on a dark studio floor. A soft beam of light lands on one corner of the rectangle and the shape immediately reforms into a simple interface panel with a rounded button. An unseen hand-shaped light glides toward the button and taps it, and the panel instantly reshapes into a new layout, one element sliding out and another fading in, as if each change is a new frame growing directly out of the last rather than a scene cut. Camera holds a fixed slow zoom throughout, clean minimalist studio lighting, soft neutral color grading, physically accurate soft shadows, no readable text, no logos, no real interface elements, Gen-4.5-style photoreal rendering with smooth continuous motion and no jump cuts.

Step 1: What "Interface World Model" Actually Means

A world model, in the sense researchers have used the term since well before Solaris, is a system that builds an internal representation of an environment and predicts how that environment changes in response to actions, rather than simply describing the environment in words. Google DeepMind's Genie 3 is the clearest existing example: give it a text prompt and it generates a photo-real or imagined 3D environment that stays consistent for several minutes as an agent walks through it, remembering what was behind you if you turn around [8]. Runway's own GWM-1, announced in December 2025, applies the same idea to explorable 3D worlds, photorealistic avatars, and synthetic robotics training data, built as an autoregressive model on top of Gen-4.5 [5] [7].

Solaris takes that same underlying mechanism, a model that predicts the next state of a world given the current state and an action, and points it at something none of those systems targeted: the software interface itself. Instead of simulating a 3D room or a Minecraft-style landscape, Solaris simulates a window, a dashboard, a mobile app screen, or a settings menu. The "world" being modeled is not a physical space, it is the visual and behavioral logic of a graphical user interface. Independent coverage from cryptobriefing described it plainly as a real-time interactive interface model that renders continuous visual output instead of assembling one from predefined components [14], and outlets like Silicon Snark and Glitchwire framed the same idea more colorfully: an interface where "the buttons improvise" because there is no fixed button object underneath them at all, just a model deciding, frame by frame, that a rectangle should look pressed [15] [16].

That framing matters because it clarifies what Solaris is not. It is not a code generator that writes React components faster. It is not a screen recording being replayed. It is not a templated UI kit with a large language model filling in variables. Tools in those categories still ultimately produce and execute real code, which means their outputs inherit the strengths and the rigidity of traditional software: predictable, debuggable, but limited to states someone explicitly programmed for. Solaris produces no code at all. Every pixel you see is a model's prediction, and every interaction you perform becomes an input the model conditions its next prediction on. That is a genuinely different computational substrate for a graphical interface than anything most engineers have built against before, and it is why Runway frames it as a new category rather than a faster version of an old one.

It is worth being precise about what "no underlying code" does and does not mean in practice, since it is easy to round this off into something stranger than it is. Solaris itself, the model, is of course code, weights, and infrastructure like any neural network. What has no code behind it is the specific interface you see on screen at any given moment, the login form, the dashboard, the settings toggle. A traditionally built app has a fixed, inspectable definition of every screen sitting in a source file somewhere, whether or not that screen is currently visible. A Solaris-generated interface has no such definition anywhere. The button exists only as a pattern the model has learned to render in response to a particular kind of prompt and interaction history, not as an object you could open in a file browser and edit.

Step 2: How Frame-by-Frame Interface Generation Actually Works

The mechanical core of Solaris is the same autoregressive frame-prediction loop that underlies modern video generation, repurposed for interaction. In a normal video model, frame N is generated conditioned on frame N minus one, and the model has learned from training data how scenes typically evolve: a ball that was falling keeps falling, a person mid-stride keeps walking. Solaris extends that conditioning signal to include something video models normally do not have access to: an explicit user action. A click at a specific pixel coordinate, a drag from one point to another, or a string of typed characters becomes an additional conditioning input alongside the previous frame, the same category of signal as a text prompt or a reference image, just supplied continuously rather than once at the start [1].

This is the mechanism that lets the model "learn" what a button does without anyone telling it. During training, the model observes enormous numbers of completed human-computer interactions: a cursor moving toward a rectangle, a click registering, and the visual state of the screen changing in a specific, learnable way immediately afterward. It never sees a label that says "this is a button" or a rule that says "buttons fire click handlers." It only sees the correlation between an action at a particular location and the resulting change in pixels, learned the same statistical way a video model learns that a dropped glass shatters, not because someone wrote physics code, but because it has seen it happen enough times to predict it reliably.

runway-solaris-interface-world-model-explained-2026-puppeteer-strings.png

A simplified way to think about the loop, stripped of the actual model internals Runway has not published, looks like this:

python
/code
# A conceptual illustration only. This does NOT reproduce Solaris's real
# architecture, which Runway has not published, but it shows the core
# structural idea: the next frame depends only on the previous frame
# plus whatever action just happened, the same way a video model
# conditions frame N on frame N-1.

class ToyInterfaceWorldModel:
    def __init__(self):
        self.current_frame = "blank_screen"

    def step(self, user_action):
        """Predict the next frame given the current frame and one action.
        No separate application state is stored anywhere else; whatever
        continuity exists has to live inside this single generated frame."""
        if user_action is None:
            next_frame = self.current_frame
        elif user_action["type"] == "click" and self.current_frame == "blank_screen":
            next_frame = "login_form_appears"
        elif user_action["type"] == "type" and self.current_frame == "login_form_appears":
            next_frame = "login_form_with_text_entered"
        elif user_action["type"] == "click" and self.current_frame == "login_form_with_text_entered":
            next_frame = "dashboard_view"
        else:
            next_frame = self.current_frame + "_unchanged"
        self.current_frame = next_frame
        return next_frame

model = ToyInterfaceWorldModel()
actions = [
    {"type": "click", "target": "start_button"},
    {"type": "type", "target": "email_field"},
    {"type": "click", "target": "submit_button"},
]

for action in actions:
    frame = model.step(action)
    print(f"action={action['type']} -> frame={frame}")

That toy loop is deliberately not a reproduction of Solaris's real architecture, which Runway has not open sourced or published in a paper. It is meant to make one specific point concrete: at every single step, the only inputs available to decide what the next frame looks like are the previous frame and the current action. There is no separate persistent application state being tracked in a database or a variable somewhere, the way a real app would track "is this checkbox currently checked." Whatever continuity a Solaris interface has, remembering that you typed your email address into a field two screens ago, has to be implicitly encoded in the visual history the model conditions on, not retrieved from a data structure. That is precisely why Runway names long-session coherence as one of the model's open problems, covered in Step 7 below: the mechanism that gives Solaris its flexibility, no fixed state model, is the same mechanism that makes long-term consistency hard.

Step 3: The Gen-4.5 Foundation and the Diffusion-to-Autoregressive Trick

The part of Solaris's design that deserves the most technical attention is not the interface framing, it is how Runway made a video diffusion model fast enough to feel responsive to a click. Standard video diffusion models, including the base version of Gen-4.5 that Solaris builds on, generate output through many sequential denoising steps: the model starts from pure noise and gradually refines it into a coherent frame or clip over dozens of iterations. That process produces excellent quality but it is far too slow for anything resembling a live, clickable interface, where a user expects visual feedback within roughly a hundred milliseconds of an action, not the multi-second latency a full diffusion sampling pass usually takes.

Runway's stated approach converts that many-step diffusion process into a few-step autoregressive one through three stages: first teaching the base model to generate frames autoregressively, one frame conditioned on the last, rather than generating whole clips at once; second, distilling the many-step denoising process down into just a few steps per frame; and third, training the resulting accelerated model on its own outputs to keep it stable, since a model fine-tuned only on real data tends to drift or produce artifacts once it starts feeding on its own generations in a live loop [1]. That third stage is the kind of detail that separates a research demo from something that can actually run continuously: a system generating its own next input, frame after frame after frame, will compound small errors unless it has specifically been trained to correct for the kind of imperfections its own outputs contain, which is a subtly different problem than generating a single clean sample from scratch.

This distillation step is also the direct answer to a question that comes up immediately once you understand what Solaris does: why would this be cheaper to run than a standard video model, when it is doing continuous real-time generation instead of a one-time render? The intuitive expectation is that "generate video forever, live, in response to every click" should cost more compute than "generate one ten-second clip and stop." The answer is that the few-step distillation is precisely what breaks that intuition. A standard diffusion sampling pass might run 20 to 50 denoising steps to produce one high-quality frame or clip. A distilled few-step model produces a comparable-quality frame in a handful of steps, sometimes as few as one or two, which is roughly an order of magnitude less compute per frame. Running that cheaper process continuously at interactive frame rates ends up costing meaningfully less per unit of generated content than running the original many-step process once, even though the few-step version has to run far more frequently. This is the same category of tradeoff that made real-time diffusion-based image editing tools practical in the first place: fewer, better-targeted denoising steps rather than a full sampling trajectory.

runway-solaris-interface-world-model-explained-2026-step-distillation.png

A simplified illustration of that step-count tradeoff, showing why fewer denoising steps per frame is the actual lever that makes real-time generation affordable, looks like this:

python
/code
# A conceptual illustration of why distilling many-step diffusion into a
# few-step autoregressive process is what makes real-time generation
# affordable, not just a side benefit of a faster GPU.

def compute_cost(steps_per_frame: int, frames_needed: int, cost_per_step: float) -> float:
    """Total compute cost is steps-per-frame times frames-needed, so cutting
    steps-per-frame by 10x cuts total cost by roughly 10x even though a
    live interface has to generate far more frames than a single clip."""
    return steps_per_frame * frames_needed * cost_per_step

cost_per_step = 1.0

# A single 5-second clip at standard diffusion quality: ~30 denoising
# steps, one "frame" worth of generation effort in this simplified model.
standard_clip_cost = compute_cost(steps_per_frame=30, frames_needed=1, cost_per_step=cost_per_step)

# A live interface running for the same 5 seconds at a distilled few-step
# rate, needing many more individual frame predictions to feel continuous.
live_interface_cost = compute_cost(steps_per_frame=2, frames_needed=15, cost_per_step=cost_per_step)

print(f"standard many-step clip cost: {standard_clip_cost}")
print(f"few-step live interface cost: {live_interface_cost}")
print(f"live interface is cheaper by: {standard_clip_cost / live_interface_cost:.1f}x")

It is worth naming the layered dependency explicitly, since it is easy to lose track of which model is doing what. Gen-4.5 is the general-purpose video generation foundation, trained on ordinary video and optimized for cinematic quality, physical accuracy, and prompt adherence [2]. GWM-1 took that same Gen-4.5 foundation and adapted it into an autoregressive, action-conditioned world model for 3D scenes, avatars, and robotics [5]. Solaris takes a related adaptation path but trains specifically on interaction data, clicks, drags, and typed text paired with the resulting interface changes, rather than on camera movement through 3D space or robot actuator commands. All three share a common ancestor and a common autoregressive, frame-by-frame generation strategy, but they diverge sharply in what kind of "world" their training data teaches them to predict.

Step 4: Two Historically Separate Systems, Merged Into One

Runway frames Solaris as unifying two categories of software that have always been built and shipped separately: systems that understand intent, and systems that render experience. The first category covers search engines, AI assistants, and increasingly large language models, tools whose entire job is figuring out what a person actually wants from an ambiguous request. The second category covers game engines and browsers, tools whose entire job is turning a defined application state into pixels on a screen quickly and reliably, with no understanding of what the user is trying to accomplish beyond the specific input event just received [1].

In Solaris's architecture, a language model handles the first job, reasoning about what the interface should do next given the user's request and the conversation so far, and the world model handles the second job, generating what that decision actually looks like as pixels, live [1]. Put concretely: if you ask for "a simpler version of this settings screen with fewer options," the language model is the part deciding what "simpler" should mean here, which options to drop, which to keep prominent, while Solaris is the part rendering that decision as an actual interface you can then click into, rather than a written description of one.

This division of labor is a deliberate echo of how a real application is normally built, just collapsed into two live model calls instead of a design phase followed by a much longer engineering phase. A traditional product team has a designer or product manager reasoning about what the interface should do, then an engineering team translating that reasoning into code that a browser or OS can render. Solaris compresses the "translate reasoning into a working, renderable interface" step from a multi-week engineering effort into a live, frame-by-frame generation process happening in real time as the user interacts. The language model still does the reasoning a product manager or designer would normally do. What disappears is the entire intermediate layer of engineers writing and maintaining code to make that reasoning clickable.

The practical upside of that compression is speed of iteration in a category that has always been notoriously slow to iterate. Anyone who has worked on a real product knows the gap between "we decided to change this flow" and "the change is live for users" is measured in days or weeks even at a well-run company, because turning a decision into working, tested code takes real engineering time no matter how clear the decision is. If a world model can turn that decision directly into a working, if imperfect, interface in the time it takes to describe it, the bottleneck that has defined most software development, translating intent into a working artifact, changes shape entirely. It does not disappear, since someone still has to specify the intent clearly and evaluate whether the result is right, but the "make it clickable" step stops being the slow part.

Step 5: Runway's Reconstruction-Fidelity Benchmark

Runway ran its own evaluation to establish a baseline for how well existing frontier multimodal models understand interfaces before comparing Solaris against them. The setup: give Claude Fable 5, GPT-4o, and Gemini 2.5 Pro a screenshot of a real interface and ask each model to reconstruct it, across 30 diverse interfaces ranging from plain text-heavy webpages to image-dense, visually complex layouts [1].

runway-solaris-interface-world-model-explained-2026-reconstruction-fidelity.png

The scoring used two complementary metrics rather than one. Structural Similarity, or SSIM, is a classical image-quality metric that measures how closely the pixel-level structure of a reconstruction matches the original, sensitive to layout, spacing, and overall composition. DINOv3 feature similarity works differently: instead of comparing raw pixels, it compares learned visual features extracted by a self-supervised vision model, which is more forgiving of small layout shifts but better at detecting whether the actual content and meaning of a region survived the reconstruction, even if its exact position moved [1]. Using both together catches two different kinds of failure: a reconstruction that nails the layout but changes the content would score well on SSIM and poorly on DINOv3 similarity, while one that gets the content right but rearranges the layout would score the opposite way.

The finding across all three models was consistent: information loss increased steadily with visual complexity. A simple, mostly-text interface was reconstructed with relatively little information loss by all three models. A visually dense interface, heavy on images, custom components, and layered content, showed meaningfully more degradation, and that degradation pattern held across Claude Fable 5, GPT-4o, and Gemini 2.5 Pro alike, despite the three models coming from different labs with different training approaches [1]. That consistency across three unrelated frontier models is itself informative: it suggests the failure is not a quirk of any one model's training, but a structural limitation of reconstructing a visually complex interface from a single static screenshot and a text-based generation process, exactly the gap Runway argues a purpose-built interface world model closes.

A simplified illustration of that degradation pattern, showing why information loss tracks visual complexity rather than staying flat, looks like this:

python
/code
# A conceptual illustration of Runway's finding that reconstruction
# information loss increases with visual complexity, not a real SSIM or
# DINOv3 implementation. Real SSIM and DINOv3 scoring requires actual
# image pairs and the respective libraries (scikit-image and a DINOv3
# checkpoint), which this toy version stands in for with a simple curve.

def estimated_information_loss(visual_complexity: float) -> float:
    """visual_complexity ranges 0 (plain text page) to 1 (dense, image-
    heavy layout). Loss grows faster than linearly, matching the reported
    pattern that dense interfaces degrade more than simple ones across
    all three tested models."""
    return round(visual_complexity ** 1.6, 3)

for complexity in [0.1, 0.3, 0.5, 0.7, 0.9]:
    loss = estimated_information_loss(complexity)
    print(f"visual_complexity={complexity} -> estimated_information_loss={loss}")

It is worth being specific about why this particular benchmark design is a fair one rather than a setup engineered to make Solaris look good. Runway did not compare Solaris's own reconstruction accuracy against these three models on the same task, at least not in the reconstruction-fidelity study itself. It first established, independently, that general-purpose frontier multimodal models degrade predictably as interfaces get more complex, using metrics with no relationship to how Solaris itself was trained or evaluated. That framing matters because it sets up the real claim precisely: the problem Solaris targets, faithfully reconstructing and then extending a complex interface, is one that current general-purpose models measurably struggle with, not a strawman gap invented for the announcement. Readers evaluating any vendor's benchmark claims should look for exactly this pattern, an independently defined problem with an objective metric, rather than a benchmark custom-built around the vendor's own strengths.

Step 6: The User Preference Study, 250 People and 7,500 Judgments

Runway's second study asked a more direct question: when people actually use interfaces produced by two different systems, which do they prefer, and on what dimensions? The comparison pitted Solaris-generated interfaces against interfaces coded by Claude Opus 5, given identical starting images and identical interaction requests, across 30 interaction examples [1]. Two hundred fifty participants made pairwise judgments across those examples, producing roughly 7,500 individual comparisons in total [1].

runway-solaris-interface-world-model-explained-2026-preference-study.png

The study measured two separate dimensions rather than one blended "which did you like better" score, and the results diverge in an interesting way. On "following instructions," meaning whether the resulting interface actually did what the person asked for, Solaris was preferred in 61 percent of comparisons versus 24 percent for the coded alternative, with the remaining 13 percent judged a tie [1]. On "natural behavior," meaning whether the interface felt like a genuine, coherent piece of software rather than an assembly of disconnected parts, the gap widened further: 71 percent preferred Solaris, 21 percent preferred the coded version, and 6 percent called it a tie [1].

Dimension	Preferred Solaris	Preferred coded (Claude Opus 5)	Tie
Following instructions	61%	24%	13%
Natural behavior	71%	21%	6%

That gap between the two dimensions is worth sitting with rather than skimming past. A 61-to-24 margin on instruction-following is already a decisive result, but a 71-to-21 margin on natural behavior is a larger one, and it points at something specific: coded interfaces built quickly by a capable model still tend to look and feel like separately assembled components stitched together, each one individually correct but not necessarily cohering into something that behaves like a single, considered piece of software. Solaris, generating every frame as part of one continuous visual and behavioral prediction, appears to avoid that stitched-together quality more consistently, likely because it has no separate "components" to stitch in the first place; there is only one model predicting one coherent visual outcome at every step. Whether that same coherence holds up outside a controlled study with a fixed set of 30 examples is a fair open question, and it connects directly to the long-session coherence limitation Runway itself names in Step 7.

It is also worth flagging what this study does and does not establish. It compares Solaris against interfaces coded live by a capable language model responding to the same brief, not against a professionally engineered, thoroughly tested production interface built over weeks by a human team. Claude Opus 5 generating code on the spot from a prompt is a reasonable and increasingly common way real interfaces get built today, so the comparison is a fair one for that specific, fast-turnaround use case. It is a different and harder claim, one this study does not make, to say Solaris would win a preference comparison against a mature, hand-refined production app that has been iterated on for months. Runway's own framing positions Solaris for exactly the category the study tests: fast, prompt-driven interface generation, not a wholesale replacement for deliberately engineered software.

Step 7: What Solaris Still Gets Wrong

Runway's own announcement names four specific, unresolved problems rather than gesturing vaguely at "it's still early." Taking each one seriously is more useful than treating the list as boilerplate disclaimer text, because each limitation traces directly back to a specific consequence of the frame-by-frame generation mechanism described in Step 2.

Legible text rendering is still unstable. Generating stable, correctly spelled, correctly positioned text has been one of the hardest open problems in video generation generally, long before interfaces entered the picture, and Runway acknowledges Solaris inherits that weakness directly [1]. This is a particularly awkward limitation for an interface-generation model specifically, since almost every real interface leans heavily on legible text: button labels, form field placeholders, menu items, error messages. A 3D game world or a talking avatar can absorb some text instability without breaking the core experience. An interface where a button's label flickers or subtly changes between frames is a much more visible and disorienting failure, because interface text is not decoration, it is the primary way a user knows what an element does.

The model is prone to confidently wrong, or hallucinated, interface states. Runway names the specific risk of "convincing wrong answers" appearing in instructional or commercial contexts, and notes that grounding the model's output in reference material or verified data remains incomplete [1]. This is the interface-generation version of a language model hallucinating a fact: the model produces a visually plausible screen, a form that looks correctly filled in, a confirmation message that looks legitimate, that does not actually correspond to a real, verified state. For a demo or a prototyping tool, an occasional wrong-looking state is a minor annoyance. For a checkout flow, a banking dashboard, or any interface making a factual or transactional claim, a confidently rendered but incorrect state is a genuinely serious failure mode, not a cosmetic one, since a user has no independent way to tell a hallucinated confirmation apart from a real one just by looking at it.

Semantic coherence degrades over long interactive sessions. Runway describes maintaining visual and semantic coherence over extended, open-ended interactions as an active area of research rather than a solved problem [1]. This is the direct, predictable consequence of the architecture described in Step 2: since there is no persistent, explicit application state anywhere, only an implicit visual history the model conditions on, whatever "memory" a Solaris session has is only as reliable as the model's ability to keep encoding and retrieving that history correctly across dozens or hundreds of generated frames. A traditional app never forgets that a checkbox is checked, because that fact lives in a variable that does not degrade with time. A generative interface has no equivalent guarantee, and the longer a session runs, the more opportunities exist for that implicit memory to drift.

Accessibility integration is incomplete. Runway names the tension directly: assistive technology and screen-reader integration needs real engineering work so that the model's flexibility does not come at the cost of usability for users who depend on those tools [1]. This is a structural problem, not a minor omission. Screen readers and other assistive technologies work by reading a structured accessibility tree, a machine-readable description of what each element on screen actually is, a button, a heading, a checked checkbox, that traditional UI frameworks generate automatically as a byproduct of how interfaces are built with named components. A Solaris interface has no such tree, because it has no components in the traditional sense at all, only pixels. Building an equivalent accessibility layer for a system whose fundamental output is a video stream, rather than a structured document, is a genuinely open engineering problem, not a checkbox Runway can tick off in a future update without real architectural work.

runway-solaris-interface-world-model-explained-2026-limitations.png

Taken together, these four limitations sketch a fairly clear near-term shape for where Solaris is and is not ready to be used. Low-stakes, short-session, prototyping and exploration contexts, mocking up an app idea, generating a quick demo, letting someone browse a hypothetical product, are exactly the use cases these limitations affect the least. High-stakes, long-session, or accessibility-critical contexts, a banking app, a government service, anything a screen-reader user needs to depend on, are exactly the use cases these limitations affect the most.

Case Study: The Interface World Model Race Runway Isn't Running Alone

It is easy to read a single company's announcement in isolation and miss how crowded the underlying category already is. Four organizations, each with real funding, real published research, and real products, are pursuing versions of the same core idea: replace a hand-coded or hand-modeled simulation with a generative model that predicts it instead. Comparing them directly is useful precisely because they have made different bets about which kind of "world" is worth modeling first.

Runway's own GWM-1, announced December 12, 2025, is the most direct point of internal comparison, since Solaris shares its Gen-4.5 lineage and its autoregressive, action-conditioned generation strategy [5]. GWM-1 ships in three variants: GWM Worlds, which turns a static scene into an explorable, persistent 3D environment where objects stay put even after you look away and back; GWM Avatars, which generates photorealistic or stylized speaking characters with synchronized lip movement, eye motion, and gesture; and GWM Robotics, distributed as an SDK for generating synthetic training data for robotics companies [6] [7]. Runway has stated an intention to eventually merge GWM-1's capabilities into a single unified model, which raises an obvious open question Solaris's announcement does not directly answer: whether Solaris will eventually fold into that same unified model, or remain a distinct, interface-specialized product. As of this writing, Runway has shipped them as separate systems, GWM-1 for 3D worlds, avatars, and robotics, Solaris for software interfaces, both built on Gen-4.5 but trained on different data for different predicted outcomes.

Google DeepMind's Genie 3, the most prominent outside comparison point, generates interactive 3D environments from a text prompt at 24 frames per second in 720p, maintaining consistency for several minutes at a time, including the well-cited detail that if you turn around inside a generated Genie 3 world, what was behind you is still there [8]. DeepMind frames world models as central to its AGI research strategy specifically because they let an AI agent train inside an effectively unlimited curriculum of simulated environments rather than requiring hand-built simulators for every scenario it needs to learn from. CEO Demis Hassabis has said he personally spends most of his research time on world model work, citing Genie 3 alongside the agent-training system SIMA 2 as his primary examples, and has described world models as essential infrastructure specifically for robotics and scientific discovery, two domains where real-world trial and error is expensive or slow [9]. Genie 3 targets open 3D exploration; Solaris targets the far more constrained, far more text-and-component-dense visual grammar of a software interface, a genuinely different generation problem even though both are, structurally, autoregressive frame predictors conditioned on action.

World Labs, founded by Fei-Fei Li alongside Ben Mildenhall, Justin Johnson, and Christoph Lassner, raised $230 million in seed financing before emerging from stealth, and launched its first commercial product, Marble, in November 2025 [10]. Marble takes a deliberately different technical approach from both Runway products and Genie 3: rather than generating a world on the fly as a user explores it, Marble produces a persistent, downloadable 3D environment upfront, from a text prompt, a photo, a video, a 3D layout, or a panorama, exportable as a Gaussian splat, a mesh, or a video file [10] [11]. That persistence-first design trades some of the spontaneity of a fully generative, live world for meaningfully less drift and morphing, since the environment is fixed once generated rather than being re-predicted frame by frame. Marble ships as a real commercial product today, with a free tier and three paid tiers up to 95 dollars a month, a sharp contrast to Solaris's early-access-only status.

Oasis, built by Decart in collaboration with the AI chip startup Etched, was the earliest of this group to ship publicly, released October 31, 2024, and trained entirely on recorded Minecraft gameplay rather than a general-purpose video foundation model [12]. Oasis takes keyboard and mouse input and generates each resulting frame live, running at roughly 20 frames per second at 460p resolution on a single Nvidia H100 GPU, producing a frame in about 0.04 seconds with the company describing the setup as effectively zero added latency [13]. Etched has stated Oasis is specifically optimized to eventually run on its purpose-built Sohu inference chip, at which point the company expects to support meaningfully higher resolution. Oasis is the narrowest of the four in scope, one game, one visual style, trained on one dataset, but it is also the closest technical precedent for what Solaris is now attempting at a much broader scale: real-time, low-latency, action-conditioned frame generation good enough to feel genuinely interactive rather than merely video-like.

runway-solaris-interface-world-model-explained-2026-competitive-landscape.png

Laid out together, the pattern across all four systems is that the "world model" label covers a genuinely diverse set of engineering bets, not one single approach with different branding. Genie 3 bets on open-ended 3D exploration for agent training. Marble bets on persistence and exportability over live generation. Oasis bets on narrow scope and low latency within a single, well-understood game. Solaris is the first to bet specifically on software interfaces, a domain defined by dense text, small interactive targets, and an expectation of near-perfect reliability that none of the other three domains demand quite as strictly. That is arguably the hardest version of the problem among the four, which is consistent with Solaris being the newest and the least publicly available of the group.

Step 8: Building With What's Actually Public Today, the Gen-4.5 API

Solaris itself has no public API, no published pricing, and no general sign-up as of September 1, 2026. Runway's own announcement directs interested parties to an early-access request form rather than a self-serve product [1]. If your goal is to actually run code against the model this post has been describing, the honest answer is that you currently cannot, and any tutorial claiming otherwise is either describing a different, unrelated product or is simply inaccurate.

What is genuinely public today is the Gen-4.5 model Solaris was built from, through Runway's documented developer API [17]. This will not generate an interactive, clickable interface the way Solaris does, since the public API produces standard, non-interactive video clips, not a live, action-conditioned generation loop. But it is the closest real, callable entry point into the same model family, and it lets you experience the underlying video generation quality Solaris was adapted from firsthand, today, with no waitlist.

Runway's REST API lives at https://api.dev.runwayml.com/v1, authenticates with a bearer token in an Authorization header, and requires a version header pinned to a specific release date rather than a version number [17]. Runway also publishes an official Python SDK that wraps the same endpoints [18], but the raw REST calls below use only the requests library so you can see exactly what is happening on the wire, whichever language you eventually use in production.

python
/code
# Real, runnable code against Runway's documented Gen-4.5 developer API.
# This generates a standard, non-interactive video clip, NOT a Solaris
# interface. Solaris itself has no public API as of September 2026.
# Docs: https://docs.dev.runwayml.com/guides/using-the-api/

import os
import time
import requests

API_BASE = "https://api.dev.runwayml.com/v1"
API_KEY = os.environ["RUNWAYML_API_SECRET"]

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json",
    "X-Runway-Version": "2024-11-06",
}

payload = {
    "model": "gen4.5",
    "promptImage": "https://example.com/starting-frame.jpg",
    "promptText": "Slow cinematic dolly-in on a quiet workshop desk at golden hour",
    "ratio": "1280:720",
    "duration": 5,
}

response = requests.post(f"{API_BASE}/image_to_video", json=payload, headers=headers)
response.raise_for_status()
task_id = response.json()["id"]
print(f"submitted task: {task_id}")

# Generation is asynchronous, so poll the task until it succeeds or fails.
# Runway asks that you poll no more than once every 5 seconds per task.
while True:
    time.sleep(5)
    task = requests.get(f"{API_BASE}/tasks/{task_id}", headers=headers).json()
    status = task.get("status")
    print(f"status: {status}")
    if status == "SUCCEEDED":
        print("video url:", task["output"][0])
        break
    if status == "FAILED":
        raise RuntimeError(f"generation failed: {task}")

Generation is asynchronous: the POST request returns a task id immediately, and the video itself is not ready until you poll the tasks endpoint and see a SUCCEEDED status. Here is the same request expressed as a raw curl command, useful for a quick manual test before wiring up the Python version above:

bash
/code
# The same Gen-4.5 image-to-video request as a raw curl call, useful for
# a quick manual test before wiring up the Python version.
curl -X POST https://api.dev.runwayml.com/v1/image_to_video \
  -H "Authorization: Bearer $RUNWAYML_API_SECRET" \
  -H "Content-Type: application/json" \
  -H "X-Runway-Version: 2024-11-06" \
  -d '{
    "model": "gen4.5",
    "promptImage": "https://example.com/starting-frame.jpg",
    "promptText": "Slow cinematic dolly-in on a quiet workshop desk at golden hour",
    "ratio": "1280:720",
    "duration": 5
  }'

A few honest caveats worth stating plainly rather than glossing over. First, gen4.5 as a model identifier and the exact endpoint paths above reflect Runway's documented API as of this writing; API surfaces change, so check https://docs.dev.runwayml.com/ directly before shipping anything against this in production. Second, this reproduces Gen-4.5's general-purpose video generation capability, cinematic clips from a prompt and a starting image, not Solaris's interaction-conditioned, real-time interface generation, which remains unavailable outside Runway's early-access program. If a tutorial elsewhere claims to give you a working Solaris API key today, treat that claim with real skepticism until Runway's own docs list it.

Production Best Practices for Builders Watching This Space

Even without direct API access to Solaris itself, there are concrete, non-speculative things worth doing today if you are building products in a space this could eventually touch, prototyping tools, no-code builders, internal tooling generators, or agentic coding assistants.

Treat generative interface output as a draft artifact, not a final one, from day one. Every limitation in Step 7, unstable text, hallucinated states, degrading long-session coherence, incomplete accessibility, points toward the same operational conclusion: a generative interface needs a review or verification step before it reaches a real user in any context where correctness matters, the same discipline teams have already learned to apply to LLM-generated code and LLM-generated copy. Building that review step into a workflow now, even against today's coded-interface tools, is the exact skill that carries over directly once interface generation from models like Solaris becomes available to build on.

Separate your reasoning layer from your rendering layer explicitly, the way Solaris's own architecture does. If you are building any kind of AI-assisted interface tool today, whether it touches Solaris or not, keeping "what should this interface do" and "what should this interface look like" as distinct, separately evaluable steps makes your system easier to debug and easier to swap components in and out of later, exactly the two-model split Runway describes between its language model and its world model.

Budget explicitly for the accessibility gap rather than treating it as a later concern. Runway's own limitations list names this directly as unfinished work, and it is the limitation least likely to be solved as a side effect of the model simply getting better at everything else, since it requires a genuinely separate engineering effort, a structured, machine-readable description of interface elements, that a purely pixel-generating system has no natural mechanism to produce on its own. Any team building on top of generative interface technology, once it is available, should plan for accessibility as a first-class requirement rather than a retrofit, the same lesson the broader software industry already learned the hard way with traditionally coded apps.

Watch the reliability-versus-flexibility tradeoff each of the four systems in the case study above makes differently, and match your own use case to the right point on that spectrum rather than assuming the most flexible option is always the best one. Marble's persistence-first design trades spontaneity for stability precisely because some use cases, an architectural walkthrough a client needs to review multiple times, a training environment that needs to behave identically across sessions, genuinely need that stability more than they need live generative flexibility. The same logic will likely apply to interface generation: some products will want the maximum flexibility Solaris offers, and others will want a more constrained, more predictable generative layer, closer to a smart template than a fully open-ended world model.

Where a Tool Like Miraflow Fits Into This Picture

It is worth being precise about what Solaris is and is not a competitor to, since the "AI video" label gets applied loosely across genuinely different categories of tool. Miraflow's Cinematic AI Video Generator, which runs on Veo3 and Veo3.1 today, produces finished, non-interactive cinematic clips from a text prompt, the kind of output used for product ads, short films, and standalone video scenes. That is a fundamentally different generation target than Solaris's real-time, click-responsive interface rendering: one produces a fixed artifact meant to be watched start to finish, the other produces a continuously regenerated, interactive surface meant to be clicked into. Neither replaces the other, and Miraflow does not use Solaris or Gen-4.5 under the hood; the comparison is useful precisely because it shows how differently "video model" can be pointed once you change what you condition generation on, a finished script versus a live user action.

The broader idea Solaris is built around, using a video-generation lineage model as the rendering layer for something interactive rather than something purely watched, is still a research-stage direction rather than a pattern available in consumer tools today. If you want to see today's version of AI video output actually working, Miraflow's Text2Shorts turns a topic into a scripted, voiced short in one pipeline, and the AI image generator and YouTube Thumbnail Maker give a faster, more hands-on sense of how far current generative visual tools have come, even without the live interactivity Solaris is specifically chasing.

Common Mistakes When Evaluating Solaris Coverage

A handful of misreadings show up repeatedly whenever a genuinely novel product category gets covered quickly across many outlets at once.

Assuming Solaris is a code generator that happens to be fast. It produces no code at all, coded or otherwise; every interface state is a generated frame, which is the entire point of calling it a world model rather than a code assistant.
Confusing Solaris with GWM-1. They share a Gen-4.5 foundation and an autoregressive generation strategy, but GWM-1 targets 3D worlds, avatars, and robotics data, while Solaris targets software interfaces specifically. They are separate products with separate training data and separate release dates, nine months apart.
Treating the 61 percent and 71 percent preference numbers as evidence Solaris beats any coded interface in general. The study compared Solaris against interfaces coded live by Claude Opus 5 from the same prompt, not against a professionally engineered, iterated-on production app, which is a narrower and fairer claim than "AI generation beats human engineering."
Assuming Solaris is available to try today. As of September 1, 2026, it is early-access only through a request form, with no public pricing or API.
Assuming any tutorial offering a working "Solaris API key" is legitimate. No such public API exists yet; what is genuinely available today is Runway's separate, documented Gen-4.5 API, which produces standard video, not interactive interfaces.
Reading Runway's named limitations, unstable text, hallucinated states, coherence drift, incomplete accessibility, as marketing disclaimers rather than real, structurally-caused constraints worth planning around if you are building anything adjacent to this category.

Frequently Asked Questions

Is Runway Solaris available to the public right now? No. As of September 1, 2026, Solaris is early-access only through a request form on Runway's site, with no public pricing and no public API. Runway states it is working with partners toward a public launch but has not given a date.

Is Solaris the same thing as GWM-1? No. Both are built on Runway's Gen-4.5 video model and use the same autoregressive, action-conditioned generation strategy, but GWM-1, announced in December 2025, targets 3D worlds, talking avatars, and robotics training data, while Solaris, announced August 31, 2026, targets software interfaces specifically. They are distinct products with separate release dates roughly nine months apart.

Does Solaris actually generate real, functioning code underneath the interface? No, and this is the single most important thing to understand about it. Every frame Solaris produces is a generated image, predicted the way a video model predicts the next frame of a clip. There is no HTML, CSS, JavaScript, or any other source code running behind what you see, which is exactly what makes it a world model rather than a code generation tool.

How does Solaris compare to using Claude, GPT, or Gemini to write an app's code directly? Runway's own reconstruction-fidelity study found that Claude Fable 5, GPT-4o, and Gemini 2.5 Pro all showed increasing information loss as interface visual complexity increased when reconstructing real interfaces from screenshots. Its separate preference study found people preferred Solaris-generated interfaces over ones coded live by Claude Opus 5 by 61 to 24 percent on following instructions and 71 to 21 percent on natural behavior, across 250 participants and roughly 7,500 pairwise judgments.

Can I call the Gen-4.5 API to build something similar today? You can call Runway's public Gen-4.5 API to generate standard, non-interactive video clips today, which is the same base model Solaris was adapted from. You cannot call Solaris itself, since it has no public API yet; any claim otherwise should be treated skeptically.

What are Solaris's biggest current weaknesses? Runway names four directly: unstable, sometimes illegible text rendering; a tendency to produce confidently wrong or hallucinated interface states; degrading semantic coherence over long interactive sessions; and incomplete integration with accessibility APIs and screen readers.

Who else is building world models like this? Google DeepMind's Genie 3 generates open 3D environments for agent training, Fei-Fei Li's World Labs makes Marble, which produces persistent, downloadable 3D environments, and Decart and Etched's Oasis generates a real-time, playable version of Minecraft. Solaris is the first of this group aimed specifically at software interfaces rather than 3D scenes or game worlds.

Should I build a production app on Solaris today? Not yet, and Runway's own stated limitations are the reason why. Between the early-access restriction, the lack of a public API or pricing, and the named issues with text stability, hallucinated states, session coherence, and accessibility, it is currently better suited to prototyping, exploration, and research than to a production interface people depend on.

Conclusion

Solaris is a genuinely new idea executed with real engineering behind it, not a rebrand of existing AI coding tools. Turning a video diffusion model into a few-step autoregressive system fast enough to feel clickable, then training it specifically on the correlation between user actions and interface state changes, is a meaningfully different technical bet than teaching a language model to write better React code, and Runway's own reconstruction-fidelity and preference studies back up the claim that the bet is paying off against current frontier models on the specific dimensions it tested. At the same time, the four limitations Runway names itself, text instability, hallucinated states, long-session coherence, and incomplete accessibility, are not small print. They describe exactly the situations where a fully generative interface is not yet a safe substitute for a hand-engineered one, and they track directly back to the same mechanism that gives Solaris its flexibility in the first place: no fixed state, no fixed components, only a model predicting the next frame. Whether Solaris becomes the interface layer a meaningful share of software eventually runs on, or stays a research direction that gets absorbed into narrower, more specialized tools the way earlier world model experiments often have, is genuinely open. What is not open to debate is that Runway, Google DeepMind, World Labs, and Decart and Etched are now running four distinct, well-funded, publicly demonstrated versions of the same underlying bet, that a generative model can stand in for a simulation, and each is betting on a different domain to prove it first. For more on the video generation techniques underneath systems like this, our breakdown of speculative decoding and faster inference covers the broader family of tricks that make real-time generative systems fast enough to feel usable, and our explainer on context engineering covers the reasoning-layer side of the same two-system split Solaris uses between its language model and its world model.