Execução de Jev em Pokémon Red terminou em 37 horas, mas Claude ajudou a criar o sistema vencedor

Jev concluiu Pokémon Red em 37 horas e 40 minutos, encerrando uma execução de Jev em Pokémon Red que exigiu 16.150 decisões do modelo. O resultado chama atenção quando comparado a experimentos anteriores com chatbots, que passaram semanas ou meses vagando por jogos semelhantes. Ainda assim, a aparente vitória de um sistema não baseado em LLM vem com uma ressalva importante. O desenvolvedor afirma que Claude Opus 5 ajudou a diagnosticar falhas e a melhorar o ambiente de decisão em torno de Jev.

A distinção importa porque Jev não observava o jogo, não se lembrava de toda a sua trajetória nem operava um controle diretamente. Uma estrutura de software personalizada lia dados selecionados da memória do Game Boy, construía escolhas permitidas e adicionava informações sobre cada opção. Jev então selecionava entre essas ações preparadas.

Claude teria atuado em outro nível do sistema. Ele revisava logs, encontrava situações em que Jev não dispunha de informações úteis e ajudava a refinar as opções e instruções apresentadas ao modelo de decisão. Portanto, a execução desafia uma suposição conhecida sobre agentes de IA, mas não estabelece que um pequeno modelo de decisão possa superar, de forma independente, um chatbot de ponta.

A execução de Jev em Pokémon Red terminou após 37 horas

O resultado principal é real dentro da configuração publicada pelo desenvolvedor, mas mede um sistema completo de software, e não um modelo isolado.

Christian Mathiesen, desenvolvedor da Frigade, criou o experimento de código aberto e transmitiu sua execução final de 25 a 26 de setembro de 2026. Os dados publicados da execução do projeto afirmam que Jev terminou Pokémon Red em 37 horas e 40 minutos.

O repositório registra 16.150 decisões e aproximadamente 39,2 milhões de tokens de entrada. Cada decisão teria levado cerca de 0,4 segundo. Jev sofreu 16 derrotas completas da equipe, incluindo 14 ao tentar vencer a Elite Four, e precisou de 15 tentativas contra a Elite Four antes de concluir o jogo.

Sua equipe final incluía um Charizard de nível 83 e um Graveler de nível 62. Nidoqueen, Beedrill, Haunter e Primeape completavam o grupo. Esses detalhes mostram que o sistema fez mais do que seguir uma rota curta e predeterminada pelas áreas iniciais.

Jev escolheu o inicial, administrou a equipe, capturou criaturas, selecionou ataques, comprou itens, curou, treinou e decidiu para onde viajar. Também navegou por menus e respondeu a instruções da história. Segundo o repositório, a estrutura não gravava diretamente na memória do jogo nem alterava sinalizadores de eventos.

No entanto, o sistema recebeu muito mais estrutura do que uma pessoa segurando um Game Boy receberia. A estrutura lia a memória para obter mapas, informações da equipe, condições de batalha, inventário e texto na tela. Ela convertia esse estado em escolhas explícitas acompanhadas de informações úteis.

Para navegação, código convencional realizava verificação de colisões e busca de caminhos A*, um algoritmo que calcula uma rota até um destino definido. Jev não decidia cada pressionamento individual de botão direcional pelo mapa. Ele selecionava objetivos de nível mais alto, enquanto software determinístico cuidava de grande parte de sua execução física.

A estrutura também incluía marcos da história que descreviam o próximo objetivo e sua localização. O progresso era verificado com base nos sinalizadores reais de eventos do jogo. Isso dava ao agente uma representação estruturada de onde estava na história, embora itens ocultos permanecessem escondidos.

A proteção contra loops adicionava outra camada. Escolhas tentadas anteriormente podiam receber avisos quando não produziam mudanças. Falhas repetidas podiam acionar uma seleção alternativa. Por fim, o sistema podia recarregar o checkpoint de marco mais recente.

