Чем больше токенов в контексте, тем хуже модель рассуждает над каждым из них. Фундаментальное свойство “attention”, общее для всех моделей. На 1M токенах даже опус 4.6 перестаёт быть полезен.

Идея RLM: использовать контекст как внешнюю среду, а не место куда надо всё запихать.

Весь длинный контекст хранится как переменная в персистентном Python (или каком-то другом) REPL. Модель его не видит, пишет код чтобы с ним взаимодействовать: читает кусками, строит индексы, делает срезы. Как разработчик с SQL базой: смотришь на данные через запросы, не грузишь всю базу в память.

Задача: найти паттерн ошибок в JSON-логе на 50MB (~10M токенов, 2.8M событий).

Шаг Обычный агент (read_file) — что в контексте Токены RLM — что в контексте Токены
Системный промпт "You are a helpful assistant..." 50 "Your context: 52 428 800 chars. Available: context, llm_query(), FINAL()" 70
Запрос "Найди паттерн ошибок в логах" 60 "Найди паттерн ошибок в логах" 80
Чтение файла Tool call read_file("app.log") → {"level":"error","msg":"timeout","svc":"auth"... (середина JSON-объекта, структура сломана) 560 >>> import json; data = json.loads(context) → [stdout: 31 chars · "Loaded: 2 847 291 events"] 110
Агрегация ещё вызовы read_file с разными офсетами — фрагменты без связи, агрегировать нельзя 1060 >>> errors = [e for e in data if e['level']=='error']; print(len(errors), errors[0]) → [stdout: 61 chars · "18 442 errors · {'ts':'2026-01-14T03:12:01','svc':'auth'..."] 160
Группировка по сервису (нет единого представления данных — файл читается кусками) — >>> from collections import Counter; print(Counter(e['svc'] for e in errors).most_common(5)) → [stdout: 78 chars · "[('auth', 9821), ('payments', 5302)...]"] 210

Основной смысл на который тут стоит обратить внимание — слева всё копится в контексте в надежде на то что attention сможет сделать агрегацию во время инференса. Справа же нагрузка на attention сильно ниже тк контекст следит за переменными/синтаксисом питона/etc, не за сырыми данными. Если в контексте лежат структурированные данные — JSON, CSV, XML — модель может распарсить их питоном и делать с ними что угодно: фильтровать, агрегировать, трансформировать. Точечный поиск по всему объёму данных — один вызов string.find()!

И, конеш, как и для любого нового концепта, есть впечатляющие бенчмарки:

BrowseComp+ (1000 документов, 6–11M токенов — ответ на каждый вопрос разбросан по нескольким из них, нужно сшить):

  • RAG + BM25: 51%
  • Summary agent: 70.5%
  • RLM (GPT-5 корень + GPT-5 mini субвызовы): 91.3%

OOLONG-Pairs (нужно обработать все пары записей в документе и агрегировать результат — квадратичная по сложности задача):

  • Чистый GPT-5: <0.1%
  • RLM с GPT-5: 58%

Claude Code же уже так делает?

“Так это ж просто субагенты, мы так уже делаем.. мой клодкод всё это умеет… он скрипты внутри запускает!”. И частично это справедливо — паттерн не новый и результаты похожи. Но есть три конкретных отличия которые важны.

Посмотрим на то, куда физически попадают данные в каждом случае.

Наивный агент: read_file → текст файла в контексте оркестратора. Вместе с system prompt и километрами обсуждений/вызовов инструментов/etc.

Claude Code с субагентами: файл читается внутри изолированного субагента, в контекст оркестратора идёт только резюме. Лучше — но резюме всё равно токены в истории. И с каждым следующим субагентом их становится больше. К тому же данную фичу клод использует достаточно…консервативно. И скорость потребления токенов ВЗЛЕТАЕТ так, что недельную “норму” можно оприходовать за два “продуктивных” вечера.

В RLM же мы видим такую картину: файл → Python-переменная в REPL. Ни в чьём контексте. В системном промпте модели написано только: “у тебя есть переменная context, используй llm_query() для субзапросов, FINAL() для финального ответа”. Модель пишет код — data[100000:150000], Counter(e['svc'] for e in errors) — получает маленький stdout. Только он идёт в историю. Сам файл остался переменной. Это именно то что показано в таблице выше: оркестратор на 10M токенов данных держит в контексте ~210 токенов.

Рекурсия происходит внутри кода, не в истории сообщений. Вызов агента в Claude Code — событие в диалоге, оно логируется. В RLM рекурсия — Python-функция в REPL:

>>> auth_errors = [e for e in data if e['svc'] == 'auth'][:500]
>>> pattern = llm_query(auth_errors, "найди паттерн ошибок")
[stdout: 43 chars · "timeout на /api/refresh после 2AM UTC"]

Субагент получил 500 записей, думал сколько угодно токенов — оркестратор увидел одну строку. pattern — просто переменная.

Авторы в статьях разграничивают: агент — это автономия, пространство действий, цикл наблюдения. RLM — это REPL для управления длинным контекстом. В общем, RLM может быть внутри агента, но текущие агенты != RLM.

Почему этого нет в продакшне

Нам рассказывают что в Anthropic уже кодят агенты и решают любые задачки, время между теорией и продом сокращается в разы. Так почему ж мы этого не видим?

Вышел независимый reproduction paper (“Think, But Don’t Overthink”) и несколько практических тестов на DeepSeek v3.2 / Kimi K2.

Глубина рекурсии > 1 ломает всё. Kimi K2, который сам по себе делает 86.6% на задачах с длинным контекстом, под RLM depth=1 (корневая модель вызывает субагента — один уровень) падает до 60%, при depth=2 (субагент сам запускает ещё субагента — два уровня вложенности) — до 55%. RLM сделал сильную модель хуже. DeepSeek на depth=2 тоже деградирует: 42% → 34%. Теоретическая красота истинной рекурсии разбивается о то что модели в ней не умеют надёжно работать(( ну по крайней мере ПОКА что не умеют

Три задокументированных сценария отказа: параметрическая галлюцинация (модель игнорирует контекст и отвечает из обучающих весов), потеря структуры вывода (возвращает сырой Python вместо ответа), бесконечные циклы псевдоверификации (без финального ответа). Задержка при двух уровнях рекурсии вырастает с 3.6 секунды до 344 секунд, абсолютная руина

Работает только на моделях с сильным кодингом. Модель должна сама написать корректный Python для неизвестной структуры данных — слабее базовый уровень кодинга, хуже результат( Конечно там можно добавить хакерские вещи типа проверки кода и итерации пока не получим корректный вариант… Но, кмк, основная идея в том что ЛЛМка достаточно умна чтобы ваншотить код а не сидеть его дебажить итерационно.

Помимо теоретической есть инфраструктурная сложность: постоянная сессия Python REPL с доступом к данным пользователя — это переписывать весь текущий sandbox, совсем другой мониторинг и точки отказа. Стандартная инфраструктура не хранит состояние (писал об этом в прошлых постах) итд

Будет ли в эксплуатации? Вероятнее всего, да. Теория вышла в декабре 2025, воспроизводящая работа — в марте 2026. Цикл от “интересный препринт” до “в работе” обычно год+. Сценарии отказов имеются — но, понятно, что это не SOTA модели и в целом они не были натренированы на существование внутри REPLa.

Источники - [Recursive Language Models — arXiv (2025)](https://arxiv.org/abs/2512.24601) - [Think, But Don't Overthink: Reproducing Recursive Language Models — arXiv (2026)](https://arxiv.org/abs/2603.02615)