Recursive Toy Improvement

Flo graph of the DeepMuse ontology

Project

Over the next few months, I am conducting a toy experiment around recursive self improvement. The toy that I'm applying RSI to is called DeepMuse.

The goal is to decrease token cost, improve precision, and extend context out to infinity. Once the toy works, scale the model to larger projects.

The best fitting use cases are those where timing is critical and deeply contextual. This spans the gamut from robots, where latency is measured in milliseconds, to project management where every activity is on the critical path.

Here are the first few iterations:

v4

Introduction

Below is the output from Gemini, after feeding it the transcript from the MLST Podcast* and its links to Darwin Gödel Machine*, Hyperagents*, and EvoTune*.

TL;DR: train a private LLM to more efficiently talk to a Foundation LLM.

RSI v4

The shift from V3 to V4 introduces a hybrid execution pipeline to strictly minimize algorithmic complexity. A local model acts as an annex and orchestrator, isolating the proprietary ontology while delegating generalized logic to a Foundation Model. By combining Group Relative Policy Optimization (GRPO) with deterministic validation, the system trains the local model's adapters to optimize prompt translation and token efficiency over multiple turns.

A plan for utilizing a local model to supervise and translate mutations for a Foundation Model, optimizing the translation policy via speculative execution and deterministic compilation checks.

Goal

Establish an execution loop that continuously reduces the system's Minimum Description Length (MDL). The objective is to shrink the compiled graph size, the pre-fill token stream, and the local model's parameter footprint, without expanding the core MuFlo grammar.

Steps

  1. Implement the Annex Architecture. A local model processes user intent, extracts only the necessary MuFlo nodes, and delegates code generation to a Foundation Model. The local model operates exclusively as a router and gatekeeper, offloading conceptual heavy lifting to the Foundation Model.
  2. Execute a Deterministic Loop. The Foundation Model generates speculative graph mutations. These mutations are injected into an automated harness governed by the compiler and unit tests. No human intervention occurs during this generation-and-test phase.
  3. Adapt via GRPO and Turn-Level Credit. The local model generates multiple speculative translation prompts. Its adapters are updated using GRPO based on compilation success. Turn-level credit assignment rewards the local model for successful intermediate compilation steps during complex, multi-stage refactors.
  4. Prune Redundancy and Monitor MDL. The system continuously measures the MDL across the ontology size, graph size, token count, and adapter weights. Any structural mutation that expands the core MuFlo ontology or introduces redundant generalized knowledge into the local model is heavily penalized.

How each step is checked

  • Every proposed mutation must pass the local compiler and predefined topological constraints before adoption.
  • The system enforces a strict penalty on any increase in algorithmic complexity; successful epochs must trend the total system MDL downward.
  • The interface between the local model and Foundation Model remains strictly text-based to prevent leakage of the proprietary graph topology.

Research Strategy

  • Architecture: Deploy a local Private Model (PM) as an orchestrator and an external Foundation Model (FM) as the execution engine. The PM extracts the minimal necessary MuFlo sub-graph and formulates text-based instructions. The FM receives this narrow context and generates the graph mutation.
  • Execution Loop: Utilize deterministic validation. The PM injects the FM's proposed mutations into a strict harness governed by the xcodebuild compiler and predefined graph constraints.
  • Optimization: Apply Group Relative Policy Optimization (GRPO) to update the PM's LoRA adapters. The PM generates multiple speculative translation prompts per turn. Reward signals are derived from compilation success, graph size, and token efficiency. Turn-level credit assignment is applied to evaluate intermediate steps in long-horizon refactoring tasks.
  • Complexity Metric: Optimize for the Minimum Description Length (MDL). The system measures and penalizes increases in the byte size of the core ontology, the parameter count of the PM's adapters, the transmitted token count, and the compiled graph size. Generalized conceptual knowledge is strictly offloaded to the FM to maintain PM efficiency.

Status

Research strategy synthesized 2026-09-15. Implementation of the deterministic GRPO loop and local adapter training pending.

v3

Introduction

Here's what I've learn so far. An ontology may solve a few problems running a model running on private hardware, like the Mac Studio M5 Ultra. First, it narrows down pre-fill; reducing the number of tokens needed to provide the best context for solving a problem. Second, the RSI part could in fact provide an infinite context, as additional sessions decompose legacy data into, what Seymour Papert called "mind sized chunks."*

So, there is an opportunity here for any organization that wants to host their own models on Premises:

  • reduce pre-filling session context by an order of magnitude,
  • reducing Foundation token cost by an order of magnitude
  • increasing precision of output
  • extending institutional context to trillions of tokens

Here is the V3 output from Claude after feeding it an analysis by Gemini:

