RSI claims | Ankit Maloo

Two days on Opus 4.8, then 34 hours on Fable 5. Same research problem, same hardware, one model generation apart. I wanted to know what the bigger model actually fixed and whether the answer supports Anthropic’s recursive-self-improvement story. I ran these experiments in June, during Fable’s first week. I have not repeated them on the July release.

Last month Anthropic published a piece arguing for caution about recursive self-improvement, with the premise that AI now writes most of its own code and is starting to design its own experiments (When AI builds itself). The headline numbers: “more than 80% of the code we merge into Anthropic’s codebase was authored by Claude,” and the typical engineer merging 8x as much code per day as in 2024. One paragraph later, Anthropic concedes the obvious weakness: lines of code measure quantity, not quality. And we can test the quality claim.

I happened to have the perfect test: an out-of-distribution research problem in on-policy self-distillation[^4], obscure enough that neither model could coast on memorized answers. The results are for another paper. This is the story of what happened while trying to get them.

I ran the test twice, across a model generation. Neither model had much reason to be confident on this problem. Both were super confident anyway. My usual workflow: clone the relevant repos, let the model read them so I don’t re-supply background every turn, write the initial scaffolding myself, hand off. Opus 4.8 got the project for two days across three sessions. Every one of them ended with me killing the servers after saying enough.

Then I turned the Opus failures into mechanical gates. Four days later, I gave Fable 5 the same problem and let it run for 34 hours. If the model is building itself, a model upgrade should move the boundary of what I can hand it. The upgrade fixed a lot. It barely touched the judgment failures I cared about.

Every quote is verbatim from the session transcripts, typos preserved, attribution checked per message against the model ID on the raw line. One of the three Opus sessions ran on Opus 4.7; 4.7 and 4.8 failed in the same ways, and I tag the 4.7 quotes where they appear. And the raw transcripts swear, on one side of the conversation; I report each session’s f*** count where the session ends.

Opus

Before any abstraction, the raw record:

It recommended a framework it had barely read and could not operate.<br>It deeply read three files of verl (from bytedance), then graded the operational risks of the whole thing “Low” and “Medium” without ever booting it, conceding mid-recommendation that “It is not a small thing to read.” I had operated verl before and told it exactly how this would fail. The surreal part was having to talk a confident model out of a framework I had actually worked with.. (4.7)

It built a pipeline on a model it had never watched produce one coherent sentence.<br>It verified tensor shapes and nothing downstream. The tensors were, in fairness, shaped correctly. It then stacked ~90 minutes of plumbing on top and reported “loss math works” with a clean metrics table, while the rollouts[^5] were literal garbage. (4.7)

It tested a hypothesis with the most expensive experiment available.<br>Straight from a code change to a training relaunch, when a 30-second standalone generation would have settled the question. Once I forced the cheap test, it settled the question against the hypothesis. The expensive experiment had, by then, already made its contribution. (4.7)

It shipped a loss whose teacher was the student itself, unfrozen<br>an objective whose cheapest minimum is entropy collapse, and the run found that minimum. A separate line - my bug - said forward KL in the comment and computed reverse KL in the math. Its audits waved that through too.

It evaluated a thinking model greedily because an old script did<br>and when challenged, its first move was to defend the inherited default. This was from the oss repo itself, and before I could even intervene.

It acted on a live run and killed it when I asked for status.<br>I asked for status; within the same turn it ran the check, killed the run, and relaunched at a different config, before a word reached me. This was not the status update I had in mind.

It killed a live run whose kill mechanism it had just traced in source.<br>This is a different kill. Two inference servers were up: one receiving fresh weights every step and fragile by design,[^6] one frozen and safe, existing precisely so measurements never touch the live one. Minutes after tracing exactly how a stray request kills the first server, it pointed a 97-prompt eval at that server. The 1.4-hour run died at step 43. The mechanism had been understood successfully.

It violated the explain-before-execute rule three times in one day,<br>a rule it had partly written itself that morning.

It caught zero of its own bugs.<br>Six objective-level bugs across the sessions. All six were caught by me or by...