Summary

Rebased onto the multi-agent episode wire (#1939): origin/main was merged wholesale and the change re-landed on top, adapted to Env/Episode.

• The v1 env server no longer owns a taskset. The client — the eval entrypoint here, the prime-rl orchestrator in the companion PR — loads the taskset once and ships each dispatched task's data on the run request (task_data, the task's dumped TaskData); the server pydantic-validates it into the taskset's declared TaskData type and rebuilds the Task exactly as load() would, then runs it through the env (slots/run_slot) as usual.
• run_eval_server now selects and resumes tasks client-side, in the same coordinate system as the in-process runner (task.data.idx) — fixing the resume coordinate bug structurally (supersedes fix(v1): resume must match saved rollouts by load position, not data.idx #2017, see Verification).
• Server-side task state is gone: no per-worker load() (a pool of N workers used to pull the dataset N times), no idx-addressed task cache, no MAX_LAZY_TASKS, and infinite tasksets no longer need to generate identical sequences in every pool worker — the one client-side generator is pulled lazily and each produced task is shipped to whichever worker runs it.
• Task data serializes whole: a TaskData subclass may not exclude fields from serialization (enforced at class definition) — an excluded field would vanish on the wire and the server would rebuild the task with silently-defaulted values. Harbor's task_dir, the only such field in the tree, now serializes (rows also become rebuildable for replay).
• Taskset.task_type() classmethod resolves the declared Task subclass off the generic (used by the server, Env.__init__, and loaders.task_type).
• The legacy v0 bridge keeps task_idx addressing — its dataset genuinely lives server-side — and run_group stays a legacy-only route, untouched. info.num_tasks is now only meaningful there.

Verification

Repro taskset: load() filters a raw 5-row dataset (like LeanTaskset filtering empty statements), so data.idx is {0,1,3,4} while load positions are {0,1,2,3}.

Before (main): uv run eval gappy_echo_v1 --server -n 4 -r 1 completes all 4 tasks; uv run eval --resume <dir> then reports "1 task(s), 1 rollout(s) owed", deletes the good idx=4 record, and re-runs idx=3 — traces.jsonl ends up {0,1,3,3} (a duplicate and a silently lost task).

After (this branch, on the episode wire):

• resume of the complete run prints nothing to resume … all 4x1 rollouts already completed without error, episodes untouched ({0,1,3,4}, all ok);
• deleting the idx=3 episode and resuming re-runs exactly data.idx 3 and restores {0,1,3,4}.

Companion prime-rl training on this branch pair: 5-step RL runs of reverse-text-v1 (finite) and alphabet-sort-v1 (infinite) — see the companion PR's Verification.

uv run pytest tests/v1 -m 'not e2e' passes.

Breaking

• Env-server wire protocol: v1 run requests take task_data (the task's wire data) instead of task_idx; task_idx remains only for the legacy bridge. EnvClient.run signature changed accordingly. Migration: load the taskset in the client (vf.load_taskset(...).select(...)) and pass task_data=task.data.model_dump(mode="json").
• TaskData fields can no longer set exclude=True — class definition now raises. Task data must survive the wire whole; harbor's task_dir (the only affected field) is un-excluded and now appears in saved traces.
• InfoResponse.num_tasks is None for v1 servers (the client owns the taskset and its count); only the legacy bridge reports a count.
• A client of an env server must now be able to load the taskset locally (the taskset package installed client-side); the server no longer materializes tasks for it.

Companion PR: PrimeIntellect-ai/prime-rl#3043.

🤖 Generated with Claude Code