Executei o renderizador neural do Agent Garten em uma H100 (e construí meu próprio mundo de código)

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: I Ran Agent Garten’s Neural Renderer on an H100 (and Built My Own Code World) · Canal: Prompt Engineer 48 · 15:01 · Assistir no YouTube

Tópicos: Agentes de IA, Inferência e otimização de modelos, Modelos de IA, Modelos multimodais

Resumo

O vídeo apresenta o Agent Garden, projeto que combina mundos definidos por código com um renderizador neural que transforma geometria em imagens em tempo real. O apresentador analisa o relatório e o repo, testa o renderizador em uma H100 e constrói uma versão própria de um mundo de esconde-esconde. O teste confirma a velocidade anunciada, mas revela dificuldades para preservar objetos pequenos e mostra que a imagem de referência precisa corresponder à geometria. A tentativa de reproduzir o aprendizado dos agentes apresenta ganhos modestos e ruidosos, enquanto o código dos mundos e o loop de prática do projeto original ainda não estão disponíveis.

Pontos-chave

No Agent Garden, o estado e as regras do mundo ficam em um programa, enquanto um renderizador neural compartilhado gera as imagens.
O renderizador usa geometria, profundidade, normais de superfície, uma imagem de referência, um prompt e histórico visual para produzir os próximos frames.
O modelo disponibilizado tem 7 bilhões de parâmetros, e o autor mediu cerca de 37,4 frames por segundo em uma H100 com o cache completo.
Os agentes do experimento de esconde-esconde veem imagens, escrevem pequenos programas em Python e registram aprendizados em arquivos de playbook entre rodadas.
A comparação entre rodadas do projeto e episódios do experimento anterior não é equivalente, e os resultados de alguns mundos variam entre as rodadas.
O repo não inclui o checkpoint listado como pendente, o mecanismo de renderização em tempo real nem os mundos de código e o loop de prática dos agentes.
No mundo próprio do apresentador, o renderizador transformou um objeto pequeno em uma caixa em uma referência visual, mas preservou a bola em outra.
O agente baseado em Claude Sonnet teve um ganho modesto em layouts inéditos: a média passou de 47,5 sem playbook para 52,1 com o playbook da quarta rodada.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação do Agent Garden	O vídeo introduz o renderizador neural e a proposta de combinar geometria simples com mundos visualmente ricos.
03:07	Como funciona o renderizador	O apresentador explica a separação entre estado do mundo e pixels, o fluxo de dados e o método de treinamento.
05:10	Agentes e resultados dos experimentos	A transcrição descreve o loop de agentes que aprendem com playbooks e ressalva os limites das comparações e dos resultados.
07:46	O que está disponível e construção do mundo de teste	O vídeo verifica o estado do repo e apresenta o mundo de esconde-esconde criado pelo autor para testar a ideia.
09:20	Teste do renderizador em uma H100	O autor executa o modelo, mede sua velocidade e compara como diferentes imagens de referência afetam a preservação dos objetos.
11:24	Aprendizado do agente no mundo próprio	O apresentador testa agentes que planejam movimentos a partir de imagens e avalia os resultados em layouts inéditos.
13:26	Conclusões, limitações e custo	O autor resume o que conseguiu verificar, o que continua indisponível e os recursos necessários para repetir o teste.

Citações

Um programa guarda o estado e as regras. Um renderizador aprendido, compartilhado entre todos os mundos, produz os pixels. — 03:07

O agente espera o resultado de cada ação antes de escolher a próxima. — 04:38

Gerar um mundo é a parte fácil. A pergunta mais difícil é se esse mundo vale o tempo de um agente. — 08:17

Essa parte é promissora, mas não foi verificada de forma independente. — 13:58

Conceitos e entidades

Agent Garden (repo): Projeto de pesquisa que combina mundos simulados definidos por código com um renderizador neural compartilhado.
Mirus Lab (empresa): Laboratório responsável pelo projeto Agent Garden.
neural renderer (conceito): Renderizador aprendido que converte geometria e outras informações visuais em frames para o agente.
adversarial forcing (conceito): Método de treinamento que usa trajetórias geradas pelo próprio modelo e um discriminador para ajudar a manter a qualidade visual.
NVIDIA Cosmos 3 Nano (modelo): Modelo de vídeo usado como ponto de partida para o renderizador do projeto.
WAN 2.2 (modelo): Autoencoder de vídeo pelo qual passam os frames gerados pelo renderizador.
H100 (modelo): GPU usada para executar o renderizador neural nos testes descritos no vídeo.
Runpod (empresa): Serviço usado para alugar uma H100 para o teste do renderizador.
Claude Sonnet (modelo): Modelo usado pelo apresentador em sua tentativa de aprendizado por rodadas.
Claude Haiku (modelo): Modelo usado nas primeiras tentativas do agente, que optava por ficar parado.

