It’s Tokens All The Way Down: How RLMs are Different — Kevin Madura, AlixPartners

Yeah. Awesome. Thanks, everyone, for being here. My name is Kevin Madura. I'm from a company called AlixPartners; we're a consulting firm. I'm here to talk to you today about RLMs. Just curious show of hands: who here is familiar with RLMs?

So we know how much time to spend on it. Okay. So not many. Allright, well, that's good. So we'll start with what an RLM is and why it's different. So RLM is a recursive language model. And really, the key difference here is that it treats the context as an object that it can interact with symbolically in its environment.

So it differs from a tool call in the sense that typically when you do a tool call, it's JSON or some type of string that's being sent, being interpreted elsewhere, maybe by some other program, and that's returning effectively as a string.

The key difference here is that it's interacting with a symbolic environment. So typically that's a REPL, a Python REPL. So that's key difference number 1. Key difference number 2 is that it has the ability to delegate to another LM, often to itself.

You can specify whether it's the same model or a different model, but fundamentally, because it lives in this environment, you can offload or make a sub-call to another LM with particular parameters that also lives in that REPL environment.

And so you get this ability to recursively decompose problems and have the LLM basically decide how to apply certain logic or certain interpretations or write its own code to solve those problems. And then that recurses down. So the sub-LMs can do the same sort of thing in terms of understanding and interpreting what it thinks it needs to do.

And I added this last one here. It's largely bitter lesson pilled, in my opinion,right? And shared by Alex and the rest of the creators of it. But as models get better, you should be able to defer more and more to the model for it to kind of figure out on its own what it needs to do.

So I don't know if this is the actual kind of starting point for RLMs. This is one that I consider to be one of the first kind of inklings of it. This is a tweet from Omar, who is Alex's advisor for RLMs.

And this was a concept that he had come up with where it was basically an ability to use DSPY and some other techniques to take in arbitrary length inputs. And basically, the use case here would be summarizing an arbitrarily long document and coming up with a table of contents and some summary of that content.

But at least to me, this was kind of the first inkling of, OK, context windows might not be something you need to deliberately manage, although there's, of course, benefits to doing so. There could be ways to exceed the context windows using some of these clever techniques.

And so if you read the paper and some of the blog posts that are out there from Alex and Omar, it has demonstrably better performance on some of these long-context tasks. So Oolong is one benchmark where

the intent of the benchmark is to measure model performance on answering questions about excessively long context. This is another one, BrowseComp, where it needs to iterate through a large body and corpus of text and answer particular questions about it.

You can see the blue line at the top there is the RLM. It's very good performance as compared to some of these other models. And even on the price curve, the purple is actually just using tool calling with GPT-5, calling a BM25 tool.

And that's actually even more expensive for worse performance than an RLM. So it's worth reading into if you're interested in some of the benchmarks and how RLMs perform. But fundamentally, an RLM, again, takes in your input, and you're kind of deferring to the model about how to decompose the process, what code it needs to write.

And it is very tightly integrated with the REPL itself. So it, by itself, defines what it needs to do. And so I kind of had this mental model in terms of, and I'm very DSPY-pilled, if you can tell by now, basically a student of Omar and the rest of the group there, where you have this relatively deterministic shell of what you want to do.

What is your intent? What is your actual task that you're trying to accomplish? You define that in terms of your inputs and your outputs and some type of guidance or prompt or what have you to the model to say, this is generally what I want to achieve.

Go off and do it. Here's the things that you can expect as your input. Here's what I want out of it. Go figure out the rest. And so this applies for using something like DSPY, but I think it applies to RLMs as well because you don't have to worry as much now about how the actual implementation works in the middle.

You can just have some guarantees about the inputs and the outputs, and you can let the model figure out the rest of that part of it. So a lot of this comes down to, if you were at, I think it was Code in November in New York City, Dex had this great talk about just broader context engineering.

And he coined something like the dumb zone, which it's kind of grayed out at the bottom there. But the point is that we all know that there's context rot,right? Once you fill up the context window to a certain degree, performance starts to degrade.

And so RLMs somewhat get around this problem because the context itself doesn't fill up as quickly because you're deferring a lot of the subtasks to the submodels. And the full kind of context and the inputs aren't exposed to the context window itself.

It lives as a variable in the REPL. And so the main LM can choose

how to access that. It can offload some of these subtasks to sub-LMs. And really, the only context that it gets back are the things that actually matter. So in terms of how it's meaningfully different, RAG, of course, you kind of just stuff the context window.

You run it to limits there. Agents are largely just bringing strings back. And you don't have this tight coupling between the logic, the execution, and the results. And so you still run into the same sort of problem there.

Same thing with tool calling and codec. And then RLMs, as I mentioned, the LLM is actually just interacting with the context, the results as variables in the REPL so that it can do additional computation on versus it trying to attend to all these different tokens in its context window.

