Interactive Training 2: Auditable Control Plane for Live Model Training

# Interactive Training 2: Auditable Control Plane for Live Model Training
Source: [https://arxiv.org/html/2607.18314](https://arxiv.org/html/2607.18314)
Wentao Zhang1,\*Xuanhe Pan2,\*Han Zhou1,\* Yang Lu2,†Yuntian Deng1,† 1University of Waterloo2University of Wisconsin\-Madison \*Equal contribution†Equal advising \{w564zhan,h46zhou,yuntian\}@uwaterloo\.ca\{xpan73,ylu97\}@wisc\.edu

###### Abstract

Experiment trackers show how training is progressing, but changing a live run still usually requires trainer\-specific code\. We presentInteractive Training 2, an open\-source control plane for steering training through a shared protocol\. Training applications declare which settings and actions they expose, humans and automated controllers submit requests through the same interface, and the training loop validates and applies them at safe control points\. A customized Aim workspace combines live metrics and controls with a chronological record of requests and outcomes\. We demonstrate the system across five NLP and reinforcement\-learning workflows\. The released code and traces provide a reusable foundation for auditable human\- and agent\-guided training\.

Interactive Training 2: Auditable Control Plane for Live Model Training

Wentao Zhang1,\*Xuanhe Pan2,\*Han Zhou1,\*Yang Lu2,†Yuntian Deng1,†1University of Waterloo2University of Wisconsin\-Madison\*Equal contribution†Equal advising\{w564zhan,h46zhou,yuntian\}@uwaterloo\.ca\{xpan73,ylu97\}@wisc\.edu

## 1Introduction

Researchers rarely treat model training as a completely passive process\. They watch the loss curves, inspect evaluations, and decide whether to lower the learning rate, rebalance the data, save a checkpoint, or stop an unstable run\. Modern experiment trackers make these decisions easier by showing what is happening, but they offer no general way to carry them out\. Acting on an observation still usually requires custom callbacks or logic written for one trainer and one experiment\. In practice, researchers already steer training in response to live behavior\(Zhang et al\.,[2022](https://arxiv.org/html/2607.18314#bib.bib22); Walsh et al\.,[2025](https://arxiv.org/html/2607.18314#bib.bib20)\), but the tooling for doing so remains fragmented\.

Interactive Training 2 makes a training run steerable through a shared interface\. The training application declares which settings may be changed and which actions may be requested\. A human, script, heuristic, or LLM agent can then submit a request through the same protocol\. The training loop remains in control: it decides when the request can be safely applied, validates it, and records the result before continuing\. For example, an application may expose a typedlearning\_ratesetting together withevaluateandsave\_checkpointactions\. A controller may request a learning rate of2×10−52\\times 10^\{\-5\}, but the optimizer is changed only when the loop reaches a designated control point\. We call this layer between training code and its controllers a*control plane*\. It defines what can change, when changes take effect, and what is recorded\.

Interactive Training v1 showed that a human or constrained LLM could modify a live Hugging Face training job through a control server\(Zhang et al\.,[2025](https://arxiv.org/html/2607.18314#bib.bib23)\)\. That system was built around a fixed vocabulary of commands executed through Hugging Face Trainer callbacks\. Interactive Training 2 turns this trainer\-specific demonstration into a reusable protocol\. Training applications can register their own settings and actions, different training loops can choose their own control points, and different kinds of controllers can interact with all of them through the same interface\.

![Refer to caption](https://arxiv.org/html/2607.18314v1/x1.png)Figure 1:One request from plan to result in the Aim Live workspace\.Enlarged crops from one illustrative BERT run show \(1\) the Round 2 journal and proposed change, \(2\) Controls and best\-so\-far round scores, \(3\) Validation loss after the setting change, and \(4\) Logging area showing the request, result, and saved checkpoint\.Figure[1](https://arxiv.org/html/2607.18314#S1.F1)previews this interaction in the customized Aim workspace\. A researcher can inspect live metrics, request a change, and see whether and when it was applied\. The accompanying journal connects plans and controller decisions to requests, results, evaluations, and checkpoints\. We call the system*auditable*because it is possible to reconstruct who requested each action, what the request contained, whether it succeeded, and what happened around it\. The goal is to let researchers add human or automated steering to different training workflows without rebuilding the monitoring, control, and logging machinery for each experiment\.

Our contributions are:

- •A shared protocol for steering live training runs\.Training applications expose typed settings and structured actions, while training loops determine the safe points at which queued requests may take effect\.
- •A unified interface for observing, controlling, and reviewing training\.A customized Aim workspace combines live metrics and controls with an ordered journal that connects controller decisions to requests, execution results, evaluations, and checkpoints\.
- •An open\-source implementation demonstrated across five workflows\.The same protocol supports callbacks, optimizer wrappers, and direct PyTorch and reinforcement\-learning loops, and can be used by humans, scripts, and LLM agents\. The code is available at[github\.com/yuntian\-group/interactive\-training](https://github.com/yuntian-group/interactive-training)and an interactive demo is available at[interactivetraining\.ai/live](https://interactivetraining.ai/live)\.

## 2System at a Glance

Consider a researcher fine\-tuning BERT\. From the Aim workspace, the researcher inspects the live validation trajectory, lowers the learning rate from3×10−53\\times 10^\{\-5\}to2×10−52\\times 10^\{\-5\}, requests an evaluation and checkpoint, and lets training continue\. The training loop applies these requests when it reaches a designated control point, records whether they succeeded, and then proceeds with the updated run\.

Figure[1](https://arxiv.org/html/2607.18314#S1.F1)illustrates this shared interaction pattern: observe the run, submit a request, apply it at a safe point, record the outcome, and continue\. Humans, scripts, heuristics, and LLM agents all submit requests through the same protocol\. The journal keeps each request together with its source, result, and surrounding training context, making the sequence of decisions and outcomes easier to inspect than when it is scattered across console logs\.

## 3Control\-Plane Design

#### Training code defines each control\.

The application registers typed settings, which are called knobs in the Python API, and implements the corresponding getters, setters, and actions\. The same mechanism can represent an AdamWLoshchilov and Hutter \([2019](https://arxiv.org/html/2607.18314#bib.bib10)\)learning rate, source\-sampling weight, MuonJordan et al\. \([2024](https://arxiv.org/html/2607.18314#bib.bib9)\)momentum, or curriculum difficulty in reinforcement learning without putting task\-specific logic in the training session\. HTTP clients, the UI, and automated controllers all see the same list\.

![Refer to caption](https://arxiv.org/html/2607.18314v1/x2.png)Figure 2:The shared control protocol\.Training code declares settings and actions and callsTrainingSessionat safe control points\. Human users, scripts, and the optional LLM agent submit the same typed actions; the session validates, applies, and records them before the next training step, while Aim presents live metrics and the event journal\. The lower panel shows what carries across rounds; each new round creates a fresh model and optimizer\.Figure[2](https://arxiv.org/html/2607.18314#S3.F2)answers three questions: what the training code exposes, who may submit requests, and when the session applies and records them\.

#### The loop decides when changes apply\.

Requests may arrive at any time, but the training loop applies them one at a time at explicit control points\. Human users, scripts, and LLM agents submit the same request format to one queue\. The application chooses the control points, validates task\-specific actions, and can hide dangerous actions from the LLM agent\.

#### The journal links rounds\.

Within a round, metrics, requests, results, checkpoints, and controller decisions share one ordered journal\. Across rounds, the demo scripts start a new model and optimizer, then pass a text summary of configurations, actions, scores, and reflections into the next plan\.

## 4How the System Works

Figure[2](https://arxiv.org/html/2607.18314#S3.F2)shows the training loop, the long\-livedTrainingSession, and the interfaces used by controllers\. The training code still owns every model update\. Human users, scripts, and the optional LLM agent send requests through the session\.

### 4\.1Registered Settings and Actions

A typedsettingbinds a name to a getter and setter, with a data type, optional range and step size, and a natural\-language description\. The API method is namedregister\_knob\. For numerical settings, the session converts and clamps requested values before calling training\-owned code\. Anactiondefines a command such as evaluation or checkpointing\. Each submitted request records the action type, its arguments, its source, an identifier, and a timestamp\. The HTTP API and LLM agent both receive the same list of registered actions\. Examples includeset\_knob,evaluate,save\_checkpoint,load\_checkpoint,pause, andstop\. Applications can add domain\-specific actions, such as freezing a language model embedding component\.

Agoalnames the metric used to score a round, such as the best validation loss observed\. The current implementation either minimizes or maximizes that value\. Aneventrecords an increasing sequence number, event type, payload, round, and time\. Metric reports, plans, LLM calls, setting changes, action results, checkpoints, and reflections all enter the same journal as typed events\.

### 4\.2Applying Requests at Control Points

At eachsession\.step\(metrics\)call, the training process:

1. 1\.Records new metrics and snapshots the initial setting configuration\.
2. 2\.Runs attached controllers on their configured schedule, such as every 100 steps\.
3. 3\.Drains human and automated requests from one action queue\.
4. 4\.Runs the matching handler, clamps setting values, and records a result for every request\.
5. 5\.Continues to service resume and stop requests while paused\.

When a loop is idle,session\.pump\(\)processes pending requests without recording a training metric\. The call returns aStepControlobject that tells the integration whether to stop, evaluate, save or load a checkpoint, reset a module, or update a setting\. The training integration translates these decisions into the local framework’s semantics\.

Table[1](https://arxiv.org/html/2607.18314#S4.T1)summarizes the five released workflows, how each one integrates the session, what it exposes, and the scores recorded in its journal\.

Table 1:What the five released workflows expose\.Each row summarizes one multi\-round run\. Round 0 uses the original configuration without the LLM agent, and every later round starts with a fresh model and optimizer\. Eval/controller frequencies are in steps \(iterations for RLVR Countdown\)\. Scores give context for the associated journals\.The control point guarantees that when the call returns, every accepted change is already in place before the next step\. An HTTP request does not wait for that point\.POST /actionsreturns an identifier immediately, and the lateraction\_resultevent says whether the request was applied or rejected\. After reconnecting, a client can ask for recent missed events with asincecursor\.

### 4\.3Three Ways to Connect Training Code

#### Trainer\.

make\_interactive\(Trainer\)installs a callback that registers optimizer controls, reports training and evaluation metrics, and maps session decisions to Trainer control flags\(Wolf et al\.,[2020](https://arxiv.org/html/2607.18314#bib.bib21)\)\. When evaluation is scheduled, the callback waits to invoke the LLM agent until fresh evaluation metrics are available\. This callback path underlies the BERTDevlin et al\. \([2019](https://arxiv.org/html/2607.18314#bib.bib7)\)sentiment classification demonstrations and requires only replacing the Trainer class and passing a session\.

#### Optimizer patching\.

For loops that are difficult to edit, an optional wrapper turnsoptimizer\.step\(\)into a control point\. It saves the returnedStepControlon the session for the loop to read\.

#### Direct integration\.

Custom pretraining loops and reinforcement learning with verifiable rewards \(RLVR\) loops callsession\.stepdirectly\. The application chooses which diagnostics to report and how to implement checkpoint or evaluation requests\.

### 4\.4Optional LLM Agent

Any controller can use the shared protocol\. The supplied LLM agent demonstrates automated use in three phases\.Planreceives the task, goal, available settings, remaining rounds, and a short summary of earlier configurations, scores, actions, and reflections\. It returns an initial configuration and strategy\.Actreceives recent metric values, current settings, earlier decisions in the round, prior reflections, and tools generated from the registered actions\. It may issue several tool calls or intentionally take no action\.Reflectreceives the completed trajectory, action history, score, and earlier lessons, then writes a short actionable lesson and a distinct next variation\.

All recorded runs use GPT\-5\.5 with high reasoning effort as the agent\. When the agent is attached, the multi\-round driver first runs one reference round without it\. Each later round starts a fresh model and optimizer, creates a plan, runs training, computes a score, and writes a reflection to the JSONL journal\. Each entry includes the round’s starting configuration, best score and step, successful actions, and reflection\. Prompts use at most the ten latest entries to bound context growth\.

Figure[3](https://arxiv.org/html/2607.18314#S4.F3)plots the score recorded for every fresh round\. Its purpose is to keep unsuccessful rounds visible alongside rounds that set a new best\.

![Refer to caption](https://arxiv.org/html/2607.18314v1/x3.png)Figure 3:Scores recorded during five example runs\.Each point is the best score recorded in one fresh round\. The solid line tracks the best score seen so far, the diamond and dashed line mark the Round 0 reference without the LLM agent, and filled circles mark a new best\. Y\-axes use task\-specific raw units and fixed limits\. All panels share the Round 0–10 x\-scale, with Countdown ending at Round 7\. Sentiment and Countdown use percentages here\. Table[1](https://arxiv.org/html/2607.18314#S4.T1)reports their decimal values\.Table[2](https://arxiv.org/html/2607.18314#S4.T2)condenses three cases in which a failed or stalled round changed the next plan\.

Table 2:Failed rounds appear in the next plan\.
### 4\.5Aim and HTTP Interfaces

A thin FastAPI service exposes/state,/actions,/events, and a WebSocket event stream\. It owns no training logic\. An Aim transport records events on a background thread so writing metrics does not pause training\. It creates one Aim run per training round, stores the goal and control endpoint as run metadata, records numerical metrics with round and branch context, and stores controller\-related events as text sequences\. The customized Aim workspace uses that endpoint both to display metrics and to submit requests\.

## 5System Validation

#### Validation scope\.

We test three things\. First, can one protocol represent many kinds of changes? Second, does each request produce a recorded result? Third, can a later round visibly use an earlier reflection? Scores provide context for the recorded decisions; they are not controlled comparisons of optimization algorithms\. The artifact includes the five JSONL journals and the fields derived from them\. Figure[3](https://arxiv.org/html/2607.18314#S4.F3)provides the score context, and Table[1](https://arxiv.org/html/2607.18314#S4.T1)summarizes what each workflow exposes\.

### 5\.1Many Kinds of Changes

The workflows range from optimizer and checkpoint settings to source and class mixtures, 27 embedding, block, head, and residual\-group learning rates, two optimizer groups, and an RL difficulty schedule\. The same protocol works across these workflows: each application publishes its settings and actions, and controllers read that list\. Appendix[C](https://arxiv.org/html/2607.18314#A3)and Table[4](https://arxiv.org/html/2607.18314#A3.T4)give model, data, budget, call frequency, and diagnostic details\.

Table 3:From a trainer\-specific demonstration to a reusable control protocol\.Live intervention, an HTTP API, human control, checkpoint management, and within\-run LLM action are inherited from v1\.Table[3](https://arxiv.org/html/2607.18314#S5.T3)compares this shared protocol with Interactive Training v1\. Section[6](https://arxiv.org/html/2607.18314#S6)returns to that distinction\.

### 5\.2From Request to Recorded Result

Figure[1](https://arxiv.org/html/2607.18314#S1.F1)exposes a complete request path in the deployed interface\. At 6:01:46, the LLM agent requestssave\_checkpoint, the shared queue assigns the request an identifier, the next control point runs the application handler, and anaction\_resultrecords success\. Two seconds later,checkpoint\_savedrecords step 200 and evaluation loss 0\.2709\. The same journal would record an explicit failure if validation or the handler rejected the request\. Beyond this capture, the released JSONL journals record each round’s executed actions across all five workflows, so the request\-to\-result path can be checked against the released traces\.

### 5\.3Using Earlier Reflections

Table[2](https://arxiv.org/html/2607.18314#S4.T2)gives three examples of a later plan using an earlier reflection, while every round still starts a fresh model and optimizer\. After Sentiment R8 regresses, its reflection proposes asymmetric class weights; Rounds 9 and 10 record those choices\. In Muon–AdamW, the R4 reflection says that momentum has not yet been tried\. The R5 plan lowers it from0\.950\.95to0\.900\.90, preceding the score of4\.42914\.4291\. After Countdown R5 begins at the hardest curriculum level and stalls at0\.1540\.154, the next plans widen clipping, increase early exploration, and sustain a mid\-difficulty curriculum before R6 and R7 reach0\.2080\.208and0\.2320\.232\.

## 6Related Work

Experiment trackers such as Aim and Weights & Biases persist metrics\(Arakelyan et al\.,[2020](https://arxiv.org/html/2607.18314#bib.bib3); Biewald,[2020](https://arxiv.org/html/2607.18314#bib.bib6)\), while orchestration systems manage jobs and resources\. Interactive Training 2 uses a tracker as its monitoring and control UI\. The training application, not the tracker, decides what may change\. Trainer callbacks can make similar changes inside one framework\(Wolf et al\.,[2020](https://arxiv.org/html/2607.18314#bib.bib21)\)\. Our system instead gives every controller the same external protocol, records a result for each request, and lets the training loop choose where changes apply\.

Hyperparameter optimization, population\-based training, and dynamic algorithm configuration choose or adapt configurations according to a search policy\(Bergstra and Bengio,[2012](https://arxiv.org/html/2607.18314#bib.bib5); Jaderberg et al\.,[2017](https://arxiv.org/html/2607.18314#bib.bib8); Akiba et al\.,[2019](https://arxiv.org/html/2607.18314#bib.bib2); Adriaensen et al\.,[2022](https://arxiv.org/html/2607.18314#bib.bib1); Shabgahi et al\.,[2024](https://arxiv.org/html/2607.18314#bib.bib18)\)\. They can act as controllers on top of this system\. The control plane supplies the available actions, the places where changes apply, and an audit trail; the search algorithm remains separate\.

Recent LLM systems plan experiments or change training recipes\(Rao and Advani,[2026](https://arxiv.org/html/2607.18314#bib.bib16); Radianis,[2026](https://arxiv.org/html/2607.18314#bib.bib15); Rodrigues et al\.,[2026](https://arxiv.org/html/2607.18314#bib.bib17)\)\. In our system, the LLM agent is optional and uses the same protocol as humans, scripts, and heuristics\. Interactive Training v1 is the direct predecessor; Table[3](https://arxiv.org/html/2607.18314#S5.T3)isolates the new shared protocol from the inherited live\-intervention demonstration\.

## 7Conclusion

Interactive Training 2 turns live training intervention from experiment\-specific logic into a reusable interface\. Training applications define what may change and when changes may safely take effect; humans and automated controllers decide what to request through a shared protocol, and the journal records the resulting sequence of decisions and outcomes\. This separation makes training runs easier to steer, reuse, and inspect across different frameworks and workflows\. The released system provides a foundation for interactive training tools and for more systematic studies of how humans and automated agents supervise learning in progress\.

## Limitations

The training loop waits while the LLM responds\. The system also does not yet handle a response that arrives after training has moved on\. Applications remain responsible for checking custom actions\. Value bounds, type checks, permissions, and human controls limit what an agent may do, but they cannot guarantee safe or optimal actions\. High\-stakes use needs approval gates, resource budgets, rollback policies, and task\-specific safety checks\.

## References

- Adriaensen et al\. \(2022\)Steven Adriaensen, André Biedenkapp, Gresa Shala, Noor Awad, Theresa Eimer, Marius Lindauer, and Frank Hutter\. 2022\.[Automated dynamic algorithm configuration](https://doi.org/10.1613/jair.1.13922)\.*Journal of Artificial Intelligence Research*, 75:1633–1699\.
- Akiba et al\. \(2019\)Takuya Akiba, Shotaro Sano, Toshihiko Yanase, Takeru Ohta, and Masanori Koyama\. 2019\.[Optuna: A next\-generation hyperparameter optimization framework](https://doi.org/10.1145/3292500.3330701)\.In*Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining*, pages 2623–2631\.
- Arakelyan et al\. \(2020\)Gor Arakelyan, Gevorg Soghomonyan, and The Aim team\. 2020\.[Aim](https://doi.org/10.5281/zenodo.6536394)\.Computer software\.Initially released 18 June 2020\.
- Barbieri et al\. \(2020\)Francesco Barbieri, Jose Camacho\-Collados, Luis Espinosa\-Anke, and Leonardo Neves\. 2020\.TweetEval:Unified Benchmark and Comparative Evaluation for Tweet Classification\.In*Proceedings of Findings of EMNLP*\.
- Bergstra and Bengio \(2012\)James Bergstra and Yoshua Bengio\. 2012\.[Random search for hyper\-parameter optimization](http://jmlr.org/papers/v13/bergstra12a.html)\.*Journal of Machine Learning Research*, 13\(10\):281–305\.
- Biewald \(2020\)Lukas Biewald\. 2020\.[Experiment tracking with weights and biases](https://www.wandb.com/)\.Software available from wandb\.com\.
- Devlin et al\. \(2019\)Jacob Devlin, Ming\-Wei Chang, Kenton Lee, and Kristina Toutanova\. 2019\.[BERT: Pre\-training of deep bidirectional transformers for language understanding](https://doi.org/10.18653/v1/N19-1423)\.In*Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 1 \(Long and Short Papers\)*, pages 4171–4186, Minneapolis, Minnesota\. Association for Computational Linguistics\.
- Jaderberg et al\. \(2017\)Max Jaderberg, Valentin Dalibard, Simon Osindero, Wojciech M\. Czarnecki, Jeff Donahue, Ali Razavi, Oriol Vinyals, Tim Green, Iain Dunning, Karen Simonyan, Chrisantha Fernando, and Koray Kavukcuoglu\. 2017\.[Population based training of neural networks](https://arxiv.org/abs/1711.09846)\.*Preprint*, arXiv:1711\.09846\.
- Jordan et al\. \(2024\)Keller Jordan, Yuchen Jin, Vlado Boza, Jiacheng You, Franz Cesista, Laker Newhouse, and Jeremy Bernstein\. 2024\.[Muon: An optimizer for hidden layers in neural networks](https://kellerjordan.github.io/posts/muon/)\.
- Loshchilov and Hutter \(2019\)Ilya Loshchilov and Frank Hutter\. 2019\.[Decoupled weight decay regularization](https://openreview.net/forum?id=Bkg6RiCqY7)\.In*International Conference on Learning Representations*\.
- Lozhkov et al\. \(2024\)Anton Lozhkov, Loubna Ben Allal, Leandro von Werra, and Thomas Wolf\. 2024\.[Fineweb\-edu: the finest collection of educational content](https://doi.org/10.57967/hf/2497)\.
- Maas et al\. \(2011\)Andrew L\. Maas, Raymond E\. Daly, Peter T\. Pham, Dan Huang, Andrew Y\. Ng, and Christopher Potts\. 2011\.[Learning word vectors for sentiment analysis](http://www.aclweb.org/anthology/P11-1015)\.In*Proceedings of the 49th Annual Meeting of the Association for Computational Linguistics: Human Language Technologies*, pages 142–150, Portland, Oregon, USA\. Association for Computational Linguistics\.
- Malo et al\. \(2014\)P\. Malo, A\. Sinha, P\. Korhonen, J\. Wallenius, and P\. Takala\. 2014\.Good debt or bad debt: Detecting semantic orientations in economic texts\.*Journal of the Association for Information Science and Technology*, 65\.
- McAuley and Leskovec \(2013\)Julian McAuley and Jure Leskovec\. 2013\.[Hidden factors and hidden topics: understanding rating dimensions with review text](https://doi.org/10.1145/2507157.2507163)\.In*Proceedings of the 7th ACM Conference on Recommender Systems*, RecSys ’13, page 165–172, New York, NY, USA\. Association for Computing Machinery\.
- Radianis \(2026\)Anis Radianis\. 2026\.[Learn\-by\-wire training control governance: Bounded autonomous training under stress for stability and efficiency](https://arxiv.org/abs/2605.19008)\.*Preprint*, arXiv:2605\.19008\.
- Rao and Advani \(2026\)Anjali Rao and Nikhil Kamalkumar Advani\. 2026\.[AI training manager: Bounded closed\-loop control of adaptive training recipes](https://arxiv.org/abs/2606.29871)\.*Preprint*, arXiv:2606\.29871\.
- Rodrigues et al\. \(2026\)Carson Rodrigues, Oysturn Vas, Isaiah Abner DCosta, and Nithish Kumar Prabhakaran\. 2026\.[When is an LLM worth it for hyperparameter optimization? a budget\-matched study on tabular data finds the warm\-start is a default configuration, not the model](https://arxiv.org/abs/2606.21641)\.*Preprint*, arXiv:2606\.21641\.
- Shabgahi et al\. \(2024\)Soheil Zibakhsh Shabgahi, Nojan Sheybani, Aiden Tabrizi, and Farinaz Koushanfar\. 2024\.[Livetune: Dynamic parameter tuning for feedback\-driven optimization](https://arxiv.org/abs/2311.17279)\.*Preprint*, arXiv:2311\.17279\.
- Socher et al\. \(2013\)Richard Socher, Alex Perelygin, Jean Wu, Jason Chuang, Christopher D\. Manning, Andrew Ng, and Christopher Potts\. 2013\.[Recursive deep models for semantic compositionality over a sentiment treebank](https://aclanthology.org/D13-1170/)\.In*Proceedings of the 2013 Conference on Empirical Methods in Natural Language Processing*, pages 1631–1642, Seattle, Washington, USA\. Association for Computational Linguistics\.
- Walsh et al\. \(2025\)Evan Pete Walsh, Luca Soldaini, Dirk Groeneveld, Kyle Lo, Shane Arora, Akshita Bhagia, Yuling Gu, Shengyi Huang, Matt Jordan, Nathan Lambert, Dustin Schwenk, Oyvind Tafjord, Taira Anderson, David Atkinson, Faeze Brahman, Christopher Clark, Pradeep Dasigi, Nouha Dziri, Allyson Ettinger, and 23 others\. 2025\.[2 OLMo 2 furious \(COLM’s version\)](https://arxiv.org/abs/2501.00656)\.In*Second Conference on Language Modeling*\.
- Wolf et al\. \(2020\)Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Remi Louf, Morgan Funtowicz, Joe Davison, Sam Shleifer, Patrick von Platen, Clara Ma, Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao, Sylvain Gugger, and 3 others\. 2020\.[Transformers: State\-of\-the\-art natural language processing](https://doi.org/10.18653/v1/2020.emnlp-demos.6)\.In*Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: System Demonstrations*, pages 38–45\. Association for Computational Linguistics\.
- Zhang et al\. \(2022\)Susan Zhang, Stephen Roller, Naman Goyal, Mikel Artetxe, Moya Chen, Shuohui Chen, Christopher Dewan, Mona Diab, Xian Li, Xi Victoria Lin, Todor Mihaylov, Myle Ott, Sam Shleifer, Kurt Shuster, Daniel Simig, Punit Singh Koura, Anjali Sridhar, Tianlu Wang, and Luke Zettlemoyer\. 2022\.[Opt: Open pre\-trained transformer language models](https://arxiv.org/abs/2205.01068)\.*Preprint*, arXiv:2205\.01068\.
- Zhang et al\. \(2025\)Wentao Zhang, Yang Young Lu, and Yuntian Deng\. 2025\.[Interactive training: Feedback\-driven neural network optimization](https://doi.org/10.18653/v1/2025.emnlp-demos.65)\.In*Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: System Demonstrations*, pages 851–861, Suzhou, China\. Association for Computational Linguistics\.

## Appendix AMinimal Integration Example

The direct integration path requires a session, registered controls, and one call at a safe point in the loop:

```
# 1. Create the training session.
session = TrainingSession(
    goal="val_loss",
    agent=LLMAgent(every=100),
    memory="memory.jsonl",
)
# 2. Register application-owned controls.
session.register_knob(
    "lr", get=get_lr, set=set_lr,
    min=0.0, max=1e-2,
)

with session.run():
    for step, batch in enumerate(loader):
        loss = update_model(batch)
        # 3. Apply at a safe boundary.
        control = session.step(
            {"loss": float(loss)},
            step=step,
        )
        if control.stop:
            break

# HF: make_interactive(Trainer)
```

The artifact includes the complete3842×18563842\\times 1856unannotated Aim capture used for Figure[1](https://arxiv.org/html/2607.18314#S1.F1)\. It preserves the full journal, controls, metrics, and event\-stream context at native resolution; the public workspace is at[https://interactivetraining\.ai/live](https://interactivetraining.ai/live)\.

## Appendix BControl and Journal Records

Every submitted request contains an action type, arguments, identifier, timestamp, and source\. Every result records success or failure, optional returned data, and an error message\. Unknown actions and handler exceptions therefore appear as recorded failures\. Events add an increasing sequence number and round number, allowing reconnecting clients to recover recent missed events; Aim keeps a permanent copy\. One cross\-round journal row records whether the round is the Round 0 no\-LLM reference, its initial configuration and plan, best score and step, successful actions, reflection, and cumulative token usage\. Prompts include at most ten recent rows\.

GET /statereturns the current settings, actions, and session metadata\.POST /actionsenqueues a request whose lateraction\_resultreports success or failure; GET/WS/events?since=returns events after a given sequence number\. Built\-ins cover settings, evaluation, checkpoints, execution control, module reset, annotations, context, and agent configuration\. Only humans may invoke destructive actions or actions that change the agent’s own configuration\.

## Appendix CTask Configurations and Controls

The journals provide round\-level plans, actions, reflections, scores, and usage\. Table[4](https://arxiv.org/html/2607.18314#A3.T4)lists the model, data, budget, evaluation frequency, controller call frequency, and registered controls for each trace\. RLVR denotes reinforcement learning with verifiable rewards\.

Table 4:Setup details for the five recorded runs\.All recorded runs use GPT\-5\.5 with high reasoning effort as the LLM agent\. The public Muon video is a separate five\-round run with 1,000 steps per round\. For RLVR Countdown, the evaluate and controller frequencies are in iterations\. The released journals do not include hardware, wall\-clock time, or per\-step telemetry\.
## Appendix DReleased Evidence and Demonstration

#### Journal evidence\.

Table[5](https://arxiv.org/html/2607.18314#A4.T5)reports execution and usage for each workflow\. The SHA\-256 manifest links each row to its source journal\.

Table 5:Per\-workflow journal and usage summary\.Token and cost totals come from the final row of each journal and are computed from unrounded values\. “Actions” counts successful setting changes and other control actions, the count does not measure decision quality\.
#### Trace shape\.

Figure[3](https://arxiv.org/html/2607.18314#S4.F3)shows these patterns across all five workflows\. BERT makes its largest score change in the first LLM\-guided round, whereas Layerwise GPT continues setting new running bests through R8 and Muon–AdamW sets none after R5\. Sentiment includes five later rounds that do not improve the current best before its R9–R10 recovery; Countdown’s R1 jump is followed by four such rounds before R6–R7\. The released plots retain these unsuccessful rounds rather than showing only the best configuration\.

#### Execution volume\.

Across the five sessions, 47 LLM\-guided rounds record 1,207 summarized successful actions, 3\.23M/0\.68M input/output tokens, and $36\.54 at the configured GPT\-5\.5 prices\. These fields quantify exposure and cost, not decision quality\.

#### Live demonstration\.

The public site separates the five\-round, 1,000\-step\-per\-round Muon video \(5\.44→5\.135\.44\\\!\\rightarrow\\\!5\.13;[https://youtu\.be/SwEHORh6h0k](https://youtu.be/SwEHORh6h0k)\), the distinct seed\-42 11\-round, 3,000\-step\-per\-round paper trace, and a queued tiny\-BERT CPU sandbox driven by a deterministic no\-LLM policy\. In the sandbox, reviewers can change a setting or request an evaluation and observe the matchingaction\_result, privately hosted LLM demos add the plan/act/reflect path\.

## Appendix EImplementation and Reviewer Paths

The optional LLM client supports OpenAI’s Responses API and compatible chat endpoints\. Provider, model, reasoning effort, and controller call frequency are runtime settings; the recorded runs use GPT\-5\.5 with high reasoning effort\. API keys are write\-only and are redacted from state and built\-in action events\.

#### Zero install\.

At[https://interactivetraining\.ai/live](https://interactivetraining.ai/live), reviewers can inspect a recorded trace or submit a limited set of setting changes and evaluation requests to the queued CPU sandbox\. The separate Muon video is supplementary\.

#### Core smoke test\.

Tagv2\.0\.2installs without the Aim fork;tests/run\_tests\.pyexercises the session, action protocol, HTTP interfaces, built\-in integrations, journal, and scripted controllers without a GPU or provider key\.

#### Full Aim workspace\.

To reproduce the full Aim interface, use the companion Aim branch and commit indemo/aim\.lock\.json\. The main README gives the corresponding clone,AIM\_SRC, and BERT frontend commands\.