Recursive Flint: este modelo open source local para programação é insano! (testado com Pi, OpenCode e PandaCode)

Autoria: AICodeKing · 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: Recursive Flint: This OPEN Local Coding Model is CRAZY! (Tested with Pi, OpenCode & PandaCode) · Canal: AICodeKing · 10:56 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Ferramentas de desenvolvimento com IA, Modelos locais e open source

Resumo

O vídeo apresenta Flint, um modelo open source da Recursive voltado para programação com agents no computador do usuário, e testa seu desempenho em tarefas práticas. O apresentador mede a velocidade com llama.cpp, explica a configuração com Pi e OpenCode no PandaCode e observa que o desempenho cai conforme o context fica maior. Nos testes, Flint corrige bugs e cria uma API de forma confiável, além de gerar uma página frontend e um jogo com pequenos problemas. A conclusão é que o modelo é uma opção interessante para tarefas focadas, uso privado ou offline, mas não substitui modelos de ponta em trabalhos grandes.

Pontos-chave

Flint é um modelo mixture of experts com 40 bilhões de parâmetros no total e cerca de 2,5 bilhões ativos por token.
Os pesos estão no Hugging Face sob a licença Apache 2.0, e o modelo pode ser usado sem pagar por uma API.
A velocidade varia conforme o tamanho do context; em execuções longas com agents, caiu para cerca de 9 tokens por segundo.
O apresentador testou Flint com Pi e OpenCode usando PandaCode como interface.
O teste de correção de bugs encontrou e corrigiu seis problemas sem alterar os arquivos de teste.
A API de encurtamento de links passou nos 14 testes e também funcionou nas verificações manuais.
A página de frontend ficou visualmente boa, mas tinha ícones de check grandes demais na seção de preços.
Para obter bons resultados com um modelo local pequeno, o apresentador recomenda manter as tarefas curtas e o escopo restrito.

Capítulos

Início	Capítulo	Resumo
00:03	Flint: modelo, licença e alegações de desempenho	O vídeo apresenta a arquitetura, a licença, as ferramentas compatíveis e as alegações da Recursive sobre Flint.
02:40	Configuração e velocidade local	O apresentador configura Flint com llama.cpp, mede a velocidade e mostra como o context longo afeta o desempenho.
05:46	Testes práticos com Pi e OpenCode	Flint é avaliado em tarefas de frontend, correção de bugs, criação de uma API e desenvolvimento de um jogo.
08:51	Conclusões e casos de uso	O apresentador resume os resultados e recomenda Flint para tarefas focadas, privadas ou offline.

Citações

Ele executa programação agentic no seu próprio computador, e faz isso rápido. — 00:03

Então, você começa direto na zona de context longo. — 04:13

Todos os sete testes passaram, e ele não tocou nos arquivos de teste. — 07:20

Com um modelo local pequeno, mantenha o escopo restrito. — 08:51

Eu usaria para tarefas focadas, como correções de bugs, pequenas funcionalidades e testes. — 10:23

Conceitos e entidades

Flint (modelo): Modelo local open source da Recursive, voltado para programação agentic em computadores pessoais.
Recursive (empresa): Empresa que desenvolveu Flint e disponibilizou seus pesos sob a licença Apache 2.0.
Rec (ferramenta): Pequeno mecanismo de inference da Recursive para Macs, otimizado para chips específicos.
llama.cpp (ferramenta): Ferramenta usada no vídeo para executar Flint localmente e medir sua velocidade.
Pi (ferramenta): Harness de programação com agents usado nos testes de frontend e correção de bugs.
OpenCode (ferramenta): Harness de programação com agents usado nos testes de backend e de criação de um jogo.
PandaCode (ferramenta): Aplicativo desktop de código aberto do apresentador, usado como interface para Pi e OpenCode.
Hugging Face (empresa): Plataforma onde os pesos e arquivos de configuração de Flint estão disponíveis.
Apache License 2.0 (conceito): Licença sob a qual os pesos de Flint são disponibilizados.
Mixture of Experts (conceito): Arquitetura de Flint com 40 bilhões de parâmetros totais e aproximadamente 2,5 bilhões ativos por token.

