Boulder Research · Interactive world models

Know what
happens next.

We build AI that predicts how a world responds to action, then checks every prediction against a real simulation engine. It's efficient enough to run on a single GPU, not a datacenter.

Move your cursor to push the boulder
01 / The ideaScroll to decode
How we describe it to engineers

We combine learned models1, simulation engines2, and low-level systems optimization3 to make interactive environment modeling4 practical on constrained hardware5.

01 · Learned models
Intuition.

A neural network that has watched a world long enough to guess its next moment, quickly. Like any intuition, it's fast and it's sometimes wrong, and the errors build on each other.

02 · Simulation engines
The referee.

Game engines and physics simulators know the true state of the world: where everything is and what's possible. We let the model imagine, then check it against the engine and snap it back when it wanders.

03 · Low-level systems optimization
Making it fit.

Long predictions eat memory. A 14B-parameter model can generate over 200 GB of attention cache per minute. We write custom kernels and page that memory across GPU, RAM, and disk, much like an operating system does.

04 · Interactive environment modeling
“If I do this, what happens?”

Not generating a pretty video. Answering a question about cause and effect: given this world and this action, what comes next, and what comes after that?

05 · Constrained hardware
A desk, not a datacenter.

Our first target is one 16 GB GPU. We adapt open models with small add-ons instead of spending thousands of GPU-days training from scratch.

In one line
AI that predicts what happens next, checked against reality, cheap enough to use.

That's the whole company. Everything below is how we do it, and where we're pointing it first.

02 / The problemLive simulation

Imagination drifts.
Ground truth doesn't.

Ask a pure video model to imagine a game for a minute and the world slowly forgets itself. Platforms wander, blocks melt, and the player sinks through the floor. We let the model imagine, then re-anchor it to the engine's real state before small errors compound into fiction.

Pure generationt+00.0s
State errorUnbounded
Grounded · re-anchored every 1.0st+00.0s
State errorBounded
03 / The systemThree parts · one loop

Hybrid. Grounded.
Efficient.

Part 01 · Learned world model

Imagine

the intuition

We start from open pretrained checkpoints and attach compact task adapters, so one base model can learn many environments without retraining from zero.

Adapter84 MB on a 2.6 GB base
Part 02 · Simulation grounding

Check

the referee

The source engine is the oracle. Predictions are periodically re-anchored to true state, so outputs stay physically consistent and every result is auditable.

ErrorBounded, not compounding
Part 03 · Systems runtime

Fit

the engineering

Rollouts generate memory faster than a GPU can hold it. Our runtime streams state across GPU, host RAM, and NVMe, and recalls it before it's needed.

Cache~0.73 MB / token @ 14B
04 / First productAutonomous game testing

Break games
before players do.

Our first job for this technology: hand us a Godot build and autonomous agents explore it, level by level, edge case by edge case. You get back failures you can reproduce, each with the action trace, the state snapshot, and the video.

PrototypeAgent completing a full level · 3× speed
Finding #0007Stuck state
Buildplatformer_demo @ a91f2c
EngineGodot 4.x
Trace1,204 actions · seed 0x5EED
Att=00:41.7 · pos (1840, 212)
Repro5 / 5 replays
Evidenceclip.mp4 · state.json
Diffnew since build 9e10b4
Illustrative report format · not a customer finding
Why games

Games are complete worlds with rules, physics, and failure states, and they ship on deadlines with too little testing.

Why Godot

It's open source, so we can instrument it all the way down. The ecosystem is growing fast and its testing tools haven't caught up.

Why it compounds

Every run produces action, state, and failure data that makes the next model better at finding what breaks.

05 / EfficiencyDeployment targets

A desk,
not a datacenter.

Tier 0

Local

One 16 GB GPU · 1.3B model · 480p at 20 FPS (target)
Tier 1

Workstation cluster

112 GB aggregate memory · larger models, longer horizons
Tier 2

Cloud

H100 / H200 / GB200 · scale when customers need it
84MB

Task adapter that specializes a shared 2.6 GB base model. No duplicated weights per task.

4,160

H200 GPU-days that published benchmarks cite for pretraining from scratch. We adapt instead.

3tiers

Memory hierarchy (GPU → RAM → NVMe) managed continuously during long rollouts.

16GB

The first hardware target. If it runs here, it runs anywhere.

06 / RoadmapPlans labeled as plans

Start with games.
Model any world
that answers back.

  • Now
    Game testingAutonomous exploration and bug discovery for Godot studios, delivered as a managed service.
  • Next
    Testing product & APIA Godot plugin and CI workflow, then narrow world-model APIs for rollout and state prediction.
  • Later
    Robotics & sim-to-realThe same hybrid loop for robot training, where the simulator is the referee.
  • Exploring
    Industrial & sensor systemsAnomaly detection and digital twins for any system whose state changes in response to action.
07 / TeamBoulder, CO · Boston, MA

Built by people who make
models fit.

Adhitya Mohan

ML systems & robotics
  • Reverse-engineered the Rockchip RK3588 NPU to deploy a vision-language model the vendor toolchain couldn't compile (SHARD, EuroMLSys '26).
  • Ported all 130 LIBERO manipulation tasks to MuJoCo Warp: thousands of parallel robot environments on one $700 GPU.
  • Sim-to-real RL with AMD Research & Advanced Development. MS CS, CU Boulder (BASIL lab).

Chris Kellogg

AI product & infrastructure
  • AI-native full-stack architect who takes concepts to running, cloud-hosted systems without handoffs.
  • Built and runs Miniloader, a local-AI platform for running agents and models on your own hardware.
  • Works on the Mario World and Godot agent demonstrations and the path from prototype to product.

Help us find out
what happens next.

We're looking for Godot studios to be design partners, and for investors who want the technical brief and the draft paper.

Boulder Research