You are browsing as a guest. Sign up (or log in) to start making projects!

Open comments for this post

19h 5m 53s logged

rumi-Devlog #7 🍓

This was probably one of the most frustrating and important RUMI development sessions so far.

Most people only see the final discovery reports. They don’t see the chaos that happens before RUMI can generate a single theory. And trust me, there was a lot of chaos.

💔 Bug Fixes, Bug Fixes, More Bug Fixes

I started this session thinking I’d make a few improvements and continue testing.

That did not happen.

RUMI’s architecture has reached a point where changing one thing breaks three others. Every time I fixed 3 bugs, another 5 appeared from somewhere else. At one point I genuinely crashed out because every run ended with a new issue that didn’t even exist before.

It felt like:

fix_bug()
spawn_more_bugs(count=5)

Turns out there’s a reason people say:

“If it’s working, don’t touch it.”

Unfortunately I touched it. A lot. 🥀

The Problem

Even though RUMI was producing interesting discoveries, I still wasn’t satisfied. The reports were often interesting, creative, and sometimes novel, but they still felt too generic.

The pipeline would generate a theory, evaluate it once, pick a winner, and move on. I wanted RUMI to spend more time refining ideas instead of treating every discovery as a one-shot attempt.

Falling Into The OpenMythos Rabbit Hole

While researching I came across OpenMythos, a community attempt to reverse engineer Anthropic’s rumored Mythos architecture.

Nobody actually knows how Mythos works, but the community has proposed several reasoning patterns that might explain Claude-style outputs.

I spent hours reading through it asking myself:

“What parts of this could actually work inside RUMI?”

Not copying.

Adapting.

The Biggest Change I’ve Ever Made To RUMI 🥀

One idea stood out immediately: recurrent reasoning loops.

Before:

  • Mechanisms
  • Predictions
  • Theory Competition
  • Winner

One pass. One shot.

If mechanism generation was weak, everything downstream became weak too.

So I rebuilt a huge section of the pipeline.

Now RUMI performs a 3-stage recurrent refinement process:

Loop 1 — Exploration

Maximum creativity
Maximum diversity
Broad theory generation

Loop 2 — Refinement

Survivors re-enter the pipeline
Focus on evidence, consistency, and mechanism quality

Loop 3 — Convergence

Lowest creativity
Highest rigor
Final selection of the strongest explanation

Instead of living or dying from a single generation pass, theories now get multiple opportunities to evolve.

Preventing Theory Drift

Another idea I adapted was evidence grounding injection.

Recursive systems often suffer from theory drift, where ideas slowly become disconnected from the evidence that originally generated them.

To prevent this, every refinement loop continuously receives:

Literature evidence
Contradictions
Knowledge gaps
Observed anomalies

This keeps discoveries grounded instead of drifting into fantasy.

Smarter Computation

I also added convergence-aware halting.

Not every scientific problem deserves the same amount of computation. Some topics converge quickly while others require deeper exploration.

RUMI can now monitor improvements between loops and eventually stop refining once discoveries begin stabilizing.

lwk so much happened in these last 17hrs that i cant even include everything in here cause of the word limit 😭🥀

0

Comments 1

@subhansh

and yes i again pulled an all nighter for this 💔💔… ik i should’nt do ts BUT RAH IM ADDICTED 😭🥀