Colocamos Claude Code e Codex para competir com pesquisadores humanos — Elie Bakouch, Prime Intellect

Autoria: AI Engineer · 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: We Let Claude Code and Codex Race Human Researchers — Elie Bakouch, Prime Intellect · Canal: AI Engineer · 18:54 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Claude Code, Modelos de IA

Resumo

Elie Bakouch apresenta experimentos da Prime Intellect para avaliar se modelos de IA conseguem realizar pesquisa automatizada, usando competições de otimização de treinamento como ambiente de teste. A equipe deixou Codex e Claude Code explorar um cluster e comparar suas soluções com os recordes humanos, observando diferenças de comportamento e resultados. Embora os agentes tenham superado os recordes, Bakouch ressalta que não produziram mecanismos realmente novos: combinaram e aprimoraram métodos existentes. A apresentação termina com propostas para benchmarks mais estruturados e sistemas multiagente que incentivem descobertas, com avaliação humana e testes em escala.

Pontos-chave

A apresentação defende a criação de benchmarks independentes e abertos para medir a capacidade dos modelos de fazer pesquisa automatizada.
Os speedruns de treinamento oferecem objetivos verificáveis, regras claras e recompensas que podem servir tanto para avaliação quanto para treinamento.
A equipe lançou Codex e Claude Code em um cluster para competir no optimizer speedrun e tentar superar recordes humanos.
Codex e Claude Code tiveram padrões diferentes de atividade, uso de memória, subagents, tokens e compactação de contexto.
Os agentes superaram os recordes humanos no experimento, mas não inventaram novos otimizadores ou mecanismos; sobretudo combinaram e aprimoraram métodos existentes.
A proposta de benchmark futuro inclui condições distintas de acesso ao conhecimento: apenas o conhecimento dos pesos do modelo, acesso a artigos do arXiv ou acesso completo, incluindo recordes humanos.
Bakouch sugere sistemas multiagente com geradores de ideias, execução de experimentos, juízes e participação humana para orientar a descoberta.
A equipe também trabalha em sandboxing com GPU, agentes próprios e ferramentas para treinar e avaliar modelos em diferentes ambientes.

Capítulos

Início	Capítulo	Resumo
00:12	Por que avaliar pesquisa automatizada	Bakouch explica a importância de medir as capacidades de pesquisa dos modelos e de fazê-lo com benchmarks abertos e independentes.
02:59	Speedruns como ambiente de pesquisa	A apresentação descreve os speedruns de nanoGPT e de otimização, seus objetivos e seu potencial para avaliação, treinamento e descoberta.
05:36	Codex e Claude Code competem com pesquisadores	A equipe executa os dois agentes em um cluster, explica as regras de submissão de experimentos e relata diferenças no comportamento deles.
10:04	Resultados e limites dos agentes	Os agentes superam os recordes humanos, mas os resultados apresentados não demonstram a criação de novos otimizadores ou mecanismos.
11:39	Um benchmark mais estruturado	Bakouch apresenta planos para comparar modelos em condições controladas, com diferentes níveis de acesso a conhecimento e registros humanos.
14:24	Da avaliação à descoberta	A proposta combina agentes geradores, experimentos, juízes, testes em escala e orientação humana para favorecer novas descobertas.
17:12	Infraestrutura e próximos passos	A equipe descreve speedruns diversos, sandboxing com GPU e ferramentas para treinar e avaliar modelos em diferentes ambientes.

Citações

Não temos um benchmark para quantificar se isso é verdade. — 00:45

A recompensa é positiva se o modelo superar o recorde do speedrun. — 04:35

Não surgiu desses modelos nenhum otimizador ou mecanismo realmente novo. — 14:58

Os humanos são muito úteis para avaliar as ideias dos agentes e orientá-los na direção certa. — 16:39

É muito importante que parte desse autoaperfeiçoamento recursivo aconteça de forma aberta. — 18:54

Conceitos e entidades