Tradução completa (pt-BR)

00:03 Olá. Bem-vindos a mais um vídeo. Há um novo modelo aberto chamado Flint. Ele vem de uma empresa chamada Recursive. E foi feito para uma única coisa: executar programação agêntica no seu próprio computador, e fazer isso rápido. Flint é um modelo de mistura de especialistas. Tem 40 bilhões de parâmetros no total, mas apenas cerca de 2,5 bilhões ficam ativos para cada token. É por isso que ele pode ser rápido em um laptop. A Recursive diz que uma equipe pequena o construiu do zero em menos de quatro meses, com a ajuda de agents de pesquisa automatizada. Os

00:33 pesos estão no Hugging Face sob a licença Apache 2.0. Então, você pode usá-lo para qualquer coisa que quiser, sem pagar por uma API. Ele funciona com llama.cpp, ollama, LM Studio, Unsloth, vLLM e SGLang. A Recursive também criou seu próprio pequeno mecanismo de inference para Macs, chamado Rec. Agora, vamos falar das afirmações da empresa. A Recursive diz que Flint é o melhor modelo de mistura de especialistas com menos de 50 bilhões de parâmetros no SWE-bench Pro, Terminal Bench e SWE-bench Verified. Também diz que ele programa tão bem quanto modelos densos com 25 a 40

01:04 bilhões de parâmetros, mas executa mais de cinco vezes mais rápido. A empresa afirma que ele processa mais de 125 tokens por segundo em um MacBook Pro M4 Pro e mais de 150 tokens por segundo em um RTX Spark. Ele oferece suporte a até 512.000 tokens de contexto, mas a recomendação é ficar abaixo de 256.000. Agora, uma coisa antes de começarmos: não vou testá-lo no KingBench. O KingBench foi feito para os grandes modelos de ponta, e Flint é um modelo pequeno que roda em um laptop. Se eu o colocasse lado a lado com esses modelos, ele perderia, e isso não seria útil para você. Então,

01:37 isso não seria justo. Em vez disso, dei a ele o tipo de trabalho que você realmente daria a um modelo local e verifiquei pessoalmente cada resultado. Também fiz tudo isso dentro do Panda Code. Se você não conhece, Panda Code é meu aplicativo de desktop gratuito e open source para agentes de programação. Pi e OpenCode agora têm suporte completo no Panda Code, e esses são exatamente os dois harnesses que a Recursive recomenda para Flint. Então, o momento é ótimo. Também vou mostrar como configurar tudo. Vamos direto ao assunto. Primeiro, a configuração. Meu Mac é um M4 Max com 48 GB de

02:09 memória. A Recursive diz que você precisa de pelo menos 48 GB, então estou no limite exato. O jeito mais fácil é usar o Rec. Você o instala com um comando curl e depois executa rec.launch.py. Isso baixa o modelo, inicia o servidor e abre o Pi para você. Mas aqui vem a parte engraçada: quando executei o Rec, ele disse que meu Mac não atende aos requisitos. Ele só oferece suporte ao M4 Pro, ao M5 Pro e ao M5 Max. Então, o M4 Max fica de fora, mesmo sendo o chip mais rápido. Isso acontece porque o Rec usa kernels personalizados, ajustados para cada chip.

02:40 Espero que adicionem suporte a mais chips em breve, porque é no Rec que está a maior parte da velocidade. A Recursive diz que ele é de 1,4 a 2,6 vezes mais rápido que o llama.cpp. Então, usei o llama.cpp. Quando fiz o teste, o suporte a Flint no llama.cpp ainda estava em um pull request aberto, então compilei o llama.cpp por conta própria, a partir daquele branch. Se você estiver assistindo a isto um pouco mais tarde, provavelmente o pull request já foi integrado, e uma atualização normal deve funcionar. Depois, baixei o INT4_GGUF do Hugging Face. O repo é Recursive-SI/Flint

