GPT-6 Astra ascended in NetHack 3.6.7 on September 21, after 37,140 game turns. As far as anyone has documented, this is the first time a large language model agent has beaten the game. The author, who has been trying to get LLMs to play NetHack since January, had never personally ascended in the game's 36-year history. The model did it on its third attempt.

Why NetHack is a hard test for AI agents

NetHack punishes the gap between knowledge and execution. A model can explain resistances, inventory management, and monster interactions perfectly well, then fail to apply any of that knowledge when a menu is open and its last observation of the map is stale. The game demands tens of thousands of sequential decisions, each one depending on accurate tracking of hidden state that the interface does not reveal.

The BALROG benchmark, which studies LLM and vision-language model agents across six games, formalizes this distinction. Its NetHack results separate possessing game knowledge from being able to use it over long decision sequences. The benchmark also found that giving models images can make performance worse, not better, since a richer interface is not automatically a more usable one. As of September 18, BALROG's leaderboard listed GPT-6-Astra-Max at 13.2 percent average NetHack progress, an average metric across runs, not a win rate.

The ascension run is not a BALROG submission. BALROG uses different agentic strategies and evaluation protocols. The question behind this experiment was more open-ended: what happens when a capable coding agent can work on the problem, including improving its own tools?

The agent built its own harness

In January, the author had spent considerable time building a custom Python interface around the NetHack Learning Environment. Context management, observation masking, action APIs, pathfinding, all required tuning before a model could function. This attempt started with a simpler request: play NetHack through a terminal and stream it to Twitch.

The agent built what it needed from there. That does not mean no harness existed. By the end, the harness was substantial. The difference is that the author did not design a task-specific system. The agent did that engineering as part of the task, iterating on its own tools after mistakes and deaths.

The architecture was deliberately ordinary. The game ran remotely, and the local process received only what the terminal displayed, no access to the engine's internal map, RNG state, or unidentified item identities. A session wrapper captured the tmux pane as text with curses, color, and persistent inventory at 144 columns by 36 rows. A compact annotation mode added row numbers, cursor coordinates, and coordinates for selected visible map features, saving the agent from repeatedly counting character positions in a large block of text.

Checked batching, not blind key-holding

One tool call per movement is expensive and tedious. A long string of unobserved movements is a good way to die in NetHack. The eventual solution was checked batching. For a requested movement sequence, the harness parsed the displayed position, HP, game turn, dungeon level, conditions, and nearby creatures. It sent a step, captured the result, checked it, and decided whether the next step was still safe.

Checks included low health, nearby non-pet creatures, unknown or dangerous destination tiles, unexpected displacement, damage, level changes, and excessive turn advancement. These were concrete predicates over the terminal state, not another LLM call deciding whether each step looked acceptable. The distinction matters: a batch meant fewer round trips through the model, not skipping all intermediate observations. Combat still required individual actions and another look at the screen.

The guard was not a complete model of NetHack. Late in the winning run, it rejected commands on the elemental planes because its status parser did not recognize the new level labels. The agent extended the parser, tested the change, checkpointed it, and continued playing. That is a mundane software bug. It is also exactly the kind of thing a fixed interface turns into a hard stop when the player cannot repair its own tools.

Helpers, memory, and open-book research

The agent built several helper tools. A route proposer performed graph search over the remembered map rather than asking the model to mentally trace corridors. Sokoban planning helpers handled boulder movement with checks against observed results. An inventory helper could step through a gold-stashing operation while verifying the expected bag, amount, and menu state. These helpers reduced the amount of unreliable work the model had to do through language alone.

Memory was plain Markdown and JSON on disk, not a specialized memory service. The agent maintained a run journal and a compact emergency reference tracking identified items, routes, resistances, consumables, current threats, and the next objective. Working instructions told it what to read on resumption after pauses or context compaction. Maps and randomized item identities were scoped to their run, so information from a dead character did not carry over to the next one.

The author gave the agent unrestricted access to spoilers, the wiki, the web, and public NetHack source code. It could research a rule before committing to an action, including during the endgame. Reading the implementation of a wand effect tells you the rules. It does not tell you which unidentified wand you found in this particular game or how many charges remain in it. The terminal boundary still mattered.

Three runs, one ascension

Run one died from sliming on dungeon level 51 after 33,302 turns. Run two was killed by a death ray at the Castle after 12,271 turns. Run three ascended. The winning game stretched from September 9 to September 21, including pauses and saved-game resumptions. The author paid for a $200-per-month Codex subscription and purchased roughly $300 in additional credits during the experiment.

The harness code and run journals are on GitHub under the MIT license. The reviewed evidence archive is available as a release download, including the failed runs, command records, observations, and historical snapshots. The agent also built an audit recorder during the run that linked events with hashes and recorded input intent before sending keys, tracking queued inputs, observations, terminal output, and the observable conversation. The game result does not depend on taking any paragraph in the blog post on faith.

What changed the author's thinking

For a long time, the approach was finding the right harness for an LLM. Give it a better action API, compress the observations differently, fix the pathfinding. Those things mattered. The result that changed the picture is that when an LLM finally ascended, it was capable of doing much of that engineering work itself. The scaffolding helped, but producing the scaffolding was itself work the model could do.

That points toward a broader pattern for difficult AI tasks. Instead of handcrafting every interface and guard rail, you describe the goal and let the agent iterate on its own tools. The model's ability to write and maintain ordinary software became part of its ability to play the game. For tasks where the environment is complex and the interface requirements are not obvious in advance, that self-directed tooling may matter more than raw model capability.