Tradução completa (pt-BR)

00:01 Certo, neste vídeo vamos conhecer o Agent Garden, um projeto de pesquisa do Mirus Lab. Neste momento, cada bloco na tela é geometria simples, apenas formas exportadas por um programa. E agora, é isso que o renderizador neural deles transforma essa geometria em tempo real. São 20 blocos sendo reproduzidos ao mesmo tempo. E vale lembrar que nenhum deles tem texturas nem arte de game engine por trás. Li o relatório, o blog e o repo. Depois, criei uma versão pequena no meu próprio laptop e executei o renderizador disponibilizado em uma H100 alugada. Então, vamos ver

00:32 o que é real, o que ainda não foi lançado e o que aconteceu quando tentei usá-lo. Esta é a página do projeto, e a manchete diz: “O código mantém o mundo; o renderizador o exibe”. Assim, os objetos, as regras e os objetivos de um mundo ficam dentro de um programa executável, e um renderizador neural treinado desenha o que o agent realmente vê. Aqui está o clipe que melhor explica isso. A fileira de cima mostra o que o programa exporta: a vista do plano, as normais de superfície e a profundidade. A fileira de baixo mostra o mesmo jogo renderizado de três maneiras: uma cidade assombrada à noite, uma caverna escura e uma vila de Minecraft

01:02 . O jogo não mudou, só a aparência. E o primeiro grande teste deles é esconde-esconde, o mesmo jogo que a OpenAI usou em 2019. Um escondido, um perseguidor, algumas caixas e uma rampa. Mas, desta vez, os agents são agents de modelos de linguagem que observam imagens e aprendem escrevendo anotações. Eles também fizeram um filme de 2 minutos e 40 segundos. Ele começa em 2019 com o esconde-esconde da OpenAI, no qual as políticas liam estados dos objetos e leituras de sensores, não imagens. Depois, passa para a versão de hoje:

01:33 um agent em um mundo de aparência sofisticada, escrevendo um pouco de Python para agir. No filme, a primeira rodada mostra quatro agents jogando em paralelo, com um arquivo de tarefa que contém as regras, as ações e o orçamento. E a legenda da rodada posterior diz: “Na sexta rodada, o perseguidor já não consegue entrar”. O filme termina com a estrutura: um mundo de código de um lado e um renderizador neural do outro. Depois, o mesmo jogo é renderizado em quatro estilos visuais diferentes, e aparece um braço robótico com uma pipeta para mostrar que mudar o código proporciona novas tarefas e novos ambientes.

02:05 A galeria da página tem 18 mundos, e todos os clipes são divididos da mesma forma: geometria à esquerda, renderização à direita. O primeiro mostra um túnel de formigas, e dá para ver o solo, as raízes e as pequenas pedras surgirem de tubos marrons simples. Depois, uma luta de boxe entre robôs em primeira pessoa e um canhão no convés de um navio, com a explosão. Um caça no convés de um porta-aviões. Uma catapulta lançando uma bola em direção a uma cesta de basquete. Dois braços robóticos jogando xadrez e uma mão cozinhando em uma wok, com uma chama e os vegetais feitos de um conjunto de blocos simples. Um guindaste ao lado de um

02:37 caminhão. Um cavaleiro descendo um caminho de terra. Um braço robótico levantando a tampa de uma panela. Uma pipeta pingando líquido em um frasco. E dois carros de corrida na chuva. Cada um com sua própria câmera. Uma montanha-russa. Um veículo lunar. Um goleiro em um campo de futebol. Uma tocha ao lado de uma fogueira em uma floresta. Um voo de wingsuit sobre montanhas. E uma caminhada em terceira pessoa por um vale nevado. Agora, por que construir dessa maneira? O blog parte de uma troca. Um simulador ou uma game engine oferece um estado explícito.