03:11 INT4_GGUF, e o arquivo tem cerca de 26 GB. O repo também tem dois pequenos arquivos de configuração, um para Pi e outro para OpenCode, o que é ótimo. Para iniciar o servidor, você executa llama-server com o arquivo do modelo, a flag –ginger e as configurações de amostragem recomendadas pela Recursive. A temperatura é 1, top P é 0,95 e top K é 20. O comando completo está no model card, e também vou colocá-lo na descrição. Agora, vamos falar de velocidade, porque esse é o principal objetivo deste modelo.

03:41 Com o llama.bench, Flint processou cerca de 110 tokens por segundo na geração, com prompts curtos. Ele leu prompts a cerca de 3.000 tokens por segundo. Isso é muito rápido para um modelo desse tamanho. Mas a velocidade diminui conforme o contexto fica mais longo. Com 8.000 tokens de contexto, ele processou cerca de 52 tokens por segundo. Com 32.000 tokens, cerca de 32 tokens por segundo. E isso importa muito para agents. Agents de programação enviam prompts grandes. Nas minhas execuções, o primeiro prompt do Pi tinha

04:13 cerca de 17.000 tokens. E o primeiro prompt do OpenCode tinha cerca de 26.000 tokens. Então, você já começa direto na faixa de contexto longo. Nas execuções reais com agents, vi principalmente entre 40 e 60 tokens por segundo. Em uma execução longa, o contexto chegou a cerca de 115.000 tokens, e a velocidade caiu para cerca de nove tokens por segundo. Então, ele é rápido, mas mantenha as tarefas curtas e focadas. Além disso, considere esses números com cautela. Usei o llama.cpp com um pull request que, segundo o autor, ainda apresenta uma lentidão de 10% a 30%, e que ainda não tinha sido

04:44 integrado. Agora, vamos configurá-lo no Panda Code. Para o Pi, copie a configuração do Pi do repo no Hugging Face para a pasta do Pi, com o nome models.json. Essa é a pasta .pi/agent, dentro da sua pasta pessoal. Para o OpenCode, adicione o bloco do provedor Flint, que está na configuração do OpenCode, à sua própria configuração do OpenCode. Agora, abra o Panda Code. Clique no seletor de modelo, e Flint já estará lá, tanto em Pi quanto em OpenCode. Você não precisa configurar mais nada no Panda Code. Ele lê o modelo diretamente do Pi e do OpenCode. Aí, você tem tudo o que tem com qualquer outro agent: o chat, os diffs, os modos de permissão e o quadro de tarefas. Com o Pi, você pode até pressionar

05:15 Command+Enter para orientá-lo enquanto ele está trabalhando. Usei as equipes de agents do Panda Code para minhas tarefas. Então, tinha um líder que encaminhava cada tarefa para um worker, e os workers rodavam no Pi ou no OpenCode com Flint. Você pode ver todas as execuções aqui na barra lateral. Uma dica: o llama.cpp rodou com um slot aqui. Então, executei os workers um depois do outro, não ao mesmo tempo. Agora, um detalhe importante se você usa o OpenCode: ele para de esperar por uma resposta do modelo após cinco minutos sem resposta. Com um modelo local, ler um prompt de 26.000 tokens

05:46 pode levar esse tempo, porque o servidor não envia nada até terminar de ler o prompt inteiro. Então, o OpenCode desistia e tentava de novo, repetidamente, e nada acontecia. A solução é simples. Nas opções do provedor Flint, na configuração do OpenCode, defina header timeout e timeout como false. Depois disso, funcionou bem. Agora, vamos aos testes. O primeiro foi um teste de frontend no Pi. Pedi uma página inicial para um aplicativo fictício de anotações chamado Ember Notes. Ela precisava ter uma barra de navegação fixa, uma seção principal, seis cartões de recursos com ícones, preços com uma opção para alternar entre mensal e anual, uma seção de perguntas frequentes, um botão de modo escuro