recursive self-improvement (RSI) (conceito): Ideia de modelos treinarem ou aprimorarem modelos com pouca ou nenhuma intervenção humana.
speedrun (conceito): Competição com objetivo e regras definidos, como alcançar uma métrica de treinamento no menor tempo ou encontrar um otimizador eficaz.
optimizer speedrun (conceito): Modalidade em que os participantes podem alterar parâmetros relacionados ao otimizador, sem modificar livremente a arquitetura do modelo.
Codex (modelo): Modelo usado no experimento para propor e testar soluções no cluster.
Claude Code (ferramenta): Ferramenta usada no experimento para explorar soluções e competir no optimizer speedrun.
Prime Intellect (empresa): Empresa onde Elie Bakouch trabalha como engenheiro de pesquisa e que conduziu os experimentos apresentados.
Elie Bakouch (pessoa): Engenheiro de pesquisa da Prime Intellect e apresentador do trabalho sobre pesquisa automatizada por IA.
nanoGPT (repo): Repositório associado a um speedrun de treinamento de GPT-2, cuja comunidade reduziu significativamente o tempo necessário para atingir a métrica-alvo.
arXiv (ferramenta): Repositório de artigos científicos mencionado como uma possível fonte de conhecimento para os modelos no benchmark.

Tradução completa (pt-BR)

00:12 Oi, olá a todos. Obrigado por estarem aqui. Estou muito feliz hoje por falar sobre pesquisa automatizada com IA e, especialmente, sobre o desempenho de todos esses modelos de fronteira em tarefas de pesquisa automatizada com IA. Eu sou Elie. Trabalhei na Prime Intellect como engenheiro de pesquisa e vou apresentar nosso trabalho sobre esse assunto. Primeiro, quero explicar um pouco por que estamos fazendo isso e por que achamos tão importante fazê-lo abertamente.

00:45 Primeiro, acho que todos concordamos que já ouvimos grandes laboratórios dizerem que essa coisa ruim chamada autoaperfeiçoamento recursivo está chegando muito em breve. Autoaperfeiçoamento recursivo é quando modelos treinam modelos sem intervenção humana, basicamente. Mas não temos nenhum benchmark para quantificar se isso é verdade ou não, certo? E, menos ainda, não temos um benchmark de terceiros, feito por quem não são grandes laboratórios, para ver

01:21 se isso está prestes a acontecer ou não. A outra questão é que achamos muito importante entender como esses modelos fazem pesquisa, porque acreditamos que muitas das pesquisas científicas dos próximos anos também serão baseadas em ferramentas de IA. Então, é muito importante entender como esses modelos fazem pesquisa, não apenas pesquisa em IA. Por isso, tentamos criar um ambiente para testar as capacidades dos modelos para fazer isso. Então,

01:53 tudo começou com Andre Karpathy, que basicamente se divertiu fazendo um vídeo em que treinou GPT-2 do zero em cerca de 90 minutos. Treinar GPT-2 normalmente leva semanas. Não, há dois anos, acho que levou apenas cerca de 90 minutos. Então, o que significa reproduzir GPT-2 em 90 minutos? Significa que, em 90 minutos, você alcança essa perda-alvo. E foi

02:24 nesse ponto que, ao obter a mesma perda que GPT-2, você considera que seu modelo tem um desempenho mais ou menos equivalente. Depois, a comunidade pegou esse repo, o repo do GitHub, e criou outro chamado nanoGPT, e esse esforço foi liderado por alguém chamado Keller Jordan. O que aconteceu foi que eles reduziram esse tempo de 90 minutos para 45 minutos e, agora, conseguimos treinar um modelo com a perda de validação de GPT-2 em menos de dois

02:59 minutos, o que é sinceramente incrível, e levou cerca de dois anos para chegar a isso. Então, é um benchmark muito forte, no qual muitos pesquisadores muito talentosos fizeram iterações. Decidimos usar esse ambiente de speedrun, que é como um jogo. O objetivo do jogo é alcançar essa perda no menor tempo possível. Então, essa é a nanoGPT1, e você

03:29 quase não tem restrições. A única restrição é que você precisa usar os mesmos dados de validação e de treinamento, certo? Há uma nova speedrun chamada optimizer speedrun, lançada há alguns meses, e ela é um pouco diferente porque você só pode alterar os parâmetros relacionados ao otimizador. Por exemplo, na nanoGPT, você pode alterar a arquitetura, fazer coisas com atenção e tudo mais. Na optimizer speedrun,

