Skip to main content
The platform resolves the version, checks you are allowed to use it, and delivers it into the job. Your training code never holds a path or a URL it chose itself.
This page is about using an environment. To write one — the manifest, the tasks, the four protocols — see authoring environments.

What the job receives

Three environment variables, set by the control plane:
Do not hard-code any of these in an experiment. The path is the platform’s to give, and an experiment that names one directly bypasses the access check that resolved it.

The split is not yours to choose

STARFORGE_ENVIRONMENT_SPLIT is set from the operation: a training job gets train, an evaluation gets eval. There is no flag to override it. That is the whole safety property, and it is worth being blunt about why it is a state rather than a setting. Held-out data stops being held out the moment choosing it is a convenience. The run that scores best becomes the one that evaluated on its own training tasks — and nothing downstream can tell that it did. The number looks excellent, the model is not, and the mistake is invisible in every artifact the run produced. Making the operation decide means the leak is not a setting somebody can get wrong. It is a state the system cannot reach. An evaluation asking for a split the environment never declared is refused, rather than quietly served the training tasks.

The three routes, from a trainer’s point of view

The platform runs the environment server. Your trainer drives the episode through openenv-core’s client — reset, step, state — against STARFORGE_ENVIRONMENT_URL.TRL, SkyRL, Unsloth and Axolotl consume this natively. Nothing extra to write.

Rewards come from the verifier

You do not write a reward function for the environment — the environment declares what decides completion, and it is always a reference: A verifier that cannot answer raises; it does not report zero. See verifiers for why that distinction matters more than it sounds.

Sandboxes

An environment whose harness runs model-generated code declares sandbox.required. On a deployment with no sandbox provider configured, such a job is refused at admission — it does not fall back to running the code in the training container. If you need one and get refused, an administrator sets FORGE_SANDBOX_IMAGE. There is no default, deliberately: running model-generated code is not something to enable by accident.

Confirm it worked

The launcher logs the environment it resolved and the route it took:
If the reward stays flat at exactly one value for every rollout, suspect the verifier before the model — a plugin verifier returning a constant looks identical to a task the model cannot do.

Next

Author an environment

The manifest, the taskset, and the four protocols.

Rubrics

The standard a rubric verifier scores against.