Skip to content

Under maintenance. Some results may be incomplete or inaccurate.

Robotensor
All pages21

Horizon · The rules

Entering

You submit a Hugging Face repository of weights at a commit — no code — and a token that proves the repository is yours.

4 min read

You fine-tune Zero-WAM and submit the weights. Your code is not run: every model in an epoch is served by the same runtime, so evaluation time is predictable and two models differ only by what they learned.

What you submit

A Hugging Face repository at a commit, holding weights only.

The repository

transformer/*.safetensors      the same architecture as the base model
norm_stats/*.json              your action statistics
zerowam.yaml                   inference settings, within the published bounds

Check it before you send it

horizon-runtime-zerowam check reads file headers only, so it takes seconds and needs no GPU. The organiser runs the same command on the copy they fetch, so what it says on your box is what decides your entry.

Check your weights

pip install horizon-runtime-zerowam
horizon-runtime-zerowam check --weights /path/to/your/repo

What it refuses, and why:

RefusalReason
"the weights are not this model's architecture"A tensor is missing, extra, or the wrong shape. Fine-tune the base model; do not change its shape
"the repository is N GB"Over the published limit
"zerowam.yaml sets X, which is not a knob"Only the published knobs exist
"X is N, outside [a, b]"The knob is outside its bounds

What you may tune without touching code

zerowam.yaml carries the inference settings, and only the published knobs exist. Fewer steps is faster and usually worse; that trade is yours to make. action_guidance_scale is not offered, because with a video prompt the action branch runs a single pass and the setting would do nothing.

The knobs, their ranges and their defaults are published with the runtime, not in an epoch record, so this site does not quote them: horizon-runtime-zerowam check is what holds your file to them, and it names the bound it refused you on.

How you submit

Push your repository, then enter the commit through the organiser's intake. Ask the organiser for its address and its token; for the pilot it is on a private network, so you reach it over the SSH tunnel or the network they give you.

The shape of it — fill in what only you have

export HORIZON_INTAKE_TOKEN=<the organiser's intake token>
export HF_TOKEN=<a fine-grained Hugging Face token, scoped to this repository, with content write>

horizon-competition submit --intake <the intake's URL> --participant <your name> \
  --repo <owner/name> --revision $(git -C /path/to/your/repo rev-parse HEAD)

horizon-competition status --intake <the intake's URL> --repo <owner/name> --revision <the commit>

That block is an example, not a command this site built for you: the intake's address, its token and your repository are yours, and nothing in the store carries them. Every command this site offers to run as printed is built from a record and is on the page of the epoch it belongs to.

submit does not return until the organiser has decided, because deciding means fetching your repository and checking it, which takes as long as the download does. What comes back is your entry and its submitted_at, or the reason it was refused.

Three things are worth knowing about that.

Your token proves the repository is yours. The Hub is asked who the token belongs to and whether it can write to the repository you named; if it cannot, the submission is refused. This is what stops somebody else entering your repository under their name. The token fetches the repository and is then gone: it is not stored, not logged, and not published. Your account name is recorded, and that is all. Make it a fine-grained token scoped to the one repository with repo.content.write: it is sent over the intake's plain HTTP, and a token like that can write nothing else of yours. A classic write token is accepted, but can write every repository your account can.

The organiser fetches and checks, not you. repo@revision is downloaded and horizon-runtime-zerowam check is run on the copy that arrived. Nothing you send is taken on trust — including the hash of your weights, which is computed there, from the bytes fetched. That copy is the only thing served under your key.

submitted_at is the organiser's clock, and it is signed. Your entry is an ed25519-signed record in the same store as the epochs, so the stamp that breaks a tie is not a line in a file somebody could edit.

Practical notes

  • Enter a commit, not a branch. A branch can move under an epoch, and it is refused.
  • Enter the same commit twice and you get the same entry, with the time it first arrived.
  • Entries accepted before an epoch opens are the ones it takes; later ones wait for the next week. The epoch publishes that list, signed, when it opens: you can see whether you are in this week's.
  • Identical weights are one entry, whoever sends them; the earlier one keeps the place.
  • Screening runs one episode per task first. Only the shortlist gets a full evaluation, so a model that fails everything costs you a week rather than a place.

After the week closes

The epoch's secret is revealed and everything is published: the units, the demonstrations, every result, and the scoring, signed. You can re-derive the units yourself and rebuild the same demonstrations, and check the numbers you were given — and that needs nothing installed but the competition's own package: no simulator, no fork, no GPU. epoch derive refuses a secret that does not hash to the commitment the epoch published when it opened, before it saw your entry.

Verification says what each check is worth, and why the organiser's key has to come from somewhere other than the store you are checking.

Entering · Docs · Robotensor competitions