# IronBench

> Source: https://aiwiki.ai/wiki/ironbench
> Updated: 2026-09-09
> Fact-checked: 2026-09-09
> Categories: AI Research, Reinforcement Learning
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "IronBench." aiwiki.ai, 9 Sept 2026. https://aiwiki.ai/wiki/ironbench
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

IronBench is a research environment and evaluation for training a [large language model](https://aiwiki.ai/wiki/large_language_model) to propose medium-power-transformer designs. General Trajectory introduced the project in September 2026. Its system combines a [Kimi K2.6](https://aiwiki.ai/wiki/kimi_k2_6) policy, a deterministic design compiler, and a fixed physics verifier in a reinforcement-learning loop.[1][2]

General Trajectory reported that its selected policy produced a compliant design on 74.4% of single attempts across 900 held-out specifications. The reported pass@4 result was 93.0%, meaning that at least one of four independently sampled attempts passed for 93.0% of specifications.[1][2] These figures measure compliance in IronBench-Sim v1. They do not report the yield of manufactured transformers or factory acceptance tests.

## Environment and task

IronBench frames each task as a structured design problem. The observation supplies a transformer's rating, voltages, vector group, performance limits, and cost rates. The policy returns construction parameters rather than calculated performance. A deterministic compiler derives the geometry, after which the verifier computes quantities such as voltage ratio, core flux, losses, impedance, electrical clearances, temperature rise, and short-circuit limits.[1]

The frozen IronBench-Sim v1 domain is deliberately narrow:[1][2]

| Property | IronBench-Sim v1 scope |
| --- | --- |
| Phases and frequency | Three-phase, 60 Hz |
| Construction and cooling | Liquid-filled, ONAN |
| Rated capacity | 75-2,500 kVA |
| High-voltage range | 12.47-34.5 kV |
| Connection in the release manifest | Dyn |
| Outside-domain behavior | The main verifier fails closed |

Each generated task has a hidden feasible witness and a hidden total-ownership-cost baseline. The policy sees neither. A submission receives zero reward if any hard check fails. A compliant design earns a reward based on its ownership cost relative to the baseline, with a capped bonus when it beats that baseline.[1]

### Action space

The policy directly selects nine variables. The compiler derives the rest of the design:[1]

| Variable type | Variables | Admissible values |
| --- | --- | --- |
| Continuous | `b_target_t`, `vpt_factor`, `j_target_a_mm2`, `extra_gap_mm` | 0.65-1.80 T; 0.25-0.65; 1.0-4.0 A/mm2; 0-30 mm |
| Integer | `lv_layers`, `hv_layers`, `ducts` | 1-32; 1-64; 0-4 |
| Categorical | `grade`, `margin_profile` | M3, M4, M5, or M6; standard or robust |

This structure is why the project treats transformer design as suitable for reinforcement learning with verifiable rewards (RLVR): model outputs have a constrained schema, while a deterministic program can accept or reject the resulting design. RLVR has more commonly been studied in structured domains such as mathematics and programming, where exact answers or executable tests can supply the reward.[4]

IronBench's modeled observables overlap with established transformer test categories. IEEE C57.12.90-2021 covers ratio, no-load loss, impedance and load loss, dielectric, temperature, and short-circuit tests for liquid-immersed distribution and power transformers.[5] IEC 60076-1 supplies general power-transformer requirements, while IEC 60076-2 covers cooling classifications, temperature-rise limits, and temperature-rise testing for liquid-immersed transformers.[6][7] Referencing those categories does not make a simulator result equivalent to a standards-compliant factory test.

## Training

The project evaluated four policy stages: the pre-RL Kimi K2.6 policy with verifier access, a repair supervised fine-tune that was rejected, a rejection fine-tune (RFT) on verified compliant trajectories, and RFT followed by reinforcement learning. The selected policy started from the RFT checkpoint.[1][2]

Training used 50 policy-gradient updates with 256 rollouts per update, for 12,800 verifier-scored rollouts. The model update was a rank-32 [LoRA](https://aiwiki.ai/wiki/lora) adapter. The release page lists a sampling temperature of 0.75, a 4,096-token allowance, bounded verifier calls, a learning rate of 1e-5, a KL coefficient of 0.03, and process and anti-oscillation credit.[1]

The preregistered training gate required average compliance over the last ten updates to exceed the first-ten-update average by at least 5 percentage points. The reported training averages rose from 56.7% to 71.9%, a difference of 15.2 points. Pass@4 over the same training windows rose from 81.9% to 91.7%.[1][2] These are training-curve measurements, separate from the 900-task confirmatory result.

## Evaluation protocol

The release manifest divides procedural tasks into 1,800 training tasks, 600 development tasks, and 900 confirmatory tasks. It reports no task-ID overlap between any two splits. The team allowed at most three preregistered looks at the development set, selected the policy at update 50, froze its weights, and then evaluated it on the unopened confirmatory set.[1][2]

Each confirmatory row used four independent samples per specification at temperature 0.75. This produced two distinct metrics:

- Single-attempt compliance is the percentage of all generated attempts that passed every hard check.
- Pass@4 is the percentage of specifications for which at least one of four attempts passed.

The manifest also records eight invalid development shards that were rejected and resampled. It reports no remaining infrastructure errors in the final development or confirmatory evaluations.[2]

## Confirmatory results

The following results are General Trajectory's measurements from the frozen IronBench-Sim v1 confirmatory set:[2]

| Policy | Single-attempt compliance | Mean reward | Pass@4 | Exact-repeat rate |
| --- | ---: | ---: | ---: | ---: |
| Pre-RL | 42.7% | 0.4445 | 74.6% | 17.3% |
| Repair SFT | 34.1% | 0.3523 | 70.2% | 11.9% |
| RFT | 46.1% | 0.4774 | 77.2% | 15.9% |
| RFT + RL | 74.4% | 0.7751 | 93.0% | 1.4% |

Compared with the pre-RL row, the selected RFT + RL policy improved single-attempt compliance by 31.75 percentage points. The project reported a 95% confidence interval of 29.36 to 34.08 points for that paired difference.[2]

The announcement on X summarized the result as meeting 93% of unseen specifications.[3] In the full release, 93.0% is explicitly the pass@4 value. The corresponding single-attempt compliance rate is 74.4%, so the two figures are not interchangeable.[1][2]

## Secondary confirmation result

The release manifest marks its preregistered composite confirmation flag as false even though it marks the held-out compliance improvement as confirmed. A secondary check compared aggregate mean reward among positive samples. That value was 1.0411695 for the pre-RL policy and 1.0411239 for the RL policy, a difference of -0.0000456 that narrowly missed the threshold.[2]

The manifest also reports a frozen, task-paired diagnostic for 651 specifications that both policies solved. On those shared solved tasks, the RL policy's mean positive reward was higher by 0.0094, with a reported 95% confidence interval of 0.0043 to 0.0148. The project preserved both that diagnostic and the failed composite flag rather than substituting the paired result for the preregistered outcome.[2]

## Detailed solver audits

IronBench's release includes a small audit with a more detailed solver stack. Fifteen candidates that passed the fast verifier were rescored. Only five remained compliant under the project's counterfactual detailed checks, while ten changed from compliant to noncompliant. All detailed stages completed, but the whole-transformer OpenFOAM ONAN stage converged for none of the 15 candidates. Across this sample, the manifest reports a Spearman correlation of -0.336 between fast-verifier reward and detailed reward.[2]

The project also tested one 20 MVA YNd design, which falls outside the frozen 75-2,500 kVA Dyn domain. It passed the nominal fast verifier but failed the detailed audit. The whole-transformer ONAN calculation did not converge, and a stricter reduced-order thermal check exceeded all three 65 K temperature-rise limits. The release therefore labels the candidate as not detailed-verified and makes no authoritative out-of-domain compliance claim.[2]

These audits show why the 74.4% and 93.0% results should be read as benchmark scores under the frozen verifier. They do not establish that the same share of generated designs would survive higher-fidelity analysis, manufacturing review, or physical tests.

## Inference system

The project published a serving benchmark for the model used in IronBench. It is not a complete accounting of the compute used for reinforcement-learning training. The benchmark used `nvidia/Kimi-K2.6-NVFP4` with [vLLM](https://aiwiki.ai/wiki/vllm) 0.26.0 on four NVIDIA B200 GPUs, generating 1,024 output tokens per request. The release page dates the measurement to August 28, 2026.[1][2]

| Concurrent requests | Target-only throughput | EAGLE 3.1 speculative throughput |
| ---: | ---: | ---: |
| 1 | 145.3 tokens/s | 265.3 tokens/s |
| 4 | 508.9 tokens/s | 143.8 tokens/s |
| 8 | 1,009.2 tokens/s | 124.5 tokens/s |

Speculative decoding increased throughput at concurrency one but reduced aggregate throughput at four and eight concurrent requests in this benchmark. General Trajectory states that its training run therefore used target-only concurrent batches.[1][2] The release does not report total GPU-hours for the complete training run.

## Evidence and release artifacts

The public project page includes an interactive field viewer for six selected policy outputs. Its machine-readable release file records the displayed results, checkpoint identifiers, underlying artifact paths, and SHA-256 digests.[1][2]

The performance evidence remains first-party. As of September 9, 2026, the cited release materials do not include a peer-reviewed IronBench paper, an independent reproduction, or a factory-tested transformer produced from a policy design. IronBench therefore supports a narrower conclusion: within its fixed simulation domain, reinforcement learning changed the Kimi K2.6 policy's output distribution and increased compliance under the project's verifier.[1][2]

## References

1. General Trajectory. "IronBench: Reinforcement learning for power-transformer design." September 2026. https://www.generaltrajectory.com/ironbench/
2. General Trajectory. "IronBench machine-readable release data." Accessed September 9, 2026. https://www.generaltrajectory.com/ironbench/data/release.json
3. General Trajectory. "AI is now improving its own model architectures and chips." X, September 7, 2026. https://x.com/gentrajectory/status/2097015968287617258
4. Su, Y., Yu, D., Song, L., et al. "Crossing the Reward Bridge: Expanding Reinforcement Learning with Verifiable Rewards Across Diverse Domains." Proceedings of ACL 2026, pp. 3872-3892. https://aclanthology.org/2026.acl-long.178/
5. IEEE Standards Association. "IEEE C57.12.90-2021: IEEE Standard Test Code for Liquid-Immersed Distribution, Power, and Regulating Transformers." Published February 4, 2022. https://standards.ieee.org/ieee/493/7211/
6. International Electrotechnical Commission. "IEC 60076-1:2011: Power transformers, Part 1: General." Published April 20, 2011. https://webstore.iec.ch/en/publication/588
7. International Electrotechnical Commission. "IEC 60076-2:2011: Power transformers, Part 2: Temperature rise for liquid-immersed transformers." Published February 2, 2011. https://webstore.iec.ch/en/publication/599