03:07 Você pode inspecioná-lo, editá-lo e testá-lo. Mas cada nova aparência exige assets 3D e um pipeline de renderização. Portanto, criar mundos novos sai caro. Um modelo de mundo em vídeo é o oposto. As imagens são ricas, mas o estado fica dentro dos quadros gerados e da memória do modelo. Você não pode perguntar onde está a caixa número três, nem editar um objeto sem alterar os demais. O Agent Garden combina uma parte de cada abordagem. Um programa guarda o estado e as regras. Um renderizador treinado, compartilhado por todos os mundos, produz os pixels. Assim, um mundo novo é apenas código novo

03:38 e não exige nenhum trabalho novo com assets. E vale lembrar: é o mesmo renderizador para todos os mundos da galeria. O túnel de formigas, o tabuleiro de xadrez e a wok de cozinha passam todos pelos mesmos pesos; só a geometria e a imagem de referência mudam. Aqui está o ciclo descrito no relatório. O agent envia uma ação. O motor atualiza a cena e exporta a profundidade e as normais de superfície. O renderizador recebe esses dados, além de uma imagem de referência, um prompt de texto e seu próprio histórico visual, e produz os próximos quadros. Esses

04:08 quadros voltam para o agent. O renderizador começa com o modelo de vídeo Nvidia Cosmos 3 nano. O modelo disponibilizado tem 7 bilhões de parâmetros em BF-16. Ele gera blocos de quatro quadros latentes, com quatro etapas de denoising por bloco, e o vídeo passa pelo autoencoder WAN 2.2. A alegação de velocidade está na tabela dois. Um bloco de 16 quadros leva cerca de 439 milissegundos em uma H100. Isso equivale a 36,5 quadros por segundo em 480 por 432, com o cache cheio. E isso

04:38 importa porque o agent espera o resultado de cada ação antes de escolher a próxima. A técnica de treinamento se chama adversarial forcing. Em termos simples, o modelo é treinado com as próprias sequências geradas, e não com um histórico perfeito. Assim, os erros não se acumulam, e um discriminador que já viu vídeos reais impede que as texturas se deteriorem. Nas sequências de 30 segundos, o método anterior gera padrões repetitivos, enquanto o deles preserva os detalhes. Há mais um detalhe que achei interessante. Eles reproduzem a sequência em uma segunda passagem com gradientes e verificam se a reprodução corresponde à sequência original, bit a bit. Assim, uma

05:10 perda nos quadros posteriores pode ensinar o modelo a codificar os anteriores sem manter toda a sequência na memória. Agora, no lado dos agents no esconde-esconde, há um escondido e um perseguidor, em cinco jogos por rodada. E o agent só vê os quadros renderizados em primeira pessoa. Sem coordenadas, sem estado oculto. Ele age escrevendo pequenos programas em Python e, depois de cada rodada, revisa seus jogos e atualiza um manual de estratégias. E os próprios agents não são treinados. São modelos pré-treinados e só melhoram por meio do que anotam entre as rodadas. Portanto, o mesmo ciclo poderia funcionar com

05:41 qualquer modelo capaz de ler uma imagem. O manual de estratégias é uma pasta com pequenos arquivos markdown, uma lição por arquivo. O relatório mostra nomes como “verificar abrigo”, “controle de objetos” e “pouso na rampa”. Uma linha do arquivo RAM diz: “Uma rota pela rampa tem três etapas distintas”. E aqui está o número principal. No self-play da OpenAI, foram necessários cerca de 25 milhões de jogos até os escondidos construírem abrigos e cerca de 100 milhões até os perseguidores usarem rampas. Os agents visuais fizeram a primeira coisa em quatro rodadas e a segunda em 10. Dá para ver os três clipes na página. O

06:13 escondido move um painel para reconstruir sua cobertura. O perseguidor carrega uma rampa até a parede e sobe por ela. E, no terceiro clipe, o perseguidor aproxima a rampa depois de uma subida curta e tenta de novo. Agora, uma observação importante: comparar rodadas com episódios não é uma comparação equivalente, e o próprio relatório diz isso. Uma rodada são cinco jogos nos quais um modelo lê o que aconteceu e escreve anotações. Um episódio é uma execução de uma política treinada. Portanto, é uma afirmação sobre a rapidez com que

