Este modelo open source pensou por 88 mil caracteres… e não escreveu nenhum 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: This Open Model Thought for 88,000 Characters… and Wrote Zero Code · Canal: Prompt Engineer 48 · 10:28 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Modelos locais e open source, Modelos multimodais

Resumo

O vídeo avalia o Next N 2.5 mini, um modelo open weights executado em uma GPU A100 com llama.cpp, em 11 testes de código, visão, uso de ferramentas e raciocínio. O modelo se destacou na leitura de gráficos, no uso de contextos longos e em tarefas de agent com ferramentas, mas o modo de pensamento adaptativo muitas vezes consumiu muitos tokens sem produzir uma resposta. Com o pensamento desligado, foi rápido, mas também entregou código com bugs e respostas incorretas. O recurso de autocorreção visual identificou problemas nas capturas de tela, mas não conseguiu corrigi-los de forma confiável.

Pontos-chave

O modelo carregou em uma A100 de 80 GB usando 41,8 GB de VRAM com o context window completo de 262 mil tokens.
Em tarefas abertas de código, o pensamento adaptativo chegou a gerar mais de 100 mil caracteres de raciocínio sem concluir a resposta.
Ao ler o próprio gráfico de benchmark, extraiu corretamente os 61 números de nove gráficos.
Encontrou informações escondidas em três prompts de até 151 mil tokens.
O agent loop corrigiu um projeto com testes e build quebrados, verificando que ambos passaram depois das alterações.
No algoritmo testado, acertou 300 de 300 casos aleatórios com o pensamento ligado; com o pensamento desligado, acertou 214 de 300.
A autocorreção visual identificou problemas em um dashboard, mas as correções não eliminaram os defeitos.
O teste custou US$ 12,67 por cerca de oito horas de uso da GPU.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação do modelo e configuração dos testes	O vídeo apresenta o Next N 2.5 mini, suas alegações de desempenho e a configuração de execução em uma A100 com llama.cpp.
02:08	Código criativo e autocorreção	Os testes de galáxia mostram que o modelo pode gastar muitos tokens sem responder, mas também produzir código funcional após receber um orçamento maior e corrigir um bug específico.
04:13	Visão, uso do computador e tarefas com ferramentas	O modelo lê um gráfico com precisão, acerta a maioria dos alvos em capturas de tela e resolve um projeto de código com testes e build quebrados, mas falha em corrigir um dashboard visual.
07:21	Raciocínio, resultados e veredito	Os testes de contexto longo, algoritmo, lógica e honestidade mostram resultados variados, seguidos pelo balanço de pontos fortes, limitações e custo.

Citações

Em código criativo e aberto, este modelo pode pensar até a exaustão. — 03:10

Ele consegue ver o bug, mas não conseguiu corrigi-lo. — 05:48

A autocorreção descreve os problemas, mas não os corrige. — 08:23

Só não confie ainda no patch de autocorreção. — 10:28

Conceitos e entidades

Next N 2.5 mini (modelo): Modelo open weights avaliado no vídeo em tarefas de código, visão, raciocínio e uso de ferramentas.
Next AGI (empresa): Empresa responsável pelo Next N 2.5 mini.
Qwen3.5 (modelo): Arquitetura de mixture of experts na qual o modelo avaliado é baseado.
Claude Code (ferramenta): Ferramenta usada para alugar a GPU e, ao final, desligar e excluir a instância.
RunPod MCP server (ferramenta): Servidor MCP usado para selecionar, iniciar e encerrar a GPU alugada.
llama.cpp (ferramenta): Ferramenta usada para executar o modelo quantizado em uma GPU A100.
GGUF (conceito): Formato da versão quantizada do modelo usada nos testes.
autocorreção visual (conceito): Processo em que o modelo analisa uma captura de tela do próprio resultado e tenta corrigir os problemas.
A100 (ferramenta): GPU de 80 GB usada para executar os testes do modelo.

Tradução completa (pt-BR)

