Flint v1.0 vs North Mini Code: Två öppna kodnings-MoE:er som slåss om din laptop

De flesta "versus"-sidor på den här webbplatsen jämför saker som aldrig egentligen var rivaler. Den här är annorlunda. Recursive Flint v1.0 och Cohere North Mini Code är samma typ av objekt: glesa mixture-of-experts-kodmodeller, publicerade under Apache 2.0, tillräckligt små för att köras på hårdvara som en utvecklare redan äger, och båda positionerade som det lokala alternativet snarare än frontier-alternativet. Flint kom den 21 oktober 2026 med 39,8 miljarder parametrar totalt och cirka 2,5 miljarder aktiva per token. North Mini Code kom den 9 juni 2026 med 30 miljarder totalt och 3 miljarder aktiva. Det är tillräckligt nära för att valet hänger på vad som finns i filen och vad som faktiskt har mätts — och i båda avseendena är svaret inte det som rapporteringen vid lanseringen antyder.

De två filerna, dimension för dimension

Börja med vad som finns i lådan, för för två självhostade modeller är detta jämförelsen som håller när den möter verkligheten.

• Totalt antal parametrar — Flint: 39,8B. North Mini Code: 30B.

• Aktiva parametrar per token – Flint: cirka 2,5B, varav 2,2B i kroppen och resten i output-huvudet. North Mini Code: 3B. Nästan identiska, och detta är siffran som styr inferenskostnaden.

• Expertrouting – Flint: 256 routade experter, 6 valda per token plus 1 delad, över 47 MoE-lager och 2 täta lager. North Mini Code: 128 experter, 8 aktiva per token.

• Attention — Flint: en blandning av glidande fönster och globala lager med attention sinks. North Mini Code: ett 3:1-förhållande mellan glidande fönster och globala lager. Båda satsar på samma sak: att de flesta tokens bara behöver lokal attention och att några få behöver hela fönstret.

• Kontext — Flint: 262,144 token dokumenterade på modellkortet, med tillkännagivandet som anger upp till 512K och rekommenderar 256K. North Mini Code: 256K in, 64K maximal utdata.

• Modalitet – Flint: text in, text ut. North Mini Code: text in, text ut. Ingen av dem tar emot bilder, vilket spelar roll om ditt arbete innefattar skärmbilder.

• Licens — båda Apache 2.0, vikter ingår, ingen intäktsgräns.

Publicerade format – Flint: BF16, int4-safetensors, int4-GGUF, NVFP4-GGUF. North Mini Code: BF16, FP8 och W4A16.

• Disk och minne – Flint: 79,59 GB i BF16, 22,86 GB som NVFP4 och cirka 24 GB minne för att köra. North Mini Code: cirka 20 till 24 GB kvantiserat, med Coheres egen demo som körs på en Mac Studio på cirka 20 GB.

Minne är det första snittet, och det är närmare än vad parameterantalen antyder.

En naiv tolkning av 39.8B kontra 30B är att Flint behöver en tredjedel mer minne. Det gör det inte, eftersom båda är glesa och båda publicerar aggressiva kvantiserade byggen. Det du egentligen väljer mellan är en NVFP4-fil på 22.86 GB och ett kvantiserat bygge på ungefär 20 GB – tillräckligt nära för att samma 24 GB-kort ska kunna köra båda, och tillräckligt nära för att ingen av dem är det självklara valet enbart utifrån minnesfotavtryck.

Det som skiljer är marginalen. North Mini Code har rapporterats köra en 4-bitars GGUF på en Ryzen 7 med 32 GB DDR4 – en helt vanlig stationär dator, inte en arbetsstation. Flints påstående om bärbara datorer är mer specifikt: Recursives genomströmningssiffror är uppmätta på en M4 Pro MacBook Pro och på en 64 GB RTX Spark, som båda är premiummaskiner. Filen på 22,86 GB laddas på ett 24 GB-kort. Huruvida den körs i en hastighet som du skulle tolerera är en separat fråga, och det beror i hög grad på motorn.

Om din begränsning är ”maskinen jag redan äger” har North Mini Code fler rapporter om att köras på oansenlig hårdvara. Om din begränsning är ”den bästa maskinen jag äger” är Flint den nyare arkitekturen och den snabbare vid kort kontext.

En av dessa har en oberoende resultattavla

Det här är den del av jämförelsen som de flesta recensioner hoppar över, och det är den del som borde avgöra ett inköpsbeslut.

North Mini Code har mätts av Artificial Analysis. Det får 33,4 på AA Coding Index och 27,6 på AA Intelligence Index, med SWE-bench Verified på 67,6 pass@1 och 80,2 pass@10, samt 61,0 på mini-SWE-Agent. Dessa är tredjepartsmätningar som tagits fram enligt ett konsekvent protokoll, vilket innebär att de kan jämföras med andra modeller på samma index utan en fotnot om testramverk.

Flint har inget uppslag hos Artificial Analysis. Dess publicerade resultat – 74,2 på SWE-bench Verified, 89,7 på SWE-bench Pro v2, 54,9 på Terminal-Bench 2.1 – kommer från Recursives eget testramverk, och ingen har kört om dem. Metodiken är redovisad, vilket är till Recursives förtjänst: mini-swe-agent utan internet för SWE-bench-körningarna, Terminus 2 med internet för Terminal-Bench men alla lösningar som hämtats via webben räknas som misslyckanden, pass@1 genomsnittligt över minst fem försök. Redovisad metodik är inte verifierad metodik.