06:44 esse ciclo aprende, não uma competição justa. Eles também testam mais quatro mundos, com quatro rodadas cada, e cada cartão da página põe a primeira rodada ao lado da quarta. Um corgi como companheiro, uma ponte de mão única, dois cães pastores conduzindo ovelhas e uma pá-carregadeira em uma pedreira. A pontuação de engajamento do corgi vai de 13 a 19. Na ponte, dois carros precisam trocar de lado, e o tempo até ambos chegarem cai de 71 segundos para 41. A pá-carregadeira chega a 90,9 de 100 na quarta rodada

07:15 com 31 segundos de sobra. Mas veja o desempenho de conduzir ovelhas. Os números na página são 60, depois 90,1, depois 87,6 e, por fim, 88,3. Ele sobe na segunda rodada e depois oscila, e o blog não discute isso. Portanto, considere esses valores uma tendência com ruído, não uma curva regular. Agora vamos ao repo, porque é aqui que é preciso ter cuidado. No momento em que estou gravando, ele tem 153 stars, três forks, oito commits, nenhuma release e uma licença Apache 2.0. O README tem uma lista de verificação

07:46 O código de treinamento do renderer, a inference por streaming, o relatório e o blog foram verificados. Já o checkpoint no Hugging Face não foi verificado, assim como o mecanismo de renderização em tempo real e os code worlds com o loop de prática do agent. Portanto, não dá para executar hoje o experimento de esconde-esconde em si. No Hugging Face, o cartão do modelo lista os pesos do student e a torre de texto congelada, e você precisa do 2.2 VA separadamente. Um ponto de atenção: o campo de licença do modelo diz OpenMDW 1.1, enquanto o código do repo está sob Apache 2.0. Os autores listam as limitações

08:17 eles mesmos. Profundidade e normais não capturam tudo. Um objeto redondo girando parece idêntico em um mapa de profundidade. Geometria densa é redundante. E a frase em que fico pensando é: gerar um mundo é a parte fácil. A questão mais difícil é se o mundo vale o tempo de um agent. Então, quis experimentar a ideia por conta própria. Os code worlds deles não foram lançados. Por isso, escrevi um pequeno. É um pátio de 12x12 em Python puro. Muros externos, uma ou duas barreiras internas, dois painéis empurráveis, um hider vermelho e um seeker azul

08:49 que percorre um circuito de 36 casas ao longo da borda. O arquivo do mundo tem um pequeno ray caster. Para cada frame, ele exporta profundidade métrica e normais no espaço da câmera: as duas coisas que o renderer espera. Não há texturas nem assets. À esquerda está a visualização sem textura, depois as normais e, em seguida, a profundidade em 832x480. A pontuação é simples. De 40 passos, em quantos o seeker não consegue ver você? Muros e painéis bloqueiam a linha de visão. Nos seis layouts que deixei de fora, ficar parado dá cerca de 41%. Uma busca

09:20 que sabe de antemão o caminho do seeker chega a cerca de 95. Essa é a diferença que um agent precisa superar. Então, o renderer de verdade. Meu laptop tem uma RTX 4060 com 8 GB, e só o checkpoint do student tem 7 bilhões de parâmetros. Então, nunca ia caber. Aluguei uma H100 de 80 GB na Runpod por US$ 0,399 por hora, e a sessão toda durou cerca de 34 minutos. A configuração foi: clonar o repo, instalar o Torch 2.9 ou posterior, baixar cerca de 30 GB de pesos do

09:51 Hugging Face e escrever um script que conecta o loop de streaming do README ao conditioner. Os pesos foram carregados em 3,7 segundos no script. O loop é o do README. Codifique o primeiro frame como âncora. Depois, para cada bloco de quatro frames latentes, execute as quatro etapas de denoising com sigma e adicione o bloco limpo ao cache. A profundidade e as normais latentes do próximo bloco podem vir do que quer que seu mecanismo tenha feito nesse meio-tempo. O renderer precisa de um primeiro frame limpo para saber como as coisas são. Gerei esse frame com um modelo de imagem a partir da minha visualização sem textura.

10:22 Depois, passei a ele 81 frames de profundidade e normais. E dá para ver: os muros, as duas barreiras e as caixas estão onde meu código as colocou. Agora estamos em um pátio de pedra numa cidadezinha, e o seeker azul percorre sua volta. Mas olhe para a bola vermelha, o hider. Ela está lá no primeiro segundo, e então o renderer a transforma numa caixa. De acordo com meu registro, a primeira execução é lenta, entre 6 e 8 segundos por bloco, porque os kernels são compilados e os grafos CUDA são capturados.