00:00 Dei a este modelo open source 32.000 tokens para criar uma galáxia 3D. Ele pensou por 88.000 caracteres e não escreveu nenhuma linha de código. Depois, desliguei o modo de pensamento, e ele entregou uma galáxia em 45 segundos que renderizava uma tela completamente preta. Então, o Next N 2.5 mini é realmente bom? Aluguei uma GPU com um servidor MCP, executei o modelo na qualidade Q8 máxima e o submeti a 11 testes difíceis. Alguns resultados são genuinamente impressionantes; outros, nem tanto. O Next N 2.5 mini é da Next AGI. É um

00:32 modelo de pesos abertos com recursos agênticos, criado com base na arquitetura de mistura de especialistas do Qwen 3.5, com uma context window de 262.000 tokens e entrada de visão. Os autores o apresentam como adequado para uso de ferramentas em programação, uso de computador e algo que chamam de autocorreção por feedback visual, em que o modelo observa uma captura de tela do próprio trabalho e o corrige. A tabela de benchmarks deles faz afirmações ousadas: 82,9 no OS World G, que avalia clicar no elemento certo em uma captura de tela — um resultado superior ao do Claude Opus 5 naquele gráfico. 89,7 no OmniDoc, para leitura de

01:05 documentos. 73 no Terminal-Bench. Mas esses resultados são do modelo em precisão total, usando o harness deles. Eu queria saber o que se consegue com um GGUF quantizado em uma única GPU alugada. Primeiro, a GPU. Em vez de ficar clicando em um site, pedi ao Claude Code que a alugasse para mim usando o servidor MCP do RunPod. Ele listou todas as GPUs com pelo menos 48 GB, verificou a disponibilidade em tempo real e escolheu uma A100 de 80 GB na Secure Cloud por US$ 1,59. Dei uma regra de segurança: se o preço

01:35 passasse de 170, excluir o pod imediatamente. O preço ficou exatamente em 159, e o pod estava funcionando. Agora, na prática, minha chave SSH de sempre tinha uma frase secreta. Então, troquei o pod por uma chave diferente, o que o reinicia. A primeira compilação do llama.cpp falhou porque o compilador CUDA não estava no PATH e o CMake do sistema era antigo demais. Depois de corrigir isso, o modelo Q8, de 36,9 GB, mais o projetor de visão, carregou em cerca de 9 segundos, usando 41,8 GB de VRAM com a context window completa de 262.000 tokens. E é

02:08 rápido. Cerca de 90 tokens por segundo na primeira chamada, por volta de 126 tokens por segundo em gerações longas, e processamento de prompt entre 700 e 3.000 tokens por segundo. Para um modelo tão capaz em uma A100, isso é excelente. Aqui vai a bateria de testes: uma galáxia em WebGL, um jogo jogável, reconstrução de um site a partir de uma captura de tela, um dashboard. Ele precisa corrigir problemas observando as próprias capturas de tela, ler o próprio gráfico de benchmarks, clicar em alvos em capturas de tela reais, um

02:39 ciclo de agent com ferramentas, uma agulha em um palheiro de 150.000 tokens, um algoritmo difícil que eu realmente executo, um quebra-cabeça lógico e uma armadilha de honestidade. Todos os resultados aqui são reais. Teste um — e primeira surpresa: com o modo de pensamento adaptativo padrão e um orçamento de 32.000 tokens, o prompt da galáxia gerou 88.000 caracteres de raciocínio e depois foi cortado. Nenhum HTML. E não foi um caso isolado. A reconstrução do site fez o mesmo, com 95.000

03:10 caracteres; o jogo, com 76.000; e o algoritmo, com 109.000. Em tarefas criativas de programação sem muitas restrições, este modelo pode pensar até se esgotar. Então, tentei de novo com o modo de pensamento desligado. A galáxia ficou pronta em 45 segundos: uma página refinada chamada Nebula Forge, com 70.000 estrelas, sem erros de JavaScript e uma tela completamente preta. O console mostrou erros de WebGL: índice fora do intervalo. O modelo passou um número para get a triple location, em vez de um nome de atributo.

03:40 É aqui que a coisa fica boa. Enviei ao modelo o próprio erro e as poucas linhas do código do buffer e pedi uma correção mínima. Ele diagnosticou o problema com precisão: size não é um nome de atributo, então a busca retorna menos um. Em vez disso, usou as posições de layout dos shaders. Apliquei a correção, e aí está: 70.000 estrelas em braços espirais, arraste para orbitar, role para ampliar. Um bug foi entregue; outro, corrigido pelo próprio modelo. Depois, dei ao modo de pensamento um orçamento de verdade: 110.000 tokens. Ele pensou por 122.000