RSI v3

A plan for using language models to improve DeepMuse, and a test of whether the same method carries over to an organization's project-management data.

Goal

Get an improvement that can be measured and checked, without relying on a model's own ranking of its work. Frontier models propose changes. A smaller model running on the premises checks and ranks them. A person gives the final verdict on every change.

Steps

1. Ingest the toy model and refactor it into an ontology.
DeepMuse is a small app whose behavior is written in a graph language: named nodes, values, and edges that state what flows where. Its shipped graph files are the toy model. Step one takes those files in, restates them as an explicit ontology (what things exist, what connects to what, which rules the connections obey), and refactors the files against it so that each unit can be described on its own, apart from the rest of the tree.

2. Measure the prefill gain on a model running on the premises.
Before a model produces anything, it processes the whole prompt. That stage is the prefill, and its cost grows with the size of the prompt. If the ontology lets a prompt carry only the unit in question plus the grammar, instead of the whole tree, the prefill shrinks. Step two runs the same tasks with and without the ontology on a model hosted on the development machine, such as DeepSeek Flash, and reports the difference as measured time and as pass or fail on fixed checks.

3. Scale the measured gain to enterprise project-management data.
If step two shows a gain on the toy model, the same treatment is applied to a project-management system. Tasks, owners, dependencies, budgets, and change requests become the nodes and edges. The rules that define scope, risk, and who may see what become the ontology's constraints. For any given question, the model then receives only the slice of the organization's data the ontology selects. The gain from step two is measured again on that data before anything is relied on.

How each step is checked

  • Every proposed change passes fixed checks (it parses, the declared paths still exist, the app code that binds to them still resolves) before a person sees it.
  • The on-premises model's ranking is calibrated first against a random baseline, so a ranking no better than chance is detected rather than trusted.
  • The Developer gives the verdicts. No change is approved by a model.

Status

Plan and product requirements written 2026-09-12. Nothing is approved, installed, or running.

v2

Introduction

Since scoping out V1, I've learned that my Macbook Pro has enough power to start experimenting sooner, rather than later. Here is the Claude output:

Prompt

Segment our RSI goals from DeepMuse goals, here.

RSI objective

Create a business where RSI can be applied at the local level by ingesting source code into an Ontology which can be recompiled into deployment.

The Stack

  • Highest level: the user asks the model to accomplish an intent, using either a Foundation or local model to translate the dialog into an intermediate script.
  • Middle: a Developer who can understand the intermediate script, examine the related Interpretability playground, and perhaps draw convex hulls around related embeddings. The LeafGraph is an initial start at such a workflow.
  • Lowest level: a compiler may generate code for the nodes using an intermediate AST, ready for MLIR, Mojo, MAX, or CUDA.

Unknown

The degree of transparency around the post training.

Opportunity

Empower developers to both interpret and fine tune a hybrid of local models on premises and Foundation lab integration, where the on-prem weights and convex hulls remain private but are still accelerated by foundation models.

DeepMuse goals

A proof of concept in a safe toy domain in which to explore this Hybrid approach.

Refine the process of ingesting a legacy codebase into an ontology and measure performance gains on a local open weight model

Task

Devise a strategy where, on a MBP M4 Max 128 GB, a local model referees current Fable 5.1, Astra, Gemini, Grok, and their successors to compile DeepMuse into an executable ontology that evolves to user requests and engages with a Developer through an interactive ontology.

v1

Introduction

DeepMuse started out as a visual music synthesizer called Sky, which I would perform as a VJ 20+ years ago*.

Underneath was a data flow script, call Flo, which I kept rewriting. And rewriting. And rewriting. It was inspired by my days playing with an analog music synthesizer*. And then designing a project management system with Petri nets. Around that time, was a project at MIT around a Cellular Automata Machine*. And then there was Max*, a node based patcher for musical instruments. They all fostered a mindset, that information is flow.

A few years ago, I attended a workshop at NASA called: "The Virtual Iron Bird"*, which introduced the concept of using an Ontology to wrap the mission critical data flow around a space craft. So, I rewrote Flo again. But not for spacecraft; for visual music.

The goal was to make creating an ontology as fun as patching a modular synthesizer. Where you could plug, play, and experiment. The nice thing about an ontology for a toy is that, in contrast to a space craft, if you get it wrong, nobody dies. Instead, you get something interesting to iterate on. And because it is a toy, the ontology should be something a 12-year-old could understand.

I introduced this idea at a SuperHappyDevHouse* gathering, hosted ironically by Palantir. Ironically, in that I didn't know who Palantir was. It turns that Palantir was also working on ontologies. The kind where people could in fact die, when things go wrong.