04:00 você só pode trocar o Adam por m shampoo ou qualquer que seja seu otimizador favorito. E isso é um pouco mais voltado à pesquisa, porque se trata menos de otimizar o programa para que seja o mais rápido possível e mais de encontrar o melhor método possível, independentemente do tempo que você dedicar ao computador, certo? Então, por que usar speedrun como ambiente para pesquisa automatizada com IA? Primeiro, achamos que é uma boa

04:35 avaliação. Mais adiante, veremos por quê. E esse é o foco principal desta apresentação. Mas também achamos que provavelmente é um bom ambiente de treinamento, porque é uma forma de dar uma recompensa ao modelo. A recompensa é positiva se o modelo vencer a speedrun e superar o último recorde, desculpem, e é zero ou negativa se ele não conseguir. Então, é um bom ambiente para treinar modelos. Também é bastante rápido. Como vocês podem ver, os recordes anteriores eram

05:05 de cerca de 2 minutos na optimizer speedrun. Cada execução leva cerca de 15 a 20 minutos. E as regras são bem claras, basicamente. Também achamos que é um bom ambiente para fazer descobertas, como avanços na nossa pesquisa, porque há regras claras que podem ser verificadas. Então, sim. O que fizemos foi o seguinte: o lançamento foi

05:36 há cerca de dois meses, e havia essa optimizer speedrun. Decidimos competir com a comunidade lançando dois agents de IA: Codex e Claude Code. O Codex era GPT-5.5 com xhigh, e o Claude Code era Opus 4.8 com xhigh. Decidimos deixar os agents livres no nosso cluster e permitir que fizessem iterações. Tivemos V1, V2 e V3; isso significa basicamente que parávamos o agent e depois o reiniciávamos. A V3 aconteceu um ou dois dias antes do lançamento, porque vimos que nossos agents já não tinham o melhor recorde. Então, pensamos: tudo bem, peguem todos os recordes humanos das últimas semanas e tentem melhorá-los. E funcionou. Também temos essa categoria de novidade, cujo objetivo é superar o recorde usando apenas ideias novas. E veremos que isso foi mais complexo para os modelos.

06:07 Então, nosso ambiente de pesquisa é muito simples. Sinceramente, poderíamos simplesmente tê-lo substituído por /go, mas não havia um objetivo SLG na época. Então, criamos nosso próprio goal. É até engraçado termos escolhido o mesmo nome. Tínhamos o goal.md e uma espécie de agents.md que definia as regras. Deixamos o agent propor ideias e, depois, ele podia enviar um job com sbatch para o nosso cluster Slurm. Basicamente, podia enviar jobs para nós que estivessem disponíveis

06:43 mas apenas com uma determinada permissão, o que significa que, se alguém quisesse usar esse nó, o modelo simplesmente cancelaria o job. Isso se chama permissão preemptable. Então, ele mede o resultado, lê os logs de treinamento e decide se é um recorde ou não. Para validar um recorde, é preciso ultrapassar um limiar estatístico, para garantir que não seja apenas uma oscilação da otimização e que não seja algo aleatório, certo? Então, alguns resultados desse experimento. A primeira coisa, que foi sinceramente muito frustrante, é que o Claude Code continuava parando

07:16 a cada nove ou dez horas e basicamente dizia: “Sim, não consigo melhorar o recorde. É difícil demais para mim, não tem como superá-lo.” E eu dizia: “Tudo bem, continue explorando novas direções. Vamos lá, tente de novo por mais dez horas.” Aí ele dizia: “Sim, não consigo superar o recorde”, e assim por diante. Então, durante um terço do tempo, o agent do Claude Code ficava ocioso, porque eu não tinha como monitorá-lo. Já o Codex era totalmente o oposto: trabalhava o tempo todo e

07:52 quase nunca ficava ocioso, nunca fazia perguntas e foi muito impressionante nesse aspecto. Também demos aos modelos a opção de escrever várias coisas no que chamamos de bloco de notas, que é basicamente a memória ativa do modelo. Observamos que o Codex escreve bastante nesse bloco de notas. Então, cada gráfico que vou mostrar é normalizado pelo número de pedidos ativos. Isso não diz respeito apenas ao fato de o Codex trabalhar mais; é um comportamento realmente diferente.

