Quickstart

Run the whole mechanism on your laptop in a few minutes — no API key, no chain, no GPU.

Status. v3 runs live on Bittensor mainnet, netuid 99, and is open for submissions; the user-facing gateway is not built. What this page runs is offline and needs none of that: the full window simulation with a cast of archetype miners, and the miner's dev kit against your own conductor.

1. Install

git clone https://github.com/thirtyspokes99/thirtyspokes && cd thirtyspokes
uv venv --python 3.12 && uv pip install -e ".[dev]"
uv run pytest -q                       # the invariant suite

The core needs nothing beyond the dev extras. Two optional extras exist for the validator's real-world seams and are never needed offline: store (the S3 client behind the submission store) and benchmarks (SWE-bench's own grader, parquet, the Hub).

2. Watch a window run

uv run thirtyspokes-sim

One offline window, every module in the mechanism, nothing re-expressed: the committed window and its nonce, the pinned scaffold, the two reference policies and the power gate, the priced score, the four-condition verdict, and the crown's payroll. The cast is the archetype miners the mechanism must rank correctly — a specialist that genuinely routes better, an honest copy of the best fixed policy, a copier of the king, a miser that always calls the cheapest model, a spendthrift that always calls the dearest, a degenerate that never reaches an action, and a saboteur that delegates to nothing useful. The report prints who was admitted, who was refused and why, every arm's final, each duel's four conditions, and the weights that would have gone on chain.

The suite pins the order the cast must come out in: specialist > honest = copier = miser > spendthrift > degenerate > saboteur. If a change to the mechanism reorders them, a test fails.

3. Test your own conductor the way the validator will

uv run thirtyspokes-dev --model-tree ./weights --reference ./reference \
    --conductor my_serving:conductor --budget-usd 1

thirtyspokes-dev calls the validator's own functions — admit, the scaffold, the arm scorer — never a reimplementation, so what you see locally is what the validator scores. It leads its report with the two things a bare score hides: the parse-failure rate (turns that did not end in a valid action) and the endings breakdown (STOP, step cap, wall clock), then prints the decisions themselves — which model at which step, and why each episode ended.

It does not run your 70 GB of weights; that needs your serving stack, reached through the same Conductor seam the validator uses (--conductor module:attr). It touches no bucket, no chain and no network: you can iterate before registering anything.

4. What a conductor emits

One action per step, as the last line of its reply:

REASON <free text>          optional, capped at 512 tokens — never leaves the conductor
DELEGATE <model-id>         send the ORIGINAL task to this model
RETRY <model-id>            send it again, to a different (or the same) model
STOP                        submit the best answer so far

MAX_STEPS = 12 per task. The score keeps the best answer across your delegations, so a retry can only help your quality — and always costs dollars. See Build a Conductor.

5. Enter

When the dev kit says admitted and the endings look like routing rather than looping, read Mine the Subnet. It is three commands — identity, check, submit — and the last one spends your hotkey's one shot.