10:52 Depois disso, com o cache cheio, um bloco de 16 frames leva 43 segundos: isso dá 37,4 frames por segundo, e o relatório indica 36,5. Então, esse número se confirmou na minha execução. Agora, a mesma profundidade e as mesmas normais, mas com uma imagem de referência de Minecraft. E, desta vez, o hider continua sendo uma bola vermelha o tempo todo. Então, na execução com pedra, ele desapareceu; na de Minecraft, foi mantido, apesar de a geometria ser exatamente a mesma. Uma pequena esfera é um pontinho minúsculo em um mapa de profundidade. E o próprio artigo diz que cor e identidade não são totalmente capturadas pela geometria. As latentes de profundidade e normais

11:24 têm apenas 8 por 14 células. No meu primeiro teste, experimentei uma noite de Halloween, e esse foi o resultado mais fraco, porque a imagem que gerei tinha um ângulo de câmera diferente da minha geometria, e o renderer ficou dividido entre os dois. Então, a lição é simples: o frame de referência precisa estar de acordo com a geometria. A última parte é o loop evolutivo. Escrevi a mesma estrutura por rodadas: red task.md, jogar, escrever playbook.mmd, arquivar. O agent é chamado pelo Claude a partir da linha de comando

11:55 e, na minha versão, ele só recebe uma imagem da arena, nunca coordenadas. O agent vê uma imagem da posição inicial e precisa definir de uma vez só todas as 40 jogadas: para cima, para baixo, para a esquerda, para a direita ou ficar parado. Não há correção durante a partida. A pontuação só chega no final, então tudo o que ele aprende precisa vir das notas que escreve entre as rodadas. Nas minhas primeiras execuções, usei o modelo pequeno Claude Haiku, e ele simplesmente ficou parado. No playbook, dizia para não definir um plano completo de 40 passos até confirmar o mapeamento.

12:25 Esse é um agent cauteloso, mas que não aprende nada. Então, mudei para Claude Sonnet, e os números a partir daqui são desse modelo. Foram quatro rodadas, com quatro partidas cada. As médias das rodadas foram 49,4, depois 60,6, depois 37,5 e, por fim, 50. Portanto, não é uma linha reta. É ruidoso, mas veja o que diz o playbook. Na quarta rodada: para cima significa para cima na tela. Esquerda significa esquerda na tela. O seeker percorre a borda em cerca de 40 passos. Nunca ande mais de quatro passos e fique protegido atrás de um painel logo no começo. Para uma avaliação justa, deixei de fora seis layouts novos que o

12:56 agent nunca tinha visto. Sem playbooks, a média foi 47,5. Com os playbooks da quarta rodada, foi 52,1. Ficar parado dá 40,8, e a busca dá 95. Em três dos seis layouts, o resultado melhorou; em um, ficou igual; e em dois, piorou. Então, esse é um ganho pequeno em que eu não apostaria, e um layout responde pela maior parte dele. Mas o agent realmente anotou fatos sobre o mundo: o mapeamento das direções, a volta do seeker e o que bloqueia a linha de visão, usando apenas imagens e os próprios resultados. Este é o melhor layout: 72,5.

13:26 O hider anda dois passos para cima, três para a direita e dois para baixo, e então fica parado a partir do passo 13. Ele fica escondido em todos os passos, menos um. E esta é a mesma trajetória, com profundidade e normais do meu code world, processada pelo renderer real do Agent Garten. Então, o que eu acho? A ideia de separar o estado dos pixels é elegante, e a alegação de velocidade se confirmou quando medi por conta própria. O renderer é realmente utilizável. Levei uma tarde para conectar

13:58 meu próprio mundo a ele. O que não consegui verificar foi a principal alegação: que os agents evoluem em poucas rodadas. Os code worlds e o loop de prática não foram lançados. Minha pequena versão mostrou apenas um efeito fraco, e os números deles vêm das próprias execuções. Então, essa parte é promissora, mas não foi verificada por alguém de fora. Se você trabalha com agents, o que vale copiar é a estrutura por rodadas, o arquivo de tarefa, as partidas em paralelo, o playbook e um novo começo a partir do arquivo. Se você trabalha com modelos de vídeo, vale ler sobre a reprodução exata e o

