RackLife: ten days in a GPU data center

RackLife is a long-video understanding benchmark: 50 hours of continuous footage that follows one technician, Alex, through ten working days at a fictional GPU data center (Helios Compute), with 411 multiple-choice questions about what happened (version 3).

The world is rendered procedurally in Panda3D from a scripted timeline, so every answer comes from ground truth rather than from human annotation of the footage. Every clue a question relies on was shown on screen, as recorded by a per-second visibility pass of the render.

Version 3 re-rendered all ten days. Besides the main storyline, the scripts now hold 15 side storylines about objects that are moved, borrowed, returned, swapped and left behind over several days, with eight new kinds of object (thermos, lunchbox, desk plant, watering can, tool case, cable reel, hard hat, fan module). The walls and table tops of every room carry 76 cluttered pictures made with FLUX 3 Image Klein and checked against their object lists, so the scenes are no longer bare.

Video

• videos/day01.mp4 … videos/day10.mp4: one file per day, 10:00:00 to 15:00:00 game time, 5 hours each.
• 1280×720, 5 fps, H.264, 90,000 frames per day.
• Video second 0 is 10:00:00 of that day.
• The corner of every frame shows the day, the weekday and the clock. Day 1 is a Monday and Day 10 is a Wednesday.
• Spoken lines appear as subtitles at the bottom of the frame, prefixed with the speaker's name. Radio, phone, PA and lines heard through a door are marked. There is no audio track.
• The camera mostly follows Alex from behind. It cuts to close-ups when Alex looks closely at something, puts down or picks up an object, or watches CCTV playback.

Questions

Every question has a query time. A model may only see the video before the query time: all earlier days, plus the query day up to that moment. All evidence ends before the query time, and the answer never depends on anything that happens after it.

File	Format
questions_mc.json	Multiple choice, in the EgoLifeQA style. Fields: ID, query_time (date = DAYn, time = HHMMSSFF), type, question, choice_a … choice_d, answer (letter), evidence (per-day intervals in seconds from 10:00:00).

Every question has four options. The type follows the question types of MM-Lifelong:

type	Count
Counting	58
Hallucination Detection	58
Temporal Reasoning	56
Event Recognition	40
Event Tracking	38
Social Interaction	37
Entity Recognition	36
Attribute Recognition	32
State Change	31
Causal Reasoning	25

Several clues across days

Every question needs at least two clues, and the earliest clue lies on a day before the query day; no single moment of the video gives the answer. Questions ask about objects and their details, who did what with them, why, in what order, and how things changed. Four of the 411 answers are a room.

No searchable on-screen text

The video is full of text: subtitles, door signs, rack and object labels, brand names on cans, screen contents and the clock. A caption index copies all of it word for word. If a question reused that text, a model could answer it with a keyword search, without understanding the video. So no question or option does:

• Spoken lines are paraphrased, or the question asks about what they imply, without their distinctive words. People's names are kept, because the subtitles show them.
• Rooms are named by how they look, for example "the dark gray room with a wall of camera monitors", not by their door signs. The four data halls look alike, so they are one kind of room: "a server hall with rows of black server racks".
• Objects are named by what they are and what happened to them, not by their labels. Soda is named by the color of the can.
• Times are given as parts of the day, such as "late in the morning", not as clock times.

Method

RackLife is generated, not filmed: a written script is turned into footage and into questions whose answers are known exactly.

1. Script. A fictional GPU data center is defined as rooms, props, object places and characters. A ten-day script gives every character timed actions (walking, working, inspecting, picking up, putting down, handing over, buying, saying a line) and the state changes of objects. Besides the main storyline, language-model agents (Claude Sonnet in a Claude Code workflow) wrote side storylines about objects that are moved, borrowed, swapped and left behind across days; every day is compiled and checked by a program, and errors go back to the agent. The compiler turns the script into a deterministic per-second timeline of positions, states, subtitles, camera shots and events.
2. Rendering. Panda3D renders the timeline into one five-hour video per day, with procedurally generated assets, physically based lighting, burned-in subtitles and an on-screen clock. Walls and table tops carry cluttered pictures generated with FLUX 3 Image Klein from object lists with bounding boxes; agents check every picture against its object list, and a picture that does not match is generated again from a revised description. An ID pass records, once per second, how many pixels of every person, object and picture are on screen.
3. Fact sheets. The timeline and the ID pass are merged into one fact sheet per day: every event, marked by whether its person or object was on screen and whether its subtitle was shown; the position history of every object; and when each picture was in view, with its object list.
4. Questions. Question-writing agents write questions from the fact sheets, naming the clues each answer relies on; a program check, a judge and a blind check then filter them, as described below.

方法

RackLife 是生成的，不是拍摄的：先写剧本，再从剧本得到视频和题目，所以每道题的答案都确切已知。

1. 剧本：虚构的 GPU 数据中心由房间、道具、物品摆放位置和人物定义。十天的剧本给每个人物安排带时间的动作（走动、工作、查看、拿起、放下、递交、购买、说台词）以及物品的状态变化。除主线外，语言模型代理（Claude Code 工作流中的 Claude Sonnet）写了多条跨天的物品支线：物品被挪动、借走、调换、遗落。每天的剧本都由程序编译和检查，出错就把报错交回代理。编译器把剧本变成逐秒确定的时间线，包括位置、状态、字幕、镜头和事件。
2. 渲染：Panda3D 按时间线把每天渲染成一段 5 小时的视频，资产全部程序生成，使用基于物理的光照，字幕烧进画面，角落显示时钟。墙面和桌面贴有 FLUX 3 Image Klein 按带框的物品清单生成的杂物图；代理逐张对照物品清单检查，不符的改写描述后重新生成。ID 通道每秒记录每个人物、物品和贴图在画面中的像素数。
3. 事实表：时间线和 ID 通道合并成每天一份事实表：每个事件都标明动作人或物品是否在画面上、字幕是否显示；每件物品的位置变化；每张贴图何时入画及其物品清单。
4. 出题：出题代理根据事实表写题，并写明答案依赖的线索；之后经过程序检查、审核代理和盲答检查筛选，详见下文。

How the questions were made and checked

1. Fact sheets are built from the compiled timeline and the per-second visibility log of the render: every event with whether its person or object was on screen and whether its subtitle was shown, the position history of every object, and when each clutter picture was in view (with the object list of each picture).
2. Question writers, one per question type and range of days, wrote questions from the fact sheets. Each question names its clues: events that were on screen, or clutter pictures that were in view.
3. A program check confirms that every clue was on screen, that there are at least two clues with the earliest on a day before the query day, and that all clues end before the query time. It also checks the text: no sign name, label, brand or clock time; no four words in a row, two of them rare, shared with any subtitle or screen; no rare word from a spoken line a clue relies on; four distinct options; at most one answer in ten is a room.
4. A judge checked every question against the fact sheets. A question was dropped unless the answer is right and unique, every wrong option is a plausible candidate from the video, the answer needs several clues with one before the query day, no spoken line or on-screen text is quoted, and every clue was shown before the query time.
5. A blind check answered each remaining question from its text and options alone; questions it answered correctly with high confidence were dropped.

Questions were written in two rounds, the second told to avoid the questions of the first. Of 662 candidates (306 and 356), 415 passed the judge and 411 the blind check. Answered from text and options alone, without the video, 46% of the final questions are guessed correctly (25% would be chance).