Cue, product demos built as code.

Constraint

To make a demo video of a software product, you have to show it in motion: a specific interface, with its real data, doing a real thing. Producing that moving image is the task.

A frontier model cannot do it. Asked to generate the video, it returns a plausible interface rather than the actual one, because generation samples what is likely and a particular product's interface is a specific fact the model was never given. The output resembles the product and is not it.

This is not a problem more training solves. It is a scope-of-the-model limit, the kind the applied layer is built to close.

Premise

Working with a frontier model is an engineering problem before it is a capability one. The result comes from routing the task toward where the model is actually strong, not toward where it seems like it should be.

These models are strongest at code, and at the web in particular. It is the medium they are trained on and the thing they write best. A faithful moving picture of a specific interface is the opposite kind of output: asked to generate it, the model returns something plausible rather than the actual product, because the exact layout, label, number, and logo are specific facts and not likely ones.

A product demo can be expressed that way. It is a program: a webpage that reproduces the interface and plays itself on a timeline. The model is not asked to imagine the product. It is asked to write the page that reproduces it, which is the kind of work it does best.

Cue is that one move, applied. Not a video generator or editor. A program that renders your product's interface.

First principles

There are two ways to make a video with a model. Generate the pixels, or render them.

Generation fights the limit just described: it cannot hold an interface coherent, drifting frame to frame and approximating what it was not given. Rendering routes around it. The model writes a program, and the program draws the exact pixels, the same way every time. The point is not that code is deterministic. It is that code is where the capability is.

What follows is structural rather than marketed. The demo is pixel-true to your real interface, deterministic, and editable like software.

Why not generated video

The failure is structural, not a quality gap that a larger model closes. A generative model places each pixel by likelihood. A region it has seen a million times, sky, faces, streets, comes out clean. A region defined by exact specification, a layout, a number, a label, a logo, comes out approximated.

For an interface, the approximation is the whole problem. Text renders as glyph-like noise, panels reflow between frames, a logo warps as the view moves. The closer a subject sits to something the viewer already knows precisely, the more visible the gap becomes. Nobody knows a product's interface more precisely than the people who use it.

Mechanism

Cue produces a self-playing webpage. It reproduces your interface in code and performs a scripted sequence on a timeline, then records and renders it into the finished video.

The fidelity rests on one rule: nothing is drawn that does not trace to a real screenshot of your product. Reference comes before generation, never after.

Because the interface is code, it is exact, repeatable, and editable. A wrong label is a one-line change, not a re-render and another roll of the dice.

In practice

Titan Network, one of the lab's clients, ships an agentic product to its sellers: live analysis, the agent's reasoning, and the dashboards a user acts on. To launch it, that interface had to be shown in motion.

The demo below is the one Cue produced. The interface is reproduced in code and walks through itself on a single timeline: data arrives, a view changes, the agent acts. No footage was filmed and no animator was involved.

It is the same artefact this page describes, applied to a shipped product rather than the lab's own. The walkthrough is deterministic and editable: a changed label or a new screen is a code change, not a reshoot.

Boundaries

Cue does one thing: a precise demo of a real product interface. It needs real references, so a product that does not exist yet has nothing to match against, and the discipline is strict: nothing is drawn unless it traces to a real screenshot.

The nearest approach is video-as-code, a video composed by hand in a framework like React. Cue differs in medium. It builds the demo as a webpage traced to real screenshots, the form these models write best, rather than a composition assembled by hand. The price of that precision is range: Cue renders one exact demo of a real interface, not arbitrary motion graphics.

It is also distinct from generating video about a topic. The lab's other release, T2V, generates the pixels rather than rendering them. The two answer different questions. T2V makes a video about an idea. Cue makes a video of your software.

Where it came from

Cue was built for the lab's own launches. The releases the lab has published were each announced with a demo Cue produced, including Recall and Grove, alongside the field demos the lab runs for its client deployments.

The page where you request access to Cue is itself a Cue demo of Cue. The tool and its proof are the same artefact. We are releasing it because the same problem recurs wherever software has to be shown and cannot easily be filmed.