14:29 truque do discriminator. E, se você só quer ver o projeto, a página dele tem tudo. E quanto isso me custou? Um pouco mais de US$ 2 em tempo de H100, seis imagens de referência geradas e cerca de 90 chamadas na nuvem. Se quiser experimentar o renderer por conta própria, você precisa de uma GPU com 80 GB. Então, alugue uma por uma hora. Neste vídeo, vimos o que é Agent Garten, o que foi lançado e o que não foi, e como passei meu próprio code world pelo renderer deles. Se tiver interesse, você também pode experimentar no seu próprio sistema e me contar como foi. Os links estão na descrição.

15:01 Vejo você em outro vídeo. Confira o próximo vídeo.

Transcrição original

[00:01] All right, in this video we will see Agent Garden, a research project from Mirus Lab. Right now, every tile on the screen is plain geometry, just shapes that a program exports. And now this is what their neural renderer turns that geometry into in real time. 20 tiles all playing at the same time. And mind you, there are no textures and no game engine art behind any of them. I went through the report, the blog, and the repo. Then I built a small version of it on my own laptop and I ran the released renderer on a rented H100. So let’s go ahead and

[00:32] see what is real, what is not released yet, and what happened when I tried it. This is the project page and the headline is code keeps the world, the renderer shows it. So the objects, the rules, and the goals of a world live inside an executable program and a learned neural renderer draws what the agent actually sees. Here is the clip that explains it best. The top row is what the program exports. The plane view, the surface normals, and the depth. The bottom row is the same game rendered three ways. A haunted night town, a dark cave, and a Minecraft

[01:02] village. The game did not change, only the look changed. And their first big test is hideand-seek. The same game Open AI used back in 2019. A hider, a seeker, a few boxes, and a ramp. But this time, the agents are language model agents that look at pictures and they learn by writing notes. They also made a 2 minute 40cond film. It opens in 2019 with OpenAI’s hideandsek where the policies read object states and sensor readings and not images. Then it jumps to today’s

[01:33] version, an agent in a richl looking world writing a little Python to act. In the film, round one shows four agents playing in parallel with a task file that holds the rules, the actions, and the budget. And the caption on the later round says, “By round six, the seeker can no longer get in.” It closes on the framework, a code world on one side and a neural renderer on the other. Then the same game rendered in four different visual styles and a robot arm with a pipette to show that changing the code gives you new tasks and new environments.

[02:05] The gallery on the page has 18 worlds and every clip is split the same way. Geometry on the left, rendered on the right. This first one is an ant tunnel and you can see the soil, the roots and the small stones appear out of plain brown tubes. Then a robot boxing match from a firstperson view and a cannon on a ship deck with the explosion. A fighter jet on a carrier deck. A catapult shooting a ball toward a basketball hoop. Two robot arms playing chess and a hand cooking in a walk with a flame and the vegetables built from a set of simple blocks. A crane next to a

[02:37] truck. A rider on a horse going down a dirt path. A robot arm lifting the lid off a pan. A pipet dropping liquid into a flask. And two race cars in the rain. Each one from its own camera. A roller coaster. A lunar rover. A goalkeeper on a football pitch. A torch next to a campfire in a forest. A wingsuit flight over mountains. And a third person walk through a snowy valley. Now, why build it this way? The blog starts from a trade-off. A simulator or a game engine gives you explicit state.

[03:07] You can inspect it, edit it, and test it. But every new look needs 3D assets and a rendering pipeline. So, new worlds are expensive. A video world model is the opposite. The pictures are rich, but the state lives inside the generated frames and the model’s memory. You cannot ask it where box number three is, and you cannot edit one object and leave the rest alone. Agent garden takes one half of each. A program holds the state and the rules. A learned renderer shared across all the worlds produces the pixels. So a new world is just new code

[03:38] and there is no new asset work for it. And mind you, it is the same renderer for every world in the gallery. The end tunnel, the chessboard and the cooking pen all go through the same weights and only the geometry and the reference picture change. Here is the loop from the report. The agent sends an action. The engine updates the scene and exports depth and surface normals. The renderer takes those plus a reference image, a text prompt, and its own visual history and produces the next frames. Those

