Case study Part 1 of 4 · the testbed

Melvor Idle, the testbed

Most of this site's operations evidence comes from one agent: Claude playing the browser game Melvor Idle for days, with Jev making the judgment calls and plain code doing everything computable. This four-part case study drops the generic "jobs and supplies" language and shows the real thing: the game, the wiring, the cascade, and every push-down that taught it something.

What an idle game is

An idle game plays itself once you point it at something. In Melvor Idle you choose one action, such as cutting a tree, smelting a bar or fighting a monster. The game repeats it on a timer, every few seconds, until you stop it or something runs out. Each repeat gives experience points (XP) in a skill and usually an item that lands in your bank. Levels unlock better actions. The level curve is exponential, so later levels take hours or days of one action.

Three properties matter for an agent:

• One active action at a time. Woodcutting and fighting can't run together. Every choice of what to run is a real trade-off.
• Actions keep going without you. A batch of 1,000 arrows or a two-hour mining run needs no attention once started. Some systems, such as Farming plots and the Township, grow in the background whatever else you're doing.
• The state is fully readable. The game runs in the browser tab as plain JavaScript objects: every item, recipe, drop table, monster stat and timer. Code can compute almost anything a player would estimate.

Skills

Combat in one paragraph

You pick a monster in an area, and both sides attack on timers. Your accuracy against its evasion decides how often you hit; your max hit and its hit points decide how many hits a kill takes. You eat food to heal. A ranger uses an arrow on every attack unless an ammo-preservation bonus saves it, so ammunition is a running cost. Dying loses a worn item. Kills drop loot (leather, raw meat, bones, gems, seeds, rare equipment) into a loot container that throws away new drops once it's full.

Production chains: why it's a supply-chain game

The agent's character is a self-sufficient ranger: it makes nearly everything it uses and buys only lasting upgrades and raw materials it can't gather (feathers, bowstrings). That turns one goal, "get better at Ranged", into a web of chains that all have to stay fed:

Ammunition

One Adamantite Bar needs six Coal, and a 1,000-arrow restock took about 67 bars and 400 Coal. A refill touches four skills before a single arrow is fired.

Weapons, armor and food

Each chain has computable economics (XP per material, materials per hour, arrows per kill, food per arrow) and a few real judgment calls on top: which chain to feed now, what a material is worth keeping, how much risk a fight is worth.

Milestones: the character's plan

Claude owns the character's direction and writes it down as milestones in chapters: concrete, code-checkable goals such as "Ranged 55", "1,000 Adamant Arrows (quiver + bank)" or "wear the Yew Longbow". Code checks which are done; the decision model works on the first unfinished one; when a chapter closes, the watcher wakes Claude to write the next.

Beside the chapters sit standing goals that keep supplies healthy: arrows of the current tier (raised to 2,000 for the long Ranged grind), 150 cooked food, and seed stocks for the allotment and herb plots. By October 14, 2026, 37 of the 40 milestones were done: combat level 56, with Ranged 59, Fletching 70, Smithing 60 and Farming 13, all from a fresh start five days earlier. The town, farm plots and Agility course run beside the milestones as code policies.

How the agent is wired

Claude plays the real web game in a Chrome tab and clicks through its UI like a person. It never edits the save or calls game functions to skip work. Five parts do the rest:

Jev cost about $0.0009 per tick in the first session's measurement. Each tick is now two calls: the decision and a separate doubt check. Claude's wakes, not Jev calls, are the scarce resource. That shapes a lot of the design in part 3.