It's a meaningfully different way of the LLM interacting with the actual content itself. And so people always say, OK, what's the difference between that and coding agents?

In my mind, the largest difference is that the way that tool calls are done is passing strings back and forth. But you can see with the release recently of workflows that Anthropic is doing something fairly similar. And they at the CAIS conference, I think it was Tarek or someone similar, mentioned the RLM paper as a key driver of workflows and how they've implemented it.

And you can see here, the intermediate results for workflows live in script variables, i.e., a variable in the context. So it's driving some of these breakthroughs and some of these techniques from the labs as well.

I'll skip through this a bit just because I have about 10 minutes left. But generally speaking, when you want to use it, it's obviously for large or dense input context. An underexplored area is outputs as well. So if you have some type of task where you need to generate hundreds of thousands of lines or whatever it might be, RLMs, I think, would be a good candidate for that as well.

Obviously, tasks that are amenable to some type of decomposition. So if you want to look through the entire, I don't know, the whole tax code as an example and try and find loopholes or something, you can't obviously put all of that into context at once.

You could use an LLM to crunch through all of that and iteratively explore and use sub-agents to explore interesting areas of the tax code, bring back those sections, and then reason over that. And then just generally for longer horizon sessions.

And when you want to skip it, of course, it'd be something that fits in context. You want something that's low latency or the model itself is as strong of a coder. And our friend Raymond here did some great performance testing on the long chain of thought benchmark.

I'll leave this link as a lead behind after, but just to give you a sense of how well it performs on some of these tasks. It's a meaningful jump overall from 2.6 to 45.4% accuracy on many of these tasks.

And you can see it performs really well on things that are amenable to code, so logic puzzles and chess and chemistry and things like that, where it can dynamically write code, bring in only the relevant part of the context, compute that, and then return the result, where the main model is really just harvesting the results from the sub-LMs instead of trying to do that by itself.

I put together a few just super simple examples. I mean, these are kind of somewhat unfair, I suppose, to the base model. But it makes the point that there are certain tasks that base models just aren't really fit to do themselves because they have to attend all these different tokens at once in the context window, where you need or want to use some type of coding approach to that.

So in this random example, summing 12 numbers that are buried across 30,000 tokens, the LLM trying to figure all that out by itself and give you the answer isn't always going to work as well as something that you can write regex for or something similar.

And then the same sort of thing, particularly for data frames, and we'll walk through a brief example here, where because the LLM can interact with the data frame within the REPL, it just has a much better understanding of the content and can iterate through that much more quickly than having to pass tool calls back and forth in terms of JSON strings and that sort of thing.

And then I threw this in there in terms of running the same experiments with a coding agent. Now, I didn't look into this too deeply. There's probably some unfair math going on here. But you can see that it was totally bloated in terms of the way that cloud code

tried to solve these tasks. So there's more work to be done there, of course, in terms of running experiments to compare base models versus RLMs versus something like a coding agent. But for certain tasks, for production workloads, my sense is you probably don't want to just do cloud-p your prompt and hope for a good result.

You want more of a structured approach to your inputs, your outputs, and you want a defined pipeline for doing so, which reduces your cost, reduces your complexity, reduces your bloat, all that sort of thing where RLMs can shine.

So in the real world, there are a bunch of different open-source libraries that implement RLMs at some level. Some of them are more RLM-focused, like a predict RLM would be a good example of that, versus others are kind of just integrating it into the broader approach or the broader framework.

DSPY, obviously. There's ACKS, which is really interesting work that's being done there. Predict RLM is more focused on knowledge work, so it works with spreadsheets and PDFs and that sort of thing. And then FAST RLM. And then there's a tweet yesterday from this guy, Sam Hogan, who runs inference.net.

He's using an RLM to basically run and extract insights from your particular production workload traces so that they can see what makes sense to defer off to something like a GLM 5.2 and do that iteratively and automatically as your traffic goes through.

So point being, you don't have to worry about context engineering. You can kind of just throw the RLM at it and have it figure it out. I only have five minutes left, so we won't go through this whole example.

And I'll skip to some of the traces because that's probably the most interesting. But this is all you would really need to do in terms of a simple, in this case, it's like a cohort retention analysis, something that you might give to a data scientist.

But this concept of applying an RLM to a complex data structure like a data frame becomes very easy to do. This is all the code you need to do it, where I'm feeding in three different data frames. I'm saying, these are the sorts of things you need to look for.

These are the output types that I want. And then just let the RLM go on it. And I'll show you some of the traces. And so it has its own REPL where it can interact with those data frames.

And you can see it reasoning through, OK, first I need to do this. It's writing the code. And because it's living in the REPL with the data frame, you don't have this additional bloat of the tool calls back and forth.