08:26 Como podem ver, ele escreve muito mais nesse bloco de notas, nessa memória, e o formato, não sei, o tom de cada arquivo também era muito diferente. O Claude Code ficava superempolgado por conseguir um novo recorde, com vários emojis e tudo mais. Já o Codex era simplesmente: “Aqui está o que estou fazendo. Aqui está a decisão que tomei. O que vou fazer em seguida.” Era bem robótico, mais ou menos.

08:57 o Codex trabalhando mais, é um comportamento realmente diferente. Então, sim, dá para ver que ele escreve muito mais nesse bloco de rascunho, nessa memória, e o formato de cada arquivo também era muito diferente. Não sei, o tom de cada arquivo era bem diferente: o CL estava superempolgado por conseguir um novo recorde, com vários emojis e coisas assim, enquanto o CEX era simplesmente: “Aqui está o que eu faço, aqui está a decisão que tomo, o que vou fazer em seguida”, de um jeito meio superrobótico.

09:31 Sim, também temos este gráfico em que, basicamente, vimos que o Codex estava criando muito mais subagents do que o Claude. Vimos que o Codex consumiu muito mais tokens do que o Claude. Então, acho que, no total, foram cerca de um bilhão de tokens, mas há, obviamente, esse caching de tokens de entrada, então não é como se fosse um bilhão de tokens de saída. Também vimos que o Codex fez muita compactação, porque só tinha uma context window de cerca de 250 mil tokens, enquanto o Claude só fazia isso…

10:04 uma vez por hora, e o Codex fazia menos de uma vez por hora — quer dizer, uma vez durante toda a execução do Claude, e o Codex fazia isso umas 20 vezes a cada hora. Então, aqui estão os principais resultados. O que este gráfico mostra é que, em branco, vocês veem a progressão do recorde humano; em vermelho, veem o Claude — era para ser

10:37 laranja, mas tudo bem — e, em azul, veem o Codex. E dá para ver que, quase o tempo todo, Claude e Codex superam o recorde humano. O Claude é muito bom no começo, muito, muito rápido para chegar a um resultado muito bom. E uma coisa muito importante é que o modelo pode buscar os recordes humanos a qualquer momento. Foi isso que o Codex fez, foi isso que o Claude fez — desculpem, porque, quando reiniciei, ele basicamente

11:07 buscou o novo recorde humano e o superou. Então, o resultado é que, naquela época, o melhor recorde era de cerca de 2.990 passos, e o superamos por uns 50 ou 60 passos com o Claude, enquanto o Codex ficou uns 20 passos acima. Acho que isso é impressionante e… Então, isso ainda não foi lançado. É algo em que estamos trabalhando

11:39 atualmente. Basicamente, a ideia é que este é um experimento legal de fazer, mas falta estrutura. Se você quiser fazer um benchmark de verdade, precisa usar várias seeds e fazer tudo corretamente, colocando todos os modelos e os harnesses nas mesmas condições, certo? É nisso que estamos trabalhando agora. A ideia é fazer três trilhas diferentes: uma sem nenhum acesso, para realmente

12:11 medir a capacidade dos modelos de fazer pesquisa em IA com base apenas no conhecimento dos pesos do modelo; uma com acesso apenas a artigos do arXiv; e outra com acesso completo. Nessa última, eles também têm acesso ao recorde humano mais recente. Para isso, planejamos fazer tanto a trilha do nanoGPT, que é a original, quanto a speedrun de otimizadores, em que restringimos o otimizador para que ele seja novo. Vou apresentar alguns resultados da

12:45 speedrun de otimizadores. Foi isso que conseguimos. Deixamos o agent iterar por seis dias — quase cinco, digamos — e vimos que Codex, Kimi e Claude são muito eficazes. Quanto ao GLM, essa execução ainda não terminou; o modelo ainda está iterando no cluster agora, mas vemos que o Claude é muito bom nisso mais uma vez. E, surpreendentemente, vemos que o Kimi também é muito competitivo e tem uma espécie de avanço no quarto dia, quando quase

