Skip to content

Thermite for enterprises

Performance, inference and platform teams already run the loop that Thermite automates: change something, measure it, keep it if it is better. Agents can run that loop around the clock, but a team can only use what it can trust and govern. Thermite is built for that: agents only propose, code your team controls measures and decides, and every step is signed and recorded. It runs where your code and data already are.

Each of these runs on machines and clusters you control, with your own repositories, data and model endpoint.

  • Separation of duties, enforced. Agents run as operating-system users that can neither read nor change the judge. The judge builds, runs and measures each change under users of its own, and only its verdict promotes a change. “The agent says it is faster” and “it is faster” stay separate (Why agents never judge, Isolation inside a rig).
  • Signed commands, signed results. Control signs every command it sends a rig, and the rig’s harness signs every report. The supervisor in between carries both and can forge neither (Trust between control and rigs).
  • A complete record. Each rig’s ledger keeps every experiment, attempt, measurement and verdict, with the judge’s reasons. Control keeps a copy of every rig’s events, exports their results, and backs them up (Back up and restore control). Retention policies remove only what you choose, where and when you say (Remove what Thermite keeps).
  • People decide what matters. Choose what waits for a person: new champions, audits, reviews and “not possible” endings. On a rig with an auditor, a model reads a surprisingly large win for anything that games the measurement before it is kept (Decide what waits for you).
  • Roles for people, scripts and agents. One owner signs in to the dashboard and approves. Operator and agent tokens let scripts and AI assistants watch and steer, but never decide; a reader token lets a metrics scraper such as Prometheus read /metrics (Tokens and roles).
  • Keys go only where they are used. Control seals every key, sign-in and kubeconfig you give it, and hands a rig only what that rig uses (Who holds your keys).
  • Kubernetes, your way. Control sets a rig up in a namespace it creates, or in a slot your platform team made with a namespaced role and a resource quota. Network rules keep the harness to DNS, public addresses and the addresses you list, and the rig’s isolation check fails if a lane can reach the cluster’s API server (Add a rig on a Kubernetes cluster).
  • Machines and cloud GPUs. Control also sets rigs up on machines over SSH, and launches them on RunPod with a spend limit.
  • Your images, repositories and models. Build Thermite’s images into your own registry, give rigs your private repositories with deploy keys, and point the agents at your own model endpoint or gateway (Push the images to your own registry, Use a private repository, Choose a model).
  • One place to see every campaign. One dashboard shows every campaign on every rig, with model use and cost per run. A REST API, MCP and the thermite command line give your tools the same actions (Script Thermite with the REST API).
  • One owner for each installation. Thermite is self-hosted and built for one researcher or one lab, not for separate customers sharing one installation. Each team runs its own control. There is no single sign-on.
  • API keys for shared use. A Claude or ChatGPT plan may serve only its owner’s own Thermite; a Thermite that several people use takes API keys.
  • Agents run code that a model wrote. The harness reaches only DNS, the internet and its model endpoint, and on Kubernetes your network rules narrow that. On RunPod, Thermite adds no network rules. Read the security model and Known limits.
  • Thermite is 0.x. Versions make no upgrade promise yet. It is open source under the Apache License 2.0.
  1. Read the security model: what each part can reach and what it trusts.
  2. Install on one machine and watch the judge’s smoke check give a dozen known cheats their expected verdicts.
  3. Run the stack on a machine your team controls, with images from your own registry.
  4. Add a rig on your cluster, in a slot your platform team made.
  5. Give a pilot project its kit and contract, and choose what waits for you.