It's actually interacting directly with the data frame as if it was typing in its own Jupyter notebook. And there's significant advantages for doing so. And so you can see the sorts of outputs that it gets as a result.

And it, by itself, will iterate. And in this case, it didn't, but it has the option to defer to sub-LMs to do, OK, now I have this big whatever, this big subset of the data. Sub-LM, go off and do this analysis.

Give me the result. And it can do that iteratively over time. But the point is that the LM is directly interacting with the data frame in its REPL and kind of iterating through the results. And so this platform compound is RLM and DSPY native.

So it gives you this really nice breakdown of the reasoning. It separates out the code that's being generated. And ultimately, you can see

the final output, which is here, where it's formatting. OK, here are the key findings that I have. Here are the recommendations. And then you have this final submit, which is the final answer that gives you the typed outputs that you had defined up front.

And the key thing here is that the LLM itself is deciding when to stop. So you have a variable of max iteration. So you can decide whether you want it to have a maximum of 10 or 100 or whatever it is.

But it will, by itself, explore the data, understand what needs to happen. And then when it itself is comfortable, it can run submit and give you the final output. Again, being bitter, lesson filled, this will get better over time.

You can kind of just defer everything. And it will figure out what to do. And so the hope would be you don't have to I mean, we're already, whatever this is, 20 lines of code or something. But you can see a world where you can continue to go up levels of abstraction.

As long as you can define what your objective is and what you want it to do, the model will kind of figure out the rest. So we just walked through a bunch of this. But these are the different steps that it took in this example and the code that it wrote.

And then I'll just breeze through a few real-world case studies and where it's actually being used. So I mentioned predict RLM before. This is a company, Trampoline AI, I think it is. They're doing really interesting work in applying RLMs, like I mentioned before, for different pieces of knowledge work, so natively interacting with PDFs and spreadsheets and that sort of thing.

So in this relatively simple example, OK, I have a bunch of I have a directory of invoices that I need to create one consolidated inventory out of. As we all know, invoices can be complicated. They can be very long.

They can kind of be all over the place. To do that today without RLMs or this sort of framework gets very complicated very quickly. I have a lot of battle scars to prove it. But with something like an RLM, you don't need to worry as much about, OK, if I have a 200-page invoice or contract or whatever it is, you can let the RLM just churn through all of that and give you the result instead of having to worry about chunking and embedding maybe and doing all these different strategies to try and get around the context window management that we've all had to do previously.

So it allows you the point there is that you can focus on the abstractions and what you actually want to do instead of the context engineering itself, which I think is a really helpful output of all this. And an interesting tidbit for all the DSPY fans in the room, predict RLM uses DSPY to determine the schemas between the main LM and the sub-LM calls, which I personally think is a nice feature because you have a lot more readability and maintainability.

So you understand exactly what the model is trying to achieve. And the model can be much more precise and prescriptive about the types of data that it's looking for from the sub-LM. And I would want to do some experiments to test this out.

But I would think that this would improve performance for cheaper models, like a Qwen or some of the other ones, because you're specifying the inputs and outputs. And you're enforcing those types coming back. And so you get all the benefits of the RLM being able to churn through all this information.

But you have a lot more of the structure in between where when it's handing off to a sub-LM, it enforces some of those schemas. This is an example from

an AWS engineer from a couple of days ago, where he was just kind of playing around with it. But I just thought it was a nice example of you can kind of just throw arbitrary data at RLMs. In this case, it was a bunch of log data to surface some interesting results.

And he found it useful. There's a project called Halo, which uses an RLM to look at traces of

different agent tasks. And basically, the promise of Halo is that instead of optimizing a particular workflow or DSPY or other framework

structure itself, it's actually iterating on the harness. So it's like a meta-abstraction almost or meta-optimization of the harness itself. And it uses an RLM because, as we all know, traces can get very long and complicated. So the RLM can not only take in all of that context but also leverage the structure of those traces to recommend a better harness.

And then this last one, this is all the code you need. I ran this little experiment. There's an intentionally vulnerable application called it's from OWASP. But basically, it's a web app with a bunch of vulnerabilities in it. This is all the code you need on theright-hand side to run basically an agent to run through whatever it is, 500,000 lines of code to generate some type of security report.

That's just an arbitrary example. But the point is you don't need a lot of context engineering. You don't need a lot of structure around it to achieve what you want to do. And so you can feed in an arbitrary size code base into this and get some type of insights out.

So you can imagine that being applied to other areas as well. So I know I rushed through everything a little bit. But I'm happy to answer questions afterwards. I'll leave you with this. The biggest promise I see here is just imagine a world where the models are actually post-trained and actually RLM-aware.

I think things will get pretty crazy pretty quick when they actually know how to use and kind of take advantage of the RLM methodology natively. So thank you so much for your time.