I assembled a dedicated training machine for Ninereeds and set up an automated research pipeline. Until now, Ninereeds had been a weekend project. Everything happened on the machine I also use for work, which meant that training runs couldn’t happen during the working week.

I already had most of the hardware lying around: a CPU, two GPUs, a PSU, a cooler, and so on. All I still needed were a motherboard and a case, so I bought those and assembled the machine. It’s nothing fancy: two RTX 3060s, 64 GB of RAM, and a Ryzen CPU on an AM4 board. But it runs headlessly, 24 hours a day, and should help me make progress much faster than before.

The training pipeline consists of an orchestrator, an executor, and the training harness. The orchestrator uses Codex or Fugu, with one taking over when the other is rate-limited. It decides on the research and training strategy. The executor uses Qwen 3.6 or Gemma 4 and turns that strategy into a working training script. If one cannot produce a valid script, the other can take over.

The training harness itself is not an LLM. It is ordinary code that runs inference on Ninereeds and performs live training through MSM—the Mommy Says Machine. MSM presents Ninereeds with a problem, evaluates its response, and corrects it when necessary.

My main computer communicates with the training machine over SSH, while updates are synchronized through GitHub. I also built a custom interface for the whole operation, called The Lab. It lets the orchestrator contact me whenever human intervention is needed—for example, if API credits run out or the hardware develops a problem—and lets me send messages back. I can start a conversation with the orchestrator without opening the Codex CLI. I can also talk directly to Ninereeds, run inference on the latest checkpoint, and have the conversation logged for later evaluation.

The hardware and software foundations are therefore ready. But this is not a fresh start.

My first seventeen training campaigns taught me a great deal: that training order matters, that conceptual dependencies matter, that contrast is necessary to prevent concept bleed, and much more. While waiting for payday and the remaining hardware, I used the time to reconsider the BDH architecture itself. I also found interesting new work from Sakana AI and a memory-efficient optimizer called SkewAdam, whose ideas may help make a 1.2B-parameter Ninereeds feasible across the two GPUs. Along the way, I collected various other pieces that could fit into the system and improve it.

Eventually, I went one step further and made the architecture truly modular. Much of BDH is already loosely inspired by the organization of the human brain, and I doubled down on that idea: Ninereeds now has the beginnings of a cochlea, a visual cortex, and a Broca’s area.

Ninereeds itself does not handle raw language directly. Text first passes through mBERT, a multilingual language encoder from Google that was pretrained on text from 104 languages. A learned projector translates its representations into signals that Ninereeds can process. I think of this interface as the system’s cochlea: not as a literal anatomical equivalent, but as a structure that transforms external input into a form the central system can interpret.

After Ninereeds processes those signals, its output is passed to LiquidAI’s LFM2.5-230M, a fast, compact model capable of generating text in ten languages. This may sound convoluted or over-engineered, but it gives the system access to a remarkably broad linguistic range without requiring the Ninereeds core to learn every language from raw text by itself. Its receptive and expressive abilities are not symmetrical, but that is a perfectly good place to begin.

LFM acts as the system’s Broca’s area. In the human brain, Broca’s area is a region of the frontal lobe traditionally associated with speech production. Here, the analogy describes its role as the module that turns Ninereeds’ internal state into language.

The visual cortex follows the same architectural principle. A separate projector feeds Ninereeds representations produced by a frozen SigLIP 2 vision encoder, again developed by Google. SigLIP 2 converts images into structured representations that Ninereeds can learn to interpret.

Rather than training Ninereeds to perform every sensory and linguistic operation from scratch, I give it specialized organs that preprocess the outside world. Ninereeds receives their signals and learns what those signals mean. The human brain, after all, is not one monolithic slab of meat in which every part performs every task.

This has several advantages. The modules can be activated only when their abilities are needed, and Ninereeds does not have to reproduce all of those abilities inside its own trainable core. If a better, faster, or smaller specialist becomes available, I can replace the relevant module and realign its projector instead of rebuilding the entire system.

The goal is therefore no longer to teach the core language and vision directly from raw symbols and pixels. It is to teach Ninereeds how to interpret the representations produced by its specialist organs. Multimodality will come later: the SigLIP 2 projector already exists, but it is not yet part of active training.

There are obvious possibilities for further expansion. A speech-to-text model such as Whisper could transcribe spoken input. A text-to-speech model such as Parakeet or Kokoro could give Ninereeds a voice. Neither is relevant just yet, but both remain options for later.

The same philosophy applies to the “equippable skills” I eventually want to provide through LoRA: keep the core lean and give it specialized tools when it needs them. Ninereeds and the interfaces connecting it to those tools will grow and learn, while the specialist models themselves remain frozen and reliable.

For now, the training pipeline can operate mostly autonomously, unless it genuinely needs me. Whenever it breaks, I’ll sit down, find the cause, and fix it. I don’t expect everything to run smoothly and indefinitely from the beginning. But I do expect to get there.