msr-spare-1/qwen3-4b-0630-tooluse-eval-aligned-r32-spare-games-envs

qwen3-4B-Instruct-0630-tooluse-eval-aligned-r32 — generated environments

Environments generated by the SPARE proposer during training run 050mlekj (qwen3-4B-Instruct-0630-tooluse-eval-aligned-r32), recovered from the spare-viz durable cache. The run's scratch directory no longer exists; this dataset is the surviving copy.

Layout

manifest.json authoritative games list games/gen<NNNN>/game<NNNNN><NNN><slug>.py one environment per file

generation numbers are dense over the training steps actually captured; the true training step is the step field. Each game exposes the standard SPARE contract (reset(seed=None), step(action) -> (obs, reward, terminated, truncated, info)).

Loading

Load games through the project loader, not a bare import — it injects the common stdlib names and the ToolUseBaseEnv / TerminalBaseEnv base classes that generated games subclass without importing:

from spare.core.envs.synthetic_game_env import make_synthetic_env
env = make_synthetic_env("games/gen_0000/game_00000_000_api_orchestration.py")
obs, info = env.reset(seed=0)
obs, reward, terminated, truncated, info = env.step("...")

Caveats

• —Partial step coverage. The viz extractor pulls newest-first with a call budget, so a run's captured steps are a subset of the steps it trained.
• —No joined rewards. Weave payloads for these runs predate the reward join; meanreward/solverate are null where reward_joined is false.
• —skill / difficulty are parsed from the proposer prompt, not from a stored label.

Rendered in the env gallery via SPARE_VIZ_ENV_DATASETS=<rid>=<this dataset>.