06:19 que se lembrasse da sua escolha e um rodapé, tudo em um único arquivo HTML, sem bibliotecas. E ficou bonita. O design é limpo. As cores combinam bem e a tipografia é agradável. A opção anual reduz os preços em 20%, como deveria. O botão de modo escuro funciona e a página continua escura quando você a recarrega. A seção de perguntas frequentes abre e fecha, e a página funciona bem em uma tela do tamanho de um celular, mas há um erro evidente. Nos cartões de preços, os ícones de marca de seleção não têm tamanho definido, então aparecem enormes e estragam toda a seção de preços. É fácil

06:49 de corrigir, mas você perceberia o problema na mesma hora. Esse teste também demorou bastante, cerca de uma hora. O Pi continuou aumentando o contexto e, em uma rodada, Flint gerou cerca de 35.000 tokens. Então, o contexto ficou muito longo e, como eu disse, a velocidade cai bastante nessa situação. O segundo teste foi a correção de um bug, também no Pi. Criei uma pequena biblioteca de carrinho de compras com seis bugs e uma suíte de testes. Seis dos sete testes falharam. Pedi que corrigisse o código-fonte sem mexer nos testes, e ele se saiu muito bem. Encontrou os seis bugs. Corrigiu um

07:20 bug de arredondamento de ponto flutuante ao converter preços para centavos. Ele corrigiu o zero à esquerda que faltava ao formatar os centavos. Ele juntou itens com o mesmo código de produto, em vez de adicioná-los duas vezes. Encontrou um limite de desconto de 50% que estava declarado no código, mas nunca era usado, e o aplicou. Corrigiu a regra de frete grátis, então agora exatamente US$ 50 contam. E calculou o imposto sobre o preço com desconto. Agora, os sete testes passaram, e ele não mexeu nos arquivos de teste. Isso levou cerca de 7 minutos e meio. Esse é

07:50 o tipo de tarefa em que um modelo local pequeno faz muito sentido. O terceiro teste foi um de backend no Open Code. Pedi uma API de encurtador de links em Node, sem dependências. Ela precisava de endpoints para criar, redirecionar, consultar estatísticas e excluir, validação de URL, uma verificação de slugs duplicados, gravação segura em um arquivo JSON, um limite de taxa e testes. Ele escreveu o servidor e 14 testes, e os 14 passaram. Não parei por aí, então também iniciei o servidor e testei manualmente. Um slug duplicado retorna 409.

08:21 Um link FTP ou um JSON inválido retorna 400. O redirecionamento funciona e conta o clique. A exclusão retorna 24 e, depois disso, o link desaparece. E o limite de taxa entra em ação exatamente na 31ª solicitação em um minuto. Ele também grava primeiro o arquivo JSON em um arquivo temporário e depois o renomeia, para que o arquivo de dados não seja corrompido. Então, com certeza, este é um resultado sólido. Levou cerca de 9 minutos. Agora, uma coisa que notei no Open Code: na minha primeira tentativa, Flint começou a pesquisar minha

08:51 pasta inteira de anotações em busca de exemplos de encurtadores de URL antes de escrever qualquer código. Minha pasta de anotações é enorme, então o contexto encheu rápido. Quando pedi que trabalhasse apenas na própria pasta e começasse a escrever imediatamente, terminou em 9 minutos. Então, com um modelo local pequeno, mantenha o escopo restrito. O quarto teste foi um jogo no Open Code. Pedi um Breakout em um único arquivo HTML, com controles do mouse e das teclas de seta, ângulo de quique baseado no ponto em que a bola atinge a raquete, pontuação e vidas, uma segunda fase, telas de pausa, início e fim de jogo, e uma pontuação recorde.

