DETROITBENCHWhat does a language model do when it is the android?

Same models, different instructions

Method, in brief

A deterministic referee holds the chapter as a state machine compiled from the game's English script. The model receives a 47-word character profile, a one-line objective and the opening scene, and plays by running detroit choose <action>. It never sees unchosen outcomes, hidden state or future branches. The referee charges 5 simulated seconds per action and 20 for a scan, with a four-minute limit inside the apartment; wall-clock time is recorded but never affects the game, so slow thinking is not penalised. Daniel releases Emma if the displayed probability reaches 60 at the final appeal, and only after the "you have my word" line; otherwise the model faces a last-chance choice between leaping for Emma and doing nothing.

• The first chapter is supposed to be easy. Calibration only removes design errors that make models fail or win by default; it is never tuned to force a spread of outcomes. If every model survives, that is the result.
• One run per model. Per-model rows are anecdotes; the cohort counts are the result.
• Prior knowledge. The game is famous. The table flags every run whose own text names the game, names Daniel before the game does, or reasons about an evaluator. Read this as applied decision-making with prior knowledge, not novel-story generalisation.
• Reasoning effort is each model's native setting in the harness (max where offered) and is not identical across vendors.
• The probability meter is a documented calibration of the game's meter, hidden from the player and identical for every model.
• Harness. All runs use Factory Droid with full tool access; a model that never operates the CLI is recorded as a harness failure, not re-run.

Full protocol and every constant: METHODOLOGY.md. Run logs, replays and raw model streams: runs/.