live game state → agent context

Let AI see the game state.

loot.moe turns runtime game memory into structured, addressable state an AI companion can understand. Not pixels. Not copied stats. The live game underneath.

checking Node relay…

The companion gets state, not guesses.

Browser emulation can expose semantic runtime memory. loot.moe relays that state so the game can run on one device while your AI companion lives on another.

HP / SPinventoryequipmentgoldstatsCP / APabilitiesbindings
first game

Soma Bringer

The current semantic-runtime proof already decodes a meaningful slice of player state directly from emulated Nintendo DS main RAM.

cross-device

Play here. Ask there.

A game session can publish state to loot.moe. A companion surface can retrieve the same session without sharing a screen.

future

More games, same grammar.

Each game gets an adapter. The companion-facing layer stays stable: live state, latest loot, build, equipment and events.

privacy

Your ROM stays yours.

This stand-in does not include or host ROM files or copyrighted game assets. The product layer is the runtime state bridge.

A tiny pipe with a lot on the other end.

For the first real version, loot.moe does not need to call an LLM itself. Its job can be simpler and cleaner: publish the live semantic state securely, then let ChatGPT or another agent read it through a connector.

browser emulator ↓ semantic RAM adapter ↓ POST /api/v1/soma-bringer/state ↓ loot.moe live session ↓ ChatGPT connector / agent ↓ “what did I just find?”

The API already has a shape.

This stand-in ships with read endpoints for the current state, latest loot and build, plus a state-ingest endpoint for the browser runtime. The OpenAPI document is generated by the app at /openapi.json.

demo sessionSoma Bringer
loading…