A tese desta página: quando o dado não cabe no prompt, a saída não é resumir é não carregar. O Recursive Language Model inverte a relação: o modelo principal nunca vê o dado, ele escreve código que vê, e delega os pedaços caros a cópias de si mesmo rodando em paralelo. O que ele compra com isso é comprimento coerente de trabalho. O que ele paga é fatura total e tempo de parede. As duas coisas estão medidas aqui, e a página inteira serve para separar uma da outra porque confundi-las é o erro mais comum de quem lê "reduz contexto" como "reduz custo".
As quatro decisões de projeto
Explore cada etapa →
As contas, num só lugar
As 4 contas desta página. Clique em qualquer uma para pular direto para a etapa que a explica.
Honestidade, antes de começar: esta página não roda modelo nenhum nem principal, nem sub-LLM. Ela é sobre andaime, não sobre pesos. O que roda de verdade: o corpus de 6.000 linhas gerado aqui, o REPL (tamanho, fatia, contagem, filtro) operando sobre a string inteira com a saída cortada no teto, a divisão em blocos com sobreposição conferida contra a varredura completa, a contabilidade de tokens dos dois caminhos, o Monte Carlo da cópia literal, a conta de ponto de virada e o qN do fan-out. O que é declarado e não medido: o "sub-LLM" das etapas 4 e 5 é um contador determinístico e um modelo de erro por caractere um sub-LLM de verdade erraria mais, nunca menos, e é justamente disso que trata a etapa 7. Os resultados experimentais citados na etapa 6 são do artigo da Prime Intellect (jan/2026) sobre o RLM de Alex Zhang (out/2025), e estão marcados como citados em vez de medidos.
A resposta preguiçosa para "o dado é grande" é aumentar a janela. Ela esbarra em quatro problemas diferentes, com a mesma causa e com sintomas que não se parecem: o preço sobe em linha, a computação sobe ao quadrado, a qualidade cai antes do limite, e passando do limite não há degradação há recusa.
Fórmula · o custo de olhar para trás
pares de atenção = n(n+1)/2
Leia assim: cada token olha para si mesmo e para todos os anteriores é o que a máscara causal permite, e a conta é a soma dos primeiros n números. O provedor cobra por token, em linha; o custo de calcular cresce com o quadrado. Dobrar o dado dobra a fatura e quadruplica o trabalho. Quem paga a diferença primeiro é a latência.
O terceiro problema é o único que não tem número aqui: a qualidade cai antes do limite duro. É o efeito que ficou conhecido como context rot a capacidade do modelo diminui conforme o contexto cresce, bem antes de a janela encher. Esta página não mede isso: medir exigiria rodar um modelo. Fica como resultado citado, com a consequência prática que interessa: caber na janela não é o mesmo que funcionar bem nela, e otimizar só para caber é otimizar para a métrica errada. O axioma 6 de Os axiomas operacionais é a versão curta deste parágrafo.
E o quarto, a recusa: passando da janela a API não degrada, ela devolve erro. No artigo da Prime Intellect isso aparece de um jeito curioso e instrutivo nas comparações do Oolong, os prompts mais longos foram recusados para o LLM puro e contados como zero token e zero acerto, o que na prática deu ao LLM uma vantagem estatística: ele só foi avaliado nos problemas que cabiam, que são justamente os mais fáceis. É o tipo de detalhe que decide a leitura de um benchmark inteiro.
A inversão cabe em uma frase: o modelo principal não lê o dado ele escreve o código que lê. O dado nasce dentro de um REPL Python persistente, como uma variável que o modelo sabe que existe e não consegue ver. Para tocar nela, ele precisa emitir código; e o que volta para a janela é só o que aquele código imprimiu, cortado num teto.
O diagrama acima é o do artigo, refeito em HTML. Nada ali é imagem: cada bloco é um elemento, e é por isso que ele traduz junto com a página, acende conforme a fase, cabe no celular e continua legível em qualquer zoom. O original é o rlm.png do post da Prime Intellect; a fidelidade que importa é a do fluxo contexto do modelo à esquerda, REPL no meio, sub-LLMs em paralelo à direita, e a resposta final saindo de uma variável.
a variável de resposta, e o teto
# O modelo nunca viu `dados`. Ele sabe que a variável existe,# sabe o tipo, e é só isso para ver qualquer coisa, precisa imprimir.print(len(dados)) # 287.412 → 3 tokens na janela# Dividir e delegar: cada pedaço vira um prompt de sub-LLM.# llm_batch dispara todos em paralelo e devolve as respostas em ordem.
blocos = [dados[i:i+1200] for i inrange(0, len(dados), 1000)]
respostas = llm_batch([f"Conte as ocorrências em:\n{b}"for b in blocos])
# A agregação acontece em Python, não no modelo: soma não alucina.
total = sum(int(r) for r in respostas)
# A resposta mora numa variável. Escrever nela NÃO encerra nada;# o turno continua até `ready` virar True, e até lá dá para corrigir.
answer["content"] = str(total)
print(answer["content"]) # conferir antes de fechar
answer["ready"] = True
# Do lado de fora, o ambiente monta o sandbox antes do primeiro turno.# Estes quatro pontos são o contrato inteiro do andaime.
answer = {"content": "", "ready": False} # 1 · resposta por variável
REPL_MAX_OUTPUT_CHARS = 8192# 2 · teto da saída por turno
REPL_TIMEOUT_SECONDS = 120# 3 · e um relógio por chamada# 4 · ferramenta é do sub-LLM, não do principal. O texto verboso# (página web, PDF, log) morre aqui fora e volta resumido.
sandbox.expose(tools=[search, open_url], to="sub_llm")
sandbox.expose(tools=[], to="main")
# O dado entra como variável, nunca como prompt.
sandbox.put("dados", arquivo.read())
O corpus abaixo existe de verdade nesta página: 6.000 linhas de um log de sessão, geradas aqui com um gerador determinístico. Os comandos rodam sobre a string inteira não há simulação. O que a etapa mostra é a distância entre o que o comando produziu e o que o modelo chegou a ver.
Rode um comando no REPL
Saída do REPL
O teto não é detalhe de implementação é o que segura o desenho inteiro. Sem ele, o caminho mais curto para o modelo é print(dados), o dado inteiro entra na janela e o REPL vira um jeito caro e lento de fazer exatamente o que se fazia antes. Com ele, imprimir tudo deixa de ser uma opção e o modelo é obrigado a usar Python para filtrar, contar e agregar. É uma restrição que produz a competência que se queria o mesmo truque de projeto que faz um teste automatizado ensinar a escrever código testável.
Repare no que acabou de acontecer com o comando de contar: a resposta certa entrou na janela em três ou quatro caracteres, e a conta foi feita por Python, não por um modelo. Soma não alucina, len() não tem temperatura e expressão regular não tem viés de posição. Metade do valor prático deste andaime está aí, e não nos sub-LLMs: a parte determinística da tarefa saiu do modelo. O artigo mede isso num caso extremo no subconjunto do Oolong com rótulo, o RLM resolveu tudo com expressão regular, sem chamar nenhum sub-LLM, e acertou em qualquer comprimento de contexto.
A pergunta é uma contagem sobre o corpus inteiro o tipo de tarefa em que o RLM deveria brilhar. O caminho do LLM é um prompt gigante; o do RLM é dividir em blocos, mandar cada um para um sub-LLM e somar. A divisão erra de dois jeitos opostos, e os dois estão medidos abaixo, com o sub-LLM perfeito.
A pergunta
Onde os tokens foram parar
modelo principalsub-LLMs
O "sub-LLM" desta etapa é um contador determinístico escrito em JavaScript: ele acha todas as ocorrências do padrão no bloco que recebeu, sem errar nenhuma. É de propósito, e é o que dá força ao resultado mesmo com o sub-LLM perfeito, dois dos três caminhos já devolvem a resposta errada. O erro não é do modelo: é da divisão. Um sub-LLM de verdade erraria por cima disso, e a etapa 7 mostra o que acontece com a soma quando ele erra.
a diferença são três linhas
# Este é o código que quase todo mundo escreve na primeira vez.# Ele está errado das duas maneiras, e nenhuma delas dá erro.
blocos = [dados[i:i+C] for i inrange(0, len(dados), C - O)]
respostas = llm_batch([PROMPT + b for b in blocos])
# O = 0 → o que cai em cima da fronteira some# O > 0 → o que cai na faixa repetida conta duas vezes
total = sum(int(r) for r in respostas)
# A correção não é uma constante melhor: é parar de contar# e passar a IDENTIFICAR cada ocorrência pela posição global.
inicios = range(0, len(dados), C - O)
blocos = [(i, dados[i:i+C]) for i in inicios]
# O sub-LLM devolve OFFSETS dentro do bloco, não um número.# Pedir posição em vez de contagem é o que torna a soma auditável.
respostas = llm_batch([PROMPT + b for _, b in blocos])
achados = set()
for (inicio, _), r inzip(blocos, respostas):
for off inparse_offsets(r):
achados.add(inicio + off) # posição no documento inteiro
total = len(achados) # a sobreposição deixa de importar
A sobreposição é o conserto óbvio, e ela sozinha piora a resposta. Sem sobreposição perde-se o que cai em cima de uma fronteira; com sobreposição isso volta, mas tudo que está na faixa repetida é contado duas vezes e a soma passa a errar para cima, que é o erro mais perigoso dos dois, porque parece um número plausível. O conserto de verdade não é uma constante melhor: é guardar a posição global de cada ocorrência e deduplicar por ela. Vale para contagem, para extração de entidade e para qualquer agregação sobre texto dividido e é a mesma conversa da etapa de fragmentação do verbatim-copy, no artigo, onde a divisão fina prejudica o LLM puro muito mais do que o RLM.
No RLM a resposta não é o texto gerado: é o conteúdo de answer["content"], que o modelo reescreve quantas vezes quiser antes de marcar answer["ready"] = True. Isso transforma uma tacada só em um ciclo escrever, imprimir, comparar, corrigir. A simulação abaixo mostra quando esse ciclo ajuda e quando ele é teatro.
O modelo de erro é declarado, não medido: cada caractere tem probabilidade p de sair errado, independente dos outros, e cada correção tem probabilidade 4p de introduzir um erro novo a mão que conserta também erra. Um LLM de verdade não erra assim: ele erra em blocos, nas fronteiras de token, e muito mais nos trechos sem redundância, que é por que UUID é o pior caso e prosa é o melhor. O que a simulação demonstra é a mecânica do ciclo não a taxa de nenhum modelo.
A condição para o ciclo valer a pena é uma só: a conferência precisa ser mais confiável que a escrita. Quando ela é comparar duas strings é mais fácil que reproduzir uma cada rodada derruba os erros restantes pelo fator de detecção, e três rodadas resolvem quase tudo. Quando não é, o ciclo só gasta turno e ainda pode introduzir erro. É o mesmo critério que decide se vale um passo de auto-revisão em qualquer pipeline de LLM, e a pergunta a fazer é sempre a mesma: a verificação é mais barata e mais confiável que a geração? Se a resposta for não, o ciclo é teatro caro.
Esta é a frase que a maior parte das leituras erra: o RLM não economiza tokens. Ele economiza a janela do modelo principal, que é outra coisa. O dado é lido inteiro de um jeito ou de outro, e o andaime ainda cobra um pedágio fixo por turno o que cria um tamanho de dado abaixo do qual ele é só despesa.
E agora a coluna da direita, que é a que ninguém olha: o total do RLM é sempre maior. O dado é lido inteiro nos dois caminhos; no RLM ele é lido em pedaços, por sub-LLMs, com a instrução repetida em cada chamada e um raciocínio novo em cada uma. O RLM troca fatura por comprimento de janela, e essa troca só compensa quando a tarefa não caberia de jeito nenhum, ou quando o que se quer é trabalho longo e coerente. Um painel de custo que soma só a chamada principal vai mostrar queda justo quando o gasto subiu e é assim que se aprova por engano uma arquitetura que triplicou a conta.
O que o artigo mede (resultado citado, não medido aqui)
O caso do math-python é o mais instrutivo da lista, porque ali o RLM permite exatamente o mesmo comportamento do LLM puro os dois têm Python, as mesmas bibliotecas, o mesmo problema e mesmo assim o resultado piora. Não há nada que o andaime impeça; há complexidade que ele adiciona, e o modelo gasta raciocínio administrando o andaime em vez de resolver a conta. É o argumento mais forte a favor da tese do próprio artigo: andaime não treinado é imposto, e o ganho só aparece quando o modelo aprende a usá-lo. Enquanto isso não acontece, a regra prática é a curva acima dado grande, RLM; dado pequeno, o caminho simples.
Cem sub-LLMs não são um modelo cem vezes melhor: são cem sorteios independentes. E quando a agregação é uma soma, ela só está certa se todos os cem estiverem. Esta é a conta que decide se o desenho escala ou se ele só funciona na demonstração.
As armadilhas, na ordem em que aparecem
A primeira da lista é a que menos aparece nas discussões e mais me preocupa em produção. O desenho do RLM concentra as ferramentas no sub-LLM busca, abrir URL, o que a tarefa exigir e ao mesmo tempo alimenta esse sub-LLM com pedaços do dado de entrada, que quase sempre veio de fora: o PDF que o cliente subiu, a página que a busca abriu, o log de um terceiro. É o caminho mais curto que existe entre o texto de alguém e uma ferramenta sua. A mitigação é a de sempre e vale repetir: ferramenta com escopo mínimo, saída do sub-LLM tratada como dado não confiável (esquema estrito, nunca instrução), e nada de ação com efeito colateral disparada por sub-LLM sem uma conferência do lado de fora.
E a fronteira que o próprio artigo declara: RLM e atenção eficiente não competem. Atenção melhor adia o context rot é uma solução do lado do modelo, aprendida no pré-treino. Dobramento de contexto é uma solução do lado da tarefa, aprendida pelo resultado. Uma empurra o limite do que cabe; a outra decide o que vale a pena colocar lá dentro. Quem escolhe uma das duas está resolvendo metade do problema, e a metade que sobra é a que aparece em produção.
As sete, de um relance
No fim: o RLM é uma aposta explícita de que contexto é recurso escasso e vale gastar computação para administrá-lo. A aposta é boa quando o dado é grande de verdade, quando a tarefa é longa e quando parte dela é determinística e é ruim quando o dado cabe, porque aí o andaime só cobra. O que ele muda de definitivo é a pergunta de projeto: em vez de "como faço isto caber no prompt", passa a ser "o que precisa mesmo estar no prompt, e o que pode ficar do lado de fora sendo tocado por código?". Essa pergunta sobrevive à moda: ela continua valendo quando a janela for de dez milhões de tokens, porque o problema nunca foi o tamanho da janela foi o que a gente insiste em colocar dentro dela.