Essas intervenções não invalidam a execução. Todo agente prático de IA depende de software ao redor, memória, ferramentas e lógica de recuperação. Elas significam, porém, que a conquista relevante é uma arquitetura de agente bem projetada, e não uma disputa bruta entre um modelo e um cartucho.

A conclusão mais defensável é limitada. Um modelo de decisão, combinado com um ambiente criado para esse propósito e controles determinísticos, concluiu um jogo longo que exige milhares de escolhas sequenciais. O experimento não mostra como Jev se sairia com pixels, um espaço de ações irrestrito ou nenhuma gestão externa de estado.

Por que Pokémon continua expondo as fraquezas de agentes de IA

Pokémon parece simples no nível de turnos individuais, mas suas longas cadeias de decisões dependentes punem memória fraca e recuperação deficiente.

O Pokémon Red original é baseado em turnos, visualmente limitado e tolerante em comparação com um jogo de ação rápido. Ainda assim, exige que um agente mantenha objetivos por muitas horas. O jogador precisa explorar mapas, ler diálogos, montar uma equipe, administrar recursos e lembrar quais obstáculos bloqueiam o progresso posterior.

Uma decisão ruim em batalha raramente encerra todo o jogo. Ainda assim, pequenos erros repetidos podem consumir itens, enfraquecer a equipe ou levar o jogador de volta a um centro de cura. Um agente precisa reconhecer que uma jogada localmente atraente pode prejudicar seu plano de longo prazo.

Essa combinação transformou Pokémon em um teste público para modelos de IA de propósito geral. Em fevereiro de 2025, a Anthropic equipou Claude 3.7 Sonnet com memória, capturas de tela e ferramentas para pressionar botões. Sua pesquisa sobre raciocínio estendido descreveu partidas que duraram dezenas de milhares de interações.

O experimento expôs fragilidades que conversas refinadas com chatbots tendem a esconder. Um modelo pode soar coerente enquanto perde o controle de sua localização, repete uma rota fracassada ou se compromete com um plano desatualizado. Um jogo torna esses erros visíveis porque cada decisão altera um ambiente persistente.

Outros desenvolvedores posteriormente transmitiram sistemas construídos em torno de Gemini, GPT e modelos mais recentes de Claude. Alguns acabaram concluindo jogos de Pokémon, mas as comparações continuaram difíceis. Cada projeto expunha informações diferentes, usava sistemas de memória distintos e permitia formas diferentes de assistência de desenvolvedores.

Uma análise de agentes de jogos de janeiro de 2026 descreveu modelos líderes como lentos, confusos e propensos ao excesso de confiança durante essas execuções. A crítica identificou um problema mais amplo do que Pokémon. Modelos de propósito geral podem gerar uma justificativa convincente mesmo quando sua representação interna do ambiente está incompleta.

Jev adota uma abordagem diferente. A TypeSafe AI o descreve como um modelo de Sistema Um, o que significa que ele é otimizado para julgamentos rápidos e delimitados, em vez de geração extensa de texto. Ele aceita contexto e perguntas focadas, depois retorna escolhas, pontuações ou probabilidades de sim ou não.

A empresa posiciona essas saídas como componentes dentro de software convencional. Sua introdução ao Jev enfatiza classificação, roteamento, pontuação e ramificação. Ela não apresenta Jev como substituto para todas as capacidades de um LLM.

Esse papel mais limitado se encaixa surpreendentemente bem em Pokémon quando o desenvolvedor reestrutura o jogo. Na maioria dos momentos, o jogador não está escrevendo um ensaio nem inventando um plano aberto. Ele está selecionando um ataque, escolhendo um destino, comprando um item ou decidindo se deve treinar.

O desafio está em gerar o conjunto certo de escolhas e anexar as informações adequadas. Se o modelo vê todas as opções relevantes, um mecanismo rápido de decisão pode manter o jogo avançando. Se a estrutura esconde um fato crítico, a velocidade apenas ajuda o agente a repetir o julgamento errado mais rapidamente.