What I hope to learn from making a toy RSI is how to create a dialog between a child and a machine. Of course, we are all becoming children in this new age of abundant intelligence.

Prompt

Here is my first prompt to Claude, ChatGPT, Grok, and Gemini:

I want to implement recursive self improvement (RSI) on decomposing source code into a small flo ontology, called MuFlo. The tools I want to use are: Apple Studio M5 Ultra 512 GB, open weight models to decompose DeepMuse project, close source models from OpenAI, Anthropic, and Google, to debate best implementations. See https://github.com/musesum/DeepMuse for toy application and package references to MuFlo.

Why

The output from each Foundation Lab was very different. Claude has the most history of code development, so was very specific. ChatGPT had only snippets of questions and was more philosophical. Grok was a monster that decided to just do it and started writing code for the harness. Gemini was the computer scientist of the bunch.

I was curious what the internal thesis for each reply, if there was one. So my next prompt was "Summarize Why". Here is the result:

Claude Code Fable 5.1

Why, in short:

  1. Leverage. A 40-line grammar that describes the whole instrument is worth more than 40,000 lines of Swift that implement it. Everything that reads flo — a menu, a peer, a tape, a model — gets the entire system for free.
  2. Truth in one place. Right now behavior is split: some of it is declared in flo, some of it is buried in @Published vars and hard-coded shader calls. Two sources of truth means every edit is a reconciliation. One source means an edit is just an edit.
  3. Models can only work on what fits in their head. DeepMuse as Swift doesn't fit. DeepMuse as flo does. That's the difference between a model that can patch a bug and a model that can propose a new instrument.
  4. The loop pays for itself. Every accepted fragment is a training example for the next one, so the cost of extraction falls as the corpus grows — and the same gate that verifies a translation can verify an invention. You build the checker once.
  5. It's the thing you've been building toward for thirty years. Tr3, Flo, the code leaf, pipeline.future.flo.h — every step moved more of the instrument out of code and into the graph. This is that step, with the extraction automated.

ChatGPT Sol 5.6

Do RSI on DeepMuse because it is a real, complex, evolving codebase that can serve as both training material and a hard test for MuFlo.

The purpose is to see whether repeated AI-driven decomposition can:

  • compress DeepMuse into a much smaller MuFlo ontology,
  • preserve behavior while removing language/framework-specific structure,
  • expose reusable semantic primitives across UI, audio, vision, networking, Metal, and device interaction,
  • regenerate or refactor implementations from the ontology,
  • identify where the ontology is redundant or incomplete,
  • recursively improve the ontology based on those failures.

So DeepMuse is not the end product. It is the experimental substrate for discovering whether MuFlo can become a smaller, more general executable representation of software.

Grok 4.6

Why: a synth with thousands of parameters is useless if only the author can play it.
Digital audio copied analog patching and then broke it. MIDI is 0–127, a screen is 1920×1280, an accelerometer is ±3g. Without auto-remap, every cable is a unit conversion. Without a loop-break (Visitor / GABA), a live graph eats itself. Without twins, two devices are two programs.

MuFlo is the why of size. Nine primitives, not a tenth. If it cannot be said with Node, Tree, Graph, Plugin, Value, Wildcard, Twin, Closure, Visitor, it is not decomposed yet. A 12-year-old never sees that — they see things, pipes, knobs. “Connect my thumb to brush size.”

The Swift/Metal grew anyway. RSI is the why of keeping the ontology: rewrite source until the graph is smaller than the code and still plays. Open weights on the Studio own the tree so DeepMuse never leaves the box. Closed models only argue. The chair merges.
Playable, local, small. That is the whole why.

Google Gemini 3.1 Pro Extended

ARCHITECTURAL DRIVERS: DEEPMUSE TO MUFLO DECOMPOSITION

  • State Determinism: Migrating to the MuFlo functional dataflow graph forces strict execution purity. This eliminates implicit state mutations and race conditions across complex media synchronizations, including concurrent operations bridging native iOS and external Web APIs.
  • Ontological Minimization: Reducing the codebase to a constrained node ontology simplifies the execution graph. This minimizes computational overhead for real-time processing and standardizes the routing architecture for high-frequency state updates.
  • Automated Validation: Manual architectural translation is inefficient and prone to structural drift. RSI utilizes xcodebuild as a deterministic fitness function, forcing generation to converge on mathematically verifiable compilation states without manual intervention.
  • Hallucination Suppression: Single-model generation produces high error rates in specialized frameworks (Metal, Swift 6 concurrency). The API consensus network cross-validates domain-specific constraints—memory safety, logic reduction, and shader execution—prior to local synthesis by the M5 Ultra.