Inspiration
Firefighter training has a gap in the middle. You can read a textbook on size-up, and you can do a live burn in a training tower, but the live burn costs thousands of dollars, needs a crew and a safety officer, and most departments get a handful per year. The thing you actually need to rehearse - standing in front of a building that is getting worse every second and picking one action out of five - is the part you get the fewest repetitions of.
Every digital tool we looked at solves this with a branching tree. Someone writes twelve scenarios, films or renders them, and the trainee walks through paths that were decided months ago. Trainees learn the tree, not the fire.
Real-time world models change what's possible here. If the building can be generated as you watch it, the scenario doesn't have to be written in advance, and it doesn't have to stop while you think.
What it does
Ember Command drops you in front of a burning structure and gives you five options and thirty seconds.
A Simulation Manager (Claude) writes the opening scene as a prompt. Gemini Nano Banana Pro renders it as a still, and that still anchors a live world model session on Reactor, so the first frame you see is the scene the story actually called for rather than whatever the video model felt like producing. From there the video never stops. Pick "force the front door" and the stream morphs into the door giving way and the smoke changing colour. Pick nothing and the timer runs out, and that's an input too: the Simulation Manager pushes the fire forward without you.
You set the length up front, in minutes, and the Simulation Manager paces the scenario to fit - a five-minute run is one deteriorating room, a twenty-minute run has a rescue, a water supply problem, and a decision about whether to keep crews inside.
Quick-decision mode is a toggle. On, you're graded on speed as well as judgement. Off, you can take as long as you want and only the calls themselves count. We split these deliberately. A probationary firefighter learning the decision space and a veteran drilling reaction time need different clocks.
The whole run is timestamped: every option that was on the table, which one you took, and how long you sat there. At the end that transcript goes back to the Simulation Manager for a debrief that can say things like "you ventilated before confirming the seat of the fire, three times, all in the first four minutes."
How we built it
The system is three models with a state machine in the middle.
Claude runs as the Simulation Manager. It holds the scenario state as structured text - fire location and stage, victim status, crew position, water supply, elapsed time - and it owns the story. Each turn it emits two things: five options for the trainee, and a short prompt describing what the world should look like now.
Gemini Nano Banana Pro generates the establishing image once, at session start.
Reactor hosts the world model. We use Visko Orbis Stable, which takes the Nano Banana still as an image-anchored opening and then accepts a new prompt per chunk that morphs the scene without cutting. Its bounded memory is the reason a fifteen-minute session stays the same building; earlier tests with clip-based generation gave us a new front door every time the prompt changed. The Reactor SDK handles the WebRTC session, and the frontend just plays the stream and renders the option buttons over it.
The history log is the part we care most about. Every turn appends a record with the timestamp, the world state at that moment, the five options offered, the option chosen, and the decision latency in milliseconds. The evaluation prompt at the end reads that log, not the video.
Challenges we ran into
The video will happily show a fire that behaves nothing like a fire. Orbis steers generation toward plausible motion, but no video model reasons about Ember Command conditions or flow paths. Early on our evaluation was implicitly grading the trainee against what the stream rendered, which meant a good decision could get marked down because the model decided the smoke should clear. We rebuilt it so the Simulation Manager's text state is authoritative and the video is a visual layer over it. If they disagree, the state wins and the next prompt corrects the picture.
Prompt drift was the other big one. Firefighting vocabulary and video-model vocabulary don't overlap. "Vertical ventilation" produces nothing useful. We ended up with a translation layer: the Simulation Manager emits an operational event, and a small prompt template turns it into visual language the model can render - smoke colour, where flame is showing, what the crew is doing on screen.
Timing the morph against the clock took longer than expected. Prompt changes land on the next chunk, so there's a beat between the trainee committing and the world reacting. Too short and the choice feels ignored; too long and the thirty seconds feel unfair. We pin the option buttons to the chunk boundary now so the beat is consistent instead of random.
Cost discipline, too. Reactor bills by the second for as long as the session is held. An open tab burns money. We added an idle cutoff after the first time we left a session running through lunch.
Accomplishments that we're proud of
The no-decision path. Timing out isn't a skipped turn, it generates a worse situation, and you watch it get worse. As far as we know nothing else in training software does this, and it only works because the underlying model is a live stream rather than a clip generator. Indecision having a visible cost is the single most useful thing in the build.
The debrief also turned out better than we expected. Because the log holds the options that weren't taken, Claude can talk about the decision space and not just the outcome - what a trainee passed over, repeatedly, without noticing.
What we learned
World models are a rendering target, not a simulator. We spent the first day treating Orbis like a physics engine and the rest of the hackathon undoing that. The useful mental model: the world model is the screen, your state machine is the game.
Also, image-anchored openings matter more than we assumed. Starting from a Nano Banana still instead of a text prompt gave us control over the scenario that text alone never did, and it made scenario authoring reproducible - same still, same starting conditions, comparable runs across trainees.
And thirty seconds is a long time. We assumed it would feel brutal. Watching people use it, most decisions land around eight seconds, and the ones that run to twenty are the interesting ones.
What's next for Ember Command
Real firefighters, then real feedback. Nothing here has been validated against NFPA guidance or reviewed by an instructor, and until that happens this is a prototype, not a training tool. We want a fire service training officer to tear apart the scoring rubric.
Beyond that: multi-crew sessions where two trainees run interior and exterior on the same scene and see each other's consequences; Helios as an alternate backend for its rewind buffer, so the debrief can replay a decision point and show the branch you didn't take; and scenario packs for specific structure types - high-rise, wildland interface, vehicle fire - with the Simulation Manager constrained to the tactics that apply.
Built With
- reactor
Log in or sign up for Devpost to join the conversation.