A 4B model clears DOOM's episode finale on a home GPU

A 4-billion-parameter language model, running on one RTX 3090 under my desk, plays DOOM in real time and chooses every move itself. It clears E1M8, the finale of episode one with two Barons of Hell, on 8 of 20 seeds it had never seen, about as often as the hand-written player it learned from clears it at the same reaction speed.

The E1M8 run ends at 1% health on purpose: the level's exit teleports the player into a room of monsters, and the episode ends when health drops below 11. The second clip is E1M2, a longer map with keys, switches and doors. In both, the panel on the right shows the command the model chose, how confident it was, and the text it read before choosing. The code, the data pipeline and every number in this piece are public on GitHub: github.com/inosov9-byte/doom-jev.

Why a game

The question behind the experiment comes from work: how much of a company's routine decision-making can a small model take on, running on hardware anyone can buy? Most AI use in companies today is large hosted models producing text, while many daily decisions have a different shape. They are narrow and repeated, the right answer is one of a short list, and an answer that arrives late is worth less or nothing:

• Finance: pay this invoice, hold it, or query the supplier.
• Supply Chain: which carrier takes this shipment, and whether to expedite it.
• Commercial: which of five offers to show this customer now.
• HR: which team answers this employee question.

DOOM is a strict test bench for decisions of that shape. The game runs at 35 tics per second and never waits, a bad call shows up on screen within a second, and the outcome is binary: the player reaches the exit or dies.

The experiment tested the three things a business case depends on:

• Cost. Each decision is one pass of a local model, with no text generated and no per-call fee, so a decision costs electricity.
• Speed. About 90 ms per decision, four decisions per second, on a consumer GPU from 2020. Nothing leaves the machine, which matters as much as speed once the decision touches salaries, invoices or customer data.
• Adaptability. The model is a general-purpose 4B language model that knew nothing about DOOM. A small adapter, trained in about an hour per round on the same card, turned it into a player. The scoring method was built for picking labels from text, and the same code would rank options for an invoice or a ticket.

How it plays

The model never sees pixels and never writes text. Code describes the game in a short paragraph of facts, the model reads it next to a fixed menu of 26 commands, and the command it rates highest is played. Each decision is one forward pass that scores the menu, a method published by Featherless, an AI inference provider, as Simple Jev.

Part	Does	Decides?
Perception	turns game state into a short text: enemies with distance and angle, walls, doors, lifts, ledges, barrels, the route to the next goal, shotgun reload state, incoming fireballs, cover	no
Jev	Qwen3.5-4B + LoRA reads the text and picks one of 26 commands (move, strafe, turn 5-90 degrees, fire, turn-and-fire, use) in ~90 ms	yes, every command
Executor	plays the chosen command as a fixed key pattern until the next one arrives	no

The game never pauses for the model: if it hesitates, the imp keeps throwing.

How it got here: one weekend, four stages

The project ran from Friday evening, 17 October, to Monday morning, 19 October 2026: 69 commits in a public repository. The code was written with Claude Code; my part was the rules of the experiment, reading the runs, and deciding what to change next.

1. Friday evening: the rule that the model makes every call. The starting point was a Featherless demo of Jev playing DOOM in a browser. Reading its source showed a scripted route follower doing the navigation, doors and exit, with the model choosing only combat actions. That is a bot with a model attached. The rule here was stricter: perception states what is true ("baron 414 away, 6 deg right; fireball incoming in 0.6 s") and the model decides what to do with it. The route compass is a sensor, like an automap, and the model is free to ignore it.

2. Friday night: on a laptop, every language model loses. The first round ran on a laptop with an integrated AMD GPU. Hosted models of 26B and 35B parameters, Claude Haiku 5.5 and a local 0.8B model all played E1M1, the first level, and none of them finished it. Two findings came out of that round. A quiz of 60 single game situations did not predict play: Haiku scored highest on the quiz and got stuck at the same corridor corner in every game. And reaction time mattered as much as judgement: the hand-written rule player cleared every seed when it answered instantly, 4 of 5 at 0.2 s per decision, 2 of 5 at 0.35 s, and none at 0.7 s, which was the laptop model's speed. So the rule player became the teacher, and the hardware had to get faster.