Så kan du jämföra {{1}}67,6{{/1}} med {{2}}74,2{{/2}}? Inte på ett ansvarsfullt sätt. De togs fram av olika organisationer på olika testramverk med olika regler, och gapet – {{3}}6,6 poäng{{/3}} – ligger väl inom det intervall som valet av testramverk ensamt kan flytta en poäng. Det du kan säga är snävare och fortfarande användbart: siffran för {{4}}North Mini Code{{/4}} har kontrollerats av någon som inte byggde modellen, och det har inte siffran för {{5}}Flint{{/5}}. Om du väljer utifrån bevis snarare än utifrån specifikationer, är det den asymmetrin som spelar roll.

Det finns ytterligare en datapunkt i North Mini Codes kolumn som är ofördelaktig och värd att ha: Artificial Analysis flaggade den som ovanligt ordrik och förbrukade cirka 75 miljoner output-tokens i testning jämfört med ett klassmedian på nära 25 miljoner. Ordrikedom är en kostnadsmultiplikator i en agentloop. En modell som tänker högt tre gånger så mycket kan vara billigare per token och dyrare per uppgift.

Hastighetsbilden förändras helt vid lång kontext.

Båda modellerna är snabba vid korta prompter, och båda saktar ner när kontexten fylls. Skillnaden är hur mycket.

• Flint — Recursive hävdar 125+ tokens per sekund på en M4 Pro MacBook Pro och mer än 150 på en 64 GB RTX Spark, mätt vid kort kontext med prefill exkluderat. Oberoende tester rapporterade cirka 110 tokens per sekund vid korta prompter, som sjönk till ungefär 9 tokens per sekund nära 115 000 tokens kontext. Det är siffran du bör dimensionera din agent efter, eftersom agentisk kodning tillbringar större delen av sin livstid i long-context-läget.

• North Mini Code — cirka 199 till 210 utdatatoken per sekund via Coheres API, med ungefär 0,25 sekunder till första token och ungefär 2,8 gånger genomströmningen hos jämförbara små modeller i samma test. På lokal hårdvara beror siffrorna helt på din motor och kvantisering, men mönstret är detsamma: snabb vid kort kontext, långsammare när fönstret fylls.

Den ärliga jämförelsen är inte "vilken som är snabbare" utan "vilken som är snabbare för hur en agent faktiskt arbetar". En modell som skriver en token på 8 millisekunder vid 4K-kontext och 110 millisekunder vid 115K är en annan produkt än en som försämras mer gradvis. Ingen av leverantörerna publicerar en kurva. Om långkontextuellt agentarbete är ditt användningsfall bör du mäta det i ditt eget kodförråd innan du bestämmer dig — det är en eftermiddags arbete och det kommer att säga dig mer än något av lanseringsinläggen.

Momentum kontra färskhet

North Mini Code passerade {{1}}150 000 nedladdningar{{/1}} i mitten av augusti 2026, två månader efter lanseringen. Det är en verklig signal: en modell med så stor användning har körts på hårdvara som dess upphovsmän aldrig testade, har samlat på sig rättelser i communityn och har fått sina skavanker dokumenterade av personer utan incitament att vara vänliga. Cohere rapporterade siffran, så behandla antalet som {{2}}leverantörsuppgift{{/2}}, men riktningen stöds av mängden härledda kvantiseringar i omlopp.

Flint är fyra dagar gammal. Den har bättre specifikationer på papperet, snabbare avkodning för kort kontext, ett längre dokumenterat kontextfönster och en mer intressant utvecklingshistoria. Den har också en känd chattmallbugg i GGUF-vägen för llama.cpp, ett genomströmningsstup vid lång kontext som ingen har förklarat, och i praktiken ingen communityhistorik. Tidig adoption av en fyra dagar gammal modell är en satsning på utvecklingsbanan snarare än en bedömning av artefakten.

Vad du ska ladda ner på måndag

• Välj North Mini Code om du vill ha modellen med en oberoende poäng kopplad till sig, om din hårdvara är blygsam, om dina uppgifter är vanlig mjukvaruutveckling i ett kodförråd som bekvämt ryms i kontexten, och om du värdesätter två månaders buggrapporter från communityn högre än en nyare arkitektur. Ta höjd för dess ordrikhet.

• Välj Flint om du har en premiumbärbar dator eller ett 24 GB-kort, om du vill ha det längre kontextfönstret, om kortkontextshastighet är det som ditt arbetsflöde faktiskt utnyttjar, och om du är villig att vara tidig användare i utbyte mot en modell som rimligen är den bättre om en månad.

• Välj ingen av dem som ditt enda alternativ. Båda är modeller med 2,5–3B aktiva parametrar. De är utmärkta på avgränsade uppgifter och de är inte toppmoderna kodningsassistenter, och Recursive säger detsamma om sin egen modell. Det arbete som ingen av dem klarar bra är arbete som kräver en hostad frontier-modell – och den sunda arkitekturen är en lokal standard med en eskaleringsväg, inte en modell som ska vara allt.

Det är i den här eskalationsvägen som routing gör verklig nytta. OrcaRouter serverar inte någon av dessa modeller, så inget här är ett smygreklam för en väg till dem. Vad ett routinglager gör för en local-first-uppsättning är det motsatta: det låter dig sammanfoga de uppgifter som kräver en större hostad modell i samma anropsväg, med en reservkedja för de förfrågningar där den lokala modellen hackar eller kontexten svämmar över. Rätt konfigurerad hanterar den lokala modellen rutinarbetet och den dyra modellen nås bara när den faktiskt behövs – vilket är den enda versionen av den här arkitekturen som sparar pengar.

Det tråkiga svaret är det rätta. Båda filerna är gratis, båda körs på hårdvara du förmodligen har, och det enda sättet att veta vilken som passar ditt kodförråd är att prova båda på det. Skillnaden i benchmark mellan dem är mindre än skillnaden mellan endera och din faktiska arbetsbelastning.