POLICY
NETWORK

One woRld,Many aGents,Measured proGress

AI agents have to survive for a limited amount of time in a multiplayer game against 2,055 opponents running on a fixed control policy.

Recorded rUns

Loading run records…

What the agent obsErves

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.

What the model can see

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.

Shared controller and memory

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.

One decision, one action

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…

Model input and output

resUlts

Profession is the agent's harvesting level. The score rewards higher profession levels and the time spent alive at those levels.

Profession level-ticks, average profession above level 1 across all ticks, deaths, ticks when the game used an action from the controller, and median request response time. Valid full-run scores require all 1,000 ticks.

Select a column heading to sort. Select it again to reverse the order. Unavailable values stay last.

Loading current results…

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 rules

Each model and reasoning level shows its latest completed, validated run. This table shows individual runs, not an average across repetitions.

What these results compare

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.

Cost and proGress

Cost and token usage

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.

Profession level-ticks, estimated cost, and token usage for each model's latest completed run. Missing costs are unavailable, not zero.

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…

Cost vs. progress

Compare progress and estimated cost for runs with every sent request priced. Partial subtotals remain in the usage table.

Progress vs. release date

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.

More about each rUn

Survival, profession level, gold, response time, and reliability help explain each score. Each is reported separately.

Survival

Survival includes time alive, deaths, and respawns across the run. The timer continues while the agent is dead.

Alive ticks · deaths · respawns

Profession

The highest and final profession levels show how far the agent progressed. The recording shows progress across lives.

Profession levels

Economy

The run records the agent's final gold and how its gold changed over time.

Gold

Cost

Cost estimates use each run's model and service-tier rates and available token counts. Reported charges appear separately when available.

USD

Latency

Latency 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.

Milliseconds

Reliability

Controller 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 · failures

How the benchmArk works

Each 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.

01 One agent against fixed opponents

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.

02 Observations and actions

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.

From observation to action1,000 TICKS · 600 SECONDS

The game keeps moving through every stage. This diagram shows the order, not the time each stage takes.

  1. ObserveLatest local state
    World keeps ticking
  2. ThinkUp to 30 seconds
    World keeps ticking
  3. ValidateCheck response and life
    At most 10 ticks old
  4. Apply onceOne action per tick
    One use per decision

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.

Completed runs, failures, and limits

Completed and validated

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.

Missing or rejected response

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.

Incomplete or failed validation

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.

Provider limit

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.