[04:08] frames go back to the agent. The renderer starts from the Nvidia Cosmos 3 nano video model. The release student is 7 billion parameters in BF-16. It generates in blocks of four latent frames, four dnoising steps per block, and the video goes through the WAN 2.2 autoenccoder. The speed claim is in table two. One block of 16 frames takes about 439 milliseconds on one H100. That works out to 36.5 frames per second at 480 by A32 with the cache full. And it

[04:38] matters because the agent waits for the result of each action before it picks the next one. The training idea is called adversarial forcing. In simple words, the model is trained on its own rollouts and not on perfect history. So errors do not pile up and a discriminator that has seen real videos keeps the textures from decaying. In their 30-cond rollouts, the older method gets repetitive patterns and theirs keeps the detail. There is one more detail I found neat. They replay the roll out in a second pass with gradients and they check that the replay matches the original roll out bit for bit. So, a

[05:10] loss on later frames can teach the model how to encode earlier ones without keeping the whole roll out in memory. Now, the agent side in hideand-seek, there is one hider and one seeker five games per round. And the agent only sees the rendered firstperson frames. No coordinates, no hidden state. It acts by writing short Python programs and after each round it reviews its games and updates a playbook. And the agents themselves are not trained. They are pre-trained models and they improve only through what they write down between rounds. So the same loop could run with

[05:41] any model that can read an image. The playbook is a folder of small markdown files, one lesson per file. The report shows names like check shelter, object control, and ramp landing. And one line from the RAM file reads, “A ramp route has three separate milestones.” And here’s the headline number. Openai selfplay needed about 25 million games before hiders built shelters and about 100 million before seekers used ramps. The visual agents did the first one in four rounds and the second in 10. You can see the three clips on the page. The

[06:13] hider moves a panel to rebuild its cover. The seeker carries a ramp to the wall and climbs over. And in the third clip, the seeker moves the ramp closer after a short climb and tries again. Now, one honest thing, rounds against episodes is not a like for like comparison, and the report says so itself. A round is five games where a model reads what happened and writes notes. An episode is one run of a train policy. So, it is a statement about how

[06:44] fast this loop learns and not a fair race. They also try four more worlds, four rounds each, and every card on the page puts round one next to round four. A corgi companion, a one-lane bridge, two sheep dogs hurting sheep, and a wheel loader in a quarry. The corgi engagement score goes from 13 to 19. On the bridge, two cars have to swap ends, and the time until both arrive falls from 71 seconds to 41. The loader reaches 90.9 out of 100 in round four

[07:15] with 31 seconds to spare. Look at hurting though. The numbers on the page are 60, then 90.1, then 87.6, then 88.3. It jumps in round two and then wobbles and the blog does not discuss it. So treat these as a trend with noise, not a clean curve. Now let’s go to the repo because this is where you need to be careful. As I record this, it has 153 stars, three forks, eight commits, no releases, and an Apache 2.0 license. The readme has a checklist

[07:46] checked, training code for the renderer, streaming inference, the report, and the blog. And the checkpoint on hugging phase not checked, the realtime rendering engine, and the code worlds with the agent practice loop. So, the hide-and-seek experiment itself, you cannot run today. On hugging face, the model card lists the student weights and the frozen text tower, and you need the one 2.2 VA separately. One thing to watch, the model’s license field says OpenMDW 1.1, while the repo code is Apache 2.0. The authors list the limits

[08:17] themselves. Depth and normals do not capture everything. A spinning round object looks identical in a depth map. Dense geometry is redundant. And the line I keep thinking about is generating a world is the easy part. The harder question is whether the world is worth an agent’s time. So I wanted to try the idea myself. Their code worlds are not out. So I wrote a small one. It is a 12x 12 courtyard in plain python. Outer walls, one or two inner barriers, two pushable panels, a red hider, and a blue seeker

[08:49] that walks a 36 cell loop around the edge. The world file has a small ray caster. For every frame, it exports metric depth and camera space normals. the two things the renderer expects. There are no textures and no assets. On the left is the untextured view, then the normals, then the depth at 832x480. The score is simple. Out of 40 steps, how many steps can the seeker not see you? Walls and panels block the line of sight. On the six layouts I held out, standing still gives about 41%. A search