13:21 supera o Codex com um novo recorde. Também é interessante ver que o Claude é muito mais progressivo na forma como melhora o recorde, enquanto o Kimi tem esse salto, em que meio que consegue um avanço, e assim por diante. Este é um gráfico interessante porque seis dias é bastante tempo para um LLM. Mas também dá para mudar o eixo para mostrar o número de tokens de saída, e aí a história muda um pouco, porque o Max mode consome muito

13:54 mais tokens do que Codex e Kimi, e também dá para ver que o Kimi é muito eficiente em relação ao número de tokens que usa. É o Kimi K2.7 Code. Também vemos que eles têm abordagens diferentes para usar a literatura e os artigos. Por exemplo, o Claude faz muita busca em artigos e, na verdade, encontrou um artigo que nenhum outro modelo encontrou

14:24 e isso acabou levando ao melhor recorde. É meio engraçado. E um dos principais problemas de tudo isso é que, quando lancei esses agents — e acho que é algo importante que quero que vocês lembrem desta palestra —, esperava que eles tivessem algumas ideias malucas sobre otimizadores, coisas que ninguém tinha descoberto. Mas, sinceramente, não foi o caso. Eles

14:58 fizeram alguns truques inteligentes, basicamente combinando artigos diferentes. Meio que fizeram uma melhoria de mais um ponto em vários métodos, mas não surgiu desses modelos nenhum otimizador ou mecanismo realmente novo. Acho que isso é revelador: mesmo em algo que não é simples, mas que eu diria ser acessível para as pessoas — para pesquisadores humanos que passam dias e semanas nisso —, o modelo ainda não consegue encontrar novos

15:33 otimizadores e mecanismos. Então, acreditamos que existe uma maneira de torná-los melhores para descoberta, em vez de avaliação. Isso vem de uma abordagem muito inspirada pelo AlphaEvolve, do Google, e também por vários artigos publicados desde então. É uma espécie de sistema multi-agent que interage: vários geradores. Você tem modelos fechados, mas também modelos open source, que são muito eficientes em termos de custo

16:05 certo? Eles podem sugerir ideias, depois você executa a speedrun e obtém a recompensa. Em seguida, há um avaliador que fornece feedback sobre a qualidade. O avaliador também pode ter um certo gosto: você pode fazer com que ele avalie se o método é bom ou não, fora do ciclo. Então, você pode decidir qual método quer escalar para um número maior de parâmetros e de tokens. Então, essa é a parte de

16:39 escalabilidade da speedrun, porque, na comunidade de speedrun, muita gente costuma dizer que os métodos não funcionam em grande escala. Acho muito importante incluir também elementos de escala nesse ciclo. E acho que os humanos também são muito úteis aqui para avaliar as ideias dos agents, orientá-los na direção certa e assim por diante. Ainda não testamos isso; quero dizer, estamos meio que testando agora, e esperamos que

17:12 isso leve a novas descobertas em pesquisa de IA, pelo menos. Outra possibilidade é definir várias speedruns. Este é o próximo slide; talvez seja dos slides do SafeBooru, mas, se você não entendeu a referência, ótimo: significa que você não fica tanto tempo online. A ideia é que, ao mudar o objetivo e as restrições da speedrun, você pode criar muita diversidade e orientar o modelo para seguir determinada direção e

17:44 fazer essas descobertas. No HIM, na indústria, há várias coisas aqui que ainda não lançamos, em sua maioria, mas estamos trabalhando em sandboxing de GPU para permitir que os modelos iterem em um sandbox, porque é necessário um sandbox de GPU para esse tipo de coisa. Estamos trabalhando em nossos próprios agents, que são muito eficientes para frameworks de RM. Isso significa que você tem um sistema de arquivos e pode escrever informações e lê-las de lá. E você…

18:18 Também fazemos esse tipo de programação de ferramentas de forma programática. Também estamos treinando um modelo para ser bom nisso, além de usar um modelo open source. E o que já lançamos é um conjunto de bibliotecas e um produto chamado Verifier, voltado principalmente ao treinamento, com o qual você pode treinar e avaliar basicamente qualquer ambiente em qualquer RS. E o modelo que você pode treinar pode ser, por exemplo, o GNM 5.2, que também é muito grande. E, sim, trabalhamos bastante para tornar essas coisas muito eficientes e oferecer a melhor qualidade aos nossos clientes. É. Eu…

