Survival
Survival includes time alive, deaths, and respawns across the run. The timer continues while the agent is dead.
Alive ticks · deaths · respawnsAI agents have to survive for a limited amount of time in a multiplayer game against 2,055 opponents running on a fixed control policy.
Loading run records…
Each model receives its agent's local game state in the same format. The model chooses a goal and any required target, and a shared controller turns that choice into a game action.
The model sees 11 rows by 15 columns around its agent, with nearby terrain, items, and other agents. It also receives its agent's health, equipment, inventory, and levels. The rest of the map is hidden.
Each request includes the game rules and options for goals and targets. The shared controller calculates routes and equipment steps. It also supplies up to four decisions the game used during the current life. This history clears on respawn.
The world keeps moving while the model responds. Each decision can produce one action within ten ticks, or six seconds, of its observation. The target and next step must still be valid. The controller does not continue a route while it waits for another decision.
Loading the example…
Profession is the agent's harvesting level. The score rewards higher profession levels and the time spent alive at those levels.
Select a column heading to sort. Select it again to reverse the order. Unavailable values stay last.
A full-run score requires all 1,000 ticks and verified game and recording data. An unavailable score does not mean zero.
Read the benchmark rulesEach model and reasoning level shows its latest completed, validated run. This table shows individual runs, not an average across repetitions.
After each tick, a living agent adds its profession level minus 1 to the score. Level 2 adds 1 point, level 3 adds 2, and so on. Level 1 and dead agents add zero. The total across all 1,000 ticks is the score in level-ticks. Dividing it by 1,000 gives the average above level 1. Incomplete runs and runs that fail validation have no full-run score.
Models receive observations in the same format and use the same controller for target options, routes, and equipment steps. Each request includes up to four decisions used during the agent's current life. Responses use typed choices or structured JSON, depending on the model interface.
The controller waits until a decision is used or rejected before it requests another. Each decision can produce one game action. The game keeps moving while the model responds, so the controller checks that the selected step is still valid. Recordings show observation time and action time separately.
All runs use world seed 66, agent 17, and fixed opponents. Each life starts with an empty inventory. These individual runs cover one starting world. Provider cache use can differ between runs.
The recorded prompts retain conflicting older wording about score averaging and repeated actions. These runs used 1,000 ticks and one action per decision within ten ticks of its observation. The effect of the prompt wording on model choices has not been measured.
The live game feed ranks the five living agents with the highest profession level in their current life. A lower agent number wins a tie. These ranks are separate from benchmark scores.
Live leaderboard unavailable. There is no verified game update to show.
| Rank | Agent | Life ID | Current value |
|---|
The game supplies these ranks while a live feed is connected. Updates pause when you leave this view.
This table shows reported token usage for each model's latest completed run, including requests whose actions never reached the game. Usage reporting shows how many responses include token counts.
Select a column heading to sort. Select it again to reverse the order. Unavailable values stay last.
Estimates use the model and service-tier rates recorded for each run. Missing usage leaves a partial subtotal. Select a cost to see the exact estimate, which requests it covers, and any reported charges.
Loading reported usage…
Compare progress and estimated cost for runs with every sent request priced. Partial subtotals remain in the usage table.
Compare progress by model release date. Each date comes from a published source.
Results depend on the model's choices, the shared controller, the input format, response time, and provider limits. The release-date chart includes completed, validated runs with a published model release date.
Survival, profession level, gold, response time, and reliability help explain each score. Each is reported separately.
Survival includes time alive, deaths, and respawns across the run. The timer continues while the agent is dead.
Alive ticks · deaths · respawnsThe highest and final profession levels show how far the agent progressed. The recording shows progress across lives.
Profession levelsThe run records the agent's final gold and how its gold changed over time.
GoldCost estimates use each run's model and service-tier rates and available token counts. Reported charges appear separately when available.
USDLatency measures the time from sending a request to receiving the full response. The world keeps moving during that time. Control1V1's preparation time covers all 2,056 agents together and is reported separately.
MillisecondsController ticks count the game ticks that used a model decision. Missed opportunities and rejected responses show where decisions did not reach the game.
Controller ticks · failuresEach run lasts ten minutes, with 1,000 game ticks scheduled 600 milliseconds apart. The world keeps moving while the model thinks or waits for a provider. Each request has up to 30 seconds to finish, or less near the end. A decision can act within ten ticks, or six seconds, of its observation while its original step remains valid. A response can meet its deadline and still arrive too late to act.
Each run tests one agent from the same starting state, using world seed 66 and agent number 17. The other 2,055 agents use our fixed reinforcement learning control policy, Control1V1. Each opponent has its own memory. All agents share the same clock.
After death, the agent respawns into the same world. The timer and request count continue across lives. Each life starts with an empty inventory and a fresh decision history. Dead ticks add zero to the score.
Each request includes the latest usable local observation, the game rules, and up to four decisions used during the current life. Models receive observations in the same format. The shared controller supplies goal and target options, calculates routes, and handles equipment steps. Responses use typed choices or structured JSON, depending on the model interface.
Each decision can produce one game action. The controller waits until the decision is used or rejected before it requests another. Responses from a previous life cannot act after respawn. No other controller supplies missing actions.
The game keeps moving through every stage. This diagram shows the order, not the time each stage takes.
A valid decision can act once on the earliest available tick while its original step remains valid. The controller requests decisions only when its agent can act. Each run allows at most 1,000 requests, with one request in progress at a time. Provider rate limits may reduce that number. Recordings include the time spent waiting for responses.
The world completes all 1,000 ticks. Game timing, recordings, and clean shutdown must pass validation. The score uses the state recorded after each tick. A validated run scores zero if its agent never stays alive above profession level 1.
A failed, malformed, or late response cannot act. While waiting for a new decision, the agent receives the game's no-action command. Other agents and health regeneration continue. The evaluated agent attacks only when it receives an attack command. No other controller acts for the model.
A run that stops before 1,000 ticks is incomplete. Game timing, recording, or provider access failures invalidate its score. Cancelling an unfinished request when the ten-minute run ends does not invalidate an otherwise valid gameplay score.
If a provider reaches its quota, rejects access, or changes the model route, requests stop while the world continues. Access or route failures also exclude the gameplay score. Requests also stop when a timed-out request leaves an unresolved charge. Any unpriced request leaves a partial cost estimate and excludes the run from cost comparisons.