[09:20] that knows the seeker’s path ahead of time gets about 95. That is the gap an agent has to close. Then the real renderer. My laptop has an RTX 4060 with 8 GB and the student checkpoint alone is 7 billion parameters. So it was never going to fit. I rented one H180 GB on Runpod at 399 an hour and the whole session was about 34 minutes. Setup was clone the repo, install Torch 2.9 or later, download about 30 GB of weights from

[09:51] hugging face and write one script that connects the readme streaming loop to the conditioner. The weights loaded in 3.7 seconds in the script. The loop is the one from the readme. Encode the first frame as an anchor. Then for every block of four latent frames, run the four sigas den noiseise and commit the clean block to the cache. The depth and normal latence for the next block can come from whatever your engine did in the meantime. The renderer wants one clean first frame so it knows what things look like. I made that with an image model from my untextured view.

[10:22] Then I fed it 81 frames of my depth and normals. And you can see it. The walls, the two barriers, and the crates are where my code put them. Now in a stone courtyard in a small town, and the blue seeker walks its lap. But look at the red ball, the hider. It is there in the first second, and then the renderer turns it into a crate. Timing from my log, the first run is slow between 6 and8 seconds per block because the kernels compile and the CUDA

[10:52] graphs get captured. After that with the cache full a block of 16 frames takes 43 seconds that is 37.4 frames per second and the report says 36.5. So that number held on my run. Now the same depth and normals with a Minecraft reference picture. And this time the hider stays a red ball all the way. So the stone run lost it and the Minecraft run kept it from the exact same geometry. A small sphere is a tiny blob in a depth map. And the paper itself says that color and identity are not fully captured by geometry. The depth and normal latence

[11:24] are only 8 by 14 cells. In my first test, I tried a Halloween night and that one was the weakest because the picture I generated had a different camera angle than my geometry and the renderer was caught between the two. So the lesson is simple. The reference frame has to agree with the geometry. The last part is the evolving loop. I wrote the same round structure. red task.md play write playbook.mmd archive the agent is claude called from

[11:55] the command line and it only gets a picture of the arena never coordinates in my version the agent sees one picture of the starting position and it has to commit all 40 letters at once up down left right or stay there is no correction in the middle of a game the score only arrives at the end so whatever it learns has to come from the nodes it writes between rounds my first runs used the small Claude Haiko model and it just stood still. Its playbook said don’t commit a full 40step plan until the mapping is confirmed.

[12:25] That is a careful agent but it learns nothing. So I switched to Claude Sonet and that is what the numbers from here on are from then four rounds four games each. The round means were 49.4 then 60.6 then 37.5 then 50. So it is not a straight line. It is noisy but look at what the playbook says. By round four up is screen up. Left is screen left. The seeker laps the edge in about 40 steps. Never walk more than four steps and tucked behind a panel early. For a fair check, I held out six new layouts the

[12:56] agent had never seen. Without playbooks, the mean was 47.5. With the round four playbooks, it was 52.1. Standing still gets 40.8, and the search gets 95. Three of the six went up, one stayed the same, and two went down. So, that is a small gain I would not bet on, and one layout carries most of it. But the agent did write down real facts about the world, the direction mapping, the seeker’s lab, and what block sight from nothing but pictures in its own results. This is the best layout, 72.5.

[13:26] The hider walks two steps up, three right, and two down, and then stays from step 13 on. It is hidden for all but one step. And this is that same trajectory, depth, and normals out of my code world through the real agent garden renderer. So, what do I think? The idea of splitting state from pixels is clean and the speed claim held when I measured it myself. The renderer is genuinely usable. It took me an afternoon to wire

[13:58] my own world into it. What I could not check is the main claim that agents evolve in a few rounds. The code worlds and the practice loop are not released. My small version showed only a weak effect and their numbers come from their own runs. So that part is promising but unverified from the outside. If you work on agents, the part to copy is the round structure, the task file, the parallel games, the playbook, and a fresh start from the archive. If you work on video models, the part to read is the exact replay and the

[14:29] discriminator trick. And if you just want to see it, the project page has all of it. And what did it cost me? a bit over $2 of H100 time, six generated reference pictures, and about 90 cloud calls. If you want to try the renderer yourself, you need a GPU with 80 GB. So, rent one for an hour. So, in this video, we have seen what Agent Garten is, what is released, and what is not, and how I fed my own code world into their renderer. If you’re interested, you can go ahead and try this out on your own system as well, and let me know how it goes. The links are in the description.

[15:01] I’ll see you in another one. Check out the next video.