18:54 Quero dizer, sim, estou muito animado com esse domínio. Mais uma vez, acho muito importante que parte desse autoaperfeiçoamento recursivo aconteça de forma aberta, porque há muitas pessoas trabalhando nisso que não estão em grandes laboratórios. Então, basicamente, é preciso tornar fácil para as pessoas entenderem todo esse trabalho com modelos, fazerem pesquisa e assim por diante. Esse é mais ou menos o nosso objetivo. E, sim, muito obrigado.

Transcrição original

[00:12] Hey um hi everyone. Uh thanks for being here. Uh yeah, I’m super happy today to talk about uh automated eye research and uh especially uh all those like frontier model uh perform at uh automated eye research task. Um so I’m Elie. I worked at Prime Intellect as a research engineer and uh yeah I will go through our work on on this subject. So first I want to basically explain a bit why we are doing that and why we think it’s super important to do that in the open.

[00:45] Um so first uh I think we we all agree that uh we’ve heard about like big labs saying that this bad thing called recursive self-improvement is coming very soon. Uh so recursive self-improvement is like model training models uh without uh human intervention basically. Um but uh we don’t have any benchmark to basically quantify if this is true or not right. Uh and even less we don’t have like a third party benchmark by non- big labs to to to see

[01:21] if it’s something coming soon or not. And the other part is that we think that uh it’s super important to understand all those model uh do research because we think that a lot of the scientific research that will come into the coming years uh will be based also on AI tools. So it’s super important to understand how those model do research not just only AI research. So we try to build kind of this environment to test the capabilities of the model to do so. So

[01:53] it all started with uh Andre Karpati uh that’s basically had fun by doing this video where he trained uh GPT2 from scratch in like 90 minutes like GPT2 training takes like weeks and uh no in two years ago I think it only took like 90 minutes. So what does it mean to reprod reproduce uh GPT2 in 90 minutes? It means that in 90 minutes you achieve this target loss. Um and yeah and that’s

[02:24] at this point when you have the same loss than GPT2 you consider that your model is somewhat of equal performance. Um then what happened is that the community took this repo uh this GitHub repo and create another one called moed nano GPT and this effort was leaded by someone called Keller Jordan. And what happened is that they basically took this 90 minutes then 45 minutes and then now we can train like GPT2 validation loss model in less than two

[02:59] minutes which is honestly crazy and it took like two years to to achieve this. So it’s a very strong benchmark where uh a lot of very talented researcher iterated on um yeah so we decided to take this environment of speedun so it’s kind of a game so the goal of the game is to achieve this loss in the fewest in the shortest amount of time so this is the nano GPT1 and you can uh you

[03:29] don’t have almost any constraints the only constraint that you shots that you need to use the same validation and training data, right? Um there is a new speedrun called the optimizer speedrun that was released uh a few months ago and here it’s slightly different because uh you can only change the optimizer related parameters. So for instance nano GPT you can change the architecture uh do uh attention whatever uh optimizer sp

[04:00] you can only change like Adam to m shampoo or whatever optimizer is your favorite um yeah and so this is a bit more researchy because uh it’s less about optimizing the program to be as fast as possible but more like finding the best method possible. no matter the the the time you put into the computer, right? So, um yeah, why take speedrun as an environment for automated AI research? First, uh we think that it’s a good

[04:35] evaluation. We’ll see later why. Uh and this is kind of the main focus of this talk. But we also think it’s probably a good training environment because uh it’s a way to give the model a reward. So the reward is positive if the model bit the speed run and beat the last record sorry and the reward is zero or negative if it didn’t manage to to do it. So it’s a good uh environment to train model. It’s also quite fast like as you see uh previous record were

[05:05] around 2 minutes for the optimizer one. uh each run take about like 15 to 20 minutes and uh yeah and there is like clear rules basically and we also think it’s like a good environment to make discovery so like kind of breakthrough in our research because uh there is those clear rule that you can verify or not. Um yeah. So yeah. Um so what we did uh so the release was

[05:36] like about two months ago and uh there was this optimizer speedrun and we decided to basically compete with the community by launching two AI agents. So Codex and Cloud Code. Codex was like GPT 5.5 with XI and uh cloud code was Opus 4.8 with XI. Um and yeah, we decided to basically let the agent free on our cluster uh and uh and just iterate on it. So we have like V1, V2, V3 is just