É por isso que o resultado de Jev pressiona equipes que constroem agentes inteiramente em torno de modelos de chat. Ele sugere que muitas etapas recorrentes de um agente não precisam de uma resposta cara e aberta. Um modelo especializado pode lidar com uma decisão preparada, enquanto código convencional assume cálculos exatos e a execução.

Também desafia a ideia de que um único modelo grande deve realizar percepção, memória, planejamento, julgamento e controle dentro de uma conversa contínua. A execução em Pokémon divide essas responsabilidades em componentes distintos. Essa separação parece ser a contribuição mais importante do experimento.

Jev contra chatbots é a disputa errada

A disputa significativa é entre uma IA monolítica e um sistema dividido que atribui cada tarefa ao componente mais adequado para ela.

Um chatbot aceita prompts abertos e produz linguagem. Essa flexibilidade permite explicar situações desconhecidas, escrever planos, interpretar instruções ambíguas e se recuperar por meio da conversa. A mesma flexibilidade pode criar latência desnecessária e formatação pouco confiável quando o software só precisa de uma seleção.

Jev não consegue escrever um novo documento de estratégia nem descrever livremente a tela. Ele retorna um julgamento tipado a partir de perguntas e opções fornecidas pela aplicação. Essa restrição torna sua saída mais fácil de ser consumida pelo código.

No sistema de Pokémon, a divisão de trabalho era explícita. O emulador produzia estado legível por máquina. A estrutura transformava esse estado, calculava caminhos, estimava resultados de batalha e preparava alternativas permitidas. Jev fornecia julgamento onde regras rígidas seriam inadequadas.

Essa arquitetura se parece mais com um fluxo de produção maduro do que com uma demonstração de chatbot. Sistemas confiáveis geralmente separam operações determinísticas das probabilísticas. O código deve calcular aritmética, aplicar permissões e validar esquemas. Os modelos devem lidar com ambiguidades que regras fixas não conseguem resolver de forma limpa.

A execução também ilustra o valor da memória externalizada. Jev não precisava de um histórico de conversa crescente porque a estrutura reconstruía uma descrição do estado atual para cada decisão. O histórico relevante precisava ser armazenado pela aplicação e inserido quando necessário.

Esse desenho reduz o risco de um contexto longo ficar congestionado por planos desatualizados. Também obriga desenvolvedores a decidir quais fatos importam. Essa clareza pode melhorar a confiabilidade, mas transfere uma responsabilidade significativa do modelo para o projetista do sistema.

Um chatbot de propósito geral esconde grande parte desse trabalho. Desenvolvedores podem enviar uma captura de tela, fornecer um objetivo amplo e pedir que o modelo decida o que acontece em seguida. A interface parece simples, enquanto o modelo absorve percepção, interpretação, planejamento e geração de respostas.

A simplicidade aparente traz custos além da computação. Quando algo falha, o desenvolvedor precisa identificar se o problema veio da visão, da memória, do raciocínio, da seleção de ferramentas ou de uma instrução pouco clara. Uma resposta longa em linguagem natural pode oferecer pistas, mas não garante um diagnóstico preciso.

Um pipeline de decisão tipado expõe evidências diferentes. O projeto Jev registrou o estado completo, as opções, as probabilidades e a latência de cada chamada. Os desenvolvedores podiam inspecionar quais escolhas estavam disponíveis e se o modelo expressava incerteza.

Esse registro transforma a falha de um agente em uma questão de engenharia mais específica. O modelo escolheu mal apesar de ter contexto adequado? A estrutura omitiu uma opção necessária? Uma decisão correta de alto nível se tornou uma sequência ruim de botões? Cada resposta sugere um reparo diferente.

Isso não significa que um modelo de decisão sempre vence. Ambientes abertos introduzem rotineiramente eventos que os desenvolvedores não anteciparam. Um modelo de escolhas delimitadas não pode selecionar uma ação que sua aplicação nunca ofereceu.

Um chatbot pode, às vezes, inventar um plano de recuperação para uma situação desconhecida. Ele pode interpretar texto incomum, explicar por que as ferramentas atuais são insuficientes ou propor uma nova sequência de operações. A interface mais limitada de Jev depende de outro componente para realizar esse trabalho.

