Recursive Flint v1.0: um modelo de codificação de 40B construído majoritariamente por seu próprio ciclo de pesquisa

A frase mais interessante no Recursive Flint v1.0 lançamento não é uma pontuação de benchmark. É aquela em que a Recursive diz que uma pequena equipe construiu do zero um modelo de programação de 40 bilhões de parâmetros em menos de quatro meses, com um sistema automatizado de pesquisa chamado Eureka Machine contribuindo para quase todas as etapas. O Flint está anunciado como um forte modelo local de programação — 39,8 bilhões de parâmetros no total, cerca de 2,5 bilhões ativos por token, Apache 2.0, tranquilo em um notebook. Mas o lançamento também é o primeiro teste público de uma proposição diferente: que o processo de construir um modelo pode, ele mesmo, ser amplamente automatizado. As duas leituras estão no anúncio. Apenas uma delas é reproduzível por você.

Flint foi lançado em 21 de outubro de 2026 sob a Apache 2.0, com os pesos no Hugging Face como RecursiveSI/flint. É o primeiro modelo da Recursive, o laboratório fundado pelo ex-cientista-chefe da Salesforce Richard Socher, e chegou há quatro dias — recente o suficiente para que quase nada sobre ele tenha sido testado fora do laboratório que o criou.

O que a Recursive realmente lançou

Quatro repositórios, não um só. O repositório principal de checkpoint contém pesos BF16, a configuração, o tokenizador, o template de chat e um kit de serviço SGLang, e foi criado em 21 de outubro de 2026 às 14:20 UTC. Três builds quantizados ficam ao lado dele, todos datados da mesma tarde: uma build int4 em safetensors, uma GGUF int4 e uma GGUF NVFP4. Os tamanhos abaixo vêm das próprias listagens de arquivos dos repositórios, e não do anúncio.

• Referência BF16 — 79,59 GB em 37 arquivos. Este é o arquivo que você usa se tiver uma H200 ou B300 e quiser o modelo sem diluição.

• NVFP4 GGUF — 22,86 GB. Esta é a versão que torna literal a afirmação de que "roda em um laptop", e é a que a maioria das pessoas vai realmente baixar.

• int4 GGUF — 25,99 GB, que é maior que o arquivo NVFP4, apesar de uma largura de bits nominalmente semelhante. Se você estiver escolhendo entre os dois apenas com base no espaço em disco, o NVFP4 vence.

• int4 safetensors — 22,58 GB, para stacks de serving que preferem um checkpoint safetensors a um GGUF.

A Recursive alega que seu próprio treinamento de baixa bit e uma cabeça de saída de 4 bits, destilados de volta em direção ao modelo de 16 bits, ficam dentro de 0,7 pontos da precisão total. Esse número é da Recursive, medido na avaliação da Recursive. Os tamanhos dos arquivos não são: qualquer pessoa pode lê-los no repositório.

Os quatro números, e o que cada um está medindo

A Recursive publicou um conjunto de pontuações junto com o lançamento, e a coisa mais importante a entender sobre elas é que todas foram produzidas dentro do próprio harness da Recursive. Nenhum terceiro executou novamente nenhuma delas. O índice Artificial Analysis — o árbitro independente habitual para um modelo como este — não tem nenhuma entrada para o Flint.

• SWE-bench Verified — 74,2%. O benchmark que a maioria dos leitores reconhecerá, que mede se um modelo consegue resolver issues reais do GitHub. A Recursive o executou por meio do mini-swe-agent sem nenhum acesso à internet, calculando a média de pass@1 em pelo menos cinco tentativas, com temperatura 1,0, top-p 0,95, top-k 20.

• SWE-bench Pro v2 — 89,7%. Observe o “v2”. Este não é o mesmo benchmark que o SWE-bench Pro publicado por outros laboratórios, e os dois números não podem ser subtraídos um do outro. Essa distinção importa mais do que parece, e ela se repete toda vez que Flint é comparado a um modelo que reporta SWE-bench Pro sem a designação de versão.

• Terminal-Bench 2.1 — 54,9%. Aqui a Recursive fez algo incomumente honesto e incomumente estranho: executou o Terminus 2 com a internet habilitada e, em seguida, contabilizou como falha qualquer solução obtida por meio de recuperação na web. Essa desvantagem é deliberada, e também significa que esta pontuação não é diretamente comparável a um número do Terminal-Bench produzido sem essa regra.

• LiveCodeBench v6 — 80,3%. Um benchmark de programação competitiva, e não agêntico, portanto o menos sensível à escolha de harness entre os quatro.

• IFBench — 89,2%. Seguimento de instruções, que é onde um modelo pequeno normalmente cede terreno primeiro.

A alegação que a Recursive de fato faz é mais restrita do que a cobertura sugere: o Flint lidera os modelos de mistura de especialistas com menos de 50 bilhões de parâmetros totais no SWE-bench Pro v2, no Terminal-Bench 2.1 e no SWE-bench Verified. Trata-se de uma alegação de classe, não de uma alegação absoluta. Modelos densos de tamanho comparável são excluídos dela por construção — e é exatamente por isso que o Qwen3.8 27B, um modelo denso, aparece no mesmo gráfico com pontuação mais alta na média dos seis testes da própria Recursive. A Recursive publicou isso. Merece crédito por tê-lo publicado.

A alegação da Eureka Machine é a parte que sobrevive ao modelo