[06:07] basically us stopping the agent and then restarting. V3 uh was like one or two day before the release because we saw that our agents no longer have the best record. So we were like okay take all the the human uh record in the last few week and just try to to improve upon it and and and it worked. Yeah. And we also have this novelty track where the goal is to uh beat the record with only novel ideas. Um and we’ll see that this this was more complex for the the models.

[06:43] So our RS is very simple. Honestly, we could have just replaced it with slashgo, but they there was no SLG goal at the time. So, we made our own goalm. It’s actually quite fun that we choose the same name and we had the goal. MD and kind of agents that MD that define the rules and we let the agent propose ids and then it can submit a job with sbatch on our slum cluster and uh basically the way it works is that it can submit on nodes that are available

[07:16] but only under a certain permission which means that if someone want to use this node uh the model just like cancel the job it’s called preemptable permission. So yeah, then it measure the it read basically the training logs then decide if it’s a record or not. To validate a record you need to basically pass a statistical threshold to make sure that it’s just not see the optimization and is just not random. Right? So yeah a few results from this experiment. The first one that was honestly very painful to work with is that code clothes code keep stopping

[07:52] every nine or 10 hours and basically said yeah I cannot improve the record it’s too hard for me there is no way to to go beyond it and then I was just like okay continue explore new direction hey just go again for 10 hours and then say yeah I cannot beat the recall and so on. So basically onethird of the time the cloud code agent was idle because I had no way to basically monitor it and codeex totally the opposite just worked for all the all the time and uh yeah

[08:26] almost never idle never asked for question and and and very impressive in that way. Um we also give the option for the model to basically write uh a bunch of stuff into what we call a scratch pad which is basically the active memory of the model. Uh we observe that basically codeex writes a lot on the scratch patch. So each plot that I will show are kind of normalized by the number of active order. So this is not only about

[08:57] codex working more it’s it’s really different behavior. So yeah, you see that uh writes a lot more to to this scratch pad to this memory and uh the shape of the like the the I don’t know the tone of the the each file was also super different like CL was super excited about getting new record with a bunch of emoji and so on and CEX was just like here is what I do here is the decision I take what I will do next like super robotic kind of um

[09:31] Yeah, we also have this plot where basically we saw that codex was spawning much more sub aents than cloud. Uh we saw that codex burn much more token than code. So I think in total it was like kind billion of token but it’s like there is obviously this input tok uh input caching that make it it’s not like one billion output token. Uh so yeah we also see that codex did a lot of compaction because it only had like 250k context window and cloud only do it like

[10:04] one per hour and codex is more like no it’s even less than one power for I mean one for the full run for code and codex was like one uh was 20 every one hour. So yeah um yeah here is the main results. So what this plot shows is that basically we so in in white you see that the human record progression right and in red you see cloud I mean it’s supposed to be

[10:37] orange but whatever and in blue uh you see codeex right and you see that at almost every time uh cloud and codex are better than the human record and code is super good at the beginning very very fast to achieve very good Um yeah and one thing that is super important is that the model have the ability to basically fetch the human records at any time and that’s what codex did that’s what cloud did sorry because when I restarted it it basically

[11:07] fetch the new record from human and improve upon it um yeah so the result is that uh I think at the time the best uh record was like uh 2,990 step and we beat it by like uh uh 50 or 60 step for code and codeex was like 20 step above. So I think it’s both impressive and and yeah um so we so this is like not released yet. This is something that we are working on

[11:39] currently and basically the idea is that this is a cool experiment to do but it lack of structured right. uh if you want to do a real benchmark, you want to do multiple seed, you want to do uh yeah proper uh thing where you you you you basically put all the model and earnestness in the same condition, right? So this is what we are working on right now and basically um the idea is to do three different track uh one without any access to really like

[12:11] measure the capability of the models to do AI research based on only the model weight knowledge one with only archive paper and one with like full access. So it also have access to the the like the latest record by human. And for this we plan to do both uh the nano GPT track one which is the original one and the optimizer speedun where we we only launch uh we only constrain the the optimizer to be to be novel basically. Um yeah so I will present some result on

