Tiny Recursive Models on ARC-AGI-1

Our approach to a "no text-value" TRM is to speak in its language. Turning our words into a byte grid will be our first trial at this (probably will not be our last).

Updated flowchart and notes:

Long story short: TRM does NOT take raw text as input.

After going through a better detailed implementation flowchart, we see where the TRM is used and dig into our new roadblock.

Question: How can we update the TRM to comprehend text input and not just pixel-to-pixel play?

The TRM was an "update" from the HRM (hierarchical recursive model), which was a model with smaller models and more parameters within.

We go over:

1. Why the HRM wasn't the method

2. What the TRM fixes and why it's better

3. The difference in both thought-chains

Following the 4 factors we needed to understand, here are the points we tackled:

1. Ensemble contribution

2. Puzzle-ID dependence

3. Recursion trajectory analysis

4. Training dynamics under augmentation

Using a "did - found - conclusion" model, I go over how we approached each why to find its how and what.

Here are the 4 key factors we researched.

1. Role of test-time compute

2. Dependence on puzzle ID

3. Effective depth of recursion

4. Impact of augmentation on the solution distribution

We go over the questions raised from each of these factors, acknowledging what we need to eventually know to understand the behavior of the model down to the pin.

Key term: Tokenization

→ LLM tokenization is the process of breaking text into smaller units called tokens, such as words, subwords, or characters, so a language model can convert them into numbers and process them.

THIS is what makes LLMs expensive. THIS is the issue I want to tackle.

The average engineer will use about $250k worth of tokens in a year, so let's go over a scenario of a QA system, and how we can visually picture this model being used to reduce tokenization.

All in all: TRM eliminates irrelevant garbage → reduces unnecessary tokenization → corporations save money → everyone happy.

1. x (question) enters the model; y (answer) and z (reasoning) are output from the recursion.

2. The near-completed answer is obtained after the first recursion (see the visual below).

→ In recursion, context and info building are solved: outputs y and z.

→ y and z ferment in the block and the final output is released.

→ Converted from vector to wording.

We know what it does, we don't know how.

The model outputting an amazing Pass@1 (meaning the best one) result is enough to prove the potential exists and the dreams can live.

How was it tested? In a nutshell, we eliminated certain aspects of the puzzle (puzzle ID) and saw how the algorithm behaved.

Failed: the puzzle ID mattered, therefore important.

Succeeded: worked without puzzle ID, therefore doesn't matter. Test beyond: how much more did it struggle to succeed.

As we narrow down what matters to it, we narrow down to understanding the behavior of the algorithm.

Paper link: https://arxiv.org/abs/2512.11847v1

Cheaper, faster, and more accurate. Got your attention?

Here's the research paper link: https://arxiv.org/abs/2512.11847v1

Tiny recursive models are small models (millions, not billions, of parameters) that refine their internal state recursively instead of generating token-by-token like LLMs.

Why should it matter to you? I see a plethora of possibilities and potential that this model and concept can bring to both your projects and even corporate workflows for my fellow recruiters (I hope you've made it this far).

But before we get into that, I do want to walk through the research, so I highly recommend you read just the abstract of the paper (first paragraph) and get a little more familiar with it to follow along with the next video.

Page 12 has the open-sourced GitHub repository if you're impatient and want to see the code and tests for yourself.