DuoCook: An Overcooked-Inspired Benchmark for Visual Planning and Coordination

What it claims

DuoCook is a 20-map Unreal Engine benchmark in which one VLM schedules two cooks. The target is centralized coordination, not inference about an independent partner. The authors, from UBC and UC San Diego (October 2026), report that the benchmark is far from saturated. gpt-6-astra completes 26.2% of orders. claude-opus-5, qwen3.8-27b and gemini-3.5-flash-lite complete 8.8–11.2%, and most episodes end with nothing delivered.

How it works

The controller picks high-level actions plus a grid destination (rxcy, with a random but fixed origin per map). The engine handles navigation over a NavMesh. Each call receives:

• a top-down image with grid labels and pot ingredient counters;
• a prop legend;
• a map-specific system prompt of about 4,000 words, re-sent every call;
• live-state JSON and the engine's list of legal operations;
• rejection feedback;
• each player's last six responses.

Calls are triggered by state changes: action or cook completion, order arrival or expiry, and terrain shifts. The simulation pauses during inference, so latency does not count against the model.

flowchart TD
  E[State-change event] --> P[Pause sim]
  P --> V[VLM picks action + cell per player]
  V --> C{Engine accepts?}
  C -- no --> R[Rejection feedback] --> V
  C -- yes --> N[NavMesh executes; other player continues]
  N --> E

The five map categories are basic, shared equipment, dynamic, dynamic plus shared, and separated workspaces. In dynamic maps, counters or floors move every 1,000 steps. In separated maps, ingredients must be handed across counters.

Scoring works as follows. Orders arrive every 1,000 steps and expire after 3,000. Each delivery earns 20 points plus a tip of 8, 5, 3 or 0, set by waiting-time zone. The tip is multiplied by a combo schedule (1,1,2,3,4, capped at 4), and the streak resets when an order expires. Chopping and washing occupy a player, while soup boils unattended.

The kitchens were built by two claude-opus-5 processes through SimWorld Studio's MCP tools: one writes the construction prompt and one builds the scene. The scenes were then fixed by hand (collisions, cameras, visibility) and checked with an actor-name verification script.

Evidence

Each episode runs 4,000 steps, and initial states and order sequences are fixed across models. Reported metrics are:

• total score;
• order completion;
• delivery precision, which excludes maps with no deliveries;
• action acceptance, counted per player command with retries included;
• API spend per episode in USD.

The memory ablation removes only the shared, self-authored notebook, which has age-dependent retention. The six-response history is kept in both conditions, and the results are paired per-map differences. The notebook helped Claude and Qwen and hurt GPT and Gemini. The fetched text cuts off at Table 2, so per-model scores, precision, acceptance, cost figures and ablation magnitudes are not available here.

How to use it

Models were accessed via the OpenAI API (gpt-6-astra), the Anthropic API (claude-opus-5), and OpenRouter (qwen3.8-27b, gemini-3.5-flash-lite). The fetched text gives no code release, licence or install instructions.

Limits

There is one run per model, map and condition. The authors call the results descriptive, with no variance estimate, so the mixed notebook effect may not be robust.

Engine navigation, grid labels and structured text state do much of the perception work. The authors state that scores are not comparable with benchmarks that use other observation or control interfaces.

The legal-operation list does not filter by pending orders, and rejection messages give no corrective hints. The paused simulation removes any real-time pressure from inference latency. Players cannot fall into gaps on dynamic maps.