CUA-frontier Contribute a task

CUA-frontier

Computer-use agents, tested in game development, physical and embodied AI, and professional tools like CAD.

Most computer-use benchmarks stay inside web and office apps. Here, agents build and playtest games, operate robots, machines and lab instruments, and engineer designs in CAD. Every task grades what the agent actually produces, with a verifier hardened against shortcuts.

Explore the research Meet the team Contribute a task

Research

Where computer use gets hard

Each area studies something current computer-use benchmarks cannot see: games played on their own clock and next to people, what work done on a screen does in the physical world, chip designs whose checks can be wrong too, and processes whose final state hides the mistake. Two more cut across domains: worlds that do not wait for the agent, and work shared between people and their own agents.

01 Games Can an agent play, test and build games the way people experience them: on the game's clock, next to human players, and without being told the rules? Agents can already generate a playable game and keep improving it. The projects here go after what that loop does not measure. As in CUA-SWE, the agent sees only the screen and uses only keyboard and mouse, and the verifier reads the game's own state.
02 Physical AI Can an agent design, measure, program, operate and simulate physical things through the software people use, with results that hold up when they are built, run or tested? Engineering, lab and plant work runs through software: CAD and slicers, instrument software, teach pendants and PLC editors, teleoperation screens, simulators. Computer-use benchmarks stop at the saved file or the click, and embodied benchmarks score a robot policy, or a coding agent's program, on a goal it is given. Projects here judge the agent's work by what it does once it is built, run or tested in simulated physics: the part holds, the measured value is right, the cell makes good parts at rate, the robot gets there, the simulation predicts the run it stands in for.
03 Chip & EDA When a check fails, can the agent tell whether the design, the testbench, the constraints or the flow is wrong, and fix that one? Agents write RTL and circuits, build their own tests, and push designs through implementation tools. Most prior work runs the tests for the agent or repairs one layer at a time. Projects here give the agent control of both the design and how it is checked, and score recovery against the unchanged specification.
04 Workflows Does the agent get the process right, not just the final state? Business tasks are spread across several systems, and a support ticket can read "resolved" after a refund went out twice. Projects here inject the faults real operations see, such as timeouts with an unknown outcome and duplicate webhooks, and check invariants and the order of operations as well as the end state.
05 Real time Can an agent keep deciding well when the world does not wait for it, and how fast a world can it keep up with? Decision models such as Jev and OpenAI Decisions answer a choice among given options in about a second or less, and they can drive a screen when its candidate actions are offered as that choice. Projects here build the tasks a real-time decision-maker is judged on: screens where decisions come quickly, the options are on the screen, and the best option changes while the agent decides. A task can run at several tempos, and the world's own record grades every decision as it lands, so it tells how fast a world an agent keeps up with, not only whether it finished.
06 Collaboration Can people, each working through their own computer-use agent, reconcile their changes to one application's code, visuals and running behavior, and keep what each of them needs even when their work is out of sync? More people now work through an agent of their own, on products whose parts other people own. Two changes can merge cleanly and still break what a user sees; a fix that looks right can quietly undo someone else's feature; and work published late arrives without the reasons behind it. Projects here give each person their own CUA agent on a shared application, where finding and fixing such a conflict takes running the application and looking at it. Games are the first testbed and large 3D design the second.

Approach

No role grades its own work

Each task is a prompt, a world, a verifier and an intent that have to agree. Agents build a task and attack it, frontier models attempt it, and people read every failure before anyone reviews it. Each step leaves a record that is checked automatically before review.

  1. 01 · Author agentBuilds the taskThe prompt, the world it runs in, a verifier made for it, and what it measures.
  2. 02 · VerifierCalibrated on known answersIt must accept a reference solution and reject plausible wrong ones.
  3. 03 · Red-team agentTries every shortcutA separate agent tries to pass without doing the task. What works gets fixed.
  4. 04 · Solver agentsFrontier runsFrontier models attempt the task end to end, three or more times, and at least one attempt must fail.
  5. 05 · PeopleRead every failureEach failure must come from missing capability, not a broken task.
  6. 06 · Audit agentChecks five agreementsNo hidden requirements, no back doors, no reward hacking, a real request, legitimate failures.
  7. 07 · ReviewersApprove, then mergeSomeone other than the submitter reviews it before it joins the benchmark.

Team

The people behind it

CUA-frontier is built by a growing team of students and researchers, with tasks from contributors across every area.

Organizers

Advisors

Core contributors

Meet the team
Bring a task to the frontier

Pick a project, have your coding agent build a task that tests its question, run the frontier models on it, and open a pull request. People review it there.

How to contribute