04:13 caracteres, escreveu 56.000 tokens e levou 7 minutos e meio. E, desta vez, entregou código funcional na primeira tentativa. NGC 7742, 90.000 estrelas, três braços, escala de cores por temperatura, órbita automática e um seletor da quantidade de estrelas, rodando a 60 quadros por segundo no meu laptop. A câmera padrão fica um pouco perto demais de um dos braços, mas o resultado é realmente lindo. Agora, as alegações sobre visão. Dei ao modelo a imagem do próprio gráfico de benchmarks e pedi que extraísse todos os números em JSON. Nove gráficos, 61 números. Acertou

04:45 os 61, exatamente. A pontuação do OmniDoc é plausível. Em seguida, teste de localização para uso de computador. Cinco capturas de tela reais: encontrar o elemento e fornecer um ponto de clique em uma escala de zero a 1.000. No GitHub, acertou os três: o botão de estrela, o botão verde de código e a aba de issues. No Hacker News, acertou o link de comentários da primeira notícia, bem na borda do texto. Mas, para o link de login, ignorou completamente a escala de zero a 1.000 e respondeu com um número acima de mil, então o clique ficaria fora da tela. Quatro acertos em cinco.

05:17 E uma confissão rápida: minha própria pontuação para aquele link de comentários estava errada no início. Percebi ao conferir os pixels e corrigi a pontuação. Com o modo de pensamento ligado, a conversão de captura de tela para site também foi pensada demais. Com o modo de pensamento desligado, ele reconstruiu o Hacker News em 35 segundos. Todos os títulos das notícias, domínios, pontuações, nomes de usuário e contagens de comentários estão corretos, mas o layout está errado. Cada notícia se divide em quatro linhas, e falta a coluna centralizada. Ótimo para ler, menos bom para reproduzir o layout. E este é o teste mais importante para a

05:48 proposta deles: autocorreção visual. Com o modo de pensamento ligado, o primeiro dashboard parecia bom, mas, quando lhe enviei a captura de tela, ele pensou demais e ficou sem tokens. Então, executei o ciclo com o modo de pensamento desligado. Ele criou um dashboard; fiz uma captura de tela e enviei a imagem de volta, e a descrição foi precisa: cerca de 440 pixels de espaço vazio à esquerda, o gráfico cortado e a legenda truncada. Ele percebeu todos os problemas. Depois, enviou o código corrigido, mas a nova captura de tela tinha exatamente a mesma coluna vazia. Na segunda rodada, o mesmo diagnóstico e o mesmo resultado. Ele consegue

06:20 ver o bug, mas não conseguiu corrigi-lo. O jogo Breakout foi a lição mais difícil. Com o modo de pensamento desligado, entregou um jogo neon elegante em 87 segundos, mas a IA da demonstração nunca jogava, e a tela era minúscula. Enviei os bugs quatro vezes. Na primeira rodada, encontrou problemas reais e corrigiu o tamanho da tela, mas a correção fez a bola ser lançada de um jeito que desligou a IA. Na segunda rodada, culpou a função errada e, para ser justo, meu próprio prompt identificava uma linha incorretamente, o que corrigi. Na terceira rodada, com o modo de pensamento ligado, pensou por 127.000

06:50 caracteres e ficou sem tokens. Na terceira rodada, com o modo de pensamento desligado, enviou um patch com código que nunca poderia ser executado. Quatro tentativas, e a demonstração ainda não joga sozinha. O teste do agent foi muito melhor. Um projeto Node real, com um teste que falhava, uma compilação quebrada e três ferramentas: executar shell, ler arquivo e escrever arquivo. Em sete turnos, explorou o projeto, leu todos os arquivos, descobriu que faltava o cabeçalho de autenticação no teste e que não existia uma configuração de build. Corrigiu os dois problemas e depois executou os testes e a compilação para verificar. Ambos passaram. As chamadas de ferramentas

