Glossary
Thermite’s work is organized as campaign › run › lane › trial › attempt. A campaign says what to improve or achieve. A run is that campaign at work on one rig. Inside a run, each lane is one line of search, worked by a series of trials, and a trial may submit one change: an attempt. The judge gives every attempt a verdict. The dashboard follows the same order: campaigns first, then each run with its rig, lanes and attempts.
| Term | Meaning |
|---|---|
| Advisor | One of the models the supervisor runs to watch over the research: the teachers, the combiner, the auditor and the review panel. Advisors are off until you configure them: an advisor runs only when it has a model, from the advisors file or Edit rig. Its switch on Edit rig is on by default, but a switch alone runs nothing. The teachers, the auditor and the review panel read the owner’s messages to them and answer in Live. The teachers and the auditor can also add experiments to the run’s queue, and every advisor may keep field notes. See Supervision and the advisors file |
| Agent | An AI model at work inside a rig: a worker, the planner or an advisor. Agents propose; they never judge. See Agents, lanes and the planner |
| Agent token | A token for a coordinating agent over MCP: it may read and steer, but not message agents, change a run’s experiment queue, remove rules, read or grant the knowledge base’s folders, or approve anything. See Tokens and roles |
| Approach family | A named direction of work, such as loop-tiling, that experiments belong to and that directives name. The planner makes up new ones as it plans; a directive may name a new one too, and the planner designs it at its next round: it says what it means, in its own words. A name is 2 to 41 lowercase letters, digits and dashes, written in plain words or as :name:: :Loop tiling: is loop-tiling. An experiment whose direction is in words belongs to the family those words make: “Loop tiling” is loop-tiling. A family becomes exhausted when a “not possible” proposal counts it as refuted. See Agents, lanes and the planner |
| Attempt | One submitted change. Thermite keeps every attempt with its parent, its change, its record and its verdict, even one that loses. See Verdicts and states |
| Audit | A second look at a result before it can become the champion: for a surprisingly large gain, a change whose agent declared flaws, or a goal campaign whose contract has an adversarial checklist. An audit can hold a result back, never pass one. See Decide what waits for you |
| Auditor | The advisor that answers audits: it clears a result, blocks it, or leaves it to the owner. Without one, audits wait for the owner. When it has a doubt it can’t settle, it may also put one check at the top of the run’s experiment queue. See Supervision |
| Back-pressure | Limits that hold new work until earlier work settles, such as at most 4 open attempts in a run. Work waits; nothing ends. See Limits and pacing |
| Block | One round of timing: every case runs for the change and for the champion, in a random order, on the same device. The judge decides from many blocks. See Why agents never judge |
| Briefing | Background for every agent of a new run: findings, claims, notes and reports the owner picked from past research when starting it, each with where it came from. Each agent’s brief shows it as data, not instructions. It is fixed once the run starts. See Briefings |
| Broker | The part of the harness that runs as root and starts every build, run and agent command as its own user. See Isolation inside a rig |
| Budget | A cap a contract may set: wall-clock hours, device hours or model spending. None is set by default; when one is spent, the run is paused. See Set a budget or a stop time |
| Calibration | The judge times the champion against itself (an A/A test) to learn how noisy the device is. A hill climb’s later decisions never assume less noise than this. See Limits and pacing |
| Campaign | One piece of research: what to improve or achieve, and how to judge it, set out in its contract. It runs in one of three modes. See Campaign modes |
| Cap | A limit that can stop a campaign’s agent work, such as a budget. Caps are off unless someone sets them. See Limits and pacing |
| Case | The dashboard’s word for a cell: one test case of the kit, such as one input size. The New campaign page lists them under Test cases. See Kit manifest |
| CDI | The Container Device Interface: a file that tells Podman which device files make up each GPU. NVIDIA’s container toolkit writes it, and rigs on machines get their GPUs through it. See Compatibility |
| Cell | One test case the kit can measure, such as a matrix of a given size: a name and its parameters under cells in kit.json. The contract picks the cells a campaign is judged on, and the dashboard calls them cases. See Kit manifest |
| Champion | A run’s best confirmed result so far. It starts as the seed (champion #1), and only the judge’s confirmed verdicts replace it, each with the next number, so the first improvement is champion #2. See How a change becomes the champion |
| Champion patch | A champion as a git patch against the seed, which you can download and apply to your project. See Take the result |
| Check (kit’s) | The kit’s program that reads one run’s output and says whether it passed, for example that the result is correct. It runs as part of the judge. In kit.json, a run passes only when the check’s last line is a JSON object with "pass": true; a check described on the New campaign page passes when it exits 0. See Kit manifest |
| Claim | A statement backed by exact quotes from sources the harness fetched. Research workers record them, and so may hill-climb and goal workers. It counts as verified only when every quote is found word for word and every number in it appears in its quotes. See Campaign modes |
| Combiner | The advisor that merges the two teachers’ reviews into one set of directives, and their experiments and moves for the queue into one list each. See Supervision |
| Confirmation | The judge’s second measurement of a change that looked better: fresh blocks, decided on that new data alone, plus the held-out cells. See How a change becomes the champion |
| Contract | The file that says what a campaign must achieve and how it is judged: its mode, metrics or goals, editable paths, cases and limits. Each change gets a new version number. See Contract and Write a contract |
| Control | The one central service that shows and steers every rig: the dashboard, the REST API, MCP and the command queues. See How the parts fit together |
| Cross-verified | A champion that another rig’s own judge measured and promoted, after it was sent there by propagation. The leaderboard shows which rigs cross-verified each champion: the dashboard’s address /ui/leaderboard, GET /v1/leaderboard and the MCP tool leaderboard. On a campaign’s page, such a run under Earlier runs shows cross-verified on and the rigs, and a hill climb’s page links to the leaderboard. See Run a campaign on several rigs |
| Development run | An agent’s own run of a command on the measuring device, to test or profile its change. It never counts as a result. See Sharing a device |
| Device | What a rig measures on: a GPU, or the rig’s CPUs. A rig with several GPUs can give some to the judge and some to the agents. See Sharing a device |
| Direction | Another word for an approach family: the line of work an experiment belongs to, such as loop-tiling, or a few words such as “loop tiling”. A rule names one, in plain words or as :loop tiling:. A run’s directions, with what each holds, are on its Planner tab (The run’s directions), the REST API and MCP. A lane tends to keep its last direction, so it builds on what it learned. See The planner |
| Directive | A recorded instruction that steers the planner, with its reasons and sources; it never changes a verdict. The dashboard calls directives rules. Its kinds are avoid, try, mandate (Always on the dashboard), priority, lane_count and note. An avoid, try or mandate directive names a direction; an old one in words (match), from before directives named directions, stays in force as legacy, for the planner’s model only. The owner, the teacher pair and the planner set them; the planner only when an owner’s message asks for one. A directive the owner removed is left out of the teacher pair’s and the planner’s later sets; only a redirect sets it again. See Choose what a run tries next |
| DRA | Dynamic Resource Allocation: a Kubernetes way to give pods devices, such as GPUs, through a device class like gpu.nvidia.com. A cluster rig gets its GPUs through DRA or through NVIDIA’s device plugin. See Add a rig on a Kubernetes cluster |
| Duplicate | An attempt that makes the same change as an earlier attempt of its run. It is kept but not judged again. See Verdicts and states |
| Enrollment code | A one-time code control makes for a rig in pull mode, given to its pod at launch. Control and the pod each prove that they hold it, without sending it, when control pins the pod’s keys; then it is spent. It expires only when the launch sets an expiry. See Enrollment |
| Epoch | One round of planning: the planner gives each lane an experiment, and each lane runs its trials. The dashboard calls it a round. Contract fields, such as lanes.trials_per_epoch, and the workers’ briefs keep the word epoch; the live lines say round, as in planning round 4 (2 lanes). See Agents, lanes and the planner |
| Every detail | The folded part of the What it runs on block on a rig’s page. Open it for the rig’s full hardware: each device with what uses it (Used by), and the CPUs, memory, disks and toolchain. See Give a rig several GPUs |
| Experiment | One thing for a lane to try: a title, and optionally details, a direction and why. The owner, the planner, the teacher pair and the auditor add them to a run’s experiment queue; the lanes propose them as ideas. One trial works on one experiment, which is then done, with its attempt or why there is none. An experiment can also be dropped, with why. See Choose what a run tries next and Experiment states |
| Experiment queue | A run’s experiments still to try, in order (Up next), with the lanes’ ideas and what was tried. Each run has its own, kept in the harness’s ledger, and the run page’s Experiments tab shows it. The planner gives the first ones to free lanes, never one to two lanes. See Choose what a run tries next |
| Export | A bundle the harness writes every hour when anything new happened: new events, attempts, champion patches, a snapshot of the ledger, the field notes, research notes and briefings since the last export, and the research folders of finished runs. The supervisor pushes it to the results repository, or, for a rig without one, sends it to control. See Exports and Set up the results repository |
| Fallback | The fixed rules that give out work when the planner has no model, is off, or gives no usable plan: each lane takes the next queued experiment, Always directions first, then Try directions, and none that an Avoid rule names. Every rule names a direction, so every rule applies; only an old rule in words needs the planner’s model. When the queue has nothing for a lane, or for an Always direction, the fallback adds an experiment. Live and History say the round’s work went out by the fixed rules, and why. See The planner |
| Field note | A short note an agent keeps as it works: an observation, a decision and why, a surprise, an open question or a lesson, and what it is about. Workers, the planner and the advisors write them; nobody edits or deletes one. What was tried and its result are in the experiment log instead. See Field notes |
| Finding | In a research campaign, a conclusion a worker records with a summary, why it matters and the verified claims behind it. Code accepts it only when every claim it cites is verified and every number in it appears in those claims; otherwise it stays a draft finding. See Campaign modes |
| Finished | The dashboard’s word for a closed run, on its page, in Live and under Earlier runs. A finished run takes no more work or messages. A campaign is finished when all its runs are. In Tried, a research task whose trial ended on its own reads “finished: its research is in the run’s notes”. See Verdicts and states |
| Folder | One campaign’s part of the knowledge base: what its runs recorded, each item with its run, its writer and its time. A campaign’s agents read its own folder and the folders it was granted, and never write to any. See Campaign folders |
| Fork round | A point where every lane starts again from the champion. With a budget.wall_hours, at one third and two thirds of it; without one, every 20 epochs. See Lane bests and fork rounds |
| Full reset | Wiping a rig’s state after its results are safely exported, with the owner’s confirmation. See Stop, restart, remove or reset a rig |
| Gate | The first step of judging a change in a hill climb: each case runs once, and the change must pass the kit’s check. See Verdicts and states |
| Goal | In a goal campaign, one thing the result must achieve. A goal is checked by the kit’s code, by a measured threshold, or by a review panel. See Contract |
| Goal campaign | A campaign that works until its goals are met. See Campaign modes |
| GPU fence | The broker’s use of the Linux kernel’s Landlock feature to stop each role from opening GPUs it may not use. See Isolation inside a rig |
| Grant | The owner’s choice that a campaign’s agents may also read another campaign’s folder, made on the campaign’s page (Can read from) or with kb_grant over MCP, and removed at any time. See Grants |
| Guard | A metric that must not get worse while the main metric improves. See Contract |
| Hand-out | The planner’s record of which experiment went to which lane, and why: one at the start of each round, and one for each later trial of a lane in the round. The run page’s Planner tab lists them under What the planner did, and History has a line for each. See Choose what a run tries next |
| Hard constraint | A limit a change must meet, such as a metric’s minimum. A change that breaks one is infeasible. See Contract |
| Harness | One of a rig’s two containers: it holds the ledger, the judge, the planner, the workers and the broker. It is not the worker harness, the program a worker runs in. See Harness image |
| Held-out cell | A case the judge runs only at confirmation, never while screening, so no agent can tune a change to it. Its results never reach the agents. See Hidden test cases |
| Hill climb | A campaign that keeps improving a metric. It never ends on its own. See Campaign modes |
| History | A run page’s tab that tells what happened in the run, newest first, in sentences: verdicts, new champions, pauses, how each round’s work went out, rules, changes to the queue, hand-outs and more. It shows the newest 400 events. The agents’ notes are on the Journal tab instead. See Verdicts and states |
| Idea | An experiment a worker proposes while it works, with thermite-trial idea or Pi’s idea tool; its trial goes on. It waits under Ideas from the lanes until the owner or the planner queues it or drops it, or the planner gives it to a lane. Only the planner’s model does that: without it (none set, its answer refused, the planner off, or a research run), ideas wait for the owner. See Choose what a run tries next |
| Inbox and outbox | Folders a rig’s two containers share. The supervisor puts what it fetched in the inbox; the harness writes its exports to the outbox. See Ports, volumes and secret files |
| Join command | A one-time command you run on a machine or cluster to add a rig where control cannot connect. It works once, within an hour. See Join a rig yourself |
| Journal | A run’s field notes, kept in its ledger. The run page’s Journal tab shows them, newest first, with filters by writer and by kind, beside the run’s research notes and its counts. See Field notes |
| Judge | Code in the harness that builds, measures and checks every change and gives its verdict. Agents can neither read nor change it. See Why agents never judge |
| Kept in force | An owner’s message, to everyone working or to one lane, that every new trial’s brief carries until the owner removes it (📌 N kept › Remove in Live, or the command unkeep_message). Live marks it ”📌 kept in force”. See Keep a message in force |
| Kit | A project’s recipe for the judge: how to build, run, time and check it, with its cases and hidden checks. It lives in its own repository, pinned by commit, and agents never see it. See Why the benchmark lives in a kit |
| Knowledge base | Thermite’s own store of past research, kept by control: one folder for each campaign, with what its runs recorded. The Knowledge page in the sidebar shows and searches it. Not the same as the advisors file’s kb, a search service of your own for the teachers, or an MCP server such as GBrain. See The knowledge base |
| Lane | One line of search inside a run, worked by one trial after another. Each lane has its own user and its own best result. See Agents, lanes and the planner |
| Lane best | A lane’s own best win, measured against the current champion, that has not become the champion. The planner can tell a lane to build on it. See Lane bests and fork rounds |
| Ledger | The harness’s record of everything that happened on a rig: attempts, verdicts, champions, field notes, each run’s briefing, events. Every other view, such as the dashboard, is built from it. See How the parts fit together |
| Live (a rig’s status) | The green chip a rig shows on Rigs when it has reported within the last 180 seconds, by default. Otherwise the chip says Stale, Offline, Refused, Stopped (a stopped RunPod pod), Key to accept while its key waits for the owner, or Getting ready (a RunPod pod before its first report). See The Rigs list |
| Live (the sidebar page) | The dashboard page that shows one run at a time as it works: its live view. The list on its left has the runs At work, the Idle rigs and the runs Ended in the last day. With no run chosen, it shows the first run at work; with none at work, it says “No run is at work. Pick one from the list to see its lines.” while runs that ended in the last day are listed. See Send the agents a message |
| Live view | The dashboard’s view of one run’s agents, judge and advisors as they work, which adds new lines by itself. Its filters are Everyone, one for each lane, Planner and Judge (except in a research run), Advisors and You (your messages, who read them and the advisors’ answers). Its message box writes to everyone working, a lane, the planner or the advisors; the judge takes no messages. A refused message shows Not sent. and the reason above the box. Your messages, read receipts and the advisors’ answers show as such only on lines the rig’s harness signed; any other line shows as a plain log line. Open it from Live in the sidebar, or with Live or Message on a run’s page. A rig’s page has its own Live button, which shows every session on that rig and links to each run’s Live for messages. See Send the agents a message |
| Machine | A Linux computer with Podman that control can reach over SSH and set rigs up on. See Add a rig on a machine over SSH |
| Message (the owner’s) | Text the owner sends to a run’s agents: to everyone working (every lane at work, and the planner of a hill climb or goal campaign), one lane, the planner, or the advisors (all of them, the teachers, the auditor or the review panel). It is the signed command message_agent, sent from Live or with the owner’s or an operator’s token. Control refuses one that nothing on the rig would read, such as one to the planner while it is off. Each reader reads it once, unless it is kept in force. See Send the agents a message and Signed commands |
| MCP server | A server of tools from outside Thermite, such as a knowledge base, a code host or a search for papers, that speaks the Model Context Protocol. The owner adds it once in Settings › Providers › MCP servers, with how it signs in; a campaign’s kit names the servers its workers, planner and advisors use. Control keeps its secret sealed; the rig’s harness and supervisor make the calls, so no agent sees the secret. Thermite’s own MCP, for people and agents that run campaigns, is another thing: see MCP tools. See Give agents MCP tools |
| Mode | The kind of campaign: hill climb, goal or research. See Campaign modes |
| Model file | A data file your project loads that is not in its repository, such as a machine-learning model’s weights. The contract lists each by name and SHA-256 under models, and the kit reaches it as {models:<sha256>}; it is not the AI model the agents use. The rig’s supervisor can download it by URL. See Contract and Model files on a rig |
| Model route | Where a rig’s agents reach their model: the provider, the model, its key and the worker harness. Control gives it to the rig; without one, the rig’s own settings can name a model. See Connect a model provider |
| Needs update | The chip in a rig’s Version on Rigs when the rig’s version is behind control’s, or so old that control refuses it. It opens the rig’s page, where Update to control’s version runs. See The Rigs list |
| Needs you | The dashboard’s list of everything that waits for the owner: promotions, audits, reviews, “not possible” proposals, rig keys, wipes, and rigs that stopped reporting (not a RunPod pod that is stopped). It is on Overview, and its count shows beside Overview in the sidebar and in the status bar. See Decide what waits for you |
| “Not possible” | In a goal campaign, a proposal that the goals cannot be met, made when enough approach families were tried and refuted. Only the owner can accept it, which closes the run. See Decide what waits for you |
| Offline | A rig that has not reported for 15 minutes, by default, or never reported. The REST API, MCP and thermite rig list show it as offline; Rigs shows Offline, and the rig’s page says offline, with a banner. A rig on RunPod whose pod is stopped is Stopped on Rigs and stopped on its page instead. See Rig versions and A rig’s page |
| Operator token | A token for an agent that runs campaigns for you over MCP: it may read, steer, message agents, change a run’s experiment queue and rules, and search the knowledge base and change its grants, but never approve. See Tokens and roles |
| Outside knowledge base | Before 0.1.0: an MCP server control copied campaign folders to, and that a campaign’s teacher pair could search. At the update, each became an ordinary MCP server. See Manage MCP servers |
| Overview | The first page in the dashboard’s sidebar: the tallies, Needs you, At work and What happened. A run’s page also has an Overview tab, the first of its tabs. See Your first run |
| Owner | The person who holds the owner’s token. Only the owner signs in to the dashboard and approves promotions, reviews and endings. See Tokens and roles |
| Pacing | Limits that space work out, such as a trial’s length or a wait after errors. Pacing never ends research. See Limits and pacing |
| Past research | What a run may read from the knowledge base: the items of its campaign’s folder from other runs, and of the folders granted to it. The rig’s supervisor syncs them into the run’s knowledge/ folder, which workers search, and which the planner and the advisors search with a read-only tool. See A run’s knowledge folder |
| Planner | A model call at the start of each round, with no memory of its own, that coordinates the run’s experiment queue: it gives each lane an experiment, never one to two lanes, and may add, move, drop and accept experiments, each with why. It adds a rule when an owner’s message asks for one. Without a model, when it is off, or when it gives no usable plan, the fallback gives out work. In a research campaign, a fixed research plan fills the queue instead. See The planner |
| Promotion | A change becoming the champion. The promotion policy says whether a confirmed win promotes at once (auto) or waits for the owner (owner_approval). See Decide what waits for you |
| Propagation | Sending one rig’s champion to another rig’s run of the same campaign, where that rig’s own judge measures it as an ordinary attempt. See Run a campaign on several rigs |
| Proposer | A person or script that submits changes to a rig by hand, with the proposer token and thermite submit. See Test a kit with known candidates |
| Protocol | The version of the contract between control and a rig. Control, each harness and each supervisor report theirs with their Thermite version, and control refuses a rig whose protocol it can’t work with. A rig with no protocol is never refused. See Rig versions |
| Provider | Something Thermite uses, added once on the dashboard’s Providers page: a model provider or subscription, a Git access, a machine, a cluster or a GPU cloud. MCP servers have a block of their own on the same page. See Connect a model provider |
| Pull mode | How a rig on RunPod works: its supervisor never connects to control. Control connects to the pod through RunPod’s proxy, signs every request, and in each exchange takes the rig’s calls and answers them. Everyone else gets an empty 404. See Rigs in pull mode |
| Queue | On a run’s page, its experiment queue. The judge’s jobs and control’s commands for each rig wait in queues of their own. See Choose what a run tries next |
| Read receipt | A line in Live that shows who read one of the owner’s messages, such as ”✓ lane-1 read your message: …”. A read counts when the reader works with the message: a trial once its agent is at work, the planner once its model’s plan is used, the teachers once one gave a review, and the auditor or the review panel once its answer is posted. See When each agent reads it |
| Reader token | A read-only token, for MCP and for scraping /metrics. See Tokens and roles |
| Receipt | A record, written once, of what ran and under what conditions: one for each timed block, kept in the ledger. See Why agents never judge |
| Research campaign | A campaign that gathers sources, verified claims and findings on a topic for a set time. See Campaign modes |
| Research folder | A run’s files, written by the harness from its records and read-only to the workers, who search them. A research run’s holds every archived page as text, every claim, finding, hypothesis, note and report section, an index, the newest report, and a working area for each lane. A hill-climb or goal run’s holds the sources, claims and notes its workers recorded, with an index. Every run’s has knowledge/, its past research, once there is some. See Campaign modes |
| Research note | A note a worker records with add_note, with the sources it relies on, in any mode. It is not a field note: it records what sources say. The Journal tab shows research notes in its Notes card |
| Restart the lanes | ⋯ › Restart the lanes, in the header of the run’s page or of its Live; the command reset_workers: it ends the lanes’ running trials and the current round, and every lane starts again from the champion. The experiments they were on go back to the top of the queue. Nothing the judge decided is lost. A run without agents has none. See Pause, resume or restart the lanes |
| Results repository | A git repository where rigs push their exports. See Set up the results repository |
| Review panel | The advisors that review a subjective goal without seeing who made the change: two to five in the advisors file, or three with one model when chosen on Edit rig. A pass still needs the owner’s acceptance. See Supervision |
| Rig | Where the research happens: a harness container and a supervisor container, with the device they measure on. A rig works on one run at a time. See Kits and rigs, side by side |
| Rig check | A test a rig runs on itself: model route, isolation or smoke. A smoke check makes a campaign named rig-check-…, which the Campaigns page lists only under its Rig checks and All filters. See Rig checks |
| Rig key | The key a rig’s harness signs its reports with. Control trusts it on first contact, or waits for the owner to accept it. See Accept a rig’s key |
| Rig token | The token a rig’s supervisor uses with control, for its own rig only. See Tokens and roles |
| Role user | The operating-system user each kind of work runs as inside the harness: builder, run, lane-N, agent-N and others. See Harness image |
| Round | The dashboard’s word for an epoch: one round of planning. Live’s header shows the run’s round, such as round 4. See Agents, lanes and the planner |
| Rule | The dashboard’s word for a directive: Avoid, Try or Always a direction. A run’s Planner tab lists the rules in force, each with who set it, why, what code does with it now, and Remove. On the dashboard, rules come from Tell the planner: you say what you want, in plain words or naming a direction as :shared memory tiling: (typing : lists the run’s directions), and the planner makes each rule at its next round. A direction the run doesn’t have yet is new, and the planner designs it. Code keeps every rule, with or without the planner’s model. A rule you remove stays removed: the teacher pair and the planner can’t set it again, and you can, with redirect. See Choose what a run tries next |
| Run | A campaign at work on one rig, from a starting commit. A run is running, paused or closed (Finished on the dashboard); starting a run on a rig pauses the rig’s other runs. See Verdicts and states |
| Run page | A run’s own page, opened from its campaign’s page or with Open the run in Live. Its header has Live, Message, Pause or Resume, and, while the run runs, ⋯ › Restart the lanes. A run without agents (a try, a rig check) has no Message and no Restart the lanes. Its tabs are Overview, Experiments (the run’s experiment queue), Journal (the agents’ field notes), Attempts, History and Planner (the rules and the hand-outs). See Steer a run and Choose what a run tries next |
| RunPod test pod | A short test, paid by the hour, that starts the CUDA harness image on a RunPod GPU to see whether a rig could run there. See Test a GPU on RunPod |
| Screen | The judge’s first timing of a change against the champion, in blocks, decided at set points. See Verdicts and states |
| Seed | The commit a run starts from. It is champion #1, and the champion patch applies to it. For a project in one folder of its repository, the run starts from a commit of that folder alone, made from the seed, and the patch applies to the folder. See Take the result |
| Sidebar | The column on the left of every dashboard page: Overview, Campaigns, Rigs, Live, Knowledge, Commands, Reports and Audit log, with Settings (the cog) and Sign out at its foot. See Your first run |
| Signed command | An instruction from control to a rig, such as assigning or pausing a run, signed with control’s key so the rig can check it. See Signed commands |
| Slot | A Kubernetes namespace the cluster’s operators made for Thermite, where control may set one rig up. See Add a rig on a Kubernetes cluster |
| Smoke check | The rig check that runs known changes through the judge and expects each one’s known verdict. See Rig checks |
| Stale | A rig that has not reported for 180 seconds, by default. Rigs shows it as Stale, the rig’s page says stale, with a banner, and the status bar counts it as stale. A stopped RunPod pod is not stale: it can’t report, so the sidebar and the status bar call it stopped, and Needs you shows no card for it. The REST API, MCP and thermite rig list show it as stale until it is offline. See Troubleshoot |
| Start a run | The button on a campaign’s page that opens a panel to start a new run of the campaign: on which rig, and with agents or as a try. A campaign saved on control starts from its newest version. One assigned over the API, MCP or the command line starts again from its newest assignment, with the same contract, starting commit and imports. With agents on, its From past research can start the run from items of the folders the campaign may read; a try hides it. See Start a campaign from the dashboard |
| Static checks | Checks made before a change is built: only editable paths, no forbidden patterns, no binary files, links or submodules. A change that fails is rejected_v0. See Verdicts and states |
| Status bar | The line along the bottom of every dashboard page: the rigs, how many are stale and how many RunPod pods are stopped, Needs you, the runs at work and the judge’s jobs. Pages never reload by themselves: its refresh link loads the page again. See Check a rig |
| Supervisor | A rig’s second container, its link to the outside: it relays reports, commands and the live view to and from control, hands the harness its model route, does all git work, and runs the advisors. See Supervision |
| Target | What a rig measures on, reached through a driver: cpu or cuda-gpu in this version. A kit names the target it needs. See Kits and rigs, side by side |
| Teacher | One of up to two advisors that review a run, every hour by default and soon after the owner writes to them, and recommend directives with their sources. They may also propose experiments for the run’s queue, and moves of queued ones. See Supervision |
| Token | A long random string that identifies a person, an agent or a rig to control or to a harness. See Tokens and roles |
| Trial | One worker’s session in a lane, started from fresh context, on one experiment from the run’s queue. It submits at most one attempt, and may propose ideas for the queue and keep field notes. It ends when it submits, when its time runs out, or when it stops. Not the same as a try of a kit. See One trial |
| Tried | A run’s experiments that ended, newest first, on its Experiments tab: each with its attempt and outcome, no attempt and why, who dropped it and why, or a finished research task. Chips filter it: Wins, Not better, Broken or blocked, Other results, Research finished and No attempt or dropped. See An experiment’s result |
| Try (of a kit) | A judge-only run with no agents, started with Try the kit first on the New campaign page, with Start a run and Agents › Off: a try on a campaign’s page, or with thermite assign --agents off: the judge builds the starting point and measures it, so you see the kit work before agents start. A hill climb’s try times the starting point against itself on the visible cases; hidden cases are not run. See Start a campaign from the dashboard |
| Up next | A run’s queued experiments, in order, at the top of its Experiments tab. The first ones go to free lanes. You can add one, edit one’s words, drag one to a new place, move one to the top or drop one. See Choose what a run tries next |
| Verdict | The judge’s decision on an attempt, such as win_confirmed, neutral, regress or invalid. See Verdicts and states |
| Worker | The agent that works one trial in a lane: it reads and edits the project, builds and tests, and submits a change, and may record the sources it reads, with claims and notes. In a research campaign, it reads sources and records claims and findings instead. See One trial |
| Worker harness | The program a rig’s workers run in, which gives the model its tools: Pi (built into the harness), OpenCode v2, Claude Code or Codex (the Codex CLI). It is chosen in the Runs in column of Edit rig, in The agents run in, next to The agents’ model, on the New campaign page, or with THERMITE_AGENT_HARNESS for a rig that keeps its own model. See Give each agent its own model |
Older names
Section titled “Older names”Before 2026-10-15 a rig was called a unit, and a run an instance. Older ledgers and command-line flags with those names are still read under the new names.