Retire os benchmarks e sobra uma história mais incomum. A Recursive diz que seu sistema automatizado de pesquisa gerou ideias, executou experimentos e usou os resultados para escolher quais experimentos executar em seguida. A empresa atribui a ele contribuições em pré-treinamento, pós-treinamento, inferência, quantização e kernels de hardware. Três dessas contribuições são específicas o suficiente para serem verificadas em relação aos artefatos:

• Formato do modelo. O design partiu de uma linha de base 35B-A3B e chegou a 40B no total, com 2,5B ativos. Trata-se de um movimento deliberado em direção a mais capacidade total com o mesmo custo de ativação — mais esparso, não maior no sentido que importa para inferência.

• Quantização. Mover a cabeça de saída para 4 bits e fazer autodestilação de volta a partir do modelo de 16 bits é a receita por trás da alegação de 0,7 ponto, e é por isso que um modelo de 39,8B tem uma build distribuível de 22,86 GB.

• Kernels. A Recursive escreveu um megakernel Metal voltado para os chips M4 e M5, que é o item menos surpreendente da lista, dadas as alegações de throughput, e o mais concreto.

O que a Recursive não divulgou foi quanto tempo dos pesquisadores a Eureka Machine economizou. Essa omissão é o argumento inteiro. Uma alegação de que um sistema automatizou a maior parte do desenvolvimento de modelos só faz sentido se você souber qual foi o custo da alternativa — e a formulação da própria empresa é cuidadosa aqui: o processo continua supervisionado por humanos, e não totalmente autônomo. Leia o comunicado como uma demonstração pública inicial, não como uma prova de autoaperfeiçoamento recursivo.

O que quatro dias de testes práticos podem e não podem lhe dizer

O olhar externo mais substancial sobre o Flint até agora é o de Will Knight, da Wired, que o executou em um Mac com 48 GB de memória e criou um aplicativo de lista de tarefas, uma ferramenta de pesquisa na web e um pequeno site explicativo. Todos os três funcionaram. Esse é um resultado real e não é um benchmark. São três tarefas, uma máquina, uma pessoa.

Um sinal mais útil para quem planeja realmente usar isso vem de avaliadores que mediram a taxa de transferência ao longo de bastante tempo, e não no início de uma sessão. Um teste independente relatou cerca de 110 tokens por segundo com prompts curtos, caindo para cerca de 9 tokens por segundo com cerca de 115.000 tokens de contexto. Trata-se de uma degradação de mais de cinco vezes, e é o número com que se planejar caso seu agente leia um repositório grande antes de escrever qualquer coisa. Os números de velocidade divulgados pela Recursive — mais de 125 tokens por segundo em um M4 Pro, mais de 150 em um RTX Spark de 64 GB — são medidos explicitamente em contexto curto, com o prefill excluído.

Há também um bug conhecido no template de chat no caminho GGUF do llama.cpp. Se carregar a versão quantizada e o modelo se comportar como se tivesse perdido o juízo, verifique o template antes de culpar os pesos.

Rodando isso sem apostar nenhum caminho de produção nisso

Flint é um download, não um endpoint. O OrcaRouter não o serve, e nada aqui deve ser interpretado como uma afirmação de que o fazemos.

O que isso muda é como você deve testá-lo. A forma honesta de avaliar um modelo de pesos abertos com quatro dias é executá-lo ao lado de algo em que você já confia e comparar no seu próprio repositório, não substituí-lo e torcer. Se você já chama modelos hospedados por meio de uma única API, a configuração de baixo risco é manter esse caminho como fallback enquanto o Flint cuida das tarefas que você está disposto a entregar a ele — e deixar uma cadeia de failover capturar as solicitações em que o modelo local trava, em vez de descobrir o travamento em produção. Isso é uma decisão de roteamento, não de lealdade.

A outra coisa que vale saber antes de baixar: o Flint é gratuito para executar, mas não é gratuito para possuir. Um download de 22,86 GB é o ingresso, e a máquina que o comporta confortavelmente é o custo real. Se você estava comparando o preço disso com um modelo hospedado cobrado por token, inclua o hardware no cálculo também.

O que acompanhar no próximo mês

Três coisas vão decidir se Flint será lembrado como um bom modelo pequeno de programação ou como o primeiro ponto de dados de uma discussão mais longa.

O primeiro é uma execução de benchmark independente. Até que a Artificial Analysis ou uma parte neutra comparável lhe atribua uma pontuação, toda comparação envolvendo o Flint é uma comparação entre a autoavaliação de um laboratório e a autoavaliação de outro. O segundo é se o problema de throughput de contexto longo acaba por ser um artefacto do llama.cpp, um problema do motor ou uma propriedade do modelo — essas hipóteses têm correções muito diferentes. O terceiro é se a contribuição da Eureka Machine pode sequer ser avaliada. A Recursive disse que o processo é supervisionado por humanos; a pergunta interessante é qual foi a proporção entre humanos e agentes, e essa é uma pergunta à qual uma publicação de lançamento não foi concebida para responder.

Por enquanto, o resumo defensável é curto. O Flint é um modelo de codificação genuinamente pequeno, genuinamente rápido e genuinamente aberto que roda em hardware que você provavelmente já tem, com um conjunto de pontuações que ninguém verificou e uma história de desenvolvimento que ninguém fora da empresa verificou. Esses dois fatos são a história.