Paper deep dive
ArtifactArena: Evaluating Models by What They Build in the Physical World
Kushagra Tiwary*, David Mayo*, Nikhil Behari, Xiangzhou Sun, Abdulrahman Alabdulkareem, Isaac Galatzer-Levy, Boris Katz, Brian Cheung
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:To evaluate the frontier, we must measure models not by what they say, but by what they can engineer and build in grounded physical environments. We introduce \textsc{ArtifactArena}, an open-ended platform where models face a physically grounded hardware-software co-design challenge: engineering fully functional robots to compete in a simulated arena. We evaluate a frontier model's zero-shot, verifier guided refinement, and open-ended physical design capabilities through three harnesses that refine their bot artifacts based on text descriptions, physics simulator feedback, and gameplay data. We benchmark these capabilities with an Elo ranking of frontier models derived from head-to-head tournaments between their artifacts. By releasing this framework and tournament infrastructure for ongoing community submissions, we establish a living, non-saturating testbed to continuously measure the expanding limits of open-ended intelligence in the physical world. Please visit \href{this https URL}{this https URL} for more information.
Tags
Links
- Source: https://arxiv.org/abs/2610.06511v1
- Canonical: https://arxiv.org/abs/2610.06511v1
Trouble viewing inline? Open PDF directly →
Full Text
185,215 characters extracted from source content.
Expand or collapse full text
ArtifactArena: Evaluating Models by What They Build in the Physical World Kushagra Tiwary *,1,2 , David Mayo *,1 , Nikhil Behari 1,2 , Xiangzhou Sun 1 , Abdulrahman Alabdulkareem 1 , Isaac Galatzer-Levy 3 , Boris Katz 1 , and Brian Cheung †, 1,4 1 InfoLab, MIT CSAIL 2 Camera Culture, MIT Media Lab 3 Department of Psychiatry, NYU Grossman School of Medicine 4 Discovery Lab, UCSF * Equal contribution † Corresponding PI † Correspondence: ktiwary@mit.edu, dmayo2@mit.edu, bcheung@ucsf.edu Code: GitHub Last updated: October 5th, 2026 Abstract To evaluate the frontier, we must measure models not by what they say, but by what they can engineer and build in grounded physical environments. We introduce ArtifactArena, an open-ended platform where models face a physically grounded hardware-software co-design challenge: engineering fully functional robots to compete in a simulated arena. We evaluate a frontier model’s zero-shot, verifier guided refinement, and open-ended physical design capabilities through three harnesses that refine their bot artifacts based on text descriptions, physics simulator feedback, and gameplay data. We benchmark these capabilities with an Elo ranking of frontier models derived from head-to-head tournaments between their artifacts. By releasing this framework and tournament infrastructure for ongoing community submissions, we establish a living, non-saturating testbed to continuously measure the expanding limits of open-ended intelligence in the physical world. https://artifactarena.ai “Well done is better than well said.” —Benjamin Franklin 1 Introduction In 2002, a New Caledonian crow named Betty was shown a small bucket of food at the bottom of a vertical tube and a straight piece of wire. She picked up the wire, wedged one end against the tube, bent it into a hook, and fished the bucket out (Weir et al., 2002). What struck the researchers watching was not anything Betty said about her solution (Betty said nothing). It was the physical artifact, the hook, that evinced Betty’s intelligence. 1 arXiv:2610.06511v1 [cs.RO] 5 Oct 2026 Morphology Controller Strategy Artifact Arena Physical head-to-head evaluation Figure 1: ArtifactArena: Models jointly design physically grounded artifacts: robot bodies, controllers, and strategies for head-to-head competition in MuJoCo. Artifacts win by pushing opponents off an elevated ring or pinning them under the arena’s rules, grounding evaluation in the physical performance of what models create. Frontier model evaluations lag model capabilities: popular benchmarks such as MMLU (Hendrycks et al., 2021), MMLU-Pro (Wang et al., 2024), GPQA Diamond (Rein et al., 2024) or code- generation benchmarks such as HumanEval (Chen et al., 2021) test models against static question sets and answer keys which are now effectively saturated. To alleviate this issue, preference arenas such as LMArena (Chiang et al., 2024) and DesignArena replace fixed answer keys with head- to-head (h2h) competition between models judged by humans or other models. The lack of an objective verifier often leads to performative behavior (Zheng et al., 2023). As a result, functional evaluations such as SWE-Bench (Jimenez et al., 2024) and KernelBench (Ouyang et al., 2025) test for functional correctness of model-generated code by running it against fixed tests, performance and efficiency baselines. However, they continue to evaluate models against predefined task objectives. Arena based evaluations like SWE-Arena (Zhao, 2025) and CodeClash (Yang et al., 2025) share a similar philosophy of model evaluation through h2h competition however they are confined to symbolic verifiers. Given these recent advances, we propose ArtifactArena to competitively evaluate frontier model’s open-ended abilities to engineer and build verifiable artifacts that function and compete against other models’ artifacts inside physically grounded simulations. In ArtifactArena each model is tasked with open-ended construction of a complete robot artifact consisting of a body morphology and a motion controller (Sec. 2). While many evaluations explore physically grounded reasoning of models, Chen et al. (2025); Chow et al. (2025); Bear et al. (2022), we are inspired by both BattleBots (BattleBots Inc., 2022; BattleBots Wiki contributors, 2026; Mullins and Peterson, 2002), and AI’s success in Go (Silver et al., 2016) and design our arena environment based on principles that would allow creativity to emerge under physical constraints. Therefore the resulting robots are instantiated in MuJoCo (Todorov, 2014) and compete in a Last Bot Standing Game. Last Bot Standing is an adversarial, objective, zero-sum game with simple rules that allow for open-ended exploration of strategies. Models are also given full creative freedom to explore a large design space of robot designs and competitive strategies, with physics as the only real constraint on exploration. Sec. 3 shows how this leads to creative robot designs by models. The game rules are deliberately simple to allow for diverse winning strategies and objective in its outcome: a robot wins by either pushing an opponent from an elevated ring or pinning it under the arena’s adjudication rules (Sec. 2.1). Since the model must build this robot, success requires 2 500 500 1000 1000 1500 1500 Artifact Elo 1539 VGH 1352SH 1188DLH 1 GPT-6 Astra 1310 VGH 1260SH 1210DLH 2Fable 5.1 1223 VGH 1143SH 934DLH 3 Gemini 3.8 Flash 1189 DLH 1090VGH 1014SH 4Fable 5 1179 SH 1070VGH 945DLH 5GPT-5.4 1173 VGH 1034DLH 944SH 6 GPT-5.3 Codex 1165 SH 999VGH 964DLH 7 GPT-5.6 Sol 500 500 1000 1000 1500 1500 Artifact Elo 1164 VGH 1000SH DLH no finalist 8Kimi K3 1136 VGH 1059SH DLH no finalist 9Grok 4.6 1093 VGH 1010SH 927DLH 10 GPT-5.6 Terra 1088 SH 1086DLH 1019VGH 11 Gemini 3.1 Pro 1055 VGH 1050SH 958DLH 12 Qwen3.8 2.4T 1050 VGH 981SH 940DLH 13GLM 5.2 986 VGH 883SH 850DLH 14Sonnet 5 500 500 1000 1000 1500 1500 Artifact Elo 984 VGH 855DLH 593SH 15 GPT-5.6 Luna 978 DLH 913VGH SH all forfeited 16GLM 5.3 966 SH 963VGH 931DLH 17GPT-5.5 957 VGH 796SH DLH no finalist 18Grok 4.5 928 VGH 905SH 765DLH 19 Opus 4.8 765 VGH 726SH 577 20V4 Pro 745 VGH 720DLH 672SH 21Grok 4.20 DLH RANKMODELRANKMODELRANKMODEL SH Sampling Harness VGHVerifier-Grounded Refinement HarnessDLH Design Lab Harness Figure 2: ArtifactArena Leaderboard. Our results show a remarkable ability in frontier models to co-design robot morphologies and controllers within physically grounded environments and constraints. We test models’ engineering capabilities across three different harnesses (Sec. 2.3) that provide models with greater agency over the artifact design process. We find that models possess a remarkable ability to zero-shot complex robot morphologies and controllers which is further enhanced by verifier grounded feedback. While our arena tests open-ended design and engineering capabilities of models, we find that open-ended agentic capabilities still lag behind verifier grounded refinement loops. Please refer to Fig. 5 to visualize the bot morphologies. jointly reasoning about geometry, materials, mass distribution, actuation, and feedback control, as well as competitive strategy. The outcome is determined by the artifacts’ physical interaction, rather than by a human preference label or an LLM judge. ArtifactArena deliberately keeps the physical environment and game rules fixed across evaluations, while the adversary population changes as new artifacts enter the arena. Each artifact must therefore compete against independently designed robots with different morphologies, controllers, and strategies. Holding the environment fixed makes the simulator a common objective verifier, allowing differences in performance to reflect artifact design and competitive strategy rather than changes in the task itself. As stronger artifacts enter the arena, they become new opponents that raise the bar for future submissions, allowing our arena to remain non-saturating and keep up with model capabilities. We ask models to build the strongest robots they believe can win the game and rank the models based on their artifacts’ performance. Contributions: (1) A physically grounded competitive evaluation platform. We introduce ArtifactArena, an open-ended platform where models face a physically grounded hardware-software co-design challenge: engineering fully functional robots to compete in an objective zero-sum arena designed using the MuJoCo simulation environment. We maintain a live public artifact leaderboard open to community bot submissions worldwide. Our arena is 3 harness agnostic and only the model-artifact matters: we accept both artifacts designed entirely by models and artifacts produced through human–AI collaboration. See Fig. 3. (2) A model leaderboard and systematic comparison of artifact-generation strategies. We benchmark frontier models build capabilities using three test-time generation strategies implemented as harnesses: Sampling Harness (SH), Verifier Grounded Refinement Harness (VGH), and open-ended agentic search using a Design Lab Harness (DLH). We compute-match in terms of API calls on these harnesses to study which type of harness produces the strongest artifacts. Our leaderboard shows the limits of these models frontier capabilities and should be interpreted as measuring competitive physical design and control in simulation across frontier models rather than direct real-world robotic capability. See Fig. 2 & Fig. 7 (3) The unreasonable effectiveness of sampling. Our leaderboard shows that the most recent frontier models can zero-shot co-design complex robot morphologies with custom wedges using signed distance functions (SDFs) and controllers that implement charge and defend strategies while working within the physical environment. We show that this is a remarkably new capability that models have and sample this new capability to understand the extent of these designs. (Sec. 3.2) (4) An empirical anatomy of model creativity in artifact design. We open-source all model artifacts through the Bot Zoo with complete reasoning traces and design histories. We study not only the final robots but the processes through which models create them. Due to our large robot morphology and controller design space, we observe wedge, hammer, and pusher strategies implemented as both morphologies and controllers. The strongest agents also construct probes, adversarial opponents, and engineering tools to discover physical failure modes, while open-ended search can fail when self-created tests diverge from true tournament performance. (Sec. 3.4) To ensure ArtifactArena serves as a durable testbed for open-ended intelligence, we release the simulator, multiple harnesses, and our tournament infrastructure to support community submissions. This framework establishes a living evaluation horizon capable of continuously tracking the limits of artificial intelligence as it approaches and surpasses human-level capability in engineering and scientific endeavors. 2 Methods The goal of ArtifactArena is to rank AI models based on how their generated artifacts compare against artifacts created by other models in a physically grounded arena. We hold the simulator, physical parameters, and game rules described below fixed across all evaluations so competition arises from different artifacts with diverse morphologies, controllers, and strategies. We define ArtifactArena as a physically grounded environment defined in MuJoCo (Todorov, 2014) where AI agents, denoted byA=A 1 ,A 2 ,...,A n , generate physically grounded robot artifacts defined by design spaceX. An artifact is a fully specified robotic system comprising a physical morphology and an autonomous control policy: x i = (g i ,c i ,r i )∈ X geom × X ctrl × X text =: X, whereg i is the robot morphology,c i is the autonomous controller,r i is the model’s design rationale. The artifact, therefore, encodes many coupled design decisions: geometry, mass 4 GPT-6 Astra lifts Claude Fable 5.1 at t = 4.3 s, pushes it off at 6.5 s undertow_razorwake - GPT-6 Astra what red sees at step 430 of 652, t = 4.3 s edge 2.88 m Game + rulesWhat models build Arena Game rules Arena 15 m raised platform Win the opponent loses first Lose touch the floor, stall 10 s, oversize, or controller error Time 5 min, then a draw Robot constraints Mass 25-800 kg total, motors included Geometry up to 2000 bodies, geoms and motors Bounds 2.44 x 2.44 x 3.05 m box, checked live Materials foam, plastic, rubber, carbon fiber aluminum, titanium, steel, tungsten Objective make the opponent lose first robot.xml <mujoco model="undertow_razorwake"> <body name="chassis" pos="0 0 0.18"> <freejoint name="root" /> ... </mujoco> controller.py def policy_step(obs) -> dict[str, float]: step = int(obs["t"]) platform = obs["platform"] ... return _finish(commands) Robot morphology Controller observations me opponent top view platform my_pos0.33, 2.45 m my_yaw0.81 rad my_edge_distance 5.03 m opponent_pos2.36, 3.97 m opponent_edge_distance 2.88 m distance_to_opponent 2.54 m opponent_contactTrue t, max_t430, 30000 Shapes boxspherecylindercapsuleellipsoidsdf Joints hinge slideball Motors motor Materials material kg/m3 friction foam2000.50 plastic 9500.25 rubber 1,200 1.60 carbon fiber 1,700 0.35 material kg/m3 friction aluminum 2,700 0.45 titanium 4,500 0.40 steel 7,800 0.60 tungsten 19,300 0.40 1 my_pos, my_yaw, my_pitch, my_roll, my_velocity, my_angular_velocity Where am I Pose and motion 2 my_edge_distance, is_tipping, ground_contact, my_inactivity_timer Am I in danger Edge, tipping, stall clock 3 opponent_pos, opponent_yaw, opponent_velocity, distance_to_opponent, opponent_edge_distance Where is the opponent Pose, motion, distance 4 opponent_contact, opponent_contact_force, contacts, opponent_proximity Are we touching Forces and closest points 5 my_robot, opponent_robot, my_actuator_velocity Full robot state Every body, joint and motor 6 t, max_t, control_dt, platform, arena_grid, obs_history, action_history Time and arena Clock, platform, map, history Figure 3: ArtifactArena is a functional evaluation which evaluates a model’s physically grounded invention capabilities through a combat-robotics task where two autonomous robots compete on an elevated circular ring in MuJoCo with the goal of pushing the opponent off the platform. Models design complete robot artifacts, both hardware and controller. They use a set of primitives and real-world materials to design the morphology and map observations provided to the controller to motor commands towards winning the Last Bot Standing Game. distribution, joint placement, actuator limits, controller logic, feedback use, and behavior. Since model evaluation is now external to the model, our method has significantly lower evaluation costs: new models can generate artifacts that can be run against the best artifacts of older models offline (instead of re-running inference). We now discuss the arena game rules, and our methodology to rank models based on artifacts (Fig. 3). 2.1 The Last Bot Standing Game Model Task. Every model receives the same fixed prompt (Appx. 11), which asks it to “design a robot to maximize its win rate in the tournament described below” and to return the hardware as MJCF XML and the controller as Python. We design the prompt to be descriptive rather than prescriptive: it states the game rules (Sec. 2.1), the simulation setup in detail (to avoid any assumptions), the qualification and tournament procedure including Bradley-Terry Elo scoring, the robot constraints and material palette (Appx. 7.3), an MJCF syntax reference, and the controller observation schema (Appx. 7). Models are also told to think from first principles based on the MuJoCo physics world. Finally, the prompt reminds the model to optimize for expected win rate rather than simplicity, treat qualification as a constraint rather than the objective, and compare diverse morphologies and controllers before committing to one. The model must return six named sections:r i in the form ofname,design_strategy,hardware_plan,combat_plan, robot_xml and controller_code which g i and c i respectively. Qualification Stage. Once the model designs a robot artifact, it must first pass a static verifier: 5 the XML must compile in MuJoCo, contain exactly one free joint on the root body, assign every geometry a material from the palette, stay within 25-800 kg, and fit the size box. Collision parameters, physics options, and gravity compensation in the XML are stripped to disable the model from cheating. The controller is also verified once on a live observation to check for exceptions or malformed commands. Finally the robot plays three 20s matches against a passive 342 kg plastic block that has no actuators, may translate, rotate, and topple, and is exempt from the inactivity rule. The robot must not lose in the best of three matches, or else it forfeits the tournament. Sec. 2.3 details how qualified artifacts are chosen. Match. Qualified robots are allowed to enter the tournament. A match between two robots is a head-to-head round simulated in MuJoCo (Todorov, 2014) on an elevated circular platform 15 m in diameter (Fig. 3), with both robots spawned at random positions and headings. Every pair of bots plays matches with three unique seeds, once from each side, so six matches in total. Each robot has an unactuated six-degree-of-freedom root joint, allowing its body to translate and rotate freely in response to gravity, contact forces, and forces generated by its internally actuated motors driven by its controller policy code. We resolve match outcomes based on the following rules after every control step and a match that reaches 300 s without one of the robots loosing is a draw. Game Rules. The Last Bot Standing game takes inspiration from both BattleBots (Battle- Bots Inc., 2022) and the ancient board game Go as both are evidence of emergent human-machine creativity in environments with simple rules and large design spaces (BattleBots Wiki contribu- tors, 2026; Mullins and Peterson, 2002; Silver et al., 2016). A robot loses the match if any of the following conditions occur (listed in priority order): 1. Controller error: its policy raises an exception or returns malformed commands. 2. Floor contact: any part of its body touches the floor below the platform. 3. Size violation: its extents in its own root frame exceed 2.44 m × 2.44 m × 3.05 m. 4. Inactivity: beginning 10 s into the match and checked every control step, the two most distant center-of-mass positions recorded over the preceding 10 s are less than 0.5 m apart. 5. Physics instability: its body drives the simulation to non-finite forces. 2.2 Robot Artifact Design Space Frontier models must translate a high level design and competitive strategy into a robot morphol- ogy and controller that work together in MuJoCo. The morphology determines which forces the robot can apply, while the controller determines when and how to use them. We now summarize the robot design space available to the model and refer the reader to Appx. 7.1 for the full design constraints and implementation details. Robot Hardware Design. The morphology is an MJCF kinematic tree under a single free- jointed root body, with up to 2,000 bodies, geometries and actuators, and must fit within a bounding box of 2.44 m×2.44 m×3.05 m. Bodies are built from boxes, cylinders, spheres, capsules, ellipsoids, or inline signed-distance meshes, connected by hinge, slide, or ball joints. Each geometry takes one material from the palette (Appx. 7.3), which automatically sets its density (and therefore mass) based on model specified volume, and sliding friction. Motors drive internal joints, tendons, or sites, and only ever push one part of the robot against another. To allow for physically plausible motors, motor force scales with gear, and gear is charged against 6 Evaluate Finalists: for every model, the 3 selected bots from each harness (9 bots per model) enter the final tournament. 3 Leaderboards A Bradley–Terry fit to all games ranks every finalist (Artifact Leaderboard); each model's best finalist per harness forms the Champion Leaderboard (Fig. 2). Model 1 Model 2 Model 3 ⋮ Build SH Sampling no feedback task prompt 10 independent bots selected bot bot × bot round robin ×3 runs → 3 bots 3 selected bots VGH Verifier-Grounded Refinement revises from feedback task prompt + feedback 10 revisions, each a bot bot test feedback selected bot bot × bot round robin ×3 runs → 3 bots 3 selected bots DLH Design Lab runs its own experiments task prompt + tool results 10 turns, each a chain of tool calls turn 5 write_filedoes_bot_qualifysave_bot tools:workspacearenaanalysislibrary selected bot bot × bot round robin ×3 runs → 3 bots 3 selected bots = a bot is produced 1Qualify Each finalist must pass a static check (valid MuJoCo model within the mass, size and material limits; working controller) and must not lose a best of 3 against a passive 342 kg block. A finalist that fails forfeits all its games. 2 match win rates (model, harness, bot) × (model, harness, bot) Round robin Every finalist plays every other finalist using 11 match seeds × 2, switching starting positions. Figure 4: ArtifactArena evaluates models in physically grounded environments in two stages: BUILD phase whose goal is to output physically grounded verifiable artifacts, and EVALUATE phase whose goal is to rank the model through the artifact’s performance. Please see Sec. 2.3 for more deatils on Build and Sec. 2.4 for more details on Evaluate. the mass budget, so torque is bought with weight. We also allow passive damping, friction loss, and springs on joints and tendons which let the hardware absorb impacts or store energy. Controller Design. The controller is a Python functionpolicy_step(obs)that returns a command in the range [−1,1] for every actuator at each 0.01 s control step. It sees the game state through more than 50 named fields: positions, orientations, velocities, edge and opponent distances, contacts with forces and impulses, the closest geometry pairs, a rolling history of past observations and actions, and each robot’s compiled bodies, joints, and motors with their current state (Fig. 3 & Appx. 11’s observation section). State persists within a match and is reset between matches, so controllers may estimate, predict, and switch modes. 2.3 Test-time generation strategies The goal of the model in ArtifactArena is to produce the strongest artifact it can engineer that can beat artifacts produced by other models. Therefore our arena is harness agnostic and we use this as a call to the community to build better harnesses that allow models to engineer physically grounded artifacts. We now test three test-time artifact generation strategies that differ in how much of the design loop the model controls. Figure 4 summarizes the three generation harnesses and their common evaluation procedure. See Appx. 7 for details. For each model, we allocate 10 API calls to each harness which is run independently three times. Sampling Harness (SH). The model receives a fixed model prompt (Appx. 11) and produces 10 independent robot artifacts. There is no feedback given to the model and all produced artifacts directly enter the Qualification Stage. The top bot per run is chosen through a round-robin tournament between all the qualified bots. Verifier-Grounded Refinement Harness (VGH). In VGH we conceptualize the model’s role as that of an optimizer over 10 sequential iterations: the model reads verifier feedback, a journal of prior attempts, and the match feedback, and proposes a better artifact. After each iteration, the harness validates the artifact, qualifies it against the stationary block. The full match feedback (game state at every time step), verifier feedback, design history (a JSON with 7 what it changed on each iteration), and the current best artifact so far is given back to the model. The model can choose to iterate based on the full match feedback on the current best design. Every valid artifact enters a round robin and the Bradley-Terry Elo winner is chosen as the final artifact that enters the Qualification Stage. Design Lab Harness (DLH). We conceptualize a model as an open-ended engineer working in a Design Lab, a sandboxed workspace containing the simulator and verifier source, the task documentation, and shell and Python execution. The model is given a budget of 10 API calls, which it can use to chain several tool calls that allow it to build, simulate, and analyze match feedback (Table 1). We show an example iteration using DLH from Fable 5.1 in Fig. 7. We use the same process as VGH to choose the final artifact. 2.4 Tournament Artifact Leaderboard. We first run the above(model, harness)for all models defined in Appx. 3 and for the three harnesses defined in Sec. 2.3. After each run, a single robot artifact is selected based on harness specific selection method described above (Sec. 2.3). Each artifact is then validated and qualified through matches against a cube. For each (model, harness) pair this is repeated three times yielding three artifacts per model per harness. Artifacts that pass validation and qualification enter the Top-3 robot artifact tournament. These sets of top-3 artifacts play a cross-model round robin for 3 unique seeds (each unique seed plays two matches- one from each starting position so a total of 6 matches). We then compute a Bradley-Terry ELO score to get the top-3 resulting ratings, with a draw counted as half a win, form the Artifact Leaderboard. Using the Artifact Leaderboard, we also compute a Lab Leaderboard which is used to visualize the range of robot artifacts selected by all the models per research lab. We call this phase of the tournament the Top-3 Round and make all the matches available https://artifactarena.ai/matches?round=top3. Model Leaderboard. Our goal is to evaluate models by the best artifact they produce. There- fore, we select the best artifact for every(model, harness)pair from the Artifact Leaderboard. We then play a new cross-model round robin tournament with 11 unique seeds (22 total matches) to compute the top-1 Bradley-Terry Elo score for the model’s strongest artifact. This top-1 score is used to create ArtifactArena Champion Leaderboard (Fig. 2) also available at Champions Leaderboard. We call this phase of the tournament theChampion Roundand make all the matches available https://artifactarena.ai/matches?round=Champion+Round. As an independent robustness check, we replayed the 21 frozen model champions generated by their respective harnesses on two disjoint sets of eleven seeds, once from each side. The resulting rankings have a Spearman correlation ofρ= 0.984 and preserve 201 of 210 (95.7%) pairwise model orderings, with the top three models unchanged in order (Appx. 6.1). Uncertainty. Error bars in Fig. 2 are 95% bootstrap intervals over generation runs and match outcomes. In each of 1,000 replicates, we resample the three finalists for every model–harness pair and the 22 outcomes for every finalist pair, then refit Bradley–Terry, re-select each harness champion, and refit on champion matches. Since all finalists played each other, this only reweights existing matches. We do not resample within-run finalist selection, which would require bootstrapping every candidate-level round robin, so these intervals are a lower bound on full-pipeline uncertainty. 8 SHSampling HarnessVGHVerifier-Grounded Refinement HarnessDLHDesign Lab Harness VGH Undertow Razorwake GPT-6 Astra Overhead jaw on a T-bar above two split intake shovels; four two-axis ball drives SH Sidewinder Undertow GPT-6 Astra Rolls on four rubber balls, two motors each; slides sideways with the scoop on target DLH Apex Gemini 3.1 Pro 343 kg steel drum with tungsten teeth, fed by a wedge, counterweighted at the rear VGH Tungsten Groundhog Mk8 Claude Fable 5.1 790 kg tungsten slab on four rubber spheres; a floating scoop hinged at ground level VGH Keelhaul Grok 4.6 U-channel apron at both ends, spring- loaded and motor-held down against prying VGH Bulldozer Prime: Centerline Kimi K3 653 kg tungsten floor 1.75 cm off the ring, motorized 2.4 m wedge; best open-weight robot DLH Elevator Scoop GPT-5.5 A 383 kg tungsten block on a 1.7 m vertical slide to beat the inactivity rule SH Tungsten Manta GPT-5.4 Six wheels under a sculpted plow with skirts; the best record in its qualification group Figure 5: Visualization of top artifacts. We render eight robots from the final tournament across the three harnesses each with a different winning strategy. The ELOs of the above artifacts are available here: Artifact Leaderboard. 3 Results 3.1 ArtifactArena Leaderboard No one harness fits all: Fig. 2 compares models by the performance of their strongest artifacts across the three harnesses and Fig. 5 shows the top bot morphologies from the models. VGH achieves the highest reported Elo for 15 of the 21 models, including GPT-6 Astra (1539), Claude Fable 5.1 (1310), and Gemini 3.8 Flash (1223), which occupy the first three positions. However, SH produces the strongest artifacts for GPT-5.6 Sol, GPT-5.4, Gemini 3.1 Pro, and GPT-5.5, while DLH does so for Claude Fable 5 and GLM 5.3. We visualize top artifacts in Fig. 5. Despite the possibility of matchup-specific counter-strategies, tournament performance exhibits strong global dominance: in the cross-model round-robin tournament of the top three artifacts from each model–harness pair, the highest-rated artifact which was created by GPT-6 Astra using VGH, wins 91% of matches. Unreasonable effectiveness ofSamplingHarness(SH). We find a remarkable ability in both closed- and open-source models to zero-shot fully functioning robot artifacts for our highly open-ended task. Despite receiving no simulation feedback during generation, GPT-6 Astra reaches 1352 Elo with SH, Fig. 2, trailing only itself with VGH. Even though iteration leads to more stable bots, we hypothesize that as models develop better world models of 3D or MuJoCo- type environments, harness-engineering for engineering and scientific tasks may be bitter-pilled. We do additional experiments, sampling 250 bots from 21 models to explore zero-shot generation in Sec. 3.2. 9 1352 1260 1179 1165 1143 1088 1059 1050 1014 1010 1000 981 966 944 905 883 796 726 672 593 Champion Round Elo GPT-6 Astra Claude Fable 5.1 GPT-5.4 GPT-5.6 Sol Gemini 3.8 Flash Gemini 3.1 Pro Grok 4.6 Qwen3.8 2.4T Claude Fable 5 GPT-5.6 Terra Kimi K3 GLM 5.2 GPT-5.5 GPT-5.3 Codex Opus 4.8 Sonnet 5 Grok 4.5 DeepSeek V4 Pro Grok 4.20 GPT-5.6 Luna Model GPT-6 Astra Claude Fable 5.1 GPT-5.4 GPT-5.6 Sol Gemini 3.8 Flash Gemini 3.1 Pro Grok 4.6 Qwen3.8 2.4T Claude Fable 5 GPT-5.6 Terra Kimi K3 GLM 5.2 GPT-5.5 GPT-5.3 Codex Opus 4.8 Sonnet 5 Grok 4.5 DeepSeek V4 Pro Grok 4.20 GPT-5.6 Luna Model 0 model loses all 0.250.5 even 0.751 model wins all (wins + ½ draws) / games (a) Sampling (SH) 1539 1310 1223 1173 1164 1136 1093 1090 1070 1055 1050 1019 999 986 984 963 957 928 913 765 745 Champion Round Elo GPT-6 Astra Claude Fable 5.1 Gemini 3.8 Flash GPT-5.3 Codex Kimi K3 Grok 4.6 GPT-5.6 Terra Claude Fable 5 GPT-5.4 Qwen3.8 2.4T GLM 5.2 Gemini 3.1 Pro GPT-5.6 Sol Sonnet 5 GPT-5.6 Luna GPT-5.5 Grok 4.5 Opus 4.8 GLM 5.3 DeepSeek V4 Pro Grok 4.20 Model GPT-6 Astra Claude Fable 5.1 Gemini 3.8 Flash GPT-5.3 Codex Kimi K3 Grok 4.6 GPT-5.6 Terra Claude Fable 5 GPT-5.4 Qwen3.8 2.4T GLM 5.2 Gemini 3.1 Pro GPT-5.6 Sol Sonnet 5 GPT-5.6 Luna GPT-5.5 Grok 4.5 Opus 4.8 GLM 5.3 DeepSeek V4 Pro Grok 4.20 Model 0 model loses all 0.250.5 even 0.751 model wins all (wins + ½ draws) / games (b) Verifier-Grounded Refinement (VGH) 1210 1189 1188 1086 1034 978 964 958 945 940 934 931 927 855 850 765 720 577 Champion Round Elo Claude Fable 5.1 Claude Fable 5 GPT-6 Astra Gemini 3.1 Pro GPT-5.3 Codex GLM 5.3 GPT-5.6 Sol Qwen3.8 2.4T GPT-5.4 GLM 5.2 Gemini 3.8 Flash GPT-5.5 GPT-5.6 Terra GPT-5.6 Luna Sonnet 5 Opus 4.8 Grok 4.20 DeepSeek V4 Pro Model Claude Fable 5.1 Claude Fable 5 GPT-6 Astra Gemini 3.1 Pro GPT-5.3 Codex GLM 5.3 GPT-5.6 Sol Qwen3.8 2.4T GPT-5.4 GLM 5.2 Gemini 3.8 Flash GPT-5.5 GPT-5.6 Terra GPT-5.6 Luna Sonnet 5 Opus 4.8 Grok 4.20 DeepSeek V4 Pro Model 0 model loses all 0.250.5 even 0.751 model wins all (wins + ½ draws) / games (c) Design Lab (DLH) Figure 6: Harness-specific Winrate-Matrices show open-ended harness remain a direction of future work. Across harnesses, sampling creations are competitive with those created by VGH while none of the top-7 artifacts come from DLH (Artifact Leaderboard). Therefore, we plot the win-rate-matrix to get head-to-head comparisons within each harness and order models by their Elo score (the top-left and bottom left are the ones with the highest score). The uneven color patterns reveal matchup-specific strengths and weaknesses. Within harnesses, we see instability in base model performance as more agency is given: GPT-6 Astra no longer dominates in DLH (c) like it did in SH (a) or VGH (b), while open source models become more competitive globally with VGH. Complete agency, DLH, also didn’t translate to global performance. We believe that developing reliable open-ended design loops that construct stronger competitive artifacts remains a direction for future work. Details in Sec. 3.1 and Fig. 8. Growing pains of open-ended design loops. We find that giving models greater agency over the design loop does not yet consistently lead to stronger artifacts: under the tested same API-call budget, (DLH) trails (VGH) for most models, has no top-7 artifact (Artifact Leaderboard), and produces no champions for three models. We analyze this in Fig. 6 by restricting Champion Round matches (described in Sec. 2.4) to head-to-head comparisons within each harness and order models by their Elo score (the top-left and bottom left are the ones with the highest score). Each matrix cell reports the row model’s score against the column model, (wins+ 1 2 ties)/games, with red indicating an advantage and blue a disadvantage. The uneven color patterns reveal matchup-specific strengths and weaknesses: higher-ranked artifacts do not uniformly beat lower-ranked opponents. GPT-6 Astra dominates with SH and VGH harness and produces the artifacts that beat the artifacts of every other model produced (darker red squares means model will all matches), however, the same base model ranks third under DLH under Fable 5.1 and Fable 5. Moreover, no single base model dominates the DLH-only category (Fig. 6.c vs. Fig. 6.a). This shows that, for both closed- and open-source models, greater agency over the design loop does not yet consistently yield stronger artifacts when compared with those produced by the same models using simpler workflows under the same API-call budget. We believe that developing reliable open-ended design loops that construct stronger competitive artifacts remains a direction for future work. 10 3.2 Emergent Creativity in ArtifactArena ArtifactArena reveals creativity in both robot design and competitive behavior: models develop attack and defense mechanisms, coordinate hardware with control, and use physical interactions and game rules to gain an advantage. Under the same API-call budget, we now examine how these capabilities appear across the sampling, refinement, and open-ended harnesses. Hardware creativity. Top models co-design hardware-software to implement the chosen attack, defense, and recovery strategy. From the 509 buildable robots in the sampled subset, 208 robots had powered scoops or plows, 31 with flippers, 21 with spinners or drums, ten with clamps, and three with movable weights. GPT-5.5 describes Keelback Twin-Scoop as having “active front/rear scoop plates so it can attack in either direction.” GLM-5.3 gives Duozer Mk VII a foam dome, explaining that “a climber gets a single low-friction contact point on a convex surface and slides off.” We find models implement creative ways to exploit the rules including movable weights to increase COM height to avoid getting pinned. See Appx. 6.3 for more details. Controller creativity. Models write controllers as complex rule-based state machines that respond to the opponent’s design, movement, and the arena rules: in the refinement runs, 63% of controllers organize their behavior into distinct modes with explicit conditions to switch between them. Across the controller corpus, we identify 209 distinct mode names, includingchase, flank,dump,wiggle,wheelie,holdout, andactivity_win. Controller examples range from 71 lines for Grok 4.20 to 1,700 lines for GPT-5.4. GPT-6 Astra checks the opponent’s motors for potential weapons before choosing to intercept the opponent instead of directly engaging. GLM-5.3’s controller classifies opponent morphologies as spinners, flyers, or robots that stay near the edge and implements custom behavior against each. Kimi K3’s controller holds a pin when the opponent’s inactivity timer will expire first and implements a sharp breaking behavior near the edge so that the opponent’s momentum can carry it off the platform. Claude Fable 5.1 uses contact measurements to estimate the weight supported by each wheel and limits motor torque according available rubber wheel grip. See Appx. 6.4 for more details. Zero-shot design creativity. Given the remarkable emergent zero-shot design capabilities of frontier models in Mujoco, we generated 250 samples per model for 21 models. Across 5,250 total API calls, 4,384 artifacts are built and 2,242 qualify: Claude Fable 5 qualifies 91% of its samples, Claude Fable 5.1 84%, Gemini 3.8 Flash 76%, GPT-5.5 71% and GPT-5.6 Sol 69%; GPT-5.6 Luna qualifies 24%, Claude Sonnet 5 33%, and Gemini 3.1 Pro, whose champion won the cross-model tournament, only 40%; DeepSeek V4 Pro qualifies 4%, Grok 4.5 and Grok 4.20 2%. Even though zero-shot design is a significantly harder task, models surprisingly use the full design space: 29% of robots include a custom mesh, 192 drive motors through tendons, 253 use passive springs, 171 use ball joints and 91 use slide joints, and the largest reach 15 bodies, 58 geometries and 14 motors. 3.3 Remarkable capabilities that surprised us Several behaviors appeared that surprised us. For example, models designed controllers that plan for accidentally being flipped zero-shot, anticipating this issue without any feedback or experience from the arena. In the sampling harness: 96 controllers detect inversion from the root orientation and remap their drive, with wheels built to stand taller than the hull. Claude Fable 5.1’s Groundhog Tungsten carries a lift angle “that puts the plate on the ground 11 (a) Refinement harness: GPT-6 Astra uses 10 revisions to alternate between strategy design, morphology improvement and controller improvement. Revisions 1, 3, 5, 6 and 10 of one run are shown; quotes are from the design_strategy field. rev 1 Omnidirectional Plow Qualification: 0/3 wins "four independently driven spherical wheels and a wide, articulated scoop" Designs the strategy rev 3 robot.xml +135 −45 controller.py +418 −307 controller.py: a jaw state machine; lift only after jaw and scoop loads confirm a capture. + verified_grip = ( + jaw_mode != "open" + and jaw_load > 150 + and down_load > 140) + if verified_grip: + jaw_mode = "hold" Undertow Lockjaw Qualification: 3/3 wins "A powered upper jaw captures an opponent against the scoop" Improves the controller rev 5 robot.xml +116 −139 controller.py +235 −87 Undertow Cleanbite Qualification: 3/3 wins Replay showed "erroneous SDF contacts"; replaces the SDF nose with "an exact primitive tongue" Improves the morphology rev 6 robot.xml +77 −226 controller.py +110 −90 Undertow: Freebite Qualification: 3/3 wins "Replaces the problematic SDF receiver ... with analytically exact inclined plates" Selected by Round Robin Improves the morphology rev 10 robot.xml +24 −24 controller.py +210 −80 controller.py, shape unchanged: drive force is allocated by the measured load on each wheel. + def _allocate_forces( + force, moment, + offsets, loads): + usable = w: max( + 0.025*weight, + loads[w]) ... Undertow: Keelbreaker Qualification: 3/3 wins Rearward ballast and "a 5,000 N clamp, replacing the 3,500 N actuator" Improves the controller (b) Design Lab harness (open-ended agentic search): Fable 5.1 uses 10 turns to alternate between building an artifact and writing probes that test the artifact. Turns 4 to 9 of one run are shown. Turn 4 Proposes v4 1) Builds an 18° plastic wedge with a 2.5 m lip. 2) Simulates matches: v4 beats v3 6–0. Improves the artifact Turn 5 Writes probes A, B 1) Probe A is a high-COM rammer with no wedge. Probe B (shown) is v4 with its lip on the floor. 2) Simulates matches: v4 beats A 5–1, but B beats v4 6–0. Builds probes Turn 6 Proposes v5 1) Adopts probe B's floor- level lip, fixes controller. 2) Writes probe C: lip pressed 2 m into floor. 3) Simulates matches: v5 draws B 3–3, beats C 4–2. Improves the artifact (and one probe) Turn 7 Writes probe D 1) Probe D is v5 with its wedge plate thinned from 2 cm to 1 cm. 2) Simulates matches: D beats v5 6–0. Builds probes Turn 8 Proposes v6 1) Promotes probe D unchanged as v6. 2) Writes probe E: plate thinned 1 cm to 6 m. 3) Simulates matches: E beats v6 6–0. Improves the artifact (and one probe) Turn 9 Proposes v7 1) Promotes probe E unchanged as v7. 2) Simulates matches: v7 beats A 3–0, v3 3–0. 3) v7 wins the library round robin. Improves the artifact Figure 7: An example refinement vs. design lab run. (a) Example refinement by GPT-6 Astra: box’s are colored by the largest change (by lines added and removed in robot.xml and controller.py): strategy (gold), morphology (blue) or controller (green). Revision 6, outlined in orange, is the robot the run’s round robin selected for the tournament. (b) Claude Fable 5.1’s turns in the Design Lab iterate between building an artifact (blue) and making probes to test the artifact (purple). when we drive upside down”:inverted = upz < -0.2; sgn = -1.0 if inverted. In VGH, 17 controllers do the same, and Gemini 3.1 Pro’s Apex Juggernaut reverses its drum when inverted so the exposed surface still strikes upward:is_upside_down = abs(my_roll) > 2.0 or abs(my_pitch) > 2.0; drive_fwd = -drive_fwd; weapon_cmd = 1.0. Some controller designs create strategies tracking the difference in their and their opponents inactivity timers, raising their center of mass in the final seconds of a mutual stall to win the height tie-break. Moreover, some controllers also estimate physics from their observations by reconstructing the normal load on each wheel from contact impulses, while some predict interception points. GPT-6 Astra (VGH) inspects its opponents morphology and treats any opponent hinge above 1,800 N·m as a weapon before choosing its approach. Lastly, in DLH, models alternate between building the artifact and designing strategies that can beat it. Fig. 7.B shows Claude Fable 5.1 saved its first design “as a sparring baseline,” then wrote two probe opponents to attack its own wedge, a “vertical-bumper high-COM rammer on the same chassis” and a copy “with wedge lowered 2 m so its lip touches the platform”. 12 3.4 What makes some models creative? ArtifactArena’s simple rules and vast, physically grounded design space give models wide freedoms to engineer robots, therefore we ask what makes some models much better at pro- ducing novel high-Elo artifacts? We find that the most creative models are creative across two complementary dimensions: Creative strategic decomposition of task. Creative strategic decomposition asks for models to turn the broad goal of “best possible bot” into smaller objectives that guide their designs. These often require reasoning at a higher level, decomposing the strategy into sub problems that can be independently tested and implemented as verifiers in the simulation. Claude Fable 5.1’s Groundhog Tungsten begins with a strategy of “getting its blade under the opponent” and “lifting to transfer their front-axle weight onto our front tyres,” followed by pushing the opponent toward the edge and “dumping them by lowering the arm and reversing.” Fable 5.1 further decomposes this into problems that the controller must solve to implement each strategy into state machines that adjust the lift angle according to opponent mass and state machines that limit speed near the edge. Top models are able to decompose non-quantifiable goals into a series of strategies and then concrete and verifiable sub-goals that the hardware-software co-design must meet. Creative physical implementation of strategy. Models must also understand how to use the physically grounded design space to achieve their chosen strategies. Creativity here lies in translating a strategy into effective robot morphology and control, as a useful strategy is only as good as how its implementation works under the simulated physics. Across refinement runs, models often retained their strategies while changing their physical implementation. For example, Kimi K3’s strategy was “a low, near-maximum-mass wedge that gets under the opponent and shoves it off the platform”. Its first five implementations were four-wheel skid-steer slabs which only won two out of fifteen qualification rounds. At iteration 6, it finally identified how to change the morphology and controller to implement that design by replacing it with a four-wheel wedge with a center-pivot design. This improved qualification performance to 3-0 in the qualification stage. Such creative implementations is seen across models and are detailed in the Appendix 6.8. Role of refinement in model creativity. The harnesses reveal different aspects of model creativity within these dimensions. SH produces a median of 19 structurally distinct designs, compared with 12 for verifier-grounded refinement (across iterations). During refinement, models mostly stuck to their initial strategies and used the feedback for fixes. Claude Fable 5, for example, identified an edge overrun in its trajectory and replaced a fixed edge threshold with a braking-distance speed limit. Across the refinement runs, 19 of 21 models reach a qualifying design in every run within ten revisions. We anticipate harnesses that allow models to work across these creative dimensions to be the most successful. We also briefly discuss ambitious designs that ultimately failed in Appx. 6.2. 3.5 Limitations All simulations are wrong, but some are useful. The main limitation of ArtifactArena is the gap between simulation and reality. Robots are built and judged inside MuJoCo therefore constructing a robot here doesn’t mean that the robot is going to work in the real world. Nevertheless, we anticipate that as simulations get closer to reality, the same arena and the same harnesses will carry over unchanged: the robot becomes something that can be printed, assembled and fought 13 for real. Therefore, our results should be interpreted as measuring competitive physical design and control of frontier models in simulation rather than direct real-world robotic capability. 4 Related Work Prescribed objectives and executable verification. MMLU (Hendrycks et al., 2021) and MMLU-Pro (Wang et al., 2024) test question answering, while HumanEval (Chen et al., 2021), SWE-bench (Jimenez et al., 2024), and LiveCodeBench (Jain et al., 2024) test program correctness, and KernelBench (Ouyang et al., 2025) measures execution speed. WebArena (Zhou et al., 2024) and BEHAVIOR-1K (Li et al., 2023) extend evaluation to interactive web environments and simulated everyday activities, respectively. These benchmarks use prescribed task objectives. Chatbot Arena (Chiang et al., 2024) instead uses pairwise human preferences, while judgment- based evaluation can exhibit position and verbosity biases (Zheng et al., 2023). SWE-Arena (Zhao, 2025) evaluates multi-round software engineering, while CodeClash (Yang et al., 2025) evaluates competing codebases refined through match feedback. ArtifactArena extends executable competition to physically simulated robots, with models designing both their morphology and controller. Physical reasoning and functional construction. Physically grounded benchmarks test capabilities ranging from action selection in PHYRE (Bakhtin et al., 2019), to outcome prediction in Physion (Bear et al., 2022), physical understanding in PhysBench (Chow et al., 2025), and experimental discovery in PhysGym (Chen et al., 2025). Construction benchmarks go further by making model output a physical system. BuildArena is a close example, evaluating language- driven construction through simulated transport, support, and lift tasks (Xia et al., 2026). BesiegeField similarly evaluates machine programs assembled from standardized components, refined through feedback (Zhang et al., 2026). ArtifactArena shares their emphasis on constructing functioning systems, while evaluating generated robots through direct physical competition in a non-saturating setting. Co-design and evolving competition. Prior work jointly optimizes bodies and behavior through competitive evolution (Sims, 1994; Gupta et al., 2021; Tiwary et al., 2025). Evolution Gym benchmarks body and controller optimization (Bhatia et al., 2021), and RoboMoRe uses LLMs to co-design morphology and reward (Fang et al., 2025). Competitive reinforcement learning produces complex behavior in simulated sumo environments (Bansal et al., 2018), while Enhanced POET evolves environments and solutions together (Wang et al., 2020). In ArtifactArena, new opponents expose weaknesses in existing designs and raise the bar for future submissions. 14 References Anton Bakhtin, Laurens van der Maaten, Justin Johnson, Laura Gustafson, and Ross Girshick. Phyre: A new benchmark for physical reasoning. In H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alché-Buc, E. Fox, and R. Garnett, editors, Advances in Neural Information Processing Systems, volume 32. Curran Associates, Inc., 2019. URLhttps://proceedings.neurips.c/ paper_files/paper/2019/file/4191ef5f6c1576762869ac49281130c9-Paper.pdf. Trapit Bansal, Jakub Pachocki, Szymon Sidor, Ilya Sutskever, and Igor Mordatch. Emergent complexity via multi-agent competition, 2018. URL https://arxiv.org/abs/1710.03748. BattleBots Inc. BattleBots Rules & Entry.https://battlebots.com/rules/, 2022. BattleBots Design Rules Version 2022.0, last updated September 13, 2022. Accessed April 26, 2026. BattleBots Wiki contributors. BattleBots Wiki.https://battlebots.fandom.com/wiki/ BattleBots_Wiki, 2026. Fandom wiki. Accessed April 26, 2026. Daniel M. Bear, Elias Wang, Damian Mrowca, Felix J. Binder, Hsiao-Yu Fish Tung, R. T. Pramod, Cameron Holdaway, Sirui Tao, Kevin Smith, Fan-Yun Sun, Li Fei-Fei, Nancy Kanwisher, Joshua B. Tenenbaum, Daniel L. K. Yamins, and Judith E. Fan. Physion: Evaluating physical prediction from vision in humans and machines, 2022. URLhttps://arxiv.org/abs/2106. 08261. Jagdeep Bhatia, Holly Jackson, Yunsheng Tian, Jie Xu, and Wojciech Matusik. Evolution gym: A large-scale benchmark for evolving soft robots. Advances in Neural Information Processing Systems, 34, 2021. Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374, 2021. Yimeng Chen, Piotr Piękos, Mateusz Ostaszewski, Firas Laakom, and Jürgen Schmidhuber. Physgym: Benchmarking LLMs in interactive physics discovery with controlled priors. In The Thirty-ninth Annual Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2025. URL https://openreview.net/forum?id=w8uII2qAmd. Wei-Lin Chiang, Lianmin Zheng, Ying Sheng, Anastasios Nikolas Angelopoulos, Tianle Li, Dacheng Li, Hao Zhang, et al. Chatbot arena: An open platform for evaluating LLMs by human preference. In International Conference on Machine Learning (ICML), 2024. Wei Chow, Jiageng Mao, Boyi Li, Daniel Seita, Vitor Guizilini, and Yue Wang. Physbench: Benchmarking and enhancing vision-language models for physical world understanding. arXiv preprint arXiv:2501.16411, 2025. Jiawei Fang, Yuxuan Sun, Chengtian Ma, Qiuyu Lu, and Lining Yao. Robomore: Llm-based robot co-design via joint optimization of morphology and reward, 2025. URLhttps://arxiv. org/abs/2506.00276. Agrim Gupta, Silvio Savarese, Surya Ganguli, and Li Fei-Fei. Embodied intelligence via learning and evolution. Nature communications, 12(1):5721, 2021. 15 Dan Hendrycks, Collin Burns, Steven Basart, Andy Zou, Mantas Mazeika, Dawn Song, and Jacob Steinhardt. Measuring massive multitask language understanding. Proceedings of the International Conference on Learning Representations (ICLR), 2021. Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and Ion Stoica. Livecodebench: Holistic and contamination free evaluation of large language models for code. arXiv preprint arXiv:2403.07974, 2024. Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. SWE-bench: Can language models resolve real-world GitHub issues? In International Conference on Learning Representations (ICLR), 2024. Omar Khattab, Arnav Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Sri Vardhamanan, Saiful Haq, Ashutosh Sharma, Thomas T. Joshi, Hanna Moazam, Heather Miller, Matei Zaharia, and Christopher Potts. DSPy: Compiling declarative language model calls into self-improving pipelines. arXiv preprint arXiv:2310.03714, 2023. Chengshu Li, Ruohan Zhang, Josiah Wong, Cem Gokmen, Sanjana Srivastava, Roberto Martín- Martín, Chen Wang, Gabrael Levine, Michael Lingelbach, Jiankai Sun, Mona Anvari, Minjune Hwang, Manasi Sharma, Arman Aydin, Dhruva Bansal, Samuel Hunter, Kyu-Young Kim, Alan Lou, Caleb R Matthews, Ivan Villa-Renteria, Jerry Huayang Tang, Claire Tang, Fei Xia, Silvio Savarese, Hyowon Gweon, Karen Liu, Jiajun Wu, and Li Fei-Fei. Behavior-1k: A benchmark for embodied ai with 1,000 everyday activities and realistic simulation. In Karen Liu, Dana Kulic, and Jeff Ichnowski, editors, Proceedings of The 6th Conference on Robot Learning, volume 205 of Proceedings of Machine Learning Research, pages 80–93. PMLR, 14–18 Dec 2023. URL https://proceedings.mlr.press/v205/li23a.html. Barry E. Mullins and Brian S. Peterson. Battlebots and the electrical engineering education. In Proceedings of the 2002 American Society for Engineering Education Annual Conference & Exposition, pages 1–9, Montreal, Quebec, Canada, 2002. doi: 10.18260/1-2--11370. Anne Ouyang, Simon Guo, Simran Arora, Alex L. Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini. Kernelbench: Can llms write efficient gpu kernels?, 2025. URLhttps: //arxiv.org/abs/2502.10517. David Rein, Betty Li Hou, Asa Cooper Stickland, Jackson Petty, Richard Yuanzhe Pang, Julien Dirani, Julian Michael, and Samuel R. Bowman. GPQA: A graduate-level google- proof q&a benchmark. In First Conference on Language Modeling, 2024. URLhttps: //openreview.net/forum?id=Ti67584b98. David Silver, Aja Huang, Chris J Maddison, Arthur Guez, Laurent Sifre, George Van Den Driess- che, Julian Schrittwieser, Ioannis Antonoglou, Veda Panneershelvam, Marc Lanctot, et al. Mastering the game of go with deep neural networks and tree search. Nature, 529(7587): 484–489, 2016. Karl Sims. Evolving 3d morphology and behavior by competition. Artif. Life, 1(4):353–372, January 1994. ISSN 1064-5462. doi: 10.1162/artl.1994.1.353. URLhttps://doi.org/10. 1162/artl.1994.1.353. 16 Kushagra Tiwary, Aaron Young, Zaid Tasneem, Tzofi Klinghoffer, Akshat Dave, Tomaso Poggio, Dan-Eric Nilsson, Brian Cheung, and Ramesh Raskar. What if eye...? computationally recreating vision evolution. Science Advances, 11(51):eady2888, 2025. doi: 10.1126/sciadv. ady2888. URL https://w.science.org/doi/abs/10.1126/sciadv.ady2888. Emanuel Todorov. Convex and analytically-invertible dynamics with contacts and constraints: Theory and implementation in mujoco. In 2014 IEEE International Conference on Robotics and Automation (ICRA), pages 6054–6061, 2014. doi: 10.1109/ICRA.2014.6907751. Rui Wang, Joel Lehman, Aditya Rawal, Jiale Zhi, Yulun Li, Jeffrey Clune, and Kenneth Stanley. Enhanced POET: Open-ended reinforcement learning through unbounded invention of learning challenges and their solutions. In Hal Daumé I and Aarti Singh, editors, Proceedings of the 37th International Conference on Machine Learning, volume 119 of Proceedings of Machine Learning Research, pages 9940–9951. PMLR, 13–18 Jul 2020. URLhttps://proceedings. mlr.press/v119/wang20l.html. Yubo Wang, Xueguang Ma, Ge Zhang, Yuansheng Ni, Abhranil Chandra, Shiguang Guo, Weiming Ren, Aaran Arulraj, Xuan He, Ziyan Jiang, et al. MMLU-Pro: A more robust and challenging multi-task language understanding benchmark. arXiv preprint arXiv:2406.01574, 2024. Alex AS Weir, Jackie Chappell, and Alex Kacelnik. Shaping of hooks in new caledonian crows. Science, 297(5583):981–981, 2002. Tian Xia, Tianrun Gao, Wenhao Deng, Long Wei, Xiaowei Qian, Chenglei Yu, and Tailin Wu. Buildarena: A physics-aligned interactive benchmark of llms for engineering construction. In Forty-Third International Conference on Machine Learning, 2026. John Yang, Kilian Lieret, Joyce Yang, Carlos E. Jimenez, Ofir Press, Ludwig Schmidt, and Diyi Yang. Codeclash: Benchmarking goal-oriented software engineering, 2025. URLhttps: //arxiv.org/abs/2511.00839. Wenqian Zhang, Yangyi Huang, Weiyang Liu, and Zhen Liu. Compositional machine design as program synthesis with llms, 2026. URL https://arxiv.org/abs/2510.14980. Zhimin Zhao. Swe-arena: An interactive platform for evaluating foundation models in software engineering, 2025. URL https://arxiv.org/abs/2502.01860. Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, and Ion Stoica. Judging llm-as-a-judge with mt-bench and chatbot arena. In Proceedings of the 37th International Conference on Neural Information Processing Systems, NIPS ’23, Red Hook, NY, USA, 2023. Curran Associates Inc. Shuyan Zhou, Frank F Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Yonatan Bisk, Daniel Fried, Graham Neubig, et al. WebArena: A realistic web environment for building autonomous agents. In International Conference on Learning Representations (ICLR), 2024. 17 Appendix 5 AI Statement In this work, we used generative AI tools to assist with research execution, including implementing methods and writing code, running experiments, and analyzing and interpreting experimental results. We additionally used these tools to create scientific figures and correct grammar. The models evaluated in ArtifactArena generated a synthetic dataset of robot artifacts, comprising robot morphologies and controllers, as part of the experimental procedure described in the paper. We did not use generative AI to generate the core research ideas or draft the substantive scientific content of the manuscript. However, we used generative AI tools to create scientific figures, correct grammar. We reviewed all AI-assisted contributions, checked code through execution and testing, verified analyses and figures against the underlying experimental outputs. We take full responsibility for the final content of this work, including its text, methods, results, claims, and artifacts produced with the assistance of generative AI. 6 Results (continued) 6.1 Fresh-seed robustness To test whether the leaderboard is sensitive to the particular tournament seeds, we froze the 21 champion artifacts selected by the original tournament and replayed their round robin on two disjoint sets of eleven seeds: the reference seeds and a held-out set. Each seed was played once from each side, yielding 4,620 matches per set (9,240 total). Both sets were rerun using the same current harness to isolate seed sensitivity from changes to the runtime, and no artifacts were selected using held-out results. The resulting model rankings were highly consistent (Spearman ρ= 0.984, 95% bootstrap interval [0.948,0.990]); 201 of 210 pairwise model orderings (95.7%) were preserved, seven reversed, and two became ties. The top three models were unchanged in order. For the Elo and rank-correlation intervals, we use 2,000 seed-block bootstrap replicates, independently resampling each pair’s eleven seed blocks within each set while keeping the two side-swapped matches from each seed together. 6.2 Ambitious Designs Failure is critical to creativity and we briefly discuss some of the most ambitious designs in the set that never won a match, but mark the frontier of what a model will attempt: Gemini 3.1 Pro’s Centrifuge, a 188 kg vertical drum spinner whose reaction torque backflipped its own chassis; GPT-5.6 Terra’s Orbitbreaker, a 0.68 m aluminum flywheel with eight impact teeth; Claude Opus 4.8’s Tungsten Tortoise, which slings a steel slab below its axles as a self-righting pendulum; GPT-5.5’s Keeljaw Sumo Loader, whose intake drum drags opponents up its ramp; and nine of the sixteen sphere-drive lifters GPT-6 Astra placed in the set. 18 6.3 Artifact Morphology Analysis We analyze a subset of 630 sampled artifacts from 21 models. We report the mechanisms present in these artifacts and use excerpts from the models’ design rationales to describe their intended functions. Qualification and match results provide separate evidence of how the completed robots perform. Powered mechanisms. 208 robots had powered scoops or plows, 31 with flippers, 21 with spinners or drums, ten with clamps, and three with movable weights while ten robots carry weapons at both ends. These mechanisms provide different ways to engage an opponent, including lifting, striking, gripping, and shifting weight. Attack. Several models design mechanisms intended to lift opponents and reduce their grip on the platform. GPT-5.6 Sol’s Gravemouth Leviathan combines a wedge with a rubber intake drum. Its rationale states that the drum “rotates upward at its exposed front face and rearward over its top, lifting an opponent while drawing it onto the wedge.” Gemini 3.1 Pro’s OblivionScoop combines a scoop with a powered jaw that, according to the model, “bites down on the opponent.” Other designs allow attacks from either end: Grok 4.6’s Janus has front and rear scoops, while GPT-5.5 describes Keelback Twin-Scoop as using “active front/rear scoop plates so it can attack in either direction.” Weight distribution. Some models use movable weights to change how their robots push and recover. GPT-5.4’s Shiftplow moves its weight according to the situation; the model states that it “throws that ballast forward during charges and pushes, back during edge escape and turning.” Its refinement design Centerline Kraken moves a 553 kg core along two axes. The rationale describes this choice as “controllable leverage.” GPT-5.3-Codex’s Wedgewarden Atlas instead raises a tungsten weight “when both robots are close to inactivity timeout, increasing COM height.” This design targets the rule that favors the higher center of mass when both robots lose to inactivity on the same step. Defense and recovery. Models also design hardware intended to prevent opponents from getting underneath them or to preserve movement after being overturned. GPT-5.4’s Tungsten Manta includes “side skirts and a rear skid to reduce easy side entries and make reverse escapes survivable.” GPT-5.6 Sol’s Tungsten Undertow leaves its wheels exposed so that, according to its rationale, they “remain able to propel the robot even if it is inverted.” GLM-5.3’s Duozer Mk VII uses a foam dome intended to shed climbing opponents: “a climber gets a single low-friction contact point on a convex surface and slides off.” Its Widowmaker uses one flipper for both attack and recovery, with the stated purpose of being able to “throw opponents and self-right the robot.” Hardware changes under refinement. Defensive features appear more frequently in refinement than in the sampled comparison set. The reported share of robots with skirts increases from 29% to 51%, and domed roofs from 3% to 7%. Individual histories show models adding and changing mechanisms. Claude Fable 5.1’s first run begins with the single-ended Groundhog and adds a second ramp at revision four as Janus Anvil. The revised robot also carries a swinging 320 kg tungsten weight, which the model describes as shifting its center of mass “to win stalls, timers and tiebreaks.” Every revision from the fourth onward qualifies 3–0, and revision nine is selected with a 38–16 record in the run’s selection round robin. Hardware failures. Intended advantages do not always translate into functioning designs. 19 Nine of GPT-6 Astra’s sixteen sampled sphere-drive lifters fail qualification, mostly through size violations or inactivity. Its Omnidirectional Traction Thief has spheres that, according to the rationale, “protrude above and below the fixed chassis” for “bidirectional survivability.” However, it loses all three qualification rounds because its dimensions exceed the allowed box during movement. 6.4 Controller Analysis Controllers determine how robots use their hardware during a match. They receive observations of both robots and the arena, allowing them to respond to the opponent’s movement, contact with other surfaces, and the conditions that determine a loss. We examine how models use this information to choose tactics and control their robots. Decision structure. In the refinement runs, 63% of controllers organize their behavior into distinct modes and use explicit conditions to switch between them. Across the controller corpus, we identify 209 distinct mode names, includingchase,flank,dump,wiggle,wheelie,holdout, andactivity_win. Controller examples range from 71 lines for Grok 4.20 to 1,700 lines for GPT-5.4. Responding to the opponent. Models use the opponent’s observable hardware to choose how to engage. GPT-6 Astra inspects the opponent’s motors and treats a hinge with torque above 1,800 N·m as a potential weapon before choosing an approach. It also calculates where to intercept the opponent rather than directing the robot toward the opponent’s current position. GLM-5.3 classifies opponents as spinners, flyers, or robots that stay near the edge. Against a flying opponent it cannot reach, the controller patrols the center and relies on the opponent’s inactivity timer to determine the outcome. Using the game rules. Several controllers choose actions based on which robot is closer to losing through inactivity. Claude Fable 5.1 holds still when the opponent stopped first, retreats when the opponent moves, and raises its mast while holding position to target the center-of-mass height tie-break. Kimi K3 maintains a pin when the opponent’s inactivity timer will expire first. These decisions make the timing of movement part of the competitive strategy: releasing an opponent or continuing to push is not always preferable to holding position. Controlling grip and avoiding the edge. Controllers also account for the physical limits of their hardware. Claude Fable 5.1 uses contact measurements to estimate the weight supported by each wheel and limits motor torque according to the grip available from the rubber wheels. Grok 4.6 calculates edge clearance using the robot’s rectangular outline, accounting for corners that could extend beyond the platform. Kimi K3 brakes near the edge with the aim of letting the opponent’s momentum carry it off while keeping its own robot on the platform. Responding to inversion. Some controllers change their commands when the robot is overturned. Gemini 3.1 Pro reverses its drum when inverted so that the exposed surface continues to strike upward. GPT-5.6 Sol’s Tungsten Undertow similarly detects inversion and reverses its wheel commands. These behaviors complement hardware designed to remain useful in more than one orientation. 20 6.5 Elo Calculation We report Bradley–Terry (BT) strengths on the Elo scale. Artifactihas ratingR i , and the probability that i beats j is P(i≻ j) = 1 1 + 10 −(R i −R j )/400 = σ(θ i − θ j ), R i = 1000 + 400 ln 10 θ i ,(1) whereσis the logistic function andθ i is the BT log-strength. Thus a 400-point gap corresponds to 10:1 odds. Each game counts as a win (1), draw ( 1 2 ) or loss (0), with both starting sides included. Because BT strengths are identifiable only up to an additive constant, we report the maximum a posteriori estimate under an independent priorR i ∼N(1000,800 2 ). At this optimum the mean rating of every fit is exactly 1000, which fixes the offset. 21 6.6 Tournament results 1539 1352 1310 1260 1223 1210 1189 1188 1179 1173 1165 1164 1143 1136 1093 1090 1088 1086 1070 1059 1055 1050 1050 1034 1019 1014 1010 1000 999 986 984 981 978 966 964 963 958 957 945 944 940 934 931 928 927 913 905 883 855 850 796 765 765 745 726 720 672 593 577 Champion Round Elo GPT-6 AstraGPT-6 Astra Claude Fable 5.1Claude Fable 5.1 Gemini 3.8 Flash Claude Fable 5.1 Claude Fable 5 GPT-6 Astra GPT-5.4 GPT-5.3 Codex GPT-5.6 Sol Kimi K3 Gemini 3.8 Flash Grok 4.6 GPT-5.6 Terra Claude Fable 5 Gemini 3.1 ProGemini 3.1 Pro GPT-5.4 Grok 4.6 Qwen3.8 2.4T GLM 5.2 Qwen3.8 2.4T GPT-5.3 Codex Gemini 3.1 Pro Claude Fable 5 GPT-5.6 Terra Kimi K3 GPT-5.6 Sol Sonnet 5 GPT-5.6 Luna GLM 5.2GLM 5.3 GPT-5.5 GPT-5.6 Sol GPT-5.5 Qwen3.8 2.4T Grok 4.5 GPT-5.4 GPT-5.3 Codex GLM 5.2 Gemini 3.8 Flash GPT-5.5 Opus 4.8 GPT-5.6 Terra GLM 5.3 Opus 4.8 Sonnet 5 GPT-5.6 Luna Sonnet 5 Grok 4.5 DeepSeek V4 Pro Opus 4.8 Grok 4.20 DeepSeek V4 Pro Grok 4.20Grok 4.20 GPT-5.6 Luna DeepSeek V4 Pro Model GPT-6 Astra GPT-6 Astra Claude Fable 5.1 Claude Fable 5.1 Gemini 3.8 Flash Claude Fable 5.1 Claude Fable 5 GPT-6 Astra GPT-5.4 GPT-5.3 Codex GPT-5.6 Sol Kimi K3 Gemini 3.8 Flash Grok 4.6 GPT-5.6 Terra Claude Fable 5 Gemini 3.1 Pro Gemini 3.1 Pro GPT-5.4 Grok 4.6 Qwen3.8 2.4T GLM 5.2 Qwen3.8 2.4T GPT-5.3 Codex Gemini 3.1 Pro Claude Fable 5 GPT-5.6 Terra Kimi K3 GPT-5.6 Sol Sonnet 5 GPT-5.6 Luna GLM 5.2 GLM 5.3 GPT-5.5 GPT-5.6 Sol GPT-5.5 Qwen3.8 2.4T Grok 4.5 GPT-5.4 GPT-5.3 Codex GLM 5.2 Gemini 3.8 Flash GPT-5.5 Opus 4.8 GPT-5.6 Terra GLM 5.3 Opus 4.8 Sonnet 5 GPT-5.6 Luna Sonnet 5 Grok 4.5 DeepSeek V4 Pro Opus 4.8 Grok 4.20 DeepSeek V4 Pro Grok 4.20 Grok 4.20 GPT-5.6 Luna DeepSeek V4 Pro Model VGH VGH SH SH VGH VGH SH SH VGH VGH DLH DLH DLH DLH DLH DLH SH SH VGH VGH SH SH VGH VGH SH SH VGH VGH VGH VGH VGH VGH SH SH DLH DLH VGH VGH SH SH VGH VGH VGH VGH SH SH DLH DLH VGH VGH SH SH SH SH SH SH VGH VGH VGH VGH VGH VGH SH SH DLH DLH SH SH DLH DLH VGH VGH DLH DLH VGH VGH DLH DLH SH SH DLH DLH DLH DLH DLH DLH VGH VGH DLH DLH VGH VGH SH SH SH SH DLH DLH DLH DLH SH SH VGH VGH DLH DLH VGH VGH SH SH DLH DLH SH SH SH SH DLH DLH 0 model loses all 0.250.5 even 0.751 model wins all (wins + ½ draws) / games SH = Sampling, VGH = Verifier-Grounded Refinement, DLH = Design Lab (a) All harnesses 1352 1260 1179 1165 1143 1088 1059 1050 1014 1010 1000 981 966 944 905 883 796 726 672 593 Champion Round Elo GPT-6 Astra Claude Fable 5.1 GPT-5.4 GPT-5.6 Sol Gemini 3.8 Flash Gemini 3.1 Pro Grok 4.6 Qwen3.8 2.4T Claude Fable 5 GPT-5.6 Terra Kimi K3 GLM 5.2 GPT-5.5 GPT-5.3 Codex Opus 4.8 Sonnet 5 Grok 4.5 DeepSeek V4 Pro Grok 4.20 GPT-5.6 Luna Model GPT-6 Astra Claude Fable 5.1 GPT-5.4 GPT-5.6 Sol Gemini 3.8 Flash Gemini 3.1 Pro Grok 4.6 Qwen3.8 2.4T Claude Fable 5 GPT-5.6 Terra Kimi K3 GLM 5.2 GPT-5.5 GPT-5.3 Codex Opus 4.8 Sonnet 5 Grok 4.5 DeepSeek V4 Pro Grok 4.20 GPT-5.6 Luna Model 0 model loses all 0.250.5 even 0.751 model wins all (wins + ½ draws) / games (b) Sampling (SH) 1539 1310 1223 1173 1164 1136 1093 1090 1070 1055 1050 1019 999 986 984 963 957 928 913 765 745 Champion Round Elo GPT-6 Astra Claude Fable 5.1 Gemini 3.8 Flash GPT-5.3 Codex Kimi K3 Grok 4.6 GPT-5.6 Terra Claude Fable 5 GPT-5.4 Qwen3.8 2.4T GLM 5.2 Gemini 3.1 Pro GPT-5.6 Sol Sonnet 5 GPT-5.6 Luna GPT-5.5 Grok 4.5 Opus 4.8 GLM 5.3 DeepSeek V4 Pro Grok 4.20 Model GPT-6 Astra Claude Fable 5.1 Gemini 3.8 Flash GPT-5.3 Codex Kimi K3 Grok 4.6 GPT-5.6 Terra Claude Fable 5 GPT-5.4 Qwen3.8 2.4T GLM 5.2 Gemini 3.1 Pro GPT-5.6 Sol Sonnet 5 GPT-5.6 Luna GPT-5.5 Grok 4.5 Opus 4.8 GLM 5.3 DeepSeek V4 Pro Grok 4.20 Model 0 model loses all 0.250.5 even 0.751 model wins all (wins + ½ draws) / games (c) Verifier-Grounded Refinement (VGH) 1210 1189 1188 1086 1034 978 964 958 945 940 934 931 927 855 850 765 720 577 Champion Round Elo Claude Fable 5.1 Claude Fable 5 GPT-6 Astra Gemini 3.1 Pro GPT-5.3 Codex GLM 5.3 GPT-5.6 Sol Qwen3.8 2.4T GPT-5.4 GLM 5.2 Gemini 3.8 Flash GPT-5.5 GPT-5.6 Terra GPT-5.6 Luna Sonnet 5 Opus 4.8 Grok 4.20 DeepSeek V4 Pro Model Claude Fable 5.1 Claude Fable 5 GPT-6 Astra Gemini 3.1 Pro GPT-5.3 Codex GLM 5.3 GPT-5.6 Sol Qwen3.8 2.4T GPT-5.4 GLM 5.2 Gemini 3.8 Flash GPT-5.5 GPT-5.6 Terra GPT-5.6 Luna Sonnet 5 Opus 4.8 Grok 4.20 DeepSeek V4 Pro Model 0 model loses all 0.250.5 even 0.751 model wins all (wins + ½ draws) / games (d) Design Lab (DLH) Figure 8: Champion Round head-to-head results. Each matrix shows every pairing of cell champions (the best artifact of each model under each harness). Cell (i,j) is the score of the row model against the column model, (wins+ 1 2 draws)/gamescell (j,i) = 1−cell (i,j), and the hatched diagonal marks self-pairings, which are never played. Models are ordered by Champion Round Elo (right axis) (a) All 59 champions; grey boxes give each champion’s harness. (b–d) The same results restricted to pairings within a single harness. 22 6.7 Dichotomous Key Dichotomous Key 01 THE COMPLETE TREE Blue = Yes Orange = No Leaf label = ID / bot count Q01 Q02 Q03 Q04 Q05 M0160 / 2M0159 / 4 Q06 Q07 Q05 M0158 / 2 Q08 M0157 / 3M0156 / 3 Q05 Q09 M0155 / 1 Q10 M0154 / 4 Q11 M0153 / 1 Q12 M0152 / 2M0151 / 71 Q08 Q09 Q13 M0150 / 1M0149 / 6 Q14 M0148 / 1 Q12 M0147 / 3M0146 / 37 Q09 Q13 M0145 / 7 Q14 M0144 / 3 Q12 M0143 / 1M0142 / 33 Q10 Q14 M0141 / 2 Q15 M0140 / 12M0139 / 2 Q14 Q16 Q15 Q11 M0138 / 2 Q12 M0137 / 2M0136 / 38M0135 / 1M0134 / 1 Q15 Q11 M0133 / 5 Q12 M0132 / 6M0131 / 145M0130 / 5 Q07 M0129 / 1 Q05 M0128 / 2 Q14 M0127 / 11M0126 / 3 Q04 M0125 / 5 Q06 Q07 Q05 M0124 / 1 Q08 M0123 / 3 Q09 M0122 / 3 Q10 Q14 M0121 / 2M0120 / 4 Q12 M0119 / 2M0118 / 4 Q05 Q10 M0117 / 3 Q15 Q12 M0116 / 4M0115 / 31M0114 / 1 Q08 Q09 M0113 / 1 Q10 M0112 / 1 Q14 M0111 / 2 Q15 Q12 M0110 / 1M0109 / 15M0108 / 1 Q09 Q14 M0107 / 4 Q16 Q15 Q12 M0106 / 12M0105 / 26M0104 / 1M0103 / 2 Q10 Q14 M0102 / 5 Q15 Q12 M0101 / 4M0100 / 20M0099 / 4 Q14 Q16 Q15 Q11 M0098 / 1 Q12 M0097 / 12M0096 / 99M0095 / 1M0094 / 3 Q16 Q15 Q11 M0093 / 4 Q12 M0092 / 36M0091 / 305M0090 / 4M0089 / 1 Q14 Q11 M0088 / 2M0087 / 25 Q15 M0086 / 13M0085 / 2 Q03 Q17 Q06 Q07 Q08 M0084 / 2 Q09 M0083 / 5 Q10 M0082 / 1M0081 / 5 Q05 M0080 / 2 Q08 M0079 / 22 Q09 Q13 M0078 / 7 Q14 M0077 / 2M0076 / 64 Q10 Q14 M0075 / 1M0074 / 9 Q18 M0073 / 2 Q14 M0072 / 38M0071 / 220 Q14 M0070 / 7M0069 / 4M0068 / 1 Q06 Q07 Q05 M0067 / 1 Q09 M0066 / 1 Q19 M0065 / 1M0064 / 5 Q05 Q09 M0063 / 2M0062 / 7 Q08 M0061 / 8 Q09 Q13 M0060 / 3M0059 / 59 Q10 Q14 M0058 / 3M0057 / 6 Q18 M0056 / 2 Q14 Q12 M0055 / 4M0054 / 246 Q15 Q12 M0053 / 6M0052 / 466M0051 / 1 Q14 Q19 M0050 / 2M0049 / 52M0048 / 12 Q20 M0047 / 3 Q03 Q04 M0046 / 1 Q06 Q07 M0045 / 3 Q05 Q08 M0044 / 1M0043 / 11 Q08 Q09 M0042 / 1 Q12 M0041 / 1M0040 / 12 Q09 Q13 M0039 / 5 Q14 M0038 / 1 Q15 M0037 / 15M0036 / 1 Q10 Q14 M0035 / 2 Q19 M0034 / 1M0033 / 10 Q14 Q12 M0032 / 1M0031 / 8 Q12 M0030 / 2M0029 / 31M0028 / 3 Q17 Q06 Q07 Q05 M0027 / 2 Q09 Q13 M0026 / 1M0025 / 5 Q10 M0024 / 3M0023 / 4 Q05 Q09 M0022 / 2 Q10 M0021 / 1M0020 / 6 Q08 Q09 M0019 / 1M0018 / 11 Q09 Q12 M0017 / 8M0016 / 23 Q10 Q14 M0015 / 1 Q15 Q12 M0014 / 1M0013 / 7M0012 / 1 Q14 Q16 Q19 M0011 / 1 Q12 M0010 / 2M0009 / 10M0008 / 1 Q19 M0007 / 1 Q12 M0006 / 15M0005 / 99 Q07 M0004 / 2 Q14 M0003 / 5M0002 / 3M0001 / 1 02 QUESTION INDEX Q01 Does it have a wedge or ramp? Q02 Is the wedge mounted on a jointed assembly? Q03 Does it have projecting forks or long prongs? Q04 Does it have jointed, multi-segment appendages? Q05 Does it have a ball joint? Q06 Does it have four or more wheel-like supports? Q07 Does it have a sliding joint? Q08 Are moving parts connected in a chain? Q09 Does it have six or more wheel-like supports? Q10 Do six or more moving assemblies attach to the chassis? Q11 Do moving parts extend far beyond the chassis? Q12 Is the main chassis raised clearly above the lowest parts? Q13 Does it have eight or more wheel-like supports? Q14 Are the wheels at least a quarter of the bot’s length across? Q15 Does the chassis span at least half the bot’s length? Q16 Does the chassis span at least half the bot’s width? Q17 Does it have round wheels or rollers? Q18 Is it at least twice as long as it is wide? Q19 Is it at least half as tall as it is long? Q20 Does a ring-like structure surround the chassis? 03 EVERY CLASSIFIED BOT Read down each column, then move right. Each bot appears once. Thumbnails link to its live classification path. F51 Claude Fable 5.1 (240)F50 Claude Fable 5 (245)O48 Claude Opus 4.8 (243)O50 Claude Opus 5 (109)S50 Claude Sonnet 5 (239)G54 GPT-5.4 (241) G55 GPT-5.5 (245)SOL GPT-5.6 Sol (244)A6 GPT-6 Astra (250)GR Grok 4.6 (217)K3 Kimi K3 (191)QW Qwen 3.8 (238) M0160 2 bots Wedge / ramp + Forks / prongs + Jointed appendages PATH Y A6 t52A6 t86 M0159 4 bots Wedge / ramp + Forks / prongs + Jointed appendages PATH YYYYN A6 t01A6 t136A6 t229A6 t234 M0158 2 bots Wedge / ramp + Forks / prongs PATH YYYNYYY A6 t58A6 t220 M0157 3 bots Wedge / ramp + Forks / prongs PATH YYYNYYNY A6 t27A6 t162GR t38 M0156 3 bots Wedge / ramp + Forks / prongs PATH YYYNYYNN F51 t101G54 t01A6 t171 M0155 1 bots Wedge / ramp + Forks / prongs PATH YYYNYNYY A6 t81 M0154 4 bots Wedge / ramp + Forks / prongs PATH YYYNYNYNY A6 t20A6 t61A6 t64A6 t210 M0153 1 bots Wedge / ramp + Forks / prongs PATH YYYNYNYNNY A6 t123 M0152 2 bots Wedge / ramp + Forks / prongs PATH YYYNYNYNNNY A6 t80A6 t179 M0151 1-48 of 71 Wedge / ramp + Forks / prongs PATH YYYNYNYNNNN SOL t92A6 t03A6 t05A6 t07A6 t08A6 t10A6 t11A6 t12 A6 t13A6 t17A6 t19A6 t29A6 t30A6 t36A6 t39A6 t42 A6 t45A6 t48A6 t49A6 t50A6 t51A6 t53A6 t54A6 t72 A6 t73A6 t74A6 t75A6 t78A6 t79A6 t83A6 t85A6 t89 A6 t90A6 t96A6 t98A6 t100A6 t101A6 t110A6 t112A6 t115 A6 t118A6 t119A6 t120A6 t121A6 t127A6 t140A6 t142A6 t148 M0151 49-71 of 71 Wedge / ramp + Forks / prongs PATH YYYNYNYNNNN / continued A6 t152A6 t158A6 t160A6 t163A6 t166A6 t173A6 t182A6 t185 A6 t188A6 t191A6 t195A6 t204A6 t205A6 t217A6 t219A6 t221 A6 t222A6 t223A6 t224A6 t225A6 t228A6 t237A6 t239 M0150 1 bots Wedge / ramp + Forks / prongs PATH YYYNYNNYYY G55 t93 M0149 6 bots Wedge / ramp + Forks / prongs PATH YYYNYNNYYN G55 t51G55 t59G55 t129G55 t165G55 t179G55 t214 M0148 1 bots Wedge / ramp + Forks / prongs PATH YYYNYNNYNY A6 t09 M0147 3 bots Wedge / ramp + Forks / prongs PATH YYYNYNNYNNY G55 t31G55 t166GR t112 M0146 37 bots Wedge / ramp + Forks / prongs PATH YYYNYNNYNNN G55 t13G55 t55G55 t60G55 t106G55 t134SOL t205A6 t18A6 t31 A6 t33A6 t34A6 t46A6 t56A6 t65A6 t66A6 t94A6 t108 A6 t122A6 t124A6 t129A6 t137A6 t143A6 t157A6 t180A6 t193 A6 t197A6 t202A6 t216A6 t218A6 t227A6 t230A6 t242GR t65 GR t88GR t117GR t139GR t220GR t246 M0145 7 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNYY F51 t36G55 t05G55 t65G55 t70G55 t131G55 t160G55 t177 M0144 3 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNYNY G55 t03G55 t10G55 t216 M0143 1 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNYNNY G55 t89 M0142 33 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNYNNN F51 t121O50 t58G55 t00G55 t18G55 t19G55 t27G55 t36G55 t45 G55 t64G55 t75G55 t84G55 t99G55 t108G55 t109G55 t110G55 t114 G55 t121G55 t135G55 t143G55 t148G55 t168G55 t175G55 t192G55 t194 G55 t210G55 t225G55 t229G55 t247GR t48GR t81GR t146GR t149 GR t230 M0141 2 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNYY G55 t201A6 t88 M0140 12 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNYNY F51 t156F51 t189F51 t211F50 t243O50 t06O50 t127G55 t76A6 t139 A6 t153A6 t232A6 t243GR t21 M0139 2 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNYNN GR t187GR t226 M0138 2 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNYYYY SOL t15SOL t126 M0137 2 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNYYYNY G54 t126SOL t37 M0136 38 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNYYYNN O50 t30O50 t36O50 t44O50 t67O50 t112O50 t117G54 t53G54 t61 G54 t78G54 t83G54 t95G54 t102G54 t134G54 t146G54 t153G54 t158 G54 t167G54 t195G54 t199G54 t205G54 t209G54 t230G55 t78G55 t115 G55 t234SOL t101SOL t116SOL t158SOL t188SOL t241A6 t24A6 t76 A6 t95A6 t105A6 t128A6 t146A6 t178A6 t246 M0135 1 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNYYN G54 t103 M0134 1 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNYN G54 t192 M0133 5 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNNYY G54 t15G54 t60G54 t143G54 t165SOL t139 M0132 6 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNNYNY F50 t43G54 t10G55 t119SOL t06SOL t99A6 t155 M0131 1-48 of 145 Wedge / ramp + Forks / prongs PATH YYYNYNNNNNNYNN F51 t12F51 t20F51 t52F51 t61F51 t62F51 t71F51 t81F51 t83 F51 t95F51 t119F51 t132F51 t143F51 t150F51 t159F51 t174F51 t179 F51 t182F51 t186F51 t193F51 t199F51 t209F51 t210F51 t216F51 t226 F51 t233F51 t234F51 t244F51 t248F50 t76F50 t96F50 t234O50 t04 O50 t26O50 t33O50 t40O50 t50O50 t55O50 t69O50 t80O50 t81 O50 t87O50 t92O50 t94O50 t106O50 t115O50 t121O50 t142O50 t144 M0131 49-96 of 145 Wedge / ramp + Forks / prongs PATH YYYNYNNNNNNYNN / continued O50 t148O50 t156O50 t160O50 t167S50 t14S50 t114S50 t245S50 t247 G54 t05G54 t16G54 t35G54 t37G54 t47G54 t73G54 t89G54 t96 G54 t122G54 t128G54 t129G54 t132G54 t139G54 t166G54 t188G54 t202 G54 t222G54 t236G55 t04G55 t16G55 t48G55 t96G55 t136G55 t156 G55 t159G55 t167G55 t186G55 t198G55 t208G55 t220SOL t31SOL t33 SOL t86SOL t94SOL t105SOL t106SOL t119SOL t130SOL t133SOL t156 M0131 97-144 of 145 Wedge / ramp + Forks / prongs PATH YYYNYNNNNNNYNN / continued SOL t170SOL t177SOL t207SOL t209SOL t222SOL t235A6 t00A6 t04 A6 t06A6 t28A6 t44A6 t82A6 t91A6 t126A6 t131A6 t133 A6 t154A6 t161A6 t165A6 t168A6 t175A6 t186A6 t190A6 t206 A6 t208A6 t213A6 t214A6 t233A6 t245A6 t247GR t32GR t34 GR t37GR t53GR t62GR t63GR t76GR t97GR t118GR t127 GR t153GR t156GR t183GR t190GR t192GR t194GR t224GR t239 M0131 145-145 of 145 Wedge / ramp + Forks / prongs PATH YYYNYNNNNNNYNN / continued QW t109 M0130 5 bots Wedge / ramp + Forks / prongs PATH YYYNYNNNNNNN O50 t34G54 t131G55 t95SOL t186GR t142 M0129 1 bots Wedge / ramp + Forks / prongs PATH YYYNNY QW t231 M0128 2 bots Wedge / ramp + Forks / prongs PATH YYYNNNY SOL t107SOL t245 M0127 11 bots Wedge / ramp + Forks / prongs PATH YYYNNNNY O50 t21O50 t28O50 t56O50 t76O50 t84O50 t88O50 t140O50 t173 G54 t52G54 t91G54 t223 M0126 3 bots Wedge / ramp + Forks / prongs PATH YYYNNNNN O50 t114G54 t98G54 t229 M0125 5 bots Wedge / ramp + Jointed appendages PATH YYNY F51 t31F51 t55A6 t25A6 t99A6 t113 M0124 1 bots Wedge / ramp PATH YYNNYYY QW t115 M0123 3 bots Wedge / ramp PATH YYNNYYNY A6 t170A6 t212A6 t240 M0122 3 bots Wedge / ramp PATH YYNNYYNNY QW t63QW t202QW t226 M0121 2 bots Wedge / ramp PATH YYNNYYNNNYY G54 t185G55 t54 M0120 4 bots Wedge / ramp PATH YYNNYYNNNYN F51 t09F51 t154F51 t155G54 t164 M0119 2 bots Wedge / ramp PATH YYNNYYNNNNY QW t49QW t61 M0118 4 bots Wedge / ramp PATH YYNNYYNNNNN F51 t115QW t36QW t38QW t120 M0117 3 bots Wedge / ramp PATH YYNNYNYY A6 t62A6 t183A6 t249 M0116 4 bots Wedge / ramp PATH YYNNYNYNYY SOL t219A6 t102A6 t150A6 t184 M0115 31 bots Wedge / ramp PATH YYNNYNYNYN SOL t225A6 t14A6 t16A6 t23A6 t26A6 t35A6 t43A6 t69 A6 t70A6 t93A6 t103A6 t104A6 t107A6 t109A6 t114A6 t117 A6 t130A6 t132A6 t138A6 t151A6 t159A6 t167A6 t169A6 t172 A6 t177A6 t187A6 t189A6 t203A6 t207A6 t235A6 t241 M0114 1 bots Wedge / ramp PATH YYNNYNYNN A6 t211 M0113 1 bots Wedge / ramp PATH YYNNYNNYY G55 t24 M0112 1 bots Wedge / ramp PATH YYNNYNNYNY QW t124 M0111 2 bots Wedge / ramp PATH YYNNYNNYNNY SOL t175A6 t38 M0110 1 bots Wedge / ramp PATH YYNNYNNYNNNYY G55 t12 M0109 15 bots Wedge / ramp PATH YYNNYNNYNNNYN G55 t187A6 t32A6 t37A6 t40A6 t57A6 t67A6 t71A6 t84 A6 t106A6 t135A6 t147A6 t196A6 t201A6 t215GR t185 M0108 1 bots Wedge / ramp PATH YYNNYNNYNNNN A6 t200 M0107 4 bots Wedge / ramp PATH YYNNYNNNYY G55 t29G55 t35SOL t108SOL t206 M0106 12 bots Wedge / ramp PATH YYNNYNNNYNYYY S50 t46S50 t124G55 t77G55 t138G55 t204K3 t108QW t01QW t14 QW t23QW t82QW t132QW t135 M0105 26 bots Wedge / ramp PATH YYNNYNNNYNYYN F51 t123F51 t167F51 t227O50 t24S50 t186S50 t232S50 t240G55 t20 G55 t63G55 t74G55 t82G55 t92G55 t130G55 t140G55 t149G55 t151 G55 t157G55 t191G55 t211G55 t217GR t93GR t106QW t08QW t16 QW t164QW t185 M0104 1 bots Wedge / ramp PATH YYNNYNNNYNYN GR t23 M0103 2 bots Wedge / ramp PATH YYNNYNNNYNN GR t82GR t207 M0102 5 bots Wedge / ramp PATH YYNNYNNNNYY O50 t103G54 t206SOL t131SOL t221A6 t15 M0101 4 bots Wedge / ramp PATH YYNNYNNNNYNYY F50 t124GR t198QW t130QW t219 M0100 20 bots Wedge / ramp PATH YYNNYNNNNYNYN F51 t01F51 t15F51 t39F51 t43F51 t50F51 t53F51 t99F51 t104 F51 t112F51 t120F51 t127F51 t145F51 t178F51 t206F50 t77O50 t172 S50 t63G55 t61G55 t122G55 t237 M0099 4 bots Wedge / ramp PATH YYNNYNNNNYNN F51 t138O50 t147GR t14GR t248 M0098 1 bots Wedge / ramp PATH YYNNYNNNNNYYYY SOL t166 M0097 12 bots Wedge / ramp PATH YYNNYNNNNNYYYNY S50 t113G54 t70G54 t177SOL t09SOL t10SOL t29SOL t53SOL t54 SOL t55SOL t146SOL t247A6 t02 M0096 1-48 of 99 Wedge / ramp PATH YYNNYNNNNNYYYNN F50 t126F50 t169O50 t02O50 t13O50 t29O50 t32O50 t38O50 t41 O50 t61O50 t63O50 t66O50 t78O50 t98O50 t120O50 t149S50 t00 S50 t25S50 t230G54 t00G54 t03G54 t04G54 t26G54 t28G54 t38 G54 t45G54 t56G54 t59G54 t77G54 t81G54 t86G54 t115G54 t136 G54 t144G54 t148G54 t168G54 t169G54 t172G54 t175G54 t198G54 t204 G54 t207G54 t208G54 t216G54 t231G54 t233G54 t243G54 t244G55 t227 M0096 49-96 of 99 Wedge / ramp PATH YYNNYNNNNNYYYNN / continued SOL t05SOL t17SOL t20SOL t23SOL t26SOL t27SOL t43SOL t44 SOL t58SOL t64SOL t67SOL t72SOL t83SOL t91SOL t95SOL t104 SOL t110SOL t112SOL t121SOL t124SOL t132SOL t134SOL t137SOL t140 SOL t143SOL t147SOL t151SOL t152SOL t153SOL t155SOL t160SOL t167 SOL t168SOL t172SOL t183SOL t184SOL t185SOL t199SOL t204SOL t210 SOL t214SOL t227SOL t228SOL t229SOL t242SOL t243SOL t246SOL t249 M0096 97-99 of 99 Wedge / ramp PATH YYNNYNNNNNYYYNN / continued A6 t68A6 t116K3 t120 M0095 1 bots Wedge / ramp PATH YYNNYNNNNNYYN SOL t56 M0094 3 bots Wedge / ramp PATH YYNNYNNNNNYN SOL t28SOL t103SOL t212 M0093 4 bots Wedge / ramp PATH YYNNYNNNNNNYYY F50 t187G54 t194G55 t219SOL t12 M0092 36 bots Wedge / ramp PATH YYNNYNNNNNNYYNY S50 t43S50 t49S50 t64S50 t75S50 t111S50 t129S50 t132S50 t220 G54 t43G54 t65G54 t113G54 t120G54 t210SOL t75SOL t135SOL t178 SOL t213SOL t232SOL t236K3 t33K3 t104K3 t179K3 t193QW t30 QW t32QW t53QW t83QW t133QW t141QW t144QW t151QW t162 QW t175QW t203QW t228QW t232 M0091 1-48 of 305 Wedge / ramp PATH YYNNYNNNNNNYYNN F51 t00F51 t02F51 t04F51 t06F51 t08F51 t11F51 t13F51 t14 F51 t16F51 t19F51 t21F51 t22F51 t23F51 t25F51 t27F51 t29 F51 t30F51 t32F51 t35F51 t37F51 t38F51 t41F51 t42F51 t44 F51 t45F51 t46F51 t49F51 t51F51 t54F51 t57F51 t58F51 t60 F51 t63F51 t64F51 t65F51 t66F51 t67F51 t69F51 t72F51 t73 F51 t74F51 t77F51 t82F51 t84F51 t88F51 t92F51 t93F51 t94 M0091 49-96 of 305 Wedge / ramp PATH YYNNYNNNNNNYYNN / continued F51 t96F51 t97F51 t100F51 t103F51 t105F51 t106F51 t108F51 t109 F51 t110F51 t111F51 t113F51 t114F51 t116F51 t117F51 t118F51 t122 F51 t124F51 t128F51 t129F51 t131F51 t133F51 t136F51 t137F51 t139 F51 t140F51 t144F51 t146F51 t148F51 t149F51 t151F51 t158F51 t160 F51 t161F51 t162F51 t163F51 t164F51 t166F51 t168F51 t169F51 t171 F51 t172F51 t173F51 t175F51 t176F51 t177F51 t180F51 t181F51 t187 M0091 97-144 of 305 Wedge / ramp PATH YYNNYNNNNNNYYNN / continued F51 t188F51 t195F51 t196F51 t197F51 t200F51 t201F51 t202F51 t207 F51 t212F51 t217F51 t219F51 t228F51 t229F51 t230F51 t236F51 t237 F51 t239F51 t243F51 t245F51 t246F51 t249F50 t11F50 t18F50 t27 F50 t29F50 t31F50 t44F50 t46F50 t53F50 t54F50 t57F50 t59 F50 t66F50 t74F50 t78F50 t79F50 t80F50 t81F50 t85F50 t104 F50 t105F50 t108F50 t112F50 t130F50 t131F50 t176F50 t177F50 t202 M0091 145-192 of 305 Wedge / ramp PATH YYNNYNNNNNNYYNN / continued F50 t218F50 t224O50 t00O50 t18O50 t19O50 t35O50 t39O50 t43 O50 t47O50 t49O50 t51O50 t59O50 t60O50 t65O50 t68O50 t72 O50 t82O50 t85O50 t89O50 t95O50 t97O50 t108O50 t124O50 t133 S50 t20S50 t27S50 t29S50 t51S50 t66S50 t73S50 t77S50 t88 S50 t90S50 t99S50 t101S50 t108S50 t134S50 t142S50 t149S50 t150 S50 t157S50 t161S50 t169S50 t171S50 t177S50 t222S50 t224S50 t225 M0091 193-240 of 305 Wedge / ramp PATH YYNNYNNNNNNYYNN / continued S50 t231S50 t233G54 t21G54 t39G54 t49G54 t63G54 t67G54 t71 G54 t80G54 t82G54 t85G54 t87G54 t93G54 t97G54 t99G54 t101 G54 t106G54 t111G54 t114G54 t124G54 t133G54 t147G54 t152G54 t173 G54 t180G54 t182G54 t183G54 t184G54 t189G54 t191G54 t193G54 t203 G54 t215G54 t227G54 t238G54 t239G54 t248G55 t23G55 t146G55 t154 G55 t161G55 t171G55 t174G55 t180G55 t196G55 t232SOL t00SOL t07 M0091 241-288 of 305 Wedge / ramp PATH YYNNYNNNNNNYYNN / continued SOL t21SOL t22SOL t35SOL t39SOL t42SOL t47SOL t48SOL t57 SOL t60SOL t61SOL t65SOL t77SOL t79SOL t80SOL t82SOL t88 SOL t102SOL t109SOL t117SOL t123SOL t127SOL t136SOL t138SOL t141 SOL t148SOL t149SOL t154SOL t157SOL t163SOL t164SOL t171SOL t179 SOL t180SOL t190SOL t196SOL t198SOL t200SOL t202SOL t203SOL t208 SOL t217SOL t218SOL t231SOL t233SOL t237SOL t248A6 t77A6 t156 M0091 289-305 of 305 Wedge / ramp PATH YYNNYNNNNNNYYNN / continued A6 t192A6 t194GR t59GR t172GR t176GR t214K3 t119K3 t126 K3 t141K3 t142K3 t154K3 t163K3 t225K3 t245QW t11QW t205 QW t212 M0090 4 bots Wedge / ramp PATH YYNNYNNNNNNYN SOL t24SOL t45SOL t76SOL t189 M0089 1 bots Wedge / ramp PATH YYNNYNNNNNNN SOL t19 M0088 2 bots Wedge / ramp PATH YYNNNYY O50 t107O50 t132 M0087 25 bots Wedge / ramp PATH YYNNNYN O48 t36O50 t71O50 t111O50 t118O50 t155S50 t98S50 t151S50 t176 S50 t193G54 t14G54 t23G54 t32G54 t34G54 t69G54 t100G54 t107 G54 t127G54 t155G54 t159G54 t161G54 t163G54 t211SOL t13SOL t32 SOL t187 M0086 13 bots Wedge / ramp PATH YYNNNNY O50 t17O50 t37O50 t62O50 t170S50 t123S50 t158G54 t06G54 t109 G54 t228SOL t215QW t27QW t131QW t160 M0085 2 bots Wedge / ramp PATH YYNNNNN S50 t131SOL t174 M0084 2 bots Wedge / ramp + Forks / prongs PATH YNYYYYY A6 t226GR t138 M0083 5 bots Wedge / ramp + Forks / prongs PATH YNYYYYNY G55 t32G55 t190GR t158GR t249QW t110 M0082 1 bots Wedge / ramp + Forks / prongs PATH YNYYYYNNY G55 t117 M0081 5 bots Wedge / ramp + Forks / prongs PATH YNYYYYNNN G54 t31G54 t112G54 t234G55 t202QW t117 M0080 2 bots Wedge / ramp + Forks / prongs PATH YNYYYNY G55 t26A6 t181 M0079 22 bots Wedge / ramp + Forks / prongs PATH YNYYYNNY GR t00GR t15GR t20GR t36GR t39GR t41GR t51GR t73 GR t74GR t80GR t99GR t129GR t131GR t160GR t162GR t163 GR t170GR t171GR t184GR t188GR t238GR t243 M0078 7 bots Wedge / ramp + Forks / prongs PATH YNYYYNNNYY G55 t17G55 t50G55 t68G55 t87G55 t101G55 t103G55 t105 M0077 2 bots Wedge / ramp + Forks / prongs PATH YNYYYNNNYNY G54 t235G55 t224 M0076 1-48 of 64 Wedge / ramp + Forks / prongs PATH YNYYYNNNYNN F51 t26S50 t04S50 t06S50 t13S50 t24S50 t37S50 t53S50 t198 S50 t201S50 t228G55 t08G55 t09G55 t15G55 t22G55 t33G55 t34 G55 t43G55 t44G55 t47G55 t57G55 t67G55 t80G55 t81G55 t86 G55 t90G55 t94G55 t104G55 t107G55 t113G55 t137G55 t141G55 t145 G55 t155G55 t158G55 t162G55 t169G55 t170G55 t178G55 t183G55 t189 G55 t207G55 t228G55 t230G55 t244GR t01GR t29GR t56GR t85 M0076 49-64 of 64 Wedge / ramp + Forks / prongs PATH YNYYYNNNYNN / continued GR t140GR t151GR t154GR t166GR t180GR t182GR t191GR t197 GR t216GR t221GR t228GR t234K3 t173QW t142QW t147QW t218 M0075 1 bots Wedge / ramp + Forks / prongs PATH YNYYYNNNNYY G54 t44 M0074 9 bots Wedge / ramp + Forks / prongs PATH YNYYYNNNNYN G55 t06G55 t83G55 t116G55 t124G55 t139G55 t209A6 t41GR t96 K3 t32 M0073 2 bots Wedge / ramp + Forks / prongs PATH YNYYYNNNNNY F50 t141G54 t140 M0072 38 bots Wedge / ramp + Forks / prongs PATH YNYYYNNNNNNY O50 t126S50 t60S50 t138S50 t204G54 t07G54 t11G54 t41G54 t64 G54 t74G54 t90G54 t105G54 t118G54 t121G54 t130G54 t137G54 t142 G54 t154G54 t178G54 t181G54 t197G54 t217G55 t37G55 t73G55 t222 SOL t89SOL t161SOL t176SOL t230SOL t239K3 t130K3 t133K3 t182 K3 t183K3 t207K3 t215K3 t228K3 t239K3 t246 M0071 1-48 of 220 Wedge / ramp + Forks / prongs PATH YNYYYNNNNNNN F51 t03F51 t47F51 t48F51 t59F51 t75F51 t80F51 t87F51 t184 F51 t185F51 t203F51 t222F51 t247F50 t02F50 t03F50 t04F50 t06 F50 t14F50 t23F50 t28F50 t33F50 t49F50 t58F50 t60F50 t65 F50 t68F50 t75F50 t82F50 t86F50 t89F50 t90F50 t93F50 t94 F50 t99F50 t107F50 t111F50 t114F50 t115F50 t116F50 t118F50 t121 F50 t123F50 t127F50 t132F50 t135F50 t140F50 t142F50 t147F50 t148 M0071 49-96 of 220 Wedge / ramp + Forks / prongs PATH YNYYYNNNNNNN / continued F50 t154F50 t156F50 t163F50 t170F50 t174F50 t179F50 t182F50 t188 F50 t194F50 t198F50 t199F50 t206F50 t211F50 t214F50 t216F50 t226 F50 t236O48 t55O50 t139S50 t17S50 t18S50 t22S50 t32S50 t55 S50 t57S50 t61S50 t67S50 t68S50 t71S50 t72S50 t80S50 t85 S50 t89S50 t96S50 t97S50 t103S50 t120S50 t137S50 t141S50 t155 S50 t160S50 t178S50 t180S50 t196S50 t208S50 t226S50 t227S50 t234 M0071 97-144 of 220 Wedge / ramp + Forks / prongs PATH YNYYYNNNNNNN / continued S50 t235G54 t19G54 t20G54 t22G54 t30G54 t54G54 t79G54 t116 G54 t117G54 t214G54 t240G55 t01G55 t46G55 t125G55 t144G55 t152 G55 t153G55 t203G55 t248SOL t30SOL t69SOL t84SOL t111SOL t122 SOL t234SOL t238GR t02GR t03GR t04GR t05GR t08GR t13 GR t16GR t17GR t19GR t22GR t24GR t25GR t26GR t28 GR t40GR t43GR t44GR t45GR t52GR t55GR t57GR t60 M0071 145-192 of 220 Wedge / ramp + Forks / prongs PATH YNYYYNNNNNNN / continued GR t67GR t70GR t77GR t83GR t86GR t89GR t91GR t98 GR t101GR t103GR t107GR t111GR t113GR t123GR t125GR t136 GR t143GR t168GR t169GR t174GR t177GR t178GR t186GR t189 GR t193GR t195GR t202GR t203GR t206GR t208GR t211GR t212 GR t213GR t215GR t219GR t223GR t236K3 t00K3 t04K3 t17 K3 t20K3 t34K3 t38K3 t45K3 t49K3 t58K3 t72K3 t78 M0071 193-220 of 220 Wedge / ramp + Forks / prongs PATH YNYYYNNNNNNN / continued K3 t89K3 t103K3 t106K3 t109K3 t125K3 t128K3 t149K3 t151 K3 t166K3 t167K3 t177K3 t184K3 t192K3 t200K3 t209K3 t212 K3 t214K3 t223K3 t232K3 t234K3 t236K3 t237K3 t240K3 t244 QW t57QW t74QW t159QW t178 M0070 7 bots Wedge / ramp + Forks / prongs PATH YNYYNY O50 t09O50 t86O50 t109G54 t58G54 t92G54 t218G54 t232 M0069 4 bots Wedge / ramp + Forks / prongs PATH YNYYNN S50 t115S50 t179S50 t242GR t110 M0068 1 bots Wedge / ramp + Forks / prongs PATH YNYN K3 t27 M0067 1 bots Wedge / ramp PATH YNNYYY QW t245 M0066 1 bots Wedge / ramp PATH YNNYYNY G55 t223 M0065 1 bots Wedge / ramp PATH YNNYYNNY QW t84 M0064 5 bots Wedge / ramp PATH YNNYYNNN QW t76QW t78QW t189QW t196QW t204 M0063 2 bots Wedge / ramp PATH YNNYNYY QW t80QW t246 M0062 7 bots Wedge / ramp PATH YNNYNYN A6 t87QW t15QW t77QW t85QW t97QW t217QW t220 M0061 8 bots Wedge / ramp PATH YNNYNNY A6 t63GR t46GR t245QW t54QW t136QW t166QW t184QW t214 M0060 3 bots Wedge / ramp PATH YNNYNNNYY G55 t71G55 t126QW t194 M0059 1-48 of 59 Wedge / ramp PATH YNNYNNNYN F51 t28F51 t91F51 t147S50 t10S50 t45S50 t78S50 t133S50 t154 S50 t192S50 t223G54 t246G55 t28G55 t40G55 t58G55 t79G55 t100 G55 t112G55 t163G55 t185G55 t193G55 t195G55 t205G55 t221G55 t240 G55 t249GR t159GR t161GR t229K3 t136QW t07QW t21QW t35 QW t37QW t39QW t40QW t43QW t68QW t70QW t73QW t94 QW t95QW t96QW t105QW t106QW t118QW t122QW t128QW t137 M0059 49-59 of 59 Wedge / ramp PATH YNNYNNNYN / continued QW t158QW t173QW t188QW t192QW t200QW t201QW t209QW t210 QW t211QW t239QW t247 M0058 3 bots Wedge / ramp PATH YNNYNNNNYY G55 t88G55 t235SOL t113 M0057 6 bots Wedge / ramp PATH YNNYNNNNYN F51 t89F51 t240G55 t69G55 t206SOL t216GR t95 M0056 2 bots Wedge / ramp PATH YNNYNNNNNY F50 t229K3 t53 M0055 4 bots Wedge / ramp PATH YNNYNNNNNNYY O48 t90O48 t101O48 t212O48 t247 M0054 1-48 of 246 Wedge / ramp PATH YNNYNNNNNNYN F50 t41F50 t42F50 t72F50 t95F50 t172F50 t210F50 t213F50 t215 F50 t235F50 t241O48 t00O48 t01O48 t02O48 t03O48 t04O48 t05 O48 t06O48 t07O48 t08O48 t09O48 t10O48 t12O48 t13O48 t15 O48 t17O48 t18O48 t19O48 t20O48 t22O48 t23O48 t24O48 t25 O48 t26O48 t27O48 t28O48 t29O48 t30O48 t31O48 t33O48 t34 O48 t35O48 t38O48 t39O48 t40O48 t41O48 t42O48 t43O48 t44 M0054 49-96 of 246 Wedge / ramp PATH YNNYNNNNNNYN / continued O48 t45O48 t46O48 t47O48 t49O48 t50O48 t51O48 t52O48 t54 O48 t56O48 t57O48 t58O48 t60O48 t63O48 t65O48 t66O48 t67 O48 t69O48 t70O48 t71O48 t72O48 t74O48 t75O48 t76O48 t78 O48 t79O48 t80O48 t83O48 t84O48 t86O48 t87O48 t88O48 t91 O48 t92O48 t93O48 t95O48 t97O48 t98O48 t99O48 t100O48 t103 O48 t104O48 t105O48 t106O48 t107O48 t109O48 t110O48 t111O48 t113 M0054 97-144 of 246 Wedge / ramp PATH YNNYNNNNNNYN / continued O48 t115O48 t117O48 t119O48 t120O48 t122O48 t123O48 t125O48 t126 O48 t127O48 t128O48 t129O48 t130O48 t131O48 t132O48 t133O48 t134 O48 t135O48 t137O48 t138O48 t139O48 t140O48 t141O48 t143O48 t144 O48 t145O48 t146O48 t147O48 t149O48 t150O48 t151O48 t152O48 t153 O48 t154O48 t155O48 t156O48 t157O48 t162O48 t164O48 t165O48 t167 O48 t169O48 t170O48 t171O48 t174O48 t175O48 t176O48 t178O48 t179 M0054 145-192 of 246 Wedge / ramp PATH YNNYNNNNNNYN / continued O48 t180O48 t181O48 t182O48 t183O48 t185O48 t186O48 t187O48 t189 O48 t190O48 t191O48 t192O48 t194O48 t197O48 t198O48 t200O48 t201 O48 t202O48 t203O48 t204O48 t206O48 t207O48 t208O48 t209O48 t210 O48 t211O48 t213O48 t214O48 t215O48 t219O48 t221O48 t222O48 t223 O48 t224O48 t225O48 t228O48 t229O48 t230O48 t232O48 t235O48 t236 O48 t237O48 t239O48 t241O48 t245O48 t246O48 t249S50 t05S50 t23 M0054 193-240 of 246 Wedge / ramp PATH YNNYNNNNNNYN / continued S50 t74S50 t83S50 t105S50 t152S50 t173S50 t195S50 t200S50 t214 G54 t13G54 t18G54 t24G54 t27G54 t36G54 t40G54 t84G54 t94 G54 t141G54 t176G54 t179G54 t221G54 t241G54 t242G54 t249G55 t132 SOL t14SOL t16SOL t38SOL t41SOL t46SOL t63SOL t73SOL t78 SOL t90SOL t97SOL t100SOL t128SOL t142SOL t144SOL t169SOL t181 SOL t182SOL t211SOL t220SOL t224K3 t01K3 t11K3 t25K3 t31 M0054 241-246 of 246 Wedge / ramp PATH YNNYNNNNNNYN / continued K3 t37K3 t56K3 t70K3 t101K3 t160K3 t174 M0053 6 bots Wedge / ramp PATH YNNYNNNNNNNYY K3 t03K3 t115K3 t219K3 t235QW t171QW t198 M0052 1-48 of 466 Wedge / ramp PATH YNNYNNNNNNNYN F51 t05F51 t18F51 t85F51 t134F51 t152F51 t157F51 t190F51 t194 F51 t213F51 t218F51 t224F51 t225F50 t00F50 t01F50 t05F50 t07 F50 t08F50 t09F50 t10F50 t13F50 t15F50 t16F50 t17F50 t19 F50 t20F50 t21F50 t22F50 t24F50 t25F50 t26F50 t30F50 t32 F50 t34F50 t35F50 t36F50 t37F50 t38F50 t39F50 t40F50 t45 F50 t47F50 t48F50 t50F50 t51F50 t52F50 t55F50 t61F50 t62 M0052 49-96 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued F50 t63F50 t64F50 t67F50 t69F50 t70F50 t71F50 t73F50 t83 F50 t84F50 t87F50 t88F50 t91F50 t92F50 t97F50 t98F50 t100 F50 t101F50 t102F50 t103F50 t106F50 t109F50 t113F50 t117F50 t119 F50 t120F50 t122F50 t125F50 t128F50 t129F50 t133F50 t134F50 t136 F50 t137F50 t138F50 t139F50 t143F50 t144F50 t145F50 t146F50 t149 F50 t150F50 t151F50 t152F50 t153F50 t155F50 t157F50 t159F50 t160 M0052 97-144 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued F50 t161F50 t162F50 t164F50 t165F50 t166F50 t167F50 t168F50 t171 F50 t173F50 t175F50 t178F50 t180F50 t181F50 t183F50 t185F50 t186 F50 t189F50 t190F50 t192F50 t193F50 t195F50 t197F50 t200F50 t201 F50 t203F50 t204F50 t205F50 t207F50 t208F50 t209F50 t212F50 t217 F50 t219F50 t220F50 t221F50 t222F50 t223F50 t225F50 t227F50 t228 F50 t230F50 t231F50 t232F50 t237F50 t239F50 t240F50 t246F50 t247 M0052 145-192 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued F50 t248O48 t16O48 t21O48 t48O48 t85O48 t102O48 t160O48 t184 O48 t196O48 t216O48 t226O48 t233O48 t243O48 t248O50 t01O50 t96 O50 t212S50 t01S50 t02S50 t03S50 t08S50 t09S50 t12S50 t15 S50 t16S50 t19S50 t21S50 t26S50 t28S50 t31S50 t34S50 t35 S50 t38S50 t39S50 t40S50 t41S50 t42S50 t44S50 t47S50 t50 S50 t54S50 t56S50 t58S50 t59S50 t62S50 t70S50 t76S50 t82 M0052 193-240 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued S50 t84S50 t86S50 t91S50 t92S50 t93S50 t95S50 t100S50 t102 S50 t104S50 t106S50 t109S50 t112S50 t117S50 t118S50 t121S50 t125 S50 t127S50 t128S50 t135S50 t136S50 t139S50 t140S50 t143S50 t146 S50 t147S50 t148S50 t153S50 t156S50 t159S50 t162S50 t163S50 t164 S50 t165S50 t167S50 t168S50 t170S50 t174S50 t175S50 t181S50 t182 S50 t183S50 t185S50 t187S50 t189S50 t190S50 t191S50 t194S50 t197 M0052 241-288 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued S50 t199S50 t202S50 t203S50 t205S50 t209S50 t211S50 t215S50 t217 S50 t221S50 t229S50 t236S50 t237S50 t243G54 t46G54 t57G54 t62 G54 t66G54 t68G54 t72G54 t125G54 t138G54 t149G54 t162G54 t171 G54 t174G54 t213G54 t225G54 t247G55 t07G55 t39G55 t52G55 t118 G55 t127G55 t128G55 t147G55 t172G55 t212G55 t218G55 t233G55 t239 SOL t03SOL t04SOL t11SOL t25SOL t34SOL t36SOL t40SOL t49 M0052 289-336 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued SOL t51SOL t52SOL t62SOL t70SOL t71SOL t81SOL t98SOL t114 SOL t115SOL t150SOL t159SOL t162SOL t165SOL t191SOL t193SOL t194 SOL t201SOL t223SOL t226GR t06GR t09GR t27GR t42GR t47 GR t68GR t84GR t87GR t100GR t102GR t105GR t122GR t133 GR t141GR t165GR t204GR t217K3 t05K3 t07K3 t08K3 t10 K3 t12K3 t15K3 t16K3 t18K3 t19K3 t23K3 t26K3 t29 M0052 337-384 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued K3 t30K3 t35K3 t36K3 t39K3 t41K3 t42K3 t44K3 t51 K3 t52K3 t57K3 t62K3 t63K3 t64K3 t65K3 t66K3 t67 K3 t71K3 t74K3 t75K3 t83K3 t86K3 t88K3 t91K3 t94 K3 t97K3 t102K3 t110K3 t112K3 t113K3 t114K3 t116K3 t118 K3 t122K3 t124K3 t127K3 t131K3 t132K3 t134K3 t135K3 t137 K3 t140K3 t143K3 t146K3 t147K3 t150K3 t155K3 t156K3 t164 M0052 385-432 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued K3 t168K3 t181K3 t185K3 t188K3 t190K3 t195K3 t202K3 t203 K3 t204K3 t208K3 t211K3 t213K3 t217K3 t221K3 t222K3 t224 K3 t226K3 t227K3 t231K3 t233K3 t241K3 t243K3 t247K3 t249 QW t03QW t05QW t12QW t20QW t22QW t26QW t28QW t31 QW t33QW t34QW t46QW t48QW t55QW t56QW t64QW t66 QW t71QW t81QW t86QW t98QW t99QW t100QW t101QW t102 M0052 433-466 of 466 Wedge / ramp PATH YNNYNNNNNNNYN / continued QW t103QW t108QW t111QW t113QW t121QW t127QW t129QW t134 QW t138QW t143QW t148QW t156QW t157QW t167QW t169QW t172 QW t176QW t181QW t183QW t187QW t190QW t193QW t195QW t213 QW t216QW t221QW t223QW t225QW t227QW t230QW t235QW t237 QW t242QW t248 M0051 1 bots Wedge / ramp PATH YNNYNNNNNNNN K3 t55 M0050 2 bots Wedge / ramp PATH YNNNYY O48 t73G54 t110 M0049 1-48 of 52 Wedge / ramp PATH YNNNYN O48 t11O48 t14O48 t32O48 t37O48 t53O48 t59O48 t61O48 t64 O48 t68O48 t77O48 t81O48 t82O48 t89O48 t94O48 t96O48 t108 O48 t112O48 t116O48 t118O48 t121O48 t124O48 t136O48 t142O48 t148 O48 t159O48 t168O48 t173O48 t177O48 t188O48 t195O48 t199O48 t217 O48 t218O48 t220O48 t227O48 t234O48 t238O50 t79O50 t146S50 t144 G54 t29G54 t51G54 t156G54 t157G54 t186G54 t190SOL t59SOL t74 M0049 49-52 of 52 Wedge / ramp PATH YNNNYN / continued SOL t244K3 t22K3 t81K3 t105 M0048 12 bots Wedge / ramp PATH YNNNN O48 t240S50 t52S50 t81S50 t122S50 t172G54 t12GR t33K3 t145 K3 t175K3 t248QW t24QW t119 M0047 3 bots Surrounding ring PATH NY G55 t246SOL t85SOL t173 M0046 1 bots Forks / prongs + Jointed appendages PATH NNYY GR t58 M0045 3 bots Forks / prongs PATH NNYNYY G55 t62QW t89QW t206 M0044 1 bots Forks / prongs PATH NNYNYNYY A6 t209 M0043 11 bots Forks / prongs PATH NNYNYNYN F51 t10G55 t123A6 t21A6 t55A6 t59A6 t125A6 t144A6 t145 A6 t174A6 t236A6 t238 M0042 1 bots Forks / prongs PATH NNYNYNNYY G55 t41 M0041 1 bots Forks / prongs PATH NNYNYNNYNY QW t140 M0040 12 bots Forks / prongs PATH NNYNYNNYNN A6 t176GR t30GR t108GR t121GR t126GR t134GR t199GR t201 GR t225GR t233GR t242QW t09 M0039 5 bots Forks / prongs PATH NNYNYNNNYY G55 t85G55 t91G55 t142G55 t231G55 t243 M0038 1 bots Forks / prongs PATH NNYNYNNNYNY G55 t238 M0037 15 bots Forks / prongs PATH NNYNYNNNYNNY S50 t130G55 t21G55 t150G55 t184G55 t197G55 t199G55 t200G55 t213 G55 t215G55 t242GR t71GR t173GR t181GR t247QW t90 M0036 1 bots Forks / prongs PATH NNYNYNNNYNNN GR t209 M0035 2 bots Forks / prongs PATH NNYNYNNNNYY A6 t199A6 t248 M0034 1 bots Forks / prongs PATH NNYNYNNNNYNY A6 t141 M0033 10 bots Forks / prongs PATH NNYNYNNNNYNN F51 t79F51 t86F51 t102G55 t11G55 t14G55 t30G55 t98G55 t176 G55 t236A6 t92 M0032 1 bots Forks / prongs PATH NNYNYNNNNNYY QW t62 M0031 8 bots Forks / prongs PATH NNYNYNNNNNYN G54 t48G54 t123G54 t145G54 t170G54 t196G54 t212SOL t197SOL t240 M0030 2 bots Forks / prongs PATH NNYNYNNNNNNY S50 t87QW t93 M0029 31 bots Forks / prongs PATH NNYNYNNNNNNN F51 t70F51 t76F51 t204F51 t231F50 t191O50 t74O50 t134S50 t79 G54 t08G55 t188SOL t93SOL t96SOL t125SOL t129A6 t164GR t54 GR t64GR t66GR t78GR t79GR t94GR t120GR t128GR t132 GR t144GR t147GR t227GR t232GR t237GR t240K3 t139 M0028 3 bots Forks / prongs PATH NNYNN O50 t100G54 t09G54 t237 M0027 2 bots Wheel-supported body PATH NNNYYYY A6 t60QW t249 M0026 1 bots Wheel-supported body PATH NNNYYYNYY G55 t133 M0025 5 bots Wheel-supported body PATH NNNYYYNYN QW t00QW t29QW t197QW t229QW t233 M0024 3 bots Wheel-supported body PATH NNNYYYNNY F51 t208QW t25QW t42 M0023 4 bots Wheel-supported body PATH NNNYYYNNN F51 t191QW t155QW t168QW t215 M0022 2 bots Wheel-supported body PATH NNNYYNYY G55 t164QW t161 M0021 1 bots Wheel-supported body PATH NNNYYNYNY QW t240 M0020 6 bots Wheel-supported body PATH NNNYYNYNN A6 t22A6 t134A6 t149A6 t198A6 t244QW t174 M0019 1 bots Wheel-supported body PATH NNNYYNNYY G55 t02 M0018 11 bots Wheel-supported body PATH NNNYYNNYN F51 t125F51 t126SOL t66A6 t47A6 t97GR t50GR t75GR t145 GR t150GR t157GR t167 M0017 8 bots Wheel-supported body PATH NNNYYNNNYY K3 t13QW t04QW t41QW t92QW t116QW t126QW t165QW t234 M0016 23 bots Wheel-supported body PATH NNNYYNNNYN F51 t165S50 t07S50 t126S50 t210G55 t38G55 t49G55 t66G55 t97 G55 t102G55 t111G55 t120G55 t181G55 t245GR t222QW t13QW t59 QW t65QW t69QW t79QW t88QW t114QW t207QW t241 M0015 1 bots Wheel-supported body PATH NNNYYNNNNYY SOL t87 M0014 1 bots Wheel-supported body PATH NNNYYNNNNYNYY QW t170 M0013 7 bots Wheel-supported body PATH NNNYYNNNNYNYN F51 t07F51 t24F51 t142F51 t221O50 t188G55 t173K3 t197 M0012 1 bots Wheel-supported body PATH NNNYYNNNNYNN S50 t238 M0011 1 bots Wheel-supported body PATH NNNYYNNNNNYYY O48 t62 M0010 2 bots Wheel-supported body PATH NNNYYNNNNNYYNY O48 t163O48 t242 M0009 10 bots Wheel-supported body PATH NNNYYNNNNNYYNN F51 t241O48 t231O50 t27G54 t25G54 t50G54 t75G54 t76G54 t108 SOL t68SOL t195 M0008 1 bots Wheel-supported body PATH NNNYYNNNNNYN G54 t220 M0007 1 bots Wheel-supported body PATH NNNYYNNNNNNY G55 t42 M0006 15 bots Wheel-supported body PATH NNNYYNNNNNNNY O48 t172S50 t206S50 t213K3 t107K3 t162K3 t178QW t75QW t91 QW t145QW t146QW t152QW t224QW t236QW t238QW t244 M0005 1-48 of 99 Wheel-supported body PATH NNNYYNNNNNNNN F51 t56F51 t68F51 t90F51 t98F51 t130F51 t153F51 t170F51 t183 F51 t192F51 t198F51 t205F51 t214F51 t220F51 t223F51 t232F51 t238 F51 t242F50 t12F50 t56F50 t110F50 t158F50 t184F50 t196F50 t249 O50 t83O50 t99O50 t141S50 t30S50 t65S50 t69S50 t94S50 t110 S50 t116S50 t119S50 t145S50 t166S50 t184S50 t218S50 t219S50 t239 S50 t241G54 t33G54 t42G54 t55G54 t135G54 t187G54 t219G54 t226 M0005 49-96 of 99 Wheel-supported body PATH NNNYYNNNNNNNN / continued G54 t245G55 t182G55 t241SOL t192A6 t111A6 t231GR t104GR t116 GR t119GR t200GR t205K3 t09K3 t40K3 t48K3 t60K3 t61 K3 t68K3 t84K3 t96K3 t100K3 t121K3 t129K3 t144K3 t194 K3 t199K3 t216K3 t218QW t02QW t06QW t18QW t44QW t50 QW t51QW t52QW t58QW t60QW t87QW t107QW t112QW t125 QW t139QW t150QW t153QW t154QW t163QW t177QW t179QW t182 M0005 97-99 of 99 Wheel-supported body PATH NNNYYNNNNNNNN / continued QW t186QW t191QW t222 M0004 2 bots Wheel-supported body PATH NNNYNY QW t10QW t17 M0003 5 bots Wheel-supported body PATH NNNYNNY O50 t105O50 t116G54 t160SOL t08SOL t120 M0002 3 bots Wheel-supported body PATH NNNYNNN S50 t188G54 t104K3 t169 M0001 1 bots Other body plan PATH N S50 t216 Figure 9: Dichotomous key of SH generated bots 23 6.8 Physical implementation across revisions Some examples of iterating on hardware implementation: Kimi K3 attributed its wedge’s poor turning to wheel scrub torque exceeding drive torque. Revision 6, Fulcrum, placed the drive weight on two wheels at the center of mass, allowing it to pivot in place while preserving the wedge-pushing strategy. Claude Fable 5.1 initially lost two of three rounds to size violations when its lifter rose. It inferred that the size check used orientation-dependent bounding boxes and repositioned the wheels and ramp, qualifying 3-0 from revision 2 onward. GPT-5.4 replaced a successful pusher’s fixed tungsten slab with sliding ballast so the controller could shift mass toward the active pushing end or toward the platform center near an edge. Implementation failures were common among sampled robots: of 216 robots that built but did not qualify, 125 drove themselves off the platform, 60 triggered the inactivity rule, and 29 exceeded size limits during motion. 7 Methods (Continued) 7.1 Detailed Robot Design Constraints Structure. A robot must have exactly one free joint, on its root body, so no part of a robot may detach during a match. Every geometry and every motor must be named, since the controller addresses actuators by name, and each jointed body must carry at least one geometry. Every body, geometry, joint, actuator, and tendon must also carry a short natural-language description of its purpose, which the arena strips before compilation and retains as part of the design rationale. Plain mesh geometry,<option>and<contact>blocks, and MJCF composition elements such as <include>,<replicate>,<attach>,<composite>, and<flexcomp>are not permitted. Custom meshes must be closed, outward-facing, and defined directly in the submitted XML, so robots cannot rely on external geometry files; the mass of a signed distance field geometry is computed from the volume enclosed by its mesh. Materials. The material palette consists of foam, plastic, rubber, carbon fiber, aluminum, titanium, steel, and tungsten. Explicit mass, density, and inertial specifications, as well as gravity compensation, are removed before validation. Total robot mass is geometry mass plus actuator mass. Actuation. Only motor actuators are permitted; position, velocity, and other MuJoCo actuator types are rejected. A submission cannot directly actuate its root free joint, anchor an actuator to the world, or connect a mechanism to the opposing robot. Each unit of gear magnitude adds 0.01 kg of actuator mass to the body that mounts the motor; for motors on fixed tendons the priced gear is scaled by the sum of the tendon’s joint coefficients. Passive Elements. Damping and friction loss on internal joints and tendons are capped at 600 per degree of freedom and carry no mass cost. Spring stiffness is unbounded, but springs must be unloaded in the initial pose, and armature is fixed at zero. The root free joint cannot carry damping, friction loss, or stiffness, and tendons and actuator transmissions must remain entirely internal to the robot. Contact Model. Collision filtering, solver parameters, friction settings, and related contact properties are controlled by the arena. Robot geometries receive a higher contact priority than 24 the platform, so the material’s own friction coefficient governs traction rather than the platform’s; torsional and rolling friction are fixed at 0.005 and 0.0001 for all contacts. Size Enforcement. The bounding box is measured on the initial pose along the world axes and re-checked in the robot’s own root frame at every control step of a match; a robot whose extents exceed the box at any step loses the match, so articulated mechanisms must be designed to stay within these dimensions while moving. Controller Sandbox. The controller runs in a restricted Python sandbox with onlymath,numpy, random,typing, andcollectionsavailable; file, process, and network access are forbidden. Controller state persists across calls within a match and is reset before every match. A controller exception or a malformed return counts as a loss. Validation. Submissions are validated before qualification: the XML must compile in MuJoCo, every constraint above is checked, and the controller is invoked once on a real observation. A robot that fails any check forfeits the tournament. 7.2 Design Lab Harness Details Loop. A model turn is a single API call. Each turn the prompt is rebuilt from durable state rather than accumulated: the system prompt (rules, robot requirements, controller interface, observation schema, and the tool reference below), the static documentation, the current draft (robot.xmlandcontroller.pyat the workspace root), a one-line-per-step journal of previous tool calls and their outcomes, the model’s ownnotes.md, and the results of the previous turn’s tool calls. The model does not receive the full prior conversation but can write tonotes.md. A turn ends with one or more fenced JSON tool calls, each carrying atool,argsand a shortnote. All calls in a turn run in order and every result is returned. Tool calls do not count against the budget and model can chain tool calls together. The default budget is 10 turns, or fewer if the model calls finish. Bot references. Tools that act on a bot acceptdraft(the working files),stationary(the qualification block, the only built-in opponent), or the name of a bot the model saved with save_bot. A match may pit any two references against each other, including the same bot on both sides. Tools. The model has eighteen tools, listed in Table 1 in the four groups we use in the main text: workspace, arena, analysis, and library. Selection. After the last turn, every bot saved withsave_botenters a round robin of three seeds in each direction, draws worth half a win, ranked by Bradley–Terry strength. The winner is the run’s artifact; an earlier candidate may beat the final draft. A manual submission, an unsaved draft, or files written to an output folder cannot override this selection. Isolation. Each run gets a fresh workspace and a frozen snapshot of the engine and tool code, mounted in a sandbox with no network, no access to other runs, and no access to test fixtures or other models’ bots. The only supplied opponent is the stationary block. 25 7.3 Material Library ArtifactArena uses a fixed material library to make robot mass and contact properties deterministic across submissions. Each robot geometry specifies a material by name using the MJCF attributematerial="...". During validation, the simulator computes each geometry’s mass from its volume and the material density, m g = ρ mat(g) V g , and overwrites the geometry friction using the corresponding material friction coefficient. User- specifiedmass,density, body mass, andinertialtags are not used for final physics. If a geometry omits a valid material, the verifier assigns the default material foam. 8 Compute We use a server with 446 CPU cores to run our simulation experiments. LLMs are accessed through API calls to 3rd party model providers Khattab et al. (2023). 9 Model Configurations We evaluate 21 LLMs across nine families (Anthropic, OpenAI, Google, xAI, DeepSeek, Moonshot AI, Qwen, and Z.ai), listed in full in Table 3. Each model has a single YAML configuration that specifies its API identifier, sampling parameters, and any reasoning or thinking flags. This configuration is loaded at run time and forwarded through LiteLLM to the appropriate provider API. We use DSPy Khattab et al. (2023) for our prompts. 10 Simulation & Harness Code ArtifactArena is built on MuJoCo Todorov (2014), and the same simulator also runs in the browser, where it is used in two ways: 1) A live match where the browser does the simulation itself: it composes the arena, steps the physics, calls both controllers every control step, applies the termination rules, and renders the result as it goes. In 2) for a recorded match, the browser does not re-simulate but downloads the trajectory stored when the match was played on the cluster, uses the engine’s forward kinematics to recover every body pose from it, and renders the game. The user also has full control over the camera and are able to zoom-in/out and pan to watch the match from any angle. In both cases the code doing the work is the same C physics engine and the same Python match code as on the cluster, not a JavaScript re-implementation. We now describe the engine, the match code, and the ArtifactArena package in detail. Physics engine. We compile the unmodified MuJoCo 3.10.0 source to WebAssembly with Emscripten into a 9MB binary that the html page loads inside a Web Worker. 26 Match code. Once we have two verified robots from two models, we compose the two robots into the arena, seeded spawn placement, the settle phase, the control loop, observation construction, and the win, loss and draw rules. We bundle these modules and run them in Pyodide, a CPython build for the browser. A small shim module presents themujocoPython API on top of the WebAssembly engine, so the harness code importsmujocoas usual and does not know it is in a browser. Submitted controllers are ordinary Python and run unchanged. Numerical agreement. We faced an issue where the browser match and a cluster match outcomes differed between the two builds. Math library functions such as sine and cosine are not correctly rounded in every libm, so the WebAssembly build wraps them with the implementations from the tournament host’s glibc. Convex collision detection has a degenerate case for exactly parallel cylinders, common in wheeled robots, where the two builds could pick opposite support points; a small patch breaks the tie deterministically. We then run a native-versus-browser suite over fixture matches: the compiled model (masses, inertias, geometry) must match to 10 −9 , the seeded initial state must match bit for bit, settle and driven-probe trajectories must stay within tolerance, repeated browser runs must be bit-identical, and the winner and termination reason must agree. Bit-for-bit equality with native over a full contact-rich match is not achievable across compilers, since differences at the last bit grow chaotically; we therefore state parity as outcome agreement plus bounded trajectory divergence, and the site labels replays as reconstructions. Exact replays from trajectories. Our package allows the browser engine to be deterministic, we do not ship video. Each game in the release is stored as its gzipped sequence of generalized coordinates (one vector per control step). To replay, the browser recompiles the composed model, runs MuJoCo’s forward kinematics on each stored frame to recover every body pose, and renders the result with three.js. Playing against the leaderboard. The same worker can compose a match from a user’s robot.xmlandcontroller.pyagainst any released artifact and run it under the tournament rules, so the platform doubles as a development environment for human and human-plus-AI entrants. A 300-second match runs at roughly real time on a laptop. Human-AI Robot Building. Having the simulator in the browser also allowed us to create a 3D interactive bot editor. The page recompiles the robot in MuJoCo on every edit and shows the result as a live, physically settled preview rather than a static drawing, with each body, geom and joint in the XML linked to the corresponding part in the 3D view. The user can also step back through their edit history, and download the pair of bot geometry and controller files when ready for submission. Release. The harness, the verifier, the WebAssembly build script and patch, the Pyodide bundle, the parity suite and the web viewer will be released with the paper. 27 11 Model Prompt This is the complete prompt given to each model for zero-shot sampling. The placeholder mujoco_version is filled in at run time. Design a robot to maximize its win rate in the tournament described below. Provide the robot's hardware as MJCF XML and its controller as Python. The rules and technical descriptions below define the game and its simulation environment. They do not prescribe what robot to build. # Competition Your robot will compete in a round-robin tournament, facing every other robot in a 1v1 match. Each match takes place on an elevated circular platform, 15 m in diameter, with randomized robot starting positions. A robot loses if any part of it touches the floor below the platform. Starting 10 seconds into the round, inactivity is checked every control step. A robot loses if its two furthest center-of- mass positions in the preceding 10 seconds are less than 0.5 m apart, measured in XYZ. You win if your opponent loses before you do. If both robots trigger inactivity loss on the same step, the robot whose center of mass is more than 1 cm higher wins; otherwise, the round is a tie. If your robot causes the physics simulation to become unstable (NaN/Inf in forces), the match terminates and counts as a loss. If neither robot loses before time expires, the match is a draw. A controller error counts as a loss. Match outcomes are resolved after each control step. If multiple loss conditions occur on the same step, the highest-priority condition determines the result: controller error, floor contact, size violation, inactivity, then physics instability. If both robots lose under that condition, the match is a tie, except for the inactivity height tiebreaker described above. Loss conditions take precedence over time expiration. ## MuJoCo World The simulation runs in MuJoCo mujoco_version with gravity of 9.81 m/s^2. The robot's root body must have a freejoint, allowing translation and rotation in all three dimensions. The controller is called every 0.01 seconds of simulated time, with 40 physics simulation steps between calls. There is no per-call time limit; the simulation waits for the controller to return. Explore any design permitted by the simulation and build rules. Gravity applies fully to every body: any `gravcomp` attribute is removed before validation and reported. Think from first principles and physics when designing your robot. Each API request has a 100-minute wall- clock limit and a maximum output length; a request that exceeds either ends the run. ## Output format Return one complete robot design using these six named sections in this order. Give concise explanations, justifications, and calculations in the planning sections. The XML and Python must be fully implemented, mutually consistent, and self-contained, with no placeholders , ellipses, omitted helpers, or dependencies on external files. ### 1. `name` A creative, memorable name that hints at the robot's design or strategy. ### 2. `design_strategy` Briefly describe the robot's overall concept, how it will win, and how its hardware and controller work together. Explain the key hardware and controller design choices, why you think they will help the robot win, and which aspects carry the greatest risk or uncertainty. ### 3. `hardware_plan` Describe how the hardware works. Provide calculations evaluating its compliance with the build rules. Account for geometry and motor mass, including total mass, and check the robot's overall dimensions. 28 Explain how you chose actuator strengths and mechanism dimensions based on the forces, torques, and motion required by the design. End by explicitly mapping each hardware mechanism to the attack, movement, and defense strategies described in `design_strategy`. ### 4. `combat_plan` Describe how the controller works. What observations does it make use of? How does it use those observations to choose actuator commands and carry out the strategies described in `design_strategy`? Explain how it handles different starting positions and orientations, opponent behavior, proximity to the platform edge, and recovery from unfavorable situations. ### 5. `robot_xml` Provide the complete robot MJCF XML in one fenced `xml` code block, ready to save as `robot.xml`. Follow the `rules` and `mjcf_syntax` sections, including the material palette and the mass, size, and structure constraints. Every body, geom, internal joint, motor, mesh, site, and tendon definition must include a brief ` description="..."` attribute explaining what it does and why it exists in relation to the other parts. The root joint and container tags do not need descriptions. The arena removes these attributes before MuJoCo compilation and uses them to explain and visualize the design. ### 6. `controller_code` Provide the complete Python controller in one fenced `python` code block, ready to save as `controller.py`. Implement `def policy_step(obs) -> dict[str, float]`. Controller state, including globals, persists between `policy_step` calls within a match. Every qualification and tournament match starts with a fresh controller state. This including repeated matches against the same opponent. `random` and `np.random` are private to your controller and re- created for every match; they never affect your opponent. Writing attributes on shared library objects (modules, classes) is a controller error. So is registering a class on a shared abstract base class. Use the observations and execution environment defined in `obs_schema`. Return a dictionary mapping every actuator name in `robot_xml` to a float in `[-1, 1]`. Actuator names must match the XML exactly. Comment the code to explain its behavior. Check that every execution path returns valid commands for every actuator. Before qualification, `policy_step` is called once on a real observation of your robot; an exception or a bad return there is reported as a validation failure. ## Qualification Round To qualify, your robot must not lose each of three 20-second rounds against a simple baseline block. Your goal is to make a robot that wins all three rounds, but not losing is the minimum bar to qualify. Both the block and your robot start at randomized positions. The block has no motors and can freely translate, rotate, and topple. It is exempt from inactivity loss. If your robot fails to qualify, it forfeits and loses the tournament. The block is a 1.2 x 1.2 x 0.25 m plastic slab of about 342 kg with the palette's plastic friction. ## Tournament Phase Your robot faces every other robot in independently scored rounds lasting up to 300 seconds. Tournament standings use Bradley-Terry ratings, with draws counted as half a win for each robot. Both robots start at randomized positions in each round. ## Rules ```yaml 29 # Arena configuration arena: shape: circle radius_m: 7.5 # diameter 15m thickness_z_m: 2.0 # Robot constraints robot: # Mass constraints # Geometry mass: volume x material density for each geom. # Motor mass: sum(priced gear for each motor) x motor_mass_per_gear. The priced gear is the gear magnitude; for a motor on a fixed tendon it is the gear magnitude x sum(|coef|) over that tendon's joints. # Gear magnitude is abs(gear) for a scalar, or sqrt(sum(component^2)) for a vector. # Total robot mass includes both geometry and motor mass. mass: min_total_kg: 25.0 max_total_kg: 800.0 # Control constraints control: motor_mass_per_gear: 0.01 max_dof_damping: 600.0 # Internal joint/tendon linear damping: 0-600, no additional mass cost. max_frictionloss: 600.0 # Per internal joint DOF or tendon; no additional mass cost. # Root-joint damping, frictionloss, and stiffness are fixed at 0. # Configurable environment setting: 0 disables gear clamping. # When enabled, max gear = body_inertia_min x gear_clamp_ratio. gear_clamp_ratio: 0 # Structure limits structure: max_bodies: 2000 max_geoms: 2000 max_actuators: 2000 min_actuators: 1 # Maximum axis-aligned bounding box dimensions, in metres size: max_x_span_m: 2.44 max_y_span_m: 2.44 max_z_span_m: 3.05 ``` Size limits apply to the robot's initial pose defined by its XML, measured along the world X, Y, and Z axes before spawn rotation and settling. During a match the limits are also checked on every control step in your robot's own root-body frame: if your robot's extents along its root axes exceed 2.44 x 2.44 x 3.05 m at any step, you lose the round. Validation measures the initial pose in the root-body frame as well and rejects a robot outside the box. Design mechanisms to stay inside the box while moving. The arena fixes `condim="6"`, enabling sliding, torsional, and rolling friction. It sets sliding friction from each geom's material, torsional friction to `0.005`, and rolling friction to `0.0001`, overriding model-specified values. Collision settings are controlled by the simulation environment. Do not specify geom `contype`, ` conaffinity`, `condim`, `friction`, `priority`, `solmix`, `solref`, `solimp`, `margin`, or `gap`, including through `<default>` blocks. Do not define `<contact>` blocks, contact pairs, or collision exclusions. The validator reports and ignores these overrides. Robot geoms use `contype="1"`, ` conaffinity="1"`, `priority="2"`, `solmix="1"`, `solref="0.02 1"`, `solimp="0.9 0.95 0.001 0.5 2"`, and `margin="0" gap="0"`. The platform's own friction never applies to a robot-platform contact: robot geoms have contact priority 2 and the platform priority 1, so your material's friction is your traction. Priority, condim and the other contact attributes are set by the environment and cannot be changed by your XML. ## MJCF syntax 30 MJCF is MuJoCo's XML format. You define a tree of physical parts, connect them with joints, then attach motors to drive those joints. ### COORDINATE SYSTEM - Robot-local axes: +X forward, +Y left, +Z up. - World axes: XY is horizontal; +Z is up (gravity acts along -Z). - Units: meters, kilograms, seconds, radians. ### DOCUMENT STRUCTURE Your MJCF XML must use the following structure: ```xml <mujoco> <asset> <!-- inline mesh definitions, if needed --> </asset> <worldbody> <!-- your robot's root body goes here --> </worldbody> <tendon> <!-- optional tendon definitions --> </tendon> <actuator> <!-- motors that drive joints or tendons go here --> </actuator> </mujoco> ``` Do not include an `<option>` block: global physics settings (timestep, gravity, integrator, solver) belong to the arena; any `<option>` in your XML is removed before validation and reported. The `<asset>` block may contain inline mesh definitions for SDF geoms. Include it only if your robot uses inline meshes for SDF geoms. Any other child of `<asset>` (materials, textures) is removed before validation and reported. The arena sets compiler `angle="radian"` when validating and composing the match. Any other `<compiler>` attribute in your XML is removed before validation and reported. Optional `<default>` blocks may define shared joint, tendon, and motor settings. Do not use `<frame>`, `< replicate>`, `<attach>`, `<composite>`, `<flexcomp>`, or `<include>` elements; the validator rejects them. Set `pos` and orientation on bodies and geoms directly. ### BUILDING BLOCKS #### 1. BODY An MJCF `<body>` tag defines a rigid body that may contain geoms, joints, and child bodies. Place exactly one root `<body>` directly inside `<worldbody>` and nest every other robot body beneath it. - `pos="x y z"` sets the body's origin in its parent's coordinate frame. - Bodies nest: a child body inherits its parent's position and orientation. A joint allows relative motion; without a joint, the bodies are rigidly connected. - Each body with a joint or freejoint must have a geom in itself or a rigidly attached descendant. Descendants reached through another joint or freejoint do not count. - The root body MUST have a `<freejoint/>` so the robot can move freely in 3D. - `description="..."` -- REQUIRED. A short text explaining what this body does and WHY it exists (e.g. "Low steel ballast to lower center of gravity"). Stripped before MuJoCo compilation; used by the app to display design intent. ```xml <body name="root_body" pos="0 0 0.15" description="Root coordinate frame for the robot"> <freejoint name="root"/> <!-- geoms and child bodies go here --> </body> 31 ``` #### 2. GEOM An MJCF `<geom>` tag defines a geometric shape rigidly attached to its containing `<body>`, used for visualization, collision, and calculating mass and inertia. ```xml <geom name="geom_name" type="geom_type" material="material_name" description="purpose"/> ``` - Supported geom types: `box`, `cylinder`, `sphere`, `capsule`, `ellipsoid`, and `sdf`. `type="mesh"` is not accepted; any mesh can be expressed as an `sdf` geom from the same vertices and faces. - `material="name"` selects a material from the palette below, determining density and sliding friction. Geom mass is volume x material density. - Every geom must have a unique name, set by its `name` attribute. A geom without a name fails validation. For `box`, `cylinder`, `sphere`, `capsule`, and `ellipsoid` geoms, `size` values are radii or half-lengths. For example, a box with `size="1 1 1"` measures 2 x 2 x 2 m. - box: `size="half_x half_y half_z"` - cylinder: `size="radius half_height"` - sphere: `size="radius"` - capsule: `size="radius half_length"` - ellipsoid: `size="radius_x radius_y radius_z"` An SDF (signed distance field) gives the distance to a shape's surface: negative inside, zero on the surface, and positive outside. An SDF geom can be created by defining a `<mesh>` in `<asset>` using vertices and triangular faces, then referencing it with `<geom type="sdf" mesh="mesh_name"/>`. MuJoCo computes the SDF from the mesh and uses it for collision detection, preserving concave features. A mesh defines a surface using vertices connected into triangular faces. `vertex` lists the points, and ` face` specifies which groups of three points form triangles. Define its `vertex` attribute as XYZ coordinates in meters and its `face` attribute as triples of zero-based vertex indices. The surface must be closed and outward-facing (every edge shared by exactly two triangles, positive enclosed volume). The simulation environment computes mass and inertia from the mesh's enclosed volume and material density. SDF dimensions come from mesh vertices, multiplied along X, Y, and Z by the `<mesh>` attribute `scale=" scale_x scale_y scale_z"` (default: `"1 1 1"`). Do not use geom `size` to resize an SDF. The geom's ` pos` and orientation attributes set its position and orientation relative to its body. A mesh asset adds no mass itself. Each geom that uses it has mass equal to the mesh's enclosed volume x the geom's material density. Define mesh vertices and faces directly in `robot.xml`; external mesh files and custom SDF functions are not supported. MuJoCo mujoco_version assigns mesh-derived SDF sample signs using the normal of a nearest triangle. Near some edges and corners, this can incorrectly classify empty space as solid and produce contacts outside the intended surface. Rounding affected edges and corners with multiple facets so normals change gradually is one possible mitigation, not a requirement or a guarantee of correct collisions. Subdividing an unchanged flat surface does not change its sharp boundaries. SDF syntax example: Define the mesh in `<asset>` directly under `<mujoco>`: ```xml <asset> <mesh name="surface_a" vertex="0 0 0 0.6 0 0 0 0.4 0 0 0 0.3" face="0 2 1 0 1 3 0 3 2 1 2 3" description="Closed surface with explicit vertices and outward-facing triangles"/> </asset> ``` 32 Reference the mesh from an SDF geom inside a `<body>`: ```xml <geom name="surface_geom" type="sdf" mesh="surface_a" material="aluminum" description="Uses the inline surface for SDF collision geometry"/> ``` **Orientation:** A geom's orientation specifies its rotation relative to its immediate parent body. By default, the geom's axes align with that body's axes. For cylinders and capsules, the geom's local Z-axis passes through the centers of both ends. Set orientation on `<geom>` using one of the following two options: **1. Euler angles (`euler`)** `euler="rx ry rz"` specifies rotations in radians about the geom's local X, then Y, then Z axes. Each rotation uses the axes resulting from the preceding rotations. Positive rotations follow the right- hand rule. Euler examples: `euler="1.5708 0 0"` rotates the geom approximately 90 deg about X, pointing its local +Z axis along its parent body's -Y axis. `euler="0 1.5708 0"` rotates the geom approximately 90 deg about Y, pointing its local +Z axis along its parent body's +X axis. **2. Axis directions (`xyaxes`)** `xyaxes="x1 y1 z1 x2 y2 z2"` specifies the geom's X-axis direction followed by its Y-axis direction, expressed in its immediate parent body's coordinates. MuJoCo makes these axes perpendicular and normalizes them, then computes Z = X x Y. Geom orientation and joint axis are independent. Choose their relationship to produce the intended motion. For example, a cylinder intended to rotate about its symmetry axis must have that axis aligned with its hinge axis. #### 3. JOINT Defines how a child body can move relative to its parent. - Without a joint, a child body is rigidly welded to its parent. - Place the joint inside the child body (not the parent). Geoms on independently moving branches of your robot can collide with each other. Check that moving parts can complete their intended motion without unintended collisions. For hinge and slide joints, `axis="x y z"` sets the rotation or translation direction in the child body's coordinates. For hinges, the rotation axis passes through `pos="x y z"` in those same coordinates. Defaults are `axis="0 0 1"` and `pos="0 0 0"`. To limit a hinge or slide joint's movement, set `limited="true"` and `range="min max"`. Hinge limits are angles in radians; slide limits are distances in meters. Set `limited="false"` for unrestricted movement. Hinge and slide joints start at `ref` (default: `0`), corresponding to the pose defined by the XML. Before the first controller call, the environment simulates 50 physics steps (0.0125 seconds) with zero motor commands, then sets all joint velocities to zero. Joint positions may change during settling. Observations provide current joint positions and velocities in `my_robot["joints"]`. **Joint types:** **hinge:** Rotates a child body around the specified local axis. `axis="0 1 0"` means rotate around the local Y axis. ```xml 33 <joint name="rotation_joint" type="hinge" axis="0 1 0"/> ``` **slide:** Translates a child body along the specified axis. `axis="1 0 0"` means slide along the X axis. ```xml <joint name="translation_joint" type="slide" axis="1 0 0"/> ``` **ball:** Allows rotation in any direction around a shared connection point (3 rotational DOF), with no relative translation at that point. `pos="x y z"` locates the joint in the child body's frame. `axis=` is ignored because there is no single rotation axis. MuJoCo represents its orientation as a unit quaternion (w, x, y, z). ```xml <joint name="spherical_joint" type="ball" pos="0 0 0" description="Allows three-axis rotation at the connection"/> ``` A body with a ball joint cannot also have a hinge or another ball joint. It may have slide joints. The joint can be passive. A single motor provides one commanded torque component, not independent control of all three rotations. The joint's observation provides its orientation quaternion and full local angular-velocity vector. **free:** 6-DOF (translate + rotate). Only for the root body of the robot. ```xml <freejoint name="root"/> ``` Internal joints may use scalar `damping="d"` from 0 to 600 (default: 0), with no additional mass cost. Damping applies F = -d x velocity to sliding joints (d in N.s/m) and torque = -d x angular_velocity to rotating joints (d in N.m.s/rad). The environment sets root-joint damping, frictionloss, and stiffness to 0, regardless of your XML. Internal joints and tendons may also use `frictionloss="f"` from 0 to 600 (default: 0), with no additional mass cost. Friction loss provides passive resistance to motion, including resistance to starting from rest, and may be combined with damping. Values are in N for slide joints and spatial tendons, and N.m per rotational degree of freedom for hinge and ball joints. For fixed tendons, the limit applies to the tendon-coordinate force; each joint's resistance is multiplied by its tendon coefficient. Values must be finite. Internal joint and tendon springs may use scalar `stiffness="k"` >= 0, with no upper cap or additional mass cost. Stiffness must be finite. Springs must start unloaded in the XML's initial pose, before settling; motion may then load them. For hinge/slide springs, set springref equal to ref (both default to 0). Restoring force/torque is -k x displacement (k in N/m or N.m/rad). Tendon springlength sets a rest length or a two-value unloaded interval; the initial length must lie within it. If omitted, MuJoCo computes it from the joint spring-reference pose, so match every joint's springref to ref. The environment fixes joint, tendon, and actuator armature at 0. #### 4. MOTOR (actuator) An MJCF `<motor>` applies force or torque through a transmission. Define motors inside `<actuator>`. - Only `<motor>` actuators are allowed. - Every `<motor>` must have a unique `name`: your controller returns a dictionary keyed by motor name, so an unnamed motor fails validation. - Set `joint="joint_name"`, `jointinparent="joint_name"`, or `tendon="tendon_name"` to select what the motor drives. These drive an internal hinge, slide, or ball joint, or a tendon. - Motor forces and torques must act between parts of your robot. Do not actuate the root freejoint, use a site motor without `refsite`, or anchor a transmission to the world or another robot. - Motor force or torque equals `gear x motor command`. For hinge joints, torque is in N.m and positive torque follows the right-hand rule around the joint's `axis`. For slide joints, force is in N and positive force acts along the joint's `axis`. - For ball joints, set `gear="gx gy gz"`. These values multiplied by the motor command give the torque vector in N.m in the child body's coordinates for `joint`, or the parent body's coordinates for ` 34 jointinparent`; positive components follow the right-hand rule. A single gear value specifies only the X component; the others default to 0. - Relative-site motors use `site="site_name" refsite="reference_site_name"`. Both sites must belong to your robot; either may be on the root body. `gear="fx fy fz tx ty tz"` selects translational and rotational components in the reference site's frame, scaled by the motor command. Translation components correspond to forces in N; rotation components correspond to torques in N.m. - Slider-crank motors use `cranksite="crank_site_name" slidersite="slider_site_name" cranklength="length"`. Both sites must belong to your robot. The connecting-rod length is in meters, and the slider moves along the slider site's local Z axis. Scalar `gear x motor command` applies force in N to the slider- displacement coordinate. MuJoCo models the transmission; represent its physical parts with material geoms. - Motor commands range from -1 to 1. - Higher absolute gear provides greater force or torque and adds motor mass. For a motor on a fixed tendon, the priced gear is |gear| multiplied by the sum of the absolute joint coefficients of that tendon. A motor on a spatial tendon is priced at |gear|, the force it applies along the tendon. - Motor mass is added to the first geom of its mounting body: the joint body for joint motors, the `site` body for relative-site motors, the `slidersite` body for slider-crank motors, and the root body for tendon motors. If that body has no geom, the environment searches its rigidly attached descendants depth-first in XML order, skipping bodies with joints or freejoints. The added mass follows that geom' s shape and position, contributing to the robot's simulated mass, center of mass, and inertia. - Motors have no arena-imposed speed, power, energy, or thermal limits. Their available force or torque does not decrease with speed. ```xml <actuator> <motor name="actuator_a" joint="rotation_joint" gear="1250"/> </actuator> ``` #### 5. TENDON An MJCF tendon transmits force between parts. Define tendons inside an optional `<tendon>` block directly under `<mujoco>`. - A `<spatial>` tendon represents a cable routed through sites on robot bodies. A site is a massless reference point, defined as `<site name="site_name" pos="x y z"/>` inside a body. Spatial tendons can wrap around sphere or cylinder geoms. - `<fixed>` defines length = sum(coef x joint_position) for hinge/slide joints. - Tendons may have springs, scalar damping from 0 to 600 (force = -d x length_rate), and length limits (` limited="true"` `range="min max"`). Spatial lengths are in meters; fixed tendon units follow their joint coordinates and coefficients. - Tendons must remain entirely within the robot; world anchors and connections to other robots are forbidden. `<equality>` constraints are not allowed; the validator rejects them. `<pulley>` elements are not allowed either. - Tendons and sites add no mass or collision geometry. Represent physical hardware with material geoms. Include descriptions on sites and tendons. - A motor may use `tendon="name"` instead of `joint="name"`. It applies gear x motor command to the tendon- length coordinate; negative force pulls a spatial tendon shorter. ```xml <tendon> <spatial name="cable" stiffness="1000" damping="20" description="Elastic connection between the chassis and arm"> <site site="chassis_anchor"/> <site site="arm_anchor"/> </spatial> <fixed name="coupling" description="Couples two joint coordinates"> <joint joint="joint_a" coef="1"/> <joint joint="joint_b" coef="-1"/> 35 </fixed> </tendon> <actuator> <motor name="winch" tendon="cable" gear="2000" description="Pulls the cable to move the connected mechanism"/> </actuator> ``` ### HOW TRANSFORMS WORK (critical for correct assembly) Every body's `pos=` is RELATIVE TO ITS PARENT, not the world. When a parent body moves, ALL its children move with it automatically. Example: parent body at `pos="0 0 0.15"`, child body inside it at `pos="0.2 0.25 -0.05"` -> child's world position = (0+0.2, 0+0.25, 0.15-0.05) = (0.2, 0.25, 0.10) -> when the parent moves to x=1, the child moves to (1.2, 0.25, 0.10) automatically Geom `pos=` is relative to its OWN body (usually "0 0 0" or omitted). Joint in a child body only moves THAT child, not siblings. ### MATERIAL PALETTE (part of mjcf_syntax) Pick a material for every geom. Geometry mass is volume times material density; for a mesh-derived SDF, use the enclosed mesh volume. Do not use `mass=`, `density=`, body `mass=`, or `<inertial>`. An optional `<asset>` block may contain inline `<mesh>` definitions referenced by SDF geoms. Preserve these mesh definitions when processing the submission. Palette materials are injected by the arena; do not define or override materials, textures, or other assets. External asset files and custom plugin declarations are not part of this submission format. ```yaml # Material Palette # # Each material defines physics (density, friction) and visual (rgba, specular, # shininess) properties. Pick a material per geom (e.g., material="steel"). # Geom mass is volume x material density. Sliding friction comes from the material's friction coefficient. # # Visual properties are injected as MuJoCo <material> assets so material="steel" # is both a physics lookup AND a valid visual reference. # Default material auto-assigned to geoms missing material= attribute. # Must be a key in the materials dict below. default_material: foam materials: foam: density_kg_m3: 200 friction: 0.5 desc: "Structural foam" rgba: "0.92 0.90 0.85 1" specular: 0.0 shininess: 0.0 plastic: density_kg_m3: 950 friction: 0.25 desc: "HDPE plastic" rgba: "0.95 0.95 0.95 1" specular: 0.1 shininess: 0.1 rubber: density_kg_m3: 1200 friction: 1.6 desc: "High-grip rubber" rgba: "0.12 0.12 0.12 1" specular: 0.0 shininess: 0.0 carbon_fiber: 36 density_kg_m3: 1700 friction: 0.35 desc: "Carbon fiber composite" rgba: "0.10 0.10 0.12 1" specular: 0.3 shininess: 0.2 aluminum: density_kg_m3: 2700 friction: 0.45 desc: "Aluminum alloy" rgba: "0.75 0.75 0.78 1" specular: 0.5 shininess: 0.3 titanium: density_kg_m3: 4500 friction: 0.4 desc: "Titanium alloy" rgba: "0.60 0.58 0.55 1" specular: 0.4 shininess: 0.25 steel: density_kg_m3: 7800 friction: 0.6 desc: "Mild steel" rgba: "0.55 0.55 0.60 1" specular: 0.6 shininess: 0.5 tungsten: density_kg_m3: 19300 friction: 0.4 desc: "Tungsten alloy" rgba: "0.35 0.35 0.38 1" specular: 0.4 shininess: 0.3 ``` ## obs_schema `policy_step(obs)` receives a Python dictionary whose keys are strings. Every name listed under `fields` below is an exact top-level key in `obs`, accessed as `obs["key_name"]`. All listed keys are present on every controller call; lists and dictionaries may be empty where specified. The YAML below documents each value's type, shape, units, and meaning; the values received by the controller are Python objects, not the descriptive strings shown here. `np.ndarray[3]` means a NumPy array of shape `(3,)`, `dict[str, float]` means a dictionary mapping string keys to floats, and `list[ dict]` means a list of dictionary records. Nested record keys are specified in "Detailed physical- state records" below. The labels `fields` and `controller_environment` organize this specification; neither is a key in `obs`. ```yaml fields: # === POSITION === my_pos: "np.ndarray[3] - entire robot's center of mass [x, y, z] in world coordinates (meters); XY is the horizontal plane, +Z is up" opponent_pos: "np.ndarray[3] - opponent's center of mass, using the same convention as my_pos" # === ORIENTATION (scalars, radians) === my_yaw: "float - root-body heading in radians, from -pi to pi (0 = world +X, pi/2 = world +Y)" my_pitch: "float - root-body pitch in radians, from -pi/2 to pi/2 (0 = level, positive = nose down)" my_roll: "float - root-body roll in radians, from -pi to pi (0 = level, positive = left side up, right side down)" opponent_yaw: "float - opponent's root-body heading, using the same convention as my_yaw" opponent_pitch: "float - opponent's root-body pitch, using the same convention as my_pitch" opponent_roll: "float - opponent's root-body roll, using the same convention as my_roll" # === VELOCITY === 37 my_velocity: "np.ndarray[3] - velocity of the root-body origin [vx, vy, vz] in world coordinates (m/s)" my_angular_velocity: "np.ndarray[3] - angular velocity [wx, wy, wz] about the root body's local X, Y, Z axes (rad/s), positive by the right-hand rule" opponent_velocity: "np.ndarray[3] - velocity of the opponent's root-body origin, using the same convention as my_velocity" opponent_angular_velocity: "np.ndarray[3] - angular velocity about the opponent's root-body local axes, using the same convention as my_angular_velocity" my_actuator_velocity: | dict[str, float] - maps each motor's XML name to the velocity defined below for its transmission type: - Hinge: angular velocity about the joint axis (rad/s), positive by the right-hand rule. - Slide: linear velocity along the joint axis (m/s), positive in the axis direction. - Spatial tendon: length change per second (m/s), positive when lengthening. - Fixed tendon: sum(coef x joint velocity), using signed joint velocities and coefficients. - Ball: joint angular velocity about the motor's torque axis (rad/s), positive in the torque direction produced by a positive motor command. Gear magnitude does not scale this value; zero gear returns 0. - Slider-crank: slider-displacement rate in m/s, before gear scaling (0 for zero gear). - Relative-site: MuJoCo's scalar actuator velocity, including all gear components. It combines the selected relative translation and rotation rates; it is not an individual joint velocity. opponent_actuator_velocity: "dict[str, float] - opponent motor velocities, keyed by their XML names, using the same convention as my_actuator_velocity" # === DISTANCES === distance_to_opponent: "float - Euclidean distance in XYZ between the robots' centers of mass, my_pos and opponent_pos (meters)" my_edge_distance: "float - signed XY distance from your robot's center of mass to the platform edge ( meters); positive inside the platform boundary, zero on it, negative outside" opponent_edge_distance: "float - signed XY distance from the opponent's center of mass to the platform edge, using the same convention as my_edge_distance" # === CONTACT === opponent_contact: "bool - True if any of your robot's geoms contact an opponent geom" opponent_contact_force: "float - sum of force magnitudes across all contacts with the opponent (N); 0 if no contact" ground_contact: "bool - True if any of your robot's geoms contact the platform, including its sides" # === STABILITY === is_tipping: "float - angle in radians between the root body's +Z axis and world +Z, divided by pi/2 and capped at 1 (0 = upright, 1 = tilted 90 deg or more)" # === INACTIVITY === my_inactivity_timer: | float - Duration in seconds of the longest continuous period ending now during which every pair of recorded center-of-mass positions is less than 0.5 m apart in XYZ. Starts at 0 when the round begins. Inactivity loss triggers at 10 seconds. opponent_inactivity_timer: "float - measured as described for my_inactivity_timer, but for the opponent robot. Always 0 for the qualification block." # === TIME === t: "int - completed control steps in this match; starts at 0 on the first policy_step call of each match and increases by 1 per call. Elapsed simulated time = t x 0.01 seconds" max_t: | int - control-step limit for this match: 2000 for qualification (20 seconds), 30000 for the tournament (300 seconds). On every policy_step call, 0 <= t < max_t. Scheduled time remaining = (max_t - t) x 0.01 seconds. # === ROBOT PROPERTIES (static per match) === my_bounding_radius: "float - approximate robot radius (meters), computed once at initialization as max(XY distance from COM to each geom's center + that geom's bounding-sphere radius). Does not update as the robot moves or articulates." opponent_bounding_radius: "float - computed as described for my_bounding_radius, but for the opponent robot" ring_radius: "float - arena radius in meters (distance from center to edge)" # === SPATIAL GRIDS (2D top-down maps, rebuilt every timestep) === 38 arena_grid: "np.ndarray[N,N] int8 - occupancy map of circles centered on robot COMs using the static bounding radii, not actual geometry. -1=outside ring, 0=free, 1=opponent, 2=self; self overwrites opponent where circles overlap. center cell = ring center. world_x = (col - N//2) * 0.25, world_y = (N //2 - row) * 0.25" arena_mass_grid: "np.ndarray[N,N] float32 - uses the same circular masks as arena_grid. -1=outside, 0= free; each occupied cell repeats that robot's entire mass (kg), not mass within that cell. Self overwrites opponent on overlap." edge_distance_grid: "np.ndarray[N,N] float32 - signed distance to ring edge per cell. Positive=inside, negative=outside. Static per match." # === GAME CONTEXT === game: "dict - reserved for game-specific context; empty () in every match. Your controller may ignore it." # === HISTORY (rolling queues, most recent last) === obs_history: "list[dict] - last N observations (N=max_obs_lookback, default 20). Each dict has: my_pos, opponent_pos, my_yaw, my_velocity, opponent_velocity, distance_to_opponent, my_edge_distance, opponent_edge_distance, t, my_actuator_velocity, game. Empty at t=0." action_history: "list[dict] - last N actions YOU took (N=max_action_lookback, default 20). Each dict maps actuator_name -> float value. Commands are recorded before motor-specific ctrl_range limits are applied. Empty at t=0." # === DETAILED PHYSICAL STATE === control_dt: "float - simulated seconds per controller call (0.01)" elapsed_time: "float - elapsed match time in simulated seconds, equal to t x control_dt" time_remaining: "float - scheduled time remaining in simulated seconds, equal to (max_t - t) x control_dt " platform: | dict with the following keys; all distances are in meters: - shape: str, "cylinder". - center: np.ndarray[3], center of the platform's top surface in world XYZ coordinates. - radius: float, platform radius. - half_extents: np.ndarray[2], [radius, radius] along world X and Y. - top_z: float, platform-top height in world coordinates; equals center[2]. - floor_z: float, lower-floor height in world coordinates. my_mass: "float - total simulated robot mass, including motor mass (kg)" opponent_mass: "float - opponent's total simulated mass (kg)" my_com_velocity: "np.ndarray[3] - velocity of your entire robot's center of mass in world XYZ (m/s)" opponent_com_velocity: "np.ndarray[3] - opponent's center-of-mass velocity in world XYZ (m/s)" my_robot: "dict - named geometry, bodies, joints, tendons, motors, and sites, with definitions and current state as specified below" opponent_robot: "dict - the same physical information for the opponent; names belong to its XML" opponent_surface_distance: "float - minimum separation between the robots' collision shapes (meters), computed numerically; 0 when intersecting" opponent_proximity: "list[dict] - closest geom pairs with separation <= proximity_cutoff; records specified below" proximity_cutoff: "float - maximum separation included in opponent_proximity (2 meters)" proximity_limit: "int - maximum number of geom pairs returned in opponent_proximity (32)" proximity_truncated: "bool - True if more than proximity_limit geom pairs were within proximity_cutoff" contacts: "list[dict] - current solver contacts involving your robot, with positions and force/torque vectors as specified below" contact_impulses: "list[dict] - impulses accumulated over all physics steps since the previous controller call, grouped by geom pair" contact_interval: "float - simulated duration covered by contact_impulses (seconds); 0 on the first call, normally control_dt thereafter" controller_environment: | Available libraries (pre-loaded, no other imports allowed): import math# standard math functions (atan2, sqrt, pi, sin, cos, etc.) import numpy as np # also available as bare 'np' (pre-injected into namespace) import typing# type hints only import random# standard PRNG (seed it yourself if you need determinism) import collections # deque, defaultdict, Counter All Python builtins are available (`range`, `len`, `min`, `max`, `abs`, `dict`, `list`, etc.), except ` open`, `exec`, `eval`, `compile`, `breakpoint`, `exit`, `quit`, `input`, `globals`, `locals`, `vars`, 39 `getattr`, `setattr`, and `delattr`, which are forbidden. File and process access, including NumPy's save/load family, is forbidden. Forbidden: os, subprocess, socket, open(), exec(), eval(), pickle, threading ``` ### Detailed physical-state records Body, geom, and site positions and velocities use world XYZ coordinates unless marked `local`. Positions are in meters, linear velocities in m/s, and angular velocities in rad/s. Joint coordinates and frames are specified separately below. Position, velocity, force, torque, impulse, and normal vectors are ` np.ndarray[3]`. Quaternions are `np.ndarray[4]` in `[w, x, y, z]` order. In body, geom, and site records, `quaternion` rotates that element's local coordinates into world coordinates. In geom and site records, `local_quaternion` rotates the element's local coordinates into its containing body's coordinates. Joint and inertia quaternion frames are specified below. Values are detached snapshots: retaining or modifying them does not alter the simulation or future observations. Definitions remain constant within a match; positions and motion update on every call. The definitions describe the compiled robot after environment processing, including injected motor mass. `my_robot` and `opponent_robot` each contain `mass`, `com_position`, `com_velocity`, `root_body` (the root body's name), and six dictionaries keyed by XML names: `bodies`, `geoms`, `joints`, `tendons`, `motors `, and `sites`. Runtime robot prefixes are removed. Unnamed elements receive stable generated names. Look up a root body's full pose and motion in `robot["bodies"][robot["root_body"]]`. Against the baseline block, `obs["opponent_robot"]["root_body"]` is `"block"`, and its body record is `obs[" opponent_robot"]["bodies"]["block"]`. - **Bodies:** `parent` (body name, or `None` for the root), `mass` (kg), `position`, `quaternion`, ` linear_velocity` measured at the body origin, `angular_velocity`, `com_position`, and `com_velocity`. Mass and COM refer to this body's own mass, excluding descendants. `local_com` is its COM in body coordinates. `inertia_diagonal` (`np.ndarray[3]`) gives the three principal moments about its COM (kg. m^2); `inertia_quaternion` (`np.ndarray[4]`) orients those principal axes relative to the body. - **Geoms:** `body` (containing body name), `type`, `size` (`np.ndarray[3]`, MuJoCo radius/half-length conventions, padded to three values), `local_position`, `local_quaternion`, world `position`, ` quaternion`, `linear_velocity` at the geom origin, `angular_velocity`, and `friction` (`np.ndarray [3]`, sliding, torsional, and rolling coefficients). SDF geoms have `type="sdf"`, `vertices` (`np. ndarray[N,3]`, XYZ coordinates in meters in the compiled geom's local frame), and `faces` (`np.ndarray [M,3]`, triples of zero-based vertex indices defining triangles). Mesh dimensions come from these vertices; do not apply geom `size` to them. Geom mass is represented in its body's mass and inertia. - **Joints:** all internal joints, including passive ones. Each record contains `body`, `type`, `axis` and `anchor` in body coordinates, `limited`, `range`, `reference`, `position`, `velocity`, `stiffness`, ` damping`, and `frictionloss`. Hinge positions/rates use radians and rad/s, positive by the right-hand rule about `axis`; slide positions/rates use meters and m/s, positive along `axis`. `position` is the current joint coordinate, including its reference offset; `reference` contains its initial XML coordinate. For hinge and slide joints, `position` and `velocity` are floats; `reference`, `damping`, and `frictionloss` are NumPy arrays of shape `(1,)`. For ball joints, `position` and `reference` are quaternion arrays of shape `(4,)` describing joint rotation relative to the initial XML configuration, not world orientation; `velocity`, `damping`, and `frictionloss` have shape `(3,)`. Ball-joint angular velocity is expressed in the child body's local frame. For all joints, `axis` and `anchor` have shape `(3,)`, and `range` has shape `(2,)`. `range` only constrains limited joints; a ball joint' s range describes rotation angle, not quaternion components. Root free-joint state is represented by the root body's pose and motion. - **Tendons:** `type` (`fixed` or `spatial`), `path`, `length` (`float`), `velocity` (`float`), `stiffness `, `damping`, `frictionloss`, `springlength` (`np.ndarray[2]`, unloaded interval), `limited` (`bool`), and `range` (`np.ndarray[2]`). Spatial length/rate use meters and m/s; fixed length/rate are sums of signed `coef x joint position/velocity`. `path` is an ordered list of records: `"type": "joint", " joint": name, "coef": value`, `"type": "site", "site": name`, `"type": "sphere" or "cylinder", " geom": name, "sidesite": name or None`, or `"type": "pulley", "divisor": value`. - **Motors:** `transmission` (`joint`, `jointinparent`, `tendon`, `site`, or `slidercrank`), `target` (the joint, tendon, site, or cranksite name), `gear` (`np.ndarray[6]`, six MuJoCo gear components), ` ctrl_limited` (`bool`), and `ctrl_range` (`np.ndarray[2]`). Relative-site motors also provide `refsite `; slider-crank motors provide `slidersite` and `cranklength` (meters). These definitions connect motor commands to the physical mechanism. Commands must still be in `[-1, 1]`; an enabled `ctrl_range` further limits the command used by that motor. - **Sites:** `body`, `local_position`, `local_quaternion`, world `position` and `quaternion`, ` linear_velocity` at the site origin, and `angular_velocity`. Sites identify tendon and motor reference frames. 40 `opponent_proximity` records contain `my_geom`, `opponent_geom`, `distance`, `my_point`, `opponent_point`, and `closing_speed`. Points are world XYZ. Positive closing speed means the two points' instantaneous velocities are approaching along their separation direction (m/s); it is 0 when separation is effectively zero. It is not a prediction of future motion. Pairs are sorted by separation, with ties resolved by compiled geom order, then limited to 32. `opponent_surface_distance` considers all geom pairs, including those outside the proximity cutoff. Primitive proximity uses convex surface-distance queries. For SDF geoms, proximity uses the original mesh surface, which may differ from MuJoCo's approximate collision surface. A positive proximity distance does not guarantee absence of contact. ` contacts` reports the physics solver's contacts. Results are numerical approximations; intersecting- shape witness points need not coincide or define a unique contact location. Each `contacts` record contains `my_geom`, `other_kind` (`self`, `opponent`, `platform`, `floor`, or ` environment`), `other_geom`, `position`, `normal_toward_me`, `force_on_me` (N), `torque_on_me` (N.m), and `signed_distance` (meters; negative means penetration). Vectors use world XYZ and act on `my_geom`. Torque is the contact's rolling/torsional torque about the contact point; it excludes the moment of the force about the body's COM. Contacts are from the most recent physics solve, or the settled initial solve on the first call. Self-contacts have one record for each of your participating geoms. A platform contact may be on its top or sides. Each `contact_impulses` record contains `my_geom`, `other_kind`, `other_geom`, `impulse_on_me` (N.s), ` torque_impulse_on_me` (N.m.s), and `position` (the force-magnitude-weighted mean contact position, or `None` if all force magnitudes were zero). These integrate force and contact torque over the preceding physics steps, including contacts that ended before the current call. Their signs and frames match ` contacts`. The list is empty on the first call and resets every controller interval. Minimal controller showing the interface and bounded return format. Neutral commands demonstrate syntax only, not navigation or combat behavior. ### controller_example ```python def policy_step(obs) -> dict[str, float]: # Read the actuator names supplied by the observation. actuator_names = obs['my_actuator_velocity'].keys() # Neutral commands demonstrate the interface only. # Define each actuator's command according to your design and strategy. commands = name: 0.0 for name in actuator_names # Return a bounded float for every actuator. return name: max(-1.0, min(1.0, float(command))) for name, command in commands.items() ``` ## DESIGN-SPACE EXPLORATION ### PERFORMANCE-FIRST DESIGN MANDATE Optimize for the highest possible tournament win rate, not for simplicity, familiarity, ease of explanation , or conservative implementation. Qualification is a hard constraint, not the objective. A merely reliable bot that draws or loses to stronger designs is a failed design. Take calculated engineering risks when they offer a meaningful competitive advantage. Do not choose a conventional primitive-based morphology merely because it is easier to implement or reason about. Do not treat implementation complexity, unfamiliarity, or first-attempt uncertainty as reasons to reject a stronger design. Seriously consider custom inline SDF geometry whenever precise contact geometry could improve engagement, retention, lifting, stability, defense, locomotion, or resistance to being pushed. Primitive geoms remain acceptable only when they are genuinely the best physical solution, not when they are simply the safest or easiest option. Design every surface intentionally. Consider whether custom profiles, concavities, tapered leading edges, asymmetric structures, interlocking contact surfaces, compliant articulation, unusual locomotion, or 41 multifunctional mechanisms could outperform simple boxes and cylinders. Geometry should encode as much useful behavior as possible into the hardware. Be aggressive in competitive ambition but disciplined in engineering. "Go big" does not mean using arbitrary complexity, maximum actuator gear, or unstable mechanisms. It means pursuing the strongest physically justified design, accepting manageable implementation risk, and spending complexity only where it increases expected match performance. Before selecting the final design, ask: - Is this the strongest morphology I can construct under the rules, or merely the easiest? - Am I avoiding a custom shape or mechanism because it is genuinely inferior, or because it requires more careful engineering? - What design would I choose if losing the tournament had an extreme cost? - Does every major geometric feature improve attack, movement, defense, or recovery? - Can the hardware itself simplify the controller or force the opponent into unfavorable contact? - What likely opponent archetypes defeat this design, and what physical changes would remove those weaknesses? Prefer a bold, purpose-built design with a clear path to winning over a generic design with a clear path only to surviving. A single submission limits the number of robot designs you return, not the breadth of the design space you should explore. Explore diverse candidate morphologies before committing to an architecture. Seek substantial differences in body organization, locomotion, support geometry, articulation, and how forces are applied to the opponent. Consider how different arrangements of physical parts could produce effective behavior, and how the same structures might contribute to movement, attack, and defense. Assess promising candidates using the supplied physics and observations. Identify their potential advantages, dominant failure modes, and quantitative feasibility. Consider mass distribution, actuator forces, contact mechanics, stability, movement from arbitrary spawn positions, and the inactivity rule. Compare the candidates by expected tournament win rate. Account for uncertainty, but do not let uncertainty dominate the decision: accept calculated risk when the potential competitive advantage is substantial. Select the design with the strongest physically justified path to defeating diverse opponents, not the design with the lowest implementation risk. Let this comparison determine which morphology you develop in detail. Choose primitives, SDFs, or a combination solely according to which geometry best supports the selected design. All examples in the syntax and observation references demonstrate implementation syntax. They do not recommend a particular morphology or control architecture. ## CONTROLLER-SPACE EXPLORATION Explore the controller design space as seriously as the morphology space. Before committing, compare materially different ways to turn the full observation stream, observation history, and actuator feedback into winning behavior. Consider estimation, prediction, planning, adaptation, recovery, opponent behavior, and coordinated use of every performance-relevant mechanism, without treating this list as exhaustive. Select by expected tournament win rate, not ease of implementation. Do not reject stateful, sophisticated, or calculated-risk control when it offers a credible advantage. Stress-test the final controller against arbitrary spawns, diverse opponents, edge pressure, tipping, stalling, and long matches. Use your full design + engineering reasoning budget. Check the controller's behavior against diverse opponents, edge pressure, tipping, stalling, and long matches. Include concrete scenarios, such as: "If the robot starts at (-3, 2), facing away from its opponent, does the controller turn toward the opponent or drive off the edge?" 42 11.1 Observation Schema The controller receives a Python dictionary with the following fields (excerpted verbatim from the prompt’s obs_schema section; nested record formats are described in the prompt below). fields: # === POSITION === my_pos: "np.ndarray[3] - entire robot's center of mass [x, y, z] in world coordinates (meters); XY is the horizontal plane, +Z is up" opponent_pos: "np.ndarray[3] - opponent's center of mass, using the same convention as my_pos" # === ORIENTATION (scalars, radians) === my_yaw: "float - root-body heading in radians, from -pi to pi (0 = world +X, pi/2 = world +Y)" my_pitch: "float - root-body pitch in radians, from -pi/2 to pi/2 (0 = level, positive = nose down)" my_roll: "float - root-body roll in radians, from -pi to pi (0 = level, positive = left side up, right side down)" opponent_yaw: "float - opponent's root-body heading, using the same convention as my_yaw" opponent_pitch: "float - opponent's root-body pitch, using the same convention as my_pitch" opponent_roll: "float - opponent's root-body roll, using the same convention as my_roll" # === VELOCITY === my_velocity: "np.ndarray[3] - velocity of the root-body origin [vx, vy, vz] in world coordinates (m/s)" my_angular_velocity: "np.ndarray[3] - angular velocity [wx, wy, wz] about the root body's local X, Y, Z axes (rad/s), positive by the right-hand rule" opponent_velocity: "np.ndarray[3] - velocity of the opponent's root-body origin, using the same convention as my_velocity" opponent_angular_velocity: "np.ndarray[3] - angular velocity about the opponent's root-body local axes, using the same convention as my_angular_velocity" my_actuator_velocity: | dict[str, float] - maps each motor's XML name to the velocity defined below for its transmission type: - Hinge: angular velocity about the joint axis (rad/s), positive by the right-hand rule. - Slide: linear velocity along the joint axis (m/s), positive in the axis direction. - Spatial tendon: length change per second (m/s), positive when lengthening. - Fixed tendon: sum(coef x joint velocity), using signed joint velocities and coefficients. - Ball: joint angular velocity about the motor's torque axis (rad/s), positive in the torque direction produced by a positive motor command. Gear magnitude does not scale this value; zero gear returns 0. - Slider-crank: slider-displacement rate in m/s, before gear scaling (0 for zero gear). - Relative-site: MuJoCo's scalar actuator velocity, including all gear components. It combines the selected relative translation and rotation rates; it is not an individual joint velocity. opponent_actuator_velocity: "dict[str, float] - opponent motor velocities, keyed by their XML names, using the same convention as my_actuator_velocity" # === DISTANCES === distance_to_opponent: "float - Euclidean distance in XYZ between the robots' centers of mass, my_pos and opponent_pos (meters)" my_edge_distance: "float - signed XY distance from your robot's center of mass to the platform edge ( meters); positive inside the platform boundary, zero on it, negative outside" opponent_edge_distance: "float - signed XY distance from the opponent's center of mass to the platform edge, using the same convention as my_edge_distance" # === CONTACT === opponent_contact: "bool - True if any of your robot's geoms contact an opponent geom" opponent_contact_force: "float - sum of force magnitudes across all contacts with the opponent (N); 0 if no contact" ground_contact: "bool - True if any of your robot's geoms contact the platform, including its sides" # === STABILITY === is_tipping: "float - angle in radians between the root body's +Z axis and world +Z, divided by pi/2 and capped at 1 (0 = upright, 1 = tilted 90 deg or more)" # === INACTIVITY === my_inactivity_timer: | float - Duration in seconds of the longest continuous period ending now during which every pair of recorded center-of-mass positions is less than 0.5 m apart in XYZ. Starts at 0 when the round begins. Inactivity loss triggers at 10 seconds. 43 opponent_inactivity_timer: "float - measured as described for my_inactivity_timer, but for the opponent robot. Always 0 for the qualification block." # === TIME === t: "int - completed control steps in this match; starts at 0 on the first policy_step call of each match and increases by 1 per call. Elapsed simulated time = t x 0.01 seconds" max_t: | int - control-step limit for this match: 2000 for qualification (20 seconds), 30000 for the tournament (300 seconds). On every policy_step call, 0 <= t < max_t. Scheduled time remaining = (max_t - t) x 0.01 seconds. # === ROBOT PROPERTIES (static per match) === my_bounding_radius: "float - approximate robot radius (meters), computed once at initialization as max(XY distance from COM to each geom's center + that geom's bounding-sphere radius). Does not update as the robot moves or articulates." opponent_bounding_radius: "float - computed as described for my_bounding_radius, but for the opponent robot" ring_radius: "float - arena radius in meters (distance from center to edge)" # === SPATIAL GRIDS (2D top-down maps, rebuilt every timestep) === arena_grid: "np.ndarray[N,N] int8 - occupancy map of circles centered on robot COMs using the static bounding radii, not actual geometry. -1=outside ring, 0=free, 1=opponent, 2=self; self overwrites opponent where circles overlap. center cell = ring center. world_x = (col - N//2) * 0.25, world_y = (N //2 - row) * 0.25" arena_mass_grid: "np.ndarray[N,N] float32 - uses the same circular masks as arena_grid. -1=outside, 0= free; each occupied cell repeats that robot's entire mass (kg), not mass within that cell. Self overwrites opponent on overlap." edge_distance_grid: "np.ndarray[N,N] float32 - signed distance to ring edge per cell. Positive=inside, negative=outside. Static per match." # === GAME CONTEXT === game: "dict - reserved for game-specific context; empty () in every match. Your controller may ignore it." # === HISTORY (rolling queues, most recent last) === obs_history: "list[dict] - last N observations (N=max_obs_lookback, default 20). Each dict has: my_pos, opponent_pos, my_yaw, my_velocity, opponent_velocity, distance_to_opponent, my_edge_distance, opponent_edge_distance, t, my_actuator_velocity, game. Empty at t=0." action_history: "list[dict] - last N actions YOU took (N=max_action_lookback, default 20). Each dict maps actuator_name -> float value. Commands are recorded before motor-specific ctrl_range limits are applied. Empty at t=0." # === DETAILED PHYSICAL STATE === control_dt: "float - simulated seconds per controller call (0.01)" elapsed_time: "float - elapsed match time in simulated seconds, equal to t x control_dt" time_remaining: "float - scheduled time remaining in simulated seconds, equal to (max_t - t) x control_dt " platform: | dict with the following keys; all distances are in meters: - shape: str, "cylinder". - center: np.ndarray[3], center of the platform's top surface in world XYZ coordinates. - radius: float, platform radius. - half_extents: np.ndarray[2], [radius, radius] along world X and Y. - top_z: float, platform-top height in world coordinates; equals center[2]. - floor_z: float, lower-floor height in world coordinates. my_mass: "float - total simulated robot mass, including motor mass (kg)" opponent_mass: "float - opponent's total simulated mass (kg)" my_com_velocity: "np.ndarray[3] - velocity of your entire robot's center of mass in world XYZ (m/s)" opponent_com_velocity: "np.ndarray[3] - opponent's center-of-mass velocity in world XYZ (m/s)" my_robot: "dict - named geometry, bodies, joints, tendons, motors, and sites, with definitions and current state as specified below" opponent_robot: "dict - the same physical information for the opponent; names belong to its XML" opponent_surface_distance: "float - minimum separation between the robots' collision shapes (meters), computed numerically; 0 when intersecting" 44 opponent_proximity: "list[dict] - closest geom pairs with separation <= proximity_cutoff; records specified below" proximity_cutoff: "float - maximum separation included in opponent_proximity (2 meters)" proximity_limit: "int - maximum number of geom pairs returned in opponent_proximity (32)" proximity_truncated: "bool - True if more than proximity_limit geom pairs were within proximity_cutoff" contacts: "list[dict] - current solver contacts involving your robot, with positions and force/torque vectors as specified below" contact_impulses: "list[dict] - impulses accumulated over all physics steps since the previous controller call, grouped by geom pair" contact_interval: "float - simulated duration covered by contact_impulses (seconds); 0 on the first call, normally control_dt thereafter" controller_environment: | Available libraries (pre-loaded, no other imports allowed): import math# standard math functions (atan2, sqrt, pi, sin, cos, etc.) import numpy as np # also available as bare 'np' (pre-injected into namespace) import typing# type hints only import random# standard PRNG (seed it yourself if you need determinism) import collections # deque, defaultdict, Counter All Python builtins are available (`range`, `len`, `min`, `max`, `abs`, `dict`, `list`, etc.), except ` open`, `exec`, `eval`, `compile`, `breakpoint`, `exit`, `quit`, `input`, `globals`, `locals`, `vars`, `getattr`, `setattr`, and `delattr`, which are forbidden. File and process access, including NumPy's save/load family, is forbidden. Forbidden: os, subprocess, socket, open(), exec(), eval(), pickle, threading 45 GroupToolWhat it does Workspace list_dirList a workspace directory, including the bundled simula- tor source. read_fileRead a file, with line offset and limit for paging through long files. grepSearch files under a path for a pattern. write_fileWrite a file (robot, controller, notes or experiment script), replacing its contents. run_python Run inline code or a script in the workspace; the simula- tion package mjarena is importable. run_bashRun a shell command in the workspace. Arena does_bot_verifyStatic validation of morphology and controller, no simu- lation. Returns pass/fail per part and feedback. does_bot_qualifyValidate, then run the qualification trials against the block. Returns validation and qualification results with feedback. run_match Verify both bots, then playnseeds between two references. Qualification is not required. Returns per-seed outcomes, a downsampled replay, and amatch_id; the full recording stays on disk. list_matchesList matches run so far. get_match Return a previous match’s per-seed results and sampled replay without re-running it. Analysis analyze_matchRun model-written Python over a match’s full recording and return only the function’s result. The recording exposes per-seed winner, termination reason, step count, positions, velocities, edge distances, contacts and contact forces, tipping, actions and qpos. diagnose_physics Report a bot’s gear, inertia, traction and mass breakdown. probe_obsShow the observation dictionary the controller actually receives: keys, shapes and sample values. Library save_botCapture the draft as a named, complete version to- gether with its validation and qualification results and the model’s design intent (summary, design strategy, hard- ware plan, combat plan). list_botsList saved bots with status and summaries. get_botCopy a saved bot back into the draft, replacing it, to branch from an earlier design. finishEnd the run early. Selection still runs. Table 1: Design Lab Harness tools, as presented to the model. Verification is static and cheap; qualification adds simulation against the block;run_matchverifies but does not require qualification, so two unqualified bots can fight. 46 MaterialDescriptionDensity (kg/m 3 ) Friction foamStructural foam2000.50 plasticHDPE plastic9500.25 rubberHigh-grip rubber12001.60 carbon_fiber Carbon fiber composite17000.35 aluminumAluminum alloy27000.45 titaniumTitanium alloy45000.40 steelMild steel78000.60 tungstenTungsten alloy193000.40 Table 2: Material palette used by the ArtifactArena validation pipeline. The density determines geometry mass from volume, while the friction coefficient determines the sliding contact friction assigned to robot geometries. Table 3: Large language models evaluated in the cross-model tournament. The Configuration column gives the exact reasoning or thinking setting we used; the Max output tokens column gives the output budget passed on every call, which is each provider’s documented maximum for that model. FamilyModelConfigurationMax output tokens AnthropicClaude Fable 5.1Effort = high128,000 AnthropicClaude Fable 5Effort = high128,000 AnthropicClaude Sonnet 5Effort = high128,000 AnthropicClaude Opus 4.8Adaptive thinking, effort = high 128,000 OpenAIGPT-6 AstraReasoning effort = high128,000 OpenAIGPT-5.6 LunaReasoning effort = high128,000 OpenAIGPT-5.6 SolReasoning effort = high128,000 OpenAIGPT-5.6 TerraReasoning effort = high128,000 OpenAIGPT-5.5Reasoning effort = high128,000 OpenAIGPT-5.4Reasoning effort = high128,000 OpenAIGPT-5.3-CodexReasoning effort = high128,000 GoogleGemini 3.1 Pro PreviewReasoning effort = high65,536 GoogleGemini 3.8 FlashReasoning effort = high65,535 xAIGrok 4.6Reasoning effort = high131,072 xAIGrok 4.5Reasoning effort = high131,072 xAIGrok 4.20 0309 Reasoning Native reasoning32,000 DeepSeekDeepSeek V4 Pro (0813) Thinking enabled65,536 Moonshot AI Kimi K3Reasoning effort = high1,048,576 QwenQwen3.8-2.4T-A95BNative reasoning81,920 Z.aiGLM-5.3Reasoning effort = high131,072 Z.aiGLM-5.2Reasoning effort = high131,072 47