[12:45] the optimizer speedrun. Uh this is basically what we got. So we let the agent iterate for six day almost five days let’s say and we see that uh codeex k and clothes uh are super effective so for GLM this is not finished run right so the model is actually still iterating on the cluster right now but we see that cloud is once again very good at it and we see that surprisingly Kim is also very competitive and kind of have this breakthrough on day four where he kind

[13:21] of beat Codex with a new record, right? It’s also interesting to see that uh Claude is much more like progressive in the way it improved the record and Kim has really this step function where I kind of do a breakthrough and so on. Uh so this is an interesting plot because I mean six day is quite a lot for anal uh uh but you you can change this uh axis by also the number of output token and then kind of tell a different story because in max mode consumes so much

[13:54] more token than codeex and kimmy and you also see that Kimmy is actually super efficient uh for the number of token that uh it uses. So it’s scheming K2.7 code. Um so yeah uh we also see that they have a different approach to uh using the literature and papers. Um so for instance like code is doing a lot of search on papers and actually include found a paper that no other model found

[14:24] and it actually lead to the best record. So it’s kind of funny and uh yeah um one of the main issue of all of this is that uh when I when I launched this this agent and I think that’s something important that I want you to to kind of uh remember for this co this talk is that when I launched this these different agents I was expecting them to come up with some crazy ideas on optimizer that’s like no one of discover but honestly it wasn’t the case. Uh they

[14:58] did some clever trick where basically they combine different papers. uh they kind of do plus one improvement over a bunch of method but there was really like no novel optimizer or mechanism that was uh coming from those model and I think that’s kind of telling that even on something that is not simple but I’d say that it’s kind of accessible for people right for like human researcher uh spending like days and weeks for the the model like cannot like find new uh

[15:33] optimizer and mechanism. So we believe that there is a way to basically make it more um make it better for discovery instead of evaluation and this is coming from uh this is very inspired from alpha evolve by Google and also a bunch of papers that have been released since then. It’s kind of this multi- aent system that interact together uh bunch of generator. You have closed model but you also have open source model here that are super effective for the cost

[16:05] right. Uh they can suggest ideas then you run the speedrun so you get the reward then you have a judge that basically give a quality feedback can also be like the judge also have this taste. you can kind of have like the judge have a taste about the the method if it’s good or not uh if it’s outside the loop and then you can uh basically decide which method you want to scale to a larger number of parameters and number of token. Um so this is kind of the

[16:39] scale part of the speedrun because some a lot of method in the the speedrun community uh people are often saying that they doesn’t work at large scale. So I think it’s very important to also put scale elements in this loop. Uh and I think also that uh human are super useful here to basically judge the ID of agents kind of steer them in the right direction and so on. Um yeah so we didn’t try it yet I mean we are kind of trying it right now and uh we hope that

[17:12] this will lead to to to new discovery in AI research at least and also a way is that you can define multiple speedrun so this is the next slide if you like it’s from safe bank slides but if you if you don’t have the reference good for you means that that you’re not too online uh but the idea is that uh by changing the object objective and the constraints of the speedrun you can basically create a lot of diversity and constrain the model to go into a certain direction and uh

[17:44] yeah and make those discovery. So uh at HIM in Ind. Uh there is a bunch of stuff here that we I mean most of it we didn’t release yet but we are working on GPU sandboxing to allow model to iterate into sandbox because you need GPU sandbox for this kind of stuff. We are working on our own agents that are very efficient for like RM framework. So it means like you have a file system and you can write information read from it. Uh and you

[18:18] also do like this programmatic tool coding thing. We also training a model to be good at it on top of like open source model. And uh the thing that we already released is that we have those set of liberation and product called verifier primaril training where you can basically train evaluate any environments on any RS and the model that you can train can be like GNM 5.2 too which is very big and and yeah we have like we work a lot on making those li very efficient to to ship the best quality for for our clients. Yeah. Uh I

[18:54] mean yeah super excited about this domain. Once again I think it’s super important to have uh a part of like this recursive self-improvement to happen in the open because there is actually a lot of people working that are not on big labs. So you need to basically uh yeah make it easy for people to understand all those model work to do research and so on. So that’s kind of our goal and uh yeah thanks a lot.