Loop House

• 

  Landing page

Inspiration

Time loop stories only work because of one thing: the world resets and the person doesn't. Groundhog Day, Outer Wilds, Edge of Tomorrow — the entire feeling comes from being the only one who remembers.

That's also, almost exactly, the thing a world model can do and a video model can't. A video model decides everything up front and hands you a clip. A world model generates a place that keeps running and keeps coming back. So the story structure and the technology turned out to be the same shape, and I wanted to build the thing that sat at the intersection.

What it does

You wake up in a building. It resets every 60 seconds. Somewhere in it there is a key — find it and you get out.

The building isn't built. There's no level, no 3D model, no assets, no map. It's generated live by a world model as you move through it, and it regenerates from the same anchor frame each loop, so it comes back as recognisably the same place. Nothing in the world knows you've been there before.

You're the only thing carrying memory across the reset. The house resets. You don't.

How we built it

The core architectural decision was to split ownership:

The world model owns the world. Reactor generates the building, the rooms and the atmosphere, and responds to movement input in real time. [CHECK: name the model you ended up using] My code owns what's true. A small state machine outside the model tracks position, loop number, seconds remaining and whether the key has been found.

That split is the reason it runs at all. World models generate scenes; they don't reliably track discrete objects, so asking the model to remember where the key is would have been a coin flip in front of a judge. Keeping game state in application code and letting the model do what it's actually good at made the whole thing demoable.

Persistence across the reset is handled with a fixed anchor frame — each loop seeds from the same image, which is what makes the building recognisable cycle after cycle rather than a new building every time.

Built on Next.js and TypeScript, deployed on Vercel. The Reactor key stays server-side; a route handler mints a short-lived session token and the browser connects with that.

Challenges we ran into

Persistence was the load-bearing unknown. The entire concept rests on the building coming back as the same building. That isn't something a world model gives you for free, and if it hadn't worked the idea would have had to change shape completely. The anchor frame approach is what made it hold.

World models aren't game engines, and the first instinct — let the model handle the house and the objects in it — is the wrong one. Rebuilding around the state-machine split cost time but was the difference between a demo and a gamble.

Latency and streaming. World models bill and stream per session-second while a GPU is held, so performance tuning is a live constraint, not a polish task. [CHECK: mention what you actually did — resolution drop, session cleanup, model choice]

Building solo against a hard 17:30 cutoff meant cutting continuously. Several ideas that would have made it richer — [CHECK: loop-to-loop decay? talking avatars? sound?] — were scoped out in favour of making one complete loop work reliably.

Accomplishments that we're proud of

Shipping a playable, deployed build solo in a single day, in a category where most teams had three or four people.

More than that: getting to a concept where the model is genuinely load-bearing. The test I kept applying was "could this have been pre-rendered?" — and a time loop can't be, because the whole point is a place that persists through a reset while you keep the memory. The story isn't decorated with a world model. It doesn't exist without one.

What we learned

The big one: don't ask the model to hold state. Let it generate the world, and keep the truth in your own code. That's not a workaround, it's the right architecture for this class of model, and I'd start there on anything I build next.

Also that the constraint is a design tool. Once I accepted that the model wouldn't remember anything between loops, that limitation became the premise — the house forgets, you don't. The most interesting part of the story came directly from the thing the technology couldn't do.

What's next for Loop House

Loops that diverge. Right now the reset returns you to the same conditions. The version I want has the building shift each cycle — decaying, changing light, doors that were locked standing open — so the dread compounds and the loop count becomes something you feel rather than read.

A voice in the house. A previous occupant, rendered with VEED Fabric, who appears each loop and says something different — helpful at first, tired of explaining by loop four, and by loop seven telling you she's been here longer than you have. The loop counter becomes a character arc.

More building. More rooms, more reasons to go into them, and a key that's genuinely hard to find rather than findable by exhaustion.

Mobile. The premise works even better on a phone — being trapped somewhere you hold in your hand.

Built With

• claude
• claude-code
• css
• git
• html
• javascript
• next.js
• node.js
• react
• reactor
• tailwindcss
• typescript
• vercel
• world-models