09:22 E dá para ver que ficou muito bonito. Tem um estilo neon, com brilho em tudo. A tela inicial funciona. A bola e a raquete funcionam. Os tijolos se quebram. A pontuação aumenta, e você perde vidas. P pausa o jogo. A fase dois usa uma grade um pouco diferente, e a bola é bem mais rápida. A pontuação recorde é salva quando o jogo termina. A disposição da fase dois poderia ser mais diferente, mas, no geral, funciona bem. Levou cerca de 13 minutos. Então, o que eu acho? Para um modelo que roda em um laptop, Flint é muito bom. A correção do bug e a API de backend estavam ambas corretas, e eu mesmo conferi. O trabalho de frontend parece bom, mas você

09:53 vai precisar corrigir pequenas coisas, como aquelas marcas de seleção, e não custa nada para usar, o que é simplesmente incrível. O principal é a velocidade, e ela varia um pouco. Em tarefas curtas, é muito rápido. Em execuções longas de agent, a velocidade cai bastante, pelo menos no llama.cpp atualmente. Se você tem um M4 Pro, um M5 Pro ou um M5 Max, use o Rec, porque foi para isso que a Recursive o criou. Se não tiver, o llama.cpp funciona, mas mantenha as tarefas curtas. Ele não vai substituir um modelo de ponta em tarefas grandes, mas, para código privado, para trabalhar offline ou simplesmente para não pagar por cada token, é uma

10:23 opção muito boa. Pessoalmente, eu o usaria para tarefas específicas, como correções de bugs, pequenos recursos e testes. E, se quiser usá-lo com uma interface bacana, ele funciona com Pi, Open Code e Panda Code. Você adiciona a configuração uma vez, e Flint aparece no seletor de modelos. No geral, é bem legal. Enfim, contem nos comentários o que acharam. [música] Se gostou deste vídeo, considere fazer uma doação pela opção Super Thanks ou se tornar membro clicando no botão [música] Seja membro. Além disso, curta este vídeo e inscreva-se no meu canal. Vejo vocês no próximo. Até lá, tchau.

10:56 >> [música]

Transcrição original

[00:03] Hi. Welcome to another video. So, there’s a new open model called Flint. It comes from a company called Recursive. And it’s made for one thing. It runs agentic coding on your own computer, and it does it fast. Flint is a mixture of experts model. It has 40 billion parameters in total, but only about 2.5 billion of them are active for each token. That is why it can be fast on a laptop. Recursive says that a small team built it from scratch in under 4 months with help from automated research agents. The

[00:33] weights are on hugging face under the Apache 2.0 license. So, you can use it for anything you want, and you don’t pay for an API. It works with llama.cpp, ollama, LM Studio, Unsloth, vLLM, and SGLang. Recursive also made its own small inference engine for Macs called Rec. Now, let’s talk about their claims. Recursive says that Flint is the best mixture of experts model under 50 billion parameters on SweeBench Pro, Terminal Bench, and SweeBench Verified. They also say that it codes about as well as dense models with 25 to 40

[01:04] billion parameters, but runs more than five times faster. They say it does more than 125 tokens per second on an M4 Pro MacBook Pro, and more than 150 tokens per second on an RTX Spark. It supports up to 512,000 tokens of context, but they recommend that you stay under 256,000. Now, one thing before we start, I’m not going to test this on KingBench. KingBench is made for the big frontier models, and Flint is a small model that runs on a laptop. If I put it next to those models, it would lose, and that wouldn’t tell you anything useful. So,

[01:37] that wouldn’t be fair. Instead, I gave it the kind of work that you would actually give a local model, and I checked every result myself. I also ran all of it inside Panda Code. If you don’t know, Panda Code is my free and open source desktop app for coding agents. Pi and Open Code are both fully supported in Panda Code now, and those are exactly the two harnesses that Recursive recommends for Flint. So, this is kind of great timing. I’ll show you how to set that up as well. So, let’s get right into it. First, the setup. My Mac is an M4 Max with 48 GB of

