thirty spkesDOCS
HomeDashboardGet an API key

Build a Conductor

The conductor is the miner's whole contribution: a model that reads a rendered state and emits one action. This page is the contract — what it sees, what it may say, and what the fixed scaffold does with it. The specification is docs/WHITEPAPER.md §1–§3 in the repository.

The artifact

reference model Qwen3.6-35B-A3B, pinned revision. The owner publishes the repo, revision, config.json hash, tokenizer hash and the full tensor-name/shape inventory.
artifact your own full model weights — every tensor, not a delta
architecture fixed. Layer count, hidden size, expert count and routing width, vocabulary, RoPE settings, tensor names and shapes — identical to the reference
format / dtype safetensors only, bfloat16
decoding greedy, temperature = 0, pinned max_tokens, pinned system prompt

No parameter cap, and none is claimed. The architecture pin fixes the parameter count exactly, which is stronger than a cap. Memorisation is not defended by size; it is defended by the scoring rule — a win must survive dropping your best benchmark and must move the median benchmark.

The action space

The conductor emits one action per step, parsed against a fixed grammar, as the last line of its reply. It is never executed and never forwarded.

REASON    <free text>       internal only — never leaves the conductor; capped at 512 tokens
DELEGATE  <model_id>        the scaffold sends the ORIGINAL task to this model
RETRY     <model_id>        the same, after observing an outcome
STOP                        submit the best result so far

<model_id> must appear in the window's committed catalog snapshot. Anything else is a parse failure: the step is refused, counted, and the episode continues; three consecutive parse failures force STOP. Bounds you train against, all pinned: MAX_STEPS = 12 per task, REASON_TOKEN_CAP = 512, MAX_CONDUCTOR_TOKENS = 576.

The episode

The scaffold is owner code, pinned, identical for every miner and for king and challenger:

for each task in the window's slice:
    state ← { task text, the tools this benchmark exposes, catalog snapshot,
              history: (model, outcome, cost) per step so far,
              spend so far, step index }
    loop, up to MAX_STEPS:
        action ← Conductor(state)           # greedy decode, your full weights
        DELEGATE / RETRY → the scaffold calls model_id with the ORIGINAL task, records cost + output
        STOP             → break
    grade the final result with the benchmark's own grader

Sequential, not one-shot. RETRY is what makes this more than pick-one selection: the conductor observes that a model failed and escalates or switches. It costs nothing against the invariant below, because the task text is forwarded verbatim every time. The score keeps the best answer across your delegations, so a retry can only help quality — and always costs dollars.

The catalog goes in context, compacted to id / $in / $out / ctx and cached once per window. A budget-aware policy has to see prices to be budget-aware. Any model on the catalog is allowed; it is filtered only for structural viability (a model that cannot emit text, or has no price, cannot be routed to).

The invariant that makes this cheat-proof

The only things that reach a worker model are the pinned task text and a validated model ID.

The scaffold constructs every worker request from the benchmark's own task statement. The conductor cannot rewrite it, prepend to it or append to it. There is no channel through which a memorised solution could reach the answer path, and so no detector looking for one. The owner logs every worker request and republishes it as a function of the task and the observations, so anyone can recompute byte-equality. A model ID is a short catalog slug with no room to carry a solution, and an unrecognised one is refused rather than forwarded.

The read channel

On benchmarks that declare it, the worker you delegate to may inspect the repository before answering. You do not drive this and cannot influence it — the worker issues its own reads, at most 3 per delegate, ~8 KB per observation:

READ <path> [start_line]   up to 200 numbered lines of one file
LIST <path>                the entries of one directory
FIND <text>                up to 50 `path:line:text` matches for a fixed string

It exists because it was measured to be necessary: without it, 0 of 75 R2E-Gym episodes produced a patch git apply would accept, while the gold patch scored 1.0 on 24 of 25 of the same tasks through the identical grader. The read budget resets per delegate — escalating to a stronger model is a fresh start, not a continuation. Price that in. The two benchmarks in today's launch corpus expose no tools; the channel matters the day a repository-repair benchmark is admitted.

What the scaffold cancels

These benchmarks are scaffold-dominated: the repository measured SWE-bench Pro one-shot at 0/120 while published agentic results run 62–80%. Since the scaffold is pinned and the duel is paired, that level cancels — absolute scores trail public leaderboards, and the difference between king and challenger stays attributable to routing.

Training data

Every window publishes the full decision traces of the arms the owner ran — rendered state, action, worker outcome, cost, per step — so a new miner starts from real traces on real benchmarks instead of a five-figure data-collection bill. The honest cost, recorded rather than argued: shared data pushes miners toward similar policies, ties break on seniority, and that is the same ossification pressure the breadth rule exists to counter.

Test it before you spend the shot

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

The dev kit calls the validator's own admit, scaffold and scorer. Read its parse-failure rate and endings breakdown before the score: a low final from a bad router, from turns that do not parse, and from a model that never reaches STOP look the same in one number and are three different problems.