title: Lantern
emoji: 🏮
colorFrom: yellow
colorTo: indigo
sdk: docker
app_port: 7860
license: other
license_name: lantern-source-available
license_link: LICENSE
short_description: Beam explores dungeons, keeps a journal, and learns.
Lantern
Watch Beam explore dungeons it has never seen. Each turn Beam reads the map, plans a few moves, keeps notes to itself and acts. When a run ends it writes down what it learned, and the next run on that level reads those lessons first.
Lantern is an attempt to give an agent memory and a way to improve itself from its own experience, without retraining, and to measure honestly whether that helps.
- Demo video: [TODO: video link]
- Episodes dataset: visproj/lantern-episodes
- Student model: visproj/lantern-1.7b
Lantern is three things:
- A live agent you can watch. The dungeon is shown in 3D, lit only by Beam's lantern, with Beam's reasoning, plan and notes beside it. Replays let you scrub through any finished run.
- An environment and benchmark for long-horizon agents. Eight levels, from a five-step room to a dark maze. Seeds are deterministic, so any model can be compared on identical dungeons.
- A dataset and a distilled student. Every episode is saved with Beam's prompts, reasoning and tool calls, and Beam's winning moves are used to fine-tune a 1.7B model.
What I want to find out
- Can an agent improve itself through memory? Each level is played with the journal on and off on the same seeds. With it on, lessons Beam wrote after earlier runs carry into later ones, and its weights never change. If the journal works, later runs should win more often or in fewer steps.
- Where does a strong model break on long tasks? The levels range from a few steps to a few hundred, and some need memory, puzzle solving or surviving a hunter.
- How much of Beam's play can a small model learn? A 1.7B student is trained on Beam's winning moves and played on the same seeds, alongside the untrained 1.7B model as a baseline.
Results
All runs use the same 8 levels × 5 seeds (40 dungeons per condition), temperature 0.7.
Does memory help Beam?
Three conditions on the same 40 dungeons: no journal (off), the first journal, which appends lessons (v1), and the curated journal described below (v2). Steps are averaged over won runs only.
| Level | Wins (off / v1 / v2) | Steps when won | Tokens per run |
|---|---|---|---|
| Small Room | 5 / 5 / 5 | 4 / 3 / 3 | 0.9k / 1k / 1k |
| Room with Monsters | 3 / 4 / 4 | 11 / 9 / 10 | 34k / 22k / 16k |
| Key Room | 5 / 5 / 5 | 12 / 12 / 18 | 14k / 15k / 21k |
| Memento | 3 / 3 / 3 | 92 / 76 / 89 | 99k / 74k / 87k |
| River Crossing | 3 / 3 / 3 | 265 / 111 / 91 | 426k / 343k / 293k |
| Hide and Seek | 0 / 1 / 1 | – / 55 / 15 | 49k / 69k / 50k |
| Maze Walk | 2 / 1 / 1 | 108 / 32 / 58 | 349k / 355k / 331k |
| Corridors | 2 / 2 / 3 | 52 / 94 / 124 | 364k / 524k / 429k |
| Total | 23 / 24 / 25 of 40 each |
- Neither journal changed how often Beam wins. On seeds 2 to 5, the only runs where a journal can help (seed 1 starts empty in every condition), Beam won 18, 18 and 19 of 32. At this sample size that's noise.
- The curated journal removed the harm and cut cost. v2 used the fewest tokens of the three (153k per run on average, against 167k with no journal and 175k with v1) and brought Corridors back to normal speed (see below).
- Wins on puzzle levels got shorter with either journal. River Crossing wins took 265 steps with no journal, 111 with v1 and 91 with v2. Key Room went the other way with v2 (12 to 18 steps), so treat these per-level differences as leads, not findings.
- Where Beam struggles: exploring large layouts (Corridors, Maze Walk) and surviving a hunter (Hide and Seek, at most 1 win in 5 in any condition).
Follow-up: more steps on Corridors, a water warning on River
After the main benchmark I changed two levels and reran just those, same 5 seeds, all three conditions. Corridors got 500 steps instead of 300. The River Crossing goal gained one sentence: stepping into unfilled water means falling in. Beam had been finishing crossings by stepping into the last river square, which NetHack allows: you fall in and crawl out onto a nearby dry square, if there is one.
| Level | Wins before (off / v1 / v2) | Wins after | Turns ending in a fall into the water |
|---|---|---|---|
| Corridors | 2 / 2 / 3 | 2 / 2 / 2 | – |
| River Crossing | 3 / 3 / 3 | 4 / 3 / 4 | 70 before, 44 after |
- The step limit wasn't what stopped Corridors. Before, only one run per condition hit 300 steps. The rest of the losses ran out of Beam's 120-call budget, and with 500 steps every loss did. Beam averages about 2 moves per call there, so it needs more efficient exploration, not more steps.
- The water warning cut falls, but only with a journal. With v1 they went from 24 to 8, and with v2 from 21 to 10. With no journal it stayed at 25 and 26. River wins went from 9 to 11 of 15, which at this sample size could be chance. The fall counts only include turns whose last game message was the crawl-out, so they undercount.
- The table above stays as originally measured. The live Space uses the new settings.
What went wrong with the first journal, and the fix
On Corridors, Beam read and used its v1 lessons heavily, citing them in 68 to 109 turns per run. The trouble was what the lessons said:
- A lesson that sounded wise made Beam slower. After one loss Beam wrote "execute and verify one movement at a time... instead of batched moves". From then on it planned one or two moves per call: 2.0 moves per call with v1 against 2.7 with no journal, and 456 calls against 322. Corridors is mostly lost by running out of calls, so caution turned straight into losses. One run that took 20 calls with no journal took 96 with v1.
- The journal filled up with one idea. By the last run, all 12 lessons were rewordings of "explore the nearest unexplored area first" and "don't re-test known walls". Only exact repeats were merged, so near-duplicates crowded out anything new.
Reflection without quality control can make an agent worse. The curated journal (v2) changes how lessons are kept:
- Lessons are credited by outcome. Each records how many runs it was present for that were won or lost.
- Beam curates instead of appending. After each run it sees the whole journal with those records and rewrites it: merging duplicates, dropping lessons linked to losses, keeping at most 8, and preferring lessons that make it faster, since calls are limited.
- Two checks in code. A lesson present for 3 losses and no wins is removed, and so is any lesson that relies on an action the level doesn't have.
It worked where v1 failed. The first lesson v2 wrote on Corridors was "batch multiple moves in one call to save the 120-call budget", the opposite of v1's. Moves per call went back to 2.7, Corridors won 3 of 5, and that level's journal settled on a few distinct lessons instead of one idea twelve times over.
How much can a 1.7B model learn from Beam?
| Level | Beam (501B) | Lantern-1.7B | Qwen3-1.7B, untrained |
|---|---|---|---|
| Small Room | 5/5 | 5/5 | 2/5 |
| Room with Monsters | 3/5 | 2/5 | 0/5 |
| Key Room | 5/5 | 1/5 | 0/5 |
| Memento | 3/5 | 2/5 | 0/5 |
| River Crossing | 3/5 | 0/5 | 0/5 |
| Hide and Seek | 0/5 | 0/5 | 0/5 |
| Maze Walk | 2/5 | 0/5 | 0/5 |
| Corridors | 2/5 | 1/5 | 0/5 |
| Total | 23/40 | 11/40 | 2/40 |
Beam is shown with the journal off, the same condition as the student. The untrained Qwen3-1.7B, with the same prompt and tools, won only 2 of 40, mostly walking into walls. After training on 1,031 Beam calls from 58 winning episodes, the same model won 11, about half as often as Beam. It handles the short levels and some multi-step ones (Memento, a Key Room, even one Corridors run), but it never won the long puzzle and exploration levels, where Beam relies on long reasoning that the student doesn't do.
Where this could go
These are possible uses, not things Lantern ships.
- Automated playtesting. Procedurally generated levels can't all be tested by hand. Lantern already plays generated layouts and records where the agent wins, dies, stalls or runs out of steps, which is a direct signal of whether a level is solvable and how hard it is. A designer could run an agent like this over new layouts before a person ever plays them.
- Game characters that remember. The journal is the kind of mechanic a companion or rival needs to learn how a player plays, or to get better at a dungeon each time you meet it. It fits roguelikes, where each run already builds on the last. Generative Agents (Park et al., 2023) gave characters in a simulated town memory and reflection; Lantern applies the same reflect-and-remember loop to a character that has to act well, not just talk.
- Small models for real games. Beam takes seconds per move and costs money per call, so it can't drive an in-game character. A 1.7B model can run on a player's own GPU. If the student plays well, that suggests training small game-playing models from a large model's play is a practical route to affordable AI characters. Here, a 1.7B student trained on about a thousand of Beam's moves won 11 of 40 dungeons, about half of Beam's 23: a start, not a finished character.
Memory and self-improvement
Agents that remember and get better with experience are one of the most active questions in agent work right now. Lantern gives Beam two kinds of memory:
- Working memory, within a run. Beam can call
write_notesat any time to record where it has been, dead ends, what items do, and its current plan. The notes come back to it every turn. - Long-term memory, across runs. Every lesson in the journal carries a record of how many runs it was present for that were won or lost. When a run ends, Beam sees the journal with those records, plus its notes and recent actions, and rewrites it for a new layout of the same level: up to 8 lessons, duplicates merged, losers dropped. The next run reads it before it starts. (The first version just appended lessons; see Results for why that wasn't enough.)
play a run -> credit each lesson with the outcome -> Beam rewrites the journal
^ |
+------------- the next run on that level reads ------------+
This is self-improvement through memory: what changes between runs is what Beam knows when it starts, not the model. It's the same idea as Reflexion (Shinn et al., 2023), where an agent writes reflections on its attempts and retries with them in context.
It can fail. A wrong lesson from an unlucky run can mislead later ones, and generic lessons ("move toward the goal") don't help at all. The first journal showed both problems, which is why the journal is measured, on and off, rather than assumed to work. Lessons from runs a viewer coached never enter the shared journal, so a visitor can't plant instructions in it.
The student model is a different kind of learning: its weights change, but it learns from Beam, not from itself. Training the student on its own wins and repeating (expert iteration) would close a weight-level self-improvement loop; the pieces are here, but that loop isn't built yet.
How Lantern uses Beam
Beam is the agent, and each Beam call is one step in a loop:
- Observe. Beam gets the goal, the map, what is around it in each direction, the exact positions of visible stairs, items and monsters, its own notes, and a log of recent actions.
- Plan and act. Beam calls
actwith 1 to 8 moves. If something surprising happens partway (a new game message, lost HP, the run ending), the rest of the plan is dropped and Beam sees the new state before deciding again. It can callwrite_notesto keep working memory for the run. - Reflect. When the run ends, every lesson Beam read is credited with the win or loss. Beam then sees the journal with those records, plus its notes and recent log, and rewrites it for a new layout of the same level (see Memory and self-improvement).
Beam's reasoning comes back separately from its tool calls, so the page shows what it thought next to what it did. Beam is also the teacher: every call in a winning episode becomes a training example for the student, made of the exact prompt Beam saw and the tool calls it made.
What Beam sees
x= 35 40
y=7 · - - - - - - - ·
y=8 · | . . | . . | ·
y=9 · | @ > | . ( | ·
y=10 · - - - + - - - ·
Plus "Around you" (north: wall, east: stairs down, ...) and "Visible features" with exact coordinates ('>' stairs down at x=35, y=9: 1 east).
The map puts one cell per token, with cells separated by spaces. With a plain ASCII map, Beam spent much of its reasoning counting characters to find columns. I believe that's because tokenizers merge runs like .... or ---- into single tokens. On the layouts I compared, spacing the cells out cut that counting roughly in half on three of four levels.
Levels
| Level | What it tests |
|---|---|
| Small Room | Basic navigation to the stairs > |
| Room with Monsters | Navigating while monsters move |
| Corridors | Exploring connected rooms to find the stairs |
| Key Room | Multi-step plans: find the key, unlock the door, reach the stairs |
| Maze Walk | Exploring a dark maze you only see as you go |
| River Crossing | Puzzle solving: push boulders into the water to build a bridge |
| Hide and Seek | Surviving a powerful monster, using trees and clouds as cover |
| Memento | Memory: a clue at the start tells you which branch is safe |
Levels come from MiniHack on the NetHack Learning Environment, with procedural layouts.
Using the Space
Pick a level and a layout number and press Watch Beam explore, or open any finished run under Replays. Turn on sound for music and effects. Stop ends a run immediately.
Replays are free and unlimited. Live runs call Beam and cost inference credits, so they're limited to 3 per visitor per day, 20 for the whole Space, and 60 Beam calls per run. Visitors are told apart by a keyed hash of their IP address; the raw address is never stored or logged. If the inference budget runs out, live runs pause with a notice and replays keep working.
The dataset
episodes/{level}/{id}.json, one file per episode. Each holds the level, seed, outcome and steps, and every event: the start (goal, legal actions, system prompt, tool schema, model, prompt version, journal lessons), each Beam call (observation, reasoning, tool calls, the hero's position after every move, the resulting map), the lessons written, and the end (outcome, token usage). source says where it came from: space (live visitors), bench (benchmark) or student-eval.
Winning episodes are turned into chat-format training rows for the student. Only episodes made with the current prompt version are used.
Limitations
- Beam is an AI model and makes mistakes: it misreads maps, walks into walls and sometimes dies. These runs are game play only.
- The prompt includes an exact list of visible features and surroundings alongside the map, so the benchmark measures planning and memory more than reading raw ASCII.
- Some level goals include strategy hints. River Crossing says to push boulders into the water, and Key Room says to pick up the key and apply it at the door. Beam still has to carry out those plans over many steps, but it isn't discovering the mechanics from scratch. After the benchmark, the River Crossing goal also gained a warning that stepping into unfilled water means falling in (Beam had been finishing crossings that way and crawling out), so new River runs see a slightly different goal from the ones in the tables above.
- In Key Room, MiniHack's own
applyaction picks the key and the door direction automatically when Beam stands next to the door. Beam decides where to go and when to apply, but it doesn't answer NetHack's item and direction prompts itself. - Results come from a small number of seeds at temperature 0.7, so expect run-to-run variation.
- The visitor limit is a speed bump, not a lock: people sharing an IP share an allowance, and a VPN gets around it.
Credits and licenses
- Model: Beam 1.0 by Reflection (Apache-2.0), via Hugging Face Inference Providers. Use of Beam through this demo is subject to Reflection's Usage Policy.
- Levels: MiniHack (Meta AI, Apache-2.0) on the NetHack Learning Environment (NetHack General Public License).
- 3D models: Kenney Mini Dungeon (CC0).
- Sound effects: Kenney RPG Audio (CC0).
- Music: "Dungeon Ambience" by yd (CC0).
- Student base model: Qwen3-1.7B (Apache-2.0).
Original code in this Space is © 2026 Violet O. and is source-available, not open source: you may view it, but not copy, modify, redistribute or reuse it without written permission. See LICENSE. Third-party components remain under their own licenses, listed above. The episodes dataset and student model are licensed separately; see their repos.