[02:09] memory. Recursive says that you need at least 48 GB, so I’m right at the limit. The easy way is Rec. You install it with one curl command, and then you run rec.launch.py. That downloads the model, starts the server, and opens Py for you. But, here’s the funny part. When I ran it, Rec Rec said that my Mac doesn’t meet the requirements. It only supports the M4 Pro, the M5 Pro, and the M5 Max. So, the M4 Max is out, even though it’s the faster chip. That’s because Rec uses custom kernels that they tuned for each chip.

[02:40] I hope they add more chips soon, because Rec is where most of the speed is. Recursive says that it’s 1.4 to 2.6 times faster than llama.cpp. So, I used llama.cpp instead. When I tested it, Flint support in llama.cpp was still an open pull request, so I built llama.cpp from that branch myself. If you’re watching this a bit later, it’s probably merged by now, and a normal update should work. Then I downloaded the INT4_GGuf from Hugging Face. It’s the repo Recursive SI/Flint

[03:11] INT4_GGuf, and the file is about 26 GB. The repo also has two small config files, one for Py and one for Open Code, which is nice. To start the server, you run llama server with the model file, the –ginger flag, and the sampling settings that Recursive recommends. That’s a temperature of 1, top P of 0.95, and top K of 20. The full command is in the model card, and I’ll put it in the description, too. Now, let’s talk about speed, because that’s the main point of this model.

[03:41] With llama.bench, Flint did about 110 tokens per second of output on short prompts. It read prompts at about 3,000 tokens per second. That is really fast for a model of this size. But the speed goes down as the context gets longer. At 8,000 tokens of context, it did about 52 tokens per second. At 32,000 tokens, it did about 32 tokens per second. And this matters a lot for agents. Coding agents send big prompts. In my runs, the first prompt from Pi was

[04:13] about 17,000 tokens. And the first prompt from Open Code was about 26,000 tokens. So, you start in the long context zone right away. In the real agent runs, I mostly saw between 40 and 60 tokens per second. In one long run, the context grew to about 115,000 tokens, and the speed went down to about nine tokens per second. So, it’s fast, but keep your tasks short and focused. Also, take these numbers with a grain of salt. This was llama.cpp with a pull request that the author says still has a 10 to 30% slow down, and it wasn’t

[04:44] wreck. Now, let’s set it up in Panda Code. For Pi, copy the Pi config from the Hugging Face repo into your Pi folder as models.json. That’s the .pi/agent folder in your home folder. For Open Code, add the Flint provider block from the Open Code config to your own Open Code config. Now, open Panda Code. Click the model picker, and Flint is already there under Pi and under Open Code. You don’t need to set anything else in Panda Code. It reads the model straight from Pi and Open Code. Then you get everything that you get with any other agent. You get the chat, the diffs, the permission modes, and the task board. With Pi, you can even press

[05:15] command enter to steer it while it’s working. I used Panda Code’s agent teams for my tasks. So, I had one lead that sent each task to a worker, and the workers ran on Pi or Open Code with Flint. You can see all the runs here in the sidebar. One tip, llama.cpp ran with one slot here. So, I ran the workers one after the other, not at the same time. Now, one important thing if you use Open Code, Open Code stops waiting for a model after 5 minutes with no response. With a local model, reading a 26,000 token

[05:46] prompt can take that long because the server sends nothing until it has read the whole prompt. So, open code gave up and tried again and again and nothing happened. The fix is simple. In the Flint provider options in your open code config, set header timeout and timeout to false. After that, it worked fine. So, let’s look at the tests. The first test was a front-end one in Pi. I asked for a landing page for a made-up notes app called Ember notes. It had to have a sticky navbar, a hero, six feature cards with icons, pricing with a monthly and yearly switch, an FAQ, a dark mode