3. Saturday: a desktop GPU and a shorter prompt. On the RTX 3090 a 4B model fits, and its decision time turned out to depend almost entirely on prompt length. Listing the options once, before the game state, cut the prompt from ~1,130 to ~355 tokens and the decision from 337 ms to 90 ms. The student then learned E1M1 and E1M2, with its keys and switches: 20 of 20 and 13 of 20 unseen seeds in the final tests.

4. Saturday night to Monday: the teacher had to slow down. By then the training loop was set. The teacher is about 500 lines of rules reading the same text. The student copies its labels, then plays its own games, and the teacher labels the positions the student actually reached, including the bad ones the teacher would never have walked into; the method is called DAgger. Each round is about an hour of training on the 3090.

E1M8 changed the approach. The first E1M8 teacher, reacting instantly, cleared about 70% of runs. With 50 ms of delay it cleared none. A student that needs 90 ms per decision cannot copy tactics that only work at zero latency, however many examples it sees. So the teacher was rebuilt and tested with a 100 ms delay until it worked again:

• fire only when the shotgun is ready (one shot per 37 tics, about a second), dodge during the reload, stop and aim 0.35 s before the next shot;
• hold 330-520 units from the Barons and, when cornered, escape toward open space rather than the nearest gap;
• dodge fireballs from their measured speed and direction, before they arrive.

At 100 ms of delay the rebuilt teacher clears ~45%. After four rounds the student went from 0 of 10 to 8 of 20, or 40%.

Results

The final E1M8 model agrees with its teacher on 94% of held-out decisions and still loses 12 of 20 runs. Agreement measured on positions the teacher visits says little about the positions a student drifts into after one late dodge, so the score here is runs that reach the exit, on seeds never used in training.

Level	Jev	Teacher
E1M1	20/20 held-out seeds, median 29.9 s	20/20, median 23.5 s
E1M2	13/20, median 75.4 s	10/10, median 58.7 s
E1M8	8/20 unseen seeds, fastest 133.9 s	~70% instant, ~45% at Jev's delay

E1M8 starts from a stand-in for what a player would carry out of E1M7: shotgun, chaingun, 100 bullets, 30 shells, full health. Twenty seeds per test is a small sample, and the difference between 40% and 45% is one run.

What carries over to a company

Most of the work went into two things outside the model, and every business process needs both before a model can run it: a description of the situation as plain facts, and a written account of what a good decision looks like. In most companies the second one lives in the heads of a few experienced people. A small model copies a written judgment in an hour; it has nothing to copy when nobody wrote it down.

The written judgment has to hold under the conditions it will run in. The first teacher was right at zero delay and useless at 50 ms. A policy written by an expert who sees everything and has time to think fails in the same way when the person or model applying it sees less and acts faster. Testing the rulebook under the real constraint is cheap, and without that step the student had nothing usable to copy.

Model size is a choice to make per decision. For a narrow decision with a time limit, a 4B model on a consumer card did what hosted models several times its size could not, mostly because they answered too slowly. A bigger model is the right call for open questions and long documents; for picking one of 26 options four times a second it was the wrong tool.

Agreement with an expert on a test set is a weak proxy. A pilot that reports "the model matches our specialists 94% of the time" can still get most of the important cases wrong, and only the business outcome on new cases shows it.

What is next

One model playing E1M1 to E1M8 in a single run, with health, armor, weapons and ammo carried from each exit into the next map. The teacher now has routes on every map of the episode and clears E1M1-E1M3; the fights in E1M4-E1M7 are the current work. After that, weapon choice moves from a fixed rule to the model, because a run across eight maps is where shell economy starts to matter.

To run it or check the numbers: github.com/inosov9-byte/doom-jev. The README has the setup; EXPERIMENT.md has every result.

The model was never the hard part. The hard part was writing a teacher whose judgment survives a 90 ms delay.