07:21 funcionam nativamente por meio do llama.cpp. Contexto longo. Coloquei um código secreto a 37% do caminho, dentro de 24.000, 97.000 e 151.000 tokens de texto de preenchimento. Ele encontrou os três. O prompt de 151.000 tokens foi processado a mais de 2.500 tokens por segundo, em 61 segundos no total. O algoritmo difícil: peso máximo de aresta em caminhos de árvores, com elevação binária, para 200.000 nós e consultas. Conferi cada resposta usando força bruta em 300

07:53 árvores aleatórias. Com o modo de pensamento desligado, respondeu em 5 segundos e errou: 86 de 300. Com o modo de pensamento ligado, respondeu em menos de 4 minutos e foi perfeito: 300 de 300. E resolveu o teste completo em 1,9 segundo. O mesmo padrão apareceu em um quebra-cabeça lógico sobre cinco pessoas em fila. Com o modo de pensamento ligado, afirmou corretamente que as pistas permitem três ordens diferentes, o que verifiquei por força bruta. Com o modo de pensamento desligado, anunciou com confiança que só havia uma ordem possível — errado. E, na armadilha de honestidade, um estudo falso de Stanford, ele

08:23 se recusou a inventar qualquer coisa e pediu o DOI. Muito bem. Então, aqui está o placar. Vitórias claras: leitura de gráficos, 61 de 61; contexto longo, três de três; o ciclo de agent; o algoritmo com o modo de pensamento ligado; honestidade; e velocidade. Localização com resultados mistos: quatro de cinco. A reconstrução do site e a galáxia que precisou de uma autocorreção. Derrotas: cinco casos de pensamento excessivo que acabaram em esgotamento com o orçamento padrão. Primeiras versões de código visual com erros. Um ciclo de autocorreção que descreve os problemas, mas não os corrige.

08:55 E um jogo que ele não conseguiu consertar em quatro tentativas. Prós: primeiro, é rápido, mais de 120 tokens por segundo em uma A100. Segundo, excelente capacidade de interpretar imagens e extrair informações de documentos. Terceiro, contexto longo que realmente funciona. Quarto, um loop de agent sólido, com chamadas nativas de ferramentas. Quinto, quando ele realmente pensa, a qualidade do código é alta. E sexto, é Apache 2.0, e a versão Q8 cabe em uma única GPU de 80 GB com o contexto completo. Contras: primeiro, o pensamento adaptativo pode consumir 100.000

09:25 caracteres e nunca responder. Então, você precisa de orçamentos grandes ou deixar o pensamento desativado. Segundo, com o pensamento desativado, é rápido, mas entrega bugs e respostas erradas. Terceiro, a autocorreção visual. O principal recurso anunciado não funcionou no meu teste. Quarto, às vezes ignora regras de formato de saída, como aquela escala de coordenadas. E quinto, isso foi uma quantização GGUF no llama.cpp, não no harness oficial deles, então seus resultados podem ser diferentes. E, sobre a conta, no final, pedi ao Claude Code que desligasse tudo pelo servidor MCP novamente. Ele parou o pod,

09:57 excluiu-o, confirmou que não havia nenhum pod em execução e consultou a cobrança. US$ 12,67 por cerca de 8 horas de GPU a 159. Isso foi mais do que eu planejava, porque deixei o pod em execução durante a configuração, os consertos de build e longas esperas. Lição aprendida: desligue a GPU assim que os testes terminarem. Meu veredito: Next 72.5 mini é um modelo open realmente forte para ler documentos longos e usar ferramentas com agents, além de ser rápido para programação criativa. Dê ao pensamento um orçamento grande e espere ter que enviar a ele os próprios erros. Só não confie ainda no patch de

10:28 autocorreção. Os links para o modelo e o GGUF estão na descrição. Me diga o que você [limpa a garganta] quer que eu teste em seguida.

Transcrição original

[00:00] I gave this open model 32,000 tokens to build a 3D galaxy. It thought for 88,000 characters and wrote zero lines of code. Then I turned thinking off and it shipped a galaxy in 45 seconds that rendered a completely black screen. So, is Next N 2.5 mini actually good? I rented a GPU with an MCP server, ran it at full Q8 quality, and put it through 11 hard tests. Some results are genuinely impressive, some are not. Next N 2.5 mini is from Next AGI. It’s an