[06:19] switch that remembers your choice, and a footer, all in one HTML file with no libraries. And it looks good. The design is clean. The colors work well together and the typography is nice. The yearly switch takes 20% off the prices like it should. The dark mode switch works and it stays dark when you reload the page. The FAQ opens and closes and the page holds up well on a phone-sized screen, but there’s one clear bug. In the pricing cards, the checkmark icons have no size, so they show up huge and break the whole pricing section. It’s an easy

[06:49] fix, but you would notice it right away. This one also took a long time, about an hour. Pi kept adding to the context and in one turn, Flint wrote about 35,000 tokens. So, the context got very long and as I said, the speed drops a lot at that point. The second test was a bug fix, also in Pi. I made a small shopping cart library with six bugs and a test suite. Six of the seven tests failed. I told it to fix the source code without touching the tests and it did really well. It found all six bugs. It fixed a

[07:20] float rounding bug when converting prices to cents. It fixed the missing zero padding when formatting cents. It merged items with the same product code instead of adding them twice. It found a 50% discount cap that was declared in the code but never used and it applied it. It fixed the free shipping rule, so exactly $50 now counts. And it calculated tax on the discounted price. All seven tests passed now, and it didn’t touch the test files. This took about 7 and 1/2 minutes. That is

[07:50] the kind of task where a small local model makes a lot of sense. The third test was a back-end one in open code. I asked for a link shortener API in node with no dependencies. It needed create, redirect, stats, and delete endpoints, URL validation, a check for duplicate slugs, saving to a JSON file safely, a rate limit, and tests. It wrote the server and 14 tests, and all 14 passed. I didn’t stop there, so I also started the server and tried it by hand. A duplicate slug gives you a 409.

[08:21] An FTP link or broken JSON gives you a 400. The redirect works, and it counts the click. Delete gives you a 24, and after that, the link is gone. And the rate limit kicks in at exactly the 31st request in a minute. It also writes the JSON file to a temp file first, and then renames it, so the data file doesn’t get corrupted. So, this is a solid result for sure. It took about 9 minutes. Now, here’s one thing I noticed in open code. In my first try, Flint started searching my

[08:51] whole notes folder for examples of URL shorteners before it wrote any code. My notes folder is huge, so the context filled up fast. When I told it to work only in its own folder and to start writing right away, it finished in 9 minutes. So, with a small local model, keep the scope tight. The fourth test was a game in open code. I asked for breakout in one HTML file with mouse and arrow key controls, a bounce angle based on where the ball hits the paddle, score and lives, a second level, pause, start, and game over screens, and a high score.

[09:22] And you can see that it looks really nice. It has a neon style with a glow on everything. The start screen works. The ball and paddle work. Bricks break. The score goes up, and you lose lives. P pauses the game. Level two uses a slightly different grid, and the ball is a lot faster. The high score is saved when the game ends. The level two layout could be more different, but overall this works well. It took about 13 minutes. So, what do I think? For a model that runs on a laptop, Flint is pretty good. The bug fix and the back-end API were both correct, and I checked them myself. The front-end work looks good, but you

[09:53] will need to fix small things like those check marks, and it costs you nothing to run, which is just amazing. The speed is the main point, and it’s a bit mixed. On short tasks, it’s really fast. On long agent runs, the speed drops a lot, at least in llama.cpp right now. If you have an M4 Pro, an M5 Pro, or an M5 Max, use Rec, because that is what Recursive built it for. If you don’t, llama.cpp works, but keep your tasks short. It’s not going to replace a frontier model for big tasks, but for private code, for working offline, or just for not paying for every token, this is a

[10:23] really good option. Personally, I’d use it for focused tasks like bug fixes, small features, and test. And if you want to use it with a nice interface, it works with Pi and Open Code and Panda Code. You add the config once, and Flint shows up in the model picker. Overall, it’s pretty cool. Anyway, let me know your [music] thoughts in the comments. If you like this video, consider donating through the Super Thanks option, or becoming a member by clicking [music] the join button. Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye.

[10:56] >> [music]