O enquadramento Jev versus LLM, portanto, obscurece a arquitetura que de fato teve sucesso. A execução concluída combinou um modelo rápido de decisão, um tradutor detalhado de estado, código de busca de caminhos, checkpoints, proteção contra loops e um modelo de fronteira usado durante o desenvolvimento.

Essa pilha não eliminou os modelos de linguagem de grande porte. Ela deslocou um deles para um papel de supervisão.

Claude Opus 5 Orientou o Sistema em Becos Sem Saída

O envolvimento do Claude transforma o resultado de uma vitória inesperada de modelo em evidência de uma arquitetura de IA em dois níveis.

Segundo o relato do desenvolvedor divulgado pelo Google News, Claude Opus 5 monitorou logs e ajudou a ajustar as escolhas e a redação fornecidas ao Jev. Esse trabalho teria se tornado importante quando o modelo de decisão chegava a becos sem saída.

A intervenção parece ter ocorrido por meio de alterações durante o desenvolvimento, e não com Claude escolhendo movimentos a cada turno do jogo. Essa distinção preserva o papel do Jev na tomada das decisões registradas. Ainda assim, ela complica alegações de que um sistema não baseado em LLM teve sucesso de forma independente onde chatbots falharam.

Um modelo só pode escolher bem a partir do mundo que recebe. Suponha que um agente caminhe repetidamente em direção a um caminho bloqueado porque o prompt não identifica um item necessário. Reformular as opções disponíveis pode ajudar, mas a correção mais profunda é adicionar o estado ausente.

Um modelo de fronteira é adequado para revisar esse tipo de falha. Ele pode ler uma trajetória longa, comparar tentativas repetidas, inferir qual fato está ausente e propor mudanças no harness. Essas são tarefas abertas que envolvem diagnóstico e novo texto, precisamente os trabalhos para os quais Jev não foi projetado.

O arranjo resultante lembra a distinção entre pensamento rápido e lento. Jev lida com julgamentos frequentes e delimitados. Claude realiza análises menos frequentes quando o sistema se comporta mal ou encontra uma situação que seus projetistas não conseguiram representar.

Isso não é apenas um compromisso imposto pelas limitações do Jev. Pode ser um padrão útil para produção. A maioria dos eventos de software é rotineira, enquanto um subconjunto menor exige interpretação mais profunda. Enviar todos os eventos pelo modelo mais capaz pode desperdiçar recursos e introduzir atrasos adicionais.

Em vez disso, um modelo supervisor pode analisar casos incertos, revisar lotes de falhas ou reescrever a política de decisão. Suas melhorias podem então beneficiar milhares de chamadas subsequentes feitas pelo componente mais rápido.

No entanto, o processo de orientação precisa de documentação mais rigorosa antes que pesquisadores possam tratar a execução como uma comparação limpa. O resumo público não apresenta uma linha de base controlada apenas com Jev usando o harness final. Ele também não quantifica com que frequência Claude alterou o sistema nem quanto progresso resultou de cada mudança.

O histórico do repositório contém centenas de commits, o que torna a evolução inspecionável em princípio. Ainda assim, uma sequência de commits de desenvolvimento não equivale a um protocolo experimental. Uma comparação adequada congelaria o ambiente, definiria regras de intervenção e executaria múltiplos testes com seeds controladas.

Há outra fonte de ambiguidade. Todo benchmark de agentes inclui scaffolding, mas esse scaffolding pode incorporar conhecimento substancial sobre a tarefa. O harness do Jev conhecia marcos e locais da história, calculava caminhos, estimava dano e preparava ações legais.

Uma execução com chatbot que recebe apenas capturas de tela e ferramentas amplas de botões enfrenta um problema diferente. Ela precisa realizar mais percepção e planejamento dentro do modelo. Comparar o tempo de conclusão sem equiparar essas interfaces corre o risco de atribuir ao modelo vantagens fornecidas pelo harness.

A leitura justa não é nem desdém nem triunfo. Jev tomou milhares de decisões consequentes dentro de um sistema que, ao fim, concluiu o jogo. Claude ajudou engenheiros a melhorar esse sistema. Juntos, produziram um resultado mais rápido do que várias demonstrações famosas de chatbots, mas não realizaram o mesmo teste.

O Que o Resultado Não Prova

Uma única partida bem-sucedida não pode estabelecer que modelos de decisão são, em geral, mais inteligentes, autônomos ou confiáveis do que agentes baseados em LLM.

A maior incerteza é a reprodutibilidade. O resultado publicado descreve uma execução concluída após o desenvolvimento ativo do sistema ao redor. Pokémon contém encontros aleatórios, resultados incertos em batalhas e muitas configurações possíveis de equipe.

Uma segunda execução pode seguir outra rota ou parar em um local diferente. Repetir o experimento revelaria se o sistema conclui o jogo de forma confiável ou se se beneficiou de uma trajetória favorável.

A configuração também não tem um concorrente equivalente. Para comparar Jev e Claude de maneira justa, ambos os modelos precisariam ter a mesma representação de estado, opções, navegação determinística, regras de recuperação e checkpoints. Caso contrário, o benchmark mede duas combinações diferentes de modelo e software.

Um experimento útil executaria três configurações. Uma usaria Jev com o harness congelado. Outra substituiria Jev por um modelo de uso geral, preservando todos os demais componentes. Uma terceira usaria o sistema híbrido, com um supervisor revisando falhas selecionadas.

Pesquisadores então comparariam taxas de conclusão, decisões, contagens de intervenções, tempo de relógio e comportamento de recuperação em testes repetidos. Essas medições mostrariam onde o modelo especializado ajuda e onde um modelo de fronteira continua necessário.

O uso de inspeção de memória pelo desenvolvedor também limita conclusões mais amplas. Ler o estado estruturado do jogo elimina o problema da percepção visual. Essa escolha é razoável para testar decisões, mas não estabelece que Jev possa operar diretamente em ambientes visuais desorganizados.

Aplicações reais raramente oferecem listas perfeitas de opções legais. Um roteador de suporte pode receber um novo problema que não se encaixa em nenhuma categoria conhecida. Um agente de navegador pode encontrar uma página redesenhada. Um robô físico pode observar um objeto que seu planejador nunca representou.

Modelos delimitados precisam de rotas seguras de escape para esses casos. Limiares de confiança podem enviar decisões incertas para uma pessoa ou um modelo de uso geral. As aplicações também precisam de uma forma de detectar quando a escolha correta está completamente ausente.

A probabilidade, por si só, não resolve esse problema. Um modelo pode expressar alta confiança entre alternativas ruins porque todas as opções disponíveis estão erradas. Os desenvolvedores precisam validar o conjunto de ações e monitorar os resultados posteriores.

A proteção contra loops do Jev demonstra a necessidade dessas salvaguardas. O harness marcou escolhas ineficazes, amostrou alternativas após falhas repetidas e restaurou checkpoints como último recurso. Esses mecanismos impediram que um julgamento ruim aprisionasse o sistema para sempre.

Eles também significam que a conclusão não foi puramente resultado de escolher corretamente em cada etapa. O sistema tolerou erros e se recuperou deles. A IA de produção precisa da mesma qualidade, embora os fluxos de trabalho empresariais muitas vezes não tenham um checkpoint conveniente capaz de reverter danos.

Uma ação equivocada no jogo pode custar minutos. Uma exclusão, pagamento ou resposta a cliente equivocada pode ter consequências duradouras. Desenvolvedores que consideram uma arquitetura no estilo Jev devem definir quais decisões são reversíveis e quais exigem aprovação.

O experimento também diz pouco sobre segurança. Um modelo que consome texto de fontes externas pode encontrar instruções manipuladoras ou contexto enganoso. Restringir a saída a escolhas tipadas reduz a superfície de ação, mas não garante uma interpretação correta.

Por fim, Pokémon Red é um ambiente conhecido e estável. Seus mapas, mecânicas de batalha, menus e estrutura narrativa não mudam durante a execução. Essa estabilidade permite que engenheiros construam um tradutor de estado excepcionalmente detalhado.

Muitos ambientes corporativos mudam continuamente. Documentos chegam em novos formatos, políticas evoluem e ferramentas retornam dados incompletos. Quanto mais volátil o ambiente, mais manutenção o harness exige.

A execução, portanto, apoia uma hipótese de design, não uma classificação universal. Modelos especializados de decisão parecem promissores quando as ações são delimitadas, o contexto pode ser estruturado e software determinístico consegue executar o resultado. Modelos de uso geral continuam valiosos quando o sistema precisa interpretar novidades, gerar planos ou reparar sua própria representação.

Três Sinais Mostrarão se o Resultado do Jev Importa

O próximo teste é saber se a arquitetura resiste à repetição, a comparações equivalentes e a ambientes que não foram cuidadosamente preparados ao seu redor.

Primeiro, observe execuções reproduzíveis de Pokémon usando uma versão congelada do harness. Múltiplas conclusões sem supervisão reforçariam a alegação de que o sistema representa um ciclo de decisão confiável. Falhas publicadas seriam igualmente valiosas, pois revelariam quais partes da representação de estado permanecem frágeis.

A versão mais útil incluiria trajetórias completas, versões fixas dos modelos, logs de intervenção e uma definição clara de conclusão. Ela deveria separar a recuperação automatizada das mudanças humanas feitas entre execuções. Sem essa separação, desenvolvedores não conseguem saber se as melhorias vieram do modelo ou do trabalho contínuo de engenharia.

Segundo, procure um teste equivalente entre Jev e LLM. Ambos os sistemas devem receber estado, escolhas, código de navegação e regras de checkpoint idênticos. Isso transformaria o atual contraste arquitetural em uma comparação mensurável entre modelos.

Um teste equivalente pode mostrar que um LLM tem desempenho semelhante, mas responde mais lentamente. Pode mostrar que Jev se destaca em escolhas rotineiras, mas perde em situações raras. Também pode revelar que o harness detalhado remove a maior parte da carga de inteligência de ambos os modelos.

Terceiro, observe aplicações fora dos jogos em que os resultados tenham rótulos objetivos. Roteamento de tickets, filas de moderação, classificação de documentos, seleção de ferramentas e priorização de alertas são candidatos plausíveis. Esses fluxos de trabalho produzem decisões repetidas que as equipes podem auditar em relação a resultados posteriores.

A evidência mais forte não seria uma demonstração impressionante. Seria precisão estável diante de entradas em mudança, calibração clara, baixas taxas de exceção e escalonamento seguro quando nenhuma das escolhas preparadas se encaixa.

Para desenvolvedores, a lição imediata é prática. Não peça a um único modelo que execute todas as funções cognitivas apenas porque uma interface de chat torna esse arranjo fácil. Separe percepção, estado, julgamento, execução, memória e recuperação; depois, avalie cada limite.

As equipes podem aplicar a mesma ideia aos seus próprios fluxos de trabalho de IA preservando o material de origem por trás de cada decisão. Uma base de conhecimento de engenharia pesquisável pode ajudar revisores a conectar o comportamento do modelo a especificações, logs e correções anteriores.

O experimento Jev em Pokémon Red importa porque torna a arquitetura visível. Um modelo focado lidou com milhares de escolhas, software convencional executou operações exatas e Claude supostamente ajudou a redesenhar o sistema quando sua representação falhou.

Isso não é uma vitória clara sobre os LLMs. É um argumento a favor de usá-los com menos frequência e de forma mais deliberada.

A próxima questão é se desenvolvedores conseguem reproduzir essa divisão de trabalho sem meses de ajuste específico para a tarefa. Se equipes independentes puderem congelar o harness, repetir a execução e levar o padrão para fluxos de trabalho reais, Jev terá demonstrado algo maior do que uma maneira incomum de terminar Pokémon Red.