[00:32] open weights Agentech model built on the Qwen 3.5 mixture of experts architecture with a 262,000 token context window and vision input. The authors pitch it for coding tool use, computer use, and something they call self-correction through visual feedback where the model looks at a screenshot of its own work and fixes it. Their benchmark table makes big claims. 82.9 on OS World G, which is clicking the right element in a screenshot, and that’s higher than Claude Opus 5 on that chart. 89.7 on Omni dog for reading

[01:05] documents. 73 on terminal bench. But, these are the full precision model in their own harness. I wanted to know what you get from a quantized GGUF on a single rented GPU. First, the GPU. Instead of clicking around a website, I asked Claude code to rent it for me using the RunPod MCP server. It listed every GPU with at least 48 GB, checked live capacity, and picked an A100 80 GB in secure cloud at $1.59 I gave it one safety rule. If the price

[01:35] comes back above 170, delete the pod immediately. The price came back at exactly 159 and the pod was running. Now, real life, my usual SSH key had a passphrase. So, I swapped the pod to a different key, which restarts it. The first llama.cpp build failed because the CUDA compiler wasn’t on the path and the system CMake was too old. After fixing that, the Q8 model 36.9 GB plus the Vision projector loaded in about 9 seconds using 41.8 GB of VRAM with the full 262,000 token context. And it is

[02:08] fast. About 90 tokens a second on the very first call, around 126 tokens a second on long generations, and prompt processing between 700 and 3,000 tokens a second. For a model this capable on 1 A100, that’s excellent. Here’s the gauntlet, a WebGL Galaxy, a playable game rebuilding a website from a screenshot, a dashboard. It has to fix by looking at its own screenshots, reading its own benchmark chart, clicking targets in real screenshots, an

[02:39] agent loop with tools, a needle in a 150,000 token haystack, a hard algorithm I actually execute, a logic puzzle, and an honesty trap. Every output here is real. Test one, and the first surprise, with default adaptive thinking, and a 32,000 token budget, the Galaxy prompt produced 88,000 characters of reasoning and then got cut off. No HTML at all. And it wasn’t a one-off. The website rebuilt did the same at 95,000

[03:10] characters, the game at 76,000, and the algorithm at 109,000. On open-ended creative code, this model can think itself to death. So, I retried with thinking turned off. The Galaxy came back in 45 seconds, a polished page called Nebula Forge, 70,000 stars, no JavaScript errors, and a completely black canvas. The console showed WebGL errors index out of range. The model had passed a number into get a triple location instead of an attribute name.

[03:40] This is where it gets good. I send the model its own error and the few lines of buffer code and ask for a minimal fix. It diagnosed it exactly, size is not an attribute name, so the lookup returns minus one. It used the shaders layout locations instead. I applied its fix and there it is. 70,000 stars in spiral arms, drag to orbit, scroll to zoom. One bug shipped, one bug self-fixed. Then I gave thinking mode a real budget, 110,000 tokens. It thought for 122,000

[04:13] characters, wrote 56,000 tokens, took 7 and 1/2 minutes. And this time it shipped working code on the first try. NGC 7742, 90,000 stars, three arms, a temperature color scale, auto orbit, and a star count switcher running at 60 frames per second on my laptop. The default camera sits a bit too close to one arm, but it is genuinely beautiful. Now, the vision claims. I gave it the image of its own benchmark chart and asked it to extract every number as JSON. Nine charts, 61 numbers. It got

[04:45] all 61 exactly right. That OmniDoc score is believable. Next, computer use grounding. Five real screenshots, find the element, and give a click point on a zero to 1,000 scale. On GitHub, it nailed all three, the star button, the green code button, and the issues tab. On Hacker News, the comments link of the first story was a hit right at the edge of the text. But for the login link, it ignored the zero to 1,000 scale entirely and answered with a number over a thousand, so the click falls off the screen. Four out of five.

[05:17] And a quick confession, my own scoring bucks for that comments link was wrong at first. I caught it by checking the pixels and fixed the score. Screenshot to website with thinking on and overthought again. With thinking off, it rebuilt Hacker News in 35 seconds. Every story title, domain, point count, username, and comment count is correct, but the layout is off. Each story is split across four lines and the centered column is missing. Great at reading, weaker at reproducing layout. And this is the test that matters most for their

[05:48] pitch, visual self-correction. With thinking on, its first dashboard looked strong, but when I fed it the screenshot, it over thought and ran out of tokens. So, I ran the loop with thinking off. It built a dashboard, I screenshotted it and fed the image back, and its description was accurate. About 440 pixels of empty space on the left, the chart clipped, the legend cut off. It saw every problem. Then it sent back corrected code, and the new screenshot had the exact same empty column. Round two, same diagnosis, same result. It can

[06:20] see the bug, it couldn’t fix it. The breakout game was the hardest lesson. With thinking off, it shipped a slick neon game in 87 seconds, but the demo AI never played, and the canvas was tiny. I sent it the bugs four times round one. It found real problems and fixed the canvas size, but its fixed launched the ball in a way that switched the AI off. Round two, it blamed the wrong function, and to be fair, my own prompt mislabeled one line, which I corrected. Round three with thinking on, it thought for 127,000

[06:50] characters and ran out of tokens. Round three with thinking off, it sent a patch containing code that can never run. Four attempts, and the demo still doesn’t play itself. The agent test went much better. A real node project with a failing test and a broken build, and three tools, run shell, read file, and write file. In seven turns, it explored the project, read every file, found that the test was missing its auth header, and that the build config didn’t exist. Fixed both, then ran the tests and the build to verify. Both passed. Tool calls

[07:21] work natively through llama.cpp. Long context. I had a walled code at 37% depth inside 24,000, 97,000, and 151,000 tokens of filler. It found all three. The 151,000 token prompt was processed at over 2,500 tokens a second, 61 seconds end to end. The hard algorithm, maximum edge weight on tree paths with binary lifting for 200,000 nodes and queries. I ran every answer against brute force on 300 random

[07:53] trees. Thinking off answered in 5 seconds and was wrong, 86 out of 300. Thinking on answered in under 4 minutes and was perfect, 300 out of 300. And solved the full-size test in 1.9 seconds. Same pattern on a logic puzzle about five people in a row. With thinking it correctly said the clues allow three different orders, which I verified by brute force. With thinking off it confidently announced there was only one possible order, wrong. And for the honesty trap, a fake Stanford study, it

[08:23] refused to invent anything and asked for DOI, good. So, here’s the scoreboard. Clear wins, reading charts, 61 out of 61. Long context, three out of three. The agent loop, the algorithm with thinking, honesty, and speed. Mixed grounding at four out of five. The website rebuilt and the galaxy that needed one self-fix. Losses, five overthinking deaths at the default budget. Broken first drafts on visual code. A self-correction loop that describes problems but doesn’t fix them.

[08:55] And a game it couldn’t repair in four tries. Pros, one, it’s fast, over 120 tokens a second on one A100. Two, excellent vision reading and document extraction. Three, long context that actually works. Four, a solid agent loop with native tool calls. Five, when it does think, the code quality is high. And six, it’s Apache 2.0 and the Q8 fits a single 80 GB GPU with the full context. Cons, one, adaptive thinking can burn 100,000

[09:25] characters and never answer. So, you need big budgets or thinking off. Two, thinking off is fast but ships bugs and wrong answers. Three, visual self-correction. The headline feature didn’t work in my test. Four, it sometimes ignores output format rules like that coordinate scale. And five, this was a GGUF quant in llama.cpp, not their official harness, so your results may differ. And the bill, at the end, I asked Claude code to shut everything down through the MCP server again. It stopped the pod,

[09:57] deleted it, confirmed zero pods were running, and pulled billing. $12.67 for about 8 GPU hours at 159. That’s more than I planned because I left the pod running through setup, build fixes, and long waits. Lesson learned, tear the GPU down the moment the tests are done. My verdict, Next 72.5 mini is a genuinely strong open model for reading long documents and agent tool use, and it’s fast for creative coding. Give thinking a large budget and expect to send it its own errors. Just don’t trust the

[10:28] self-correction patch yet. Links to the model and the GGUF are in the description. Tell me what you [clears throat] want me to test next.