Flint v1.0 vs North Mini Code : deux MoE de codage ouvert qui se disputent votre ordinateur portable

La plupart des pages « versus » de ce site opposent des choses qui n'ont jamais vraiment été rivales. Celle-ci est différente. Recursive Flint v1.0 et Cohere North Mini Code sont le même genre d'objet : des modèles de codage à mélange d'experts clairsemé, publiés sous Apache 2.0, assez petits pour tourner sur du matériel qu'un développeur possède déjà, et tous deux positionnés comme l'option locale plutôt que comme l'option de pointe. Flint est arrivé le 21 octobre 2026 avec 39,8 milliards de paramètres au total et environ 2,5 milliards actifs par token. North Mini Code est arrivé le 9 juin 2026 avec 30 milliards au total et 3 milliards actifs. C'est suffisamment proche pour que le choix se résume à ce que contient le fichier et à ce qui a réellement été mesuré — et sur les deux plans, la réponse n'est pas celle que la couverture du lancement laisse entendre.

Les deux fichiers, dimension par dimension

Commencez par ce qu'il y a dans la boîte, car pour deux modèles auto-hébergés, c'est la comparaison qui résiste au contact de la réalité.

• Paramètres totaux — Flint : 39,8B. North Mini Code : 30B.

• Paramètres actifs par token — Flint : environ 2,5 B, dont 2,2 B dans le corps et le reste dans la tête de sortie. North Mini Code : 3 B. Presque identiques, et c’est ce nombre qui régit le coût d’inférence.

• Routage des experts — Flint : 256 experts routés, 6 sélectionnés par token plus 1 partagé, sur 47 couches MoE et 2 couches denses. North Mini Code : 128 experts, 8 actifs par token.

• Attention — Flint : un mélange de couches à fenêtre glissante et de couches globales avec des puits d'attention. North Mini Code : un ratio de 3:1 entre fenêtre glissante et couches globales. Les deux font le même pari : la plupart des tokens n'ont besoin que d'une attention locale et quelques-uns ont besoin de la fenêtre entière.

• Contexte — Flint : 262 144 tokens documentés sur la fiche du modèle, l’annonce mentionnant jusqu’à 512K et recommandant 256K. North Mini Code : 256K en entrée, 64K de sortie maximale.

• Modalité — Flint : texte en entrée, texte en sortie. North Mini Code : texte en entrée, texte en sortie. Aucun des deux n’accepte d’images, ce qui compte si votre travail implique des captures d’écran.

• Licence — les deux sous Apache 2.0, poids inclus, aucun seuil de revenus.

• Formats publiés — Flint : BF16, safetensors int4, GGUF int4, GGUF NVFP4. North Mini Code : BF16, FP8 et W4A16.

• Disque et mémoire — Flint : 79,59 Go en BF16, 22,86 Go en NVFP4, et environ 24 Go de mémoire pour fonctionner. North Mini Code : environ 20 à 24 Go quantisé, avec la démo de Cohere elle-même tournant sur un Mac Studio à environ 20 Go.

La mémoire est la première coupe, et elle est plus proche que ne le laissent penser les nombres de paramètres.

Une lecture naïve de 39,8 B contre 30 B laisse penser que Flint a besoin d’un tiers de mémoire en plus. Ce n’est pas le cas, car les deux sont sparse et publient tous deux des versions quantifiées agressives. En réalité, vous choisissez entre un fichier NVFP4 de 22,86 Go et une version quantifiée d’environ 20 Go — assez proches pour que la même carte de 24 Go fasse tourner l’un ou l’autre, et assez proches pour qu’aucun ne soit le choix évident sur la seule empreinte.

Ce qui diffère, c’est la marge disponible. Des rapports indiquent que North Mini Code tourne en GGUF 4 bits sur un Ryzen 7 avec 32 Go de DDR4 — un ordinateur de bureau véritablement ordinaire, pas une station de travail. L’affirmation de Flint concernant l’ordinateur portable est plus précise : les chiffres de débit de Recursive sont mesurés sur un MacBook Pro M4 Pro et sur une RTX Spark de 64 Go, deux machines haut de gamme. Le fichier de 22,86 Go se chargera sur une carte de 24 Go. La question de savoir s’il tourne à une vitesse que vous jugeriez acceptable est distincte, et elle dépend fortement du moteur.

Si votre contrainte est « la machine que je possède déjà », North Mini Code bénéficie de davantage de retours d’expérience quant à son exécution sur du matériel ordinaire. Si votre contrainte est « la meilleure machine que je possède », Flint est l’architecture la plus récente et la plus rapide en contexte court.

L'un de ces éléments dispose d'un tableau des scores indépendant.

C’est la partie de la comparaison que la plupart des comptes rendus omettent, et c’est celle qui devrait décider d’un achat.

North Mini Code a été évalué par Artificial Analysis. Il obtient 33,4 sur l’AA Coding Index et 27,6 sur l’AA Intelligence Index, avec SWE-bench Verified à 67,6 en pass@1 et 80,2 en pass@10, et 61,0 sur mini-SWE-Agent. Il s’agit de mesures tierces produites selon un protocole cohérent, ce qui signifie qu’elles peuvent être comparées à d’autres modèles sur le même indice sans note de bas de page concernant les harnesses.

Flint n’a pas de fiche Artificial Analysis. Ses scores publiés — 74,2 sur SWE-bench Verified, 89,7 sur SWE-bench Pro v2, 54,9 sur Terminal-Bench 2.1 — proviennent du propre harnais de Recursive, et personne ne les a réexécutés. La méthodologie est divulguée, ce qui est tout à l’honneur de Recursive : mini-swe-agent sans accès à Internet pour les exécutions SWE-bench, Terminus 2 avec accès à Internet pour Terminal-Bench mais toute solution récupérée sur le Web comptée comme un échec, pass@1 moyenné sur au moins cinq tentatives. Une méthodologie divulguée n’est pas une méthodologie vérifiée.

Alors, peut-on comparer 67,6 avec 74,2 ? Pas de manière responsable. Ils ont été produits par des organisations différentes, sur des harnais différents, avec des règles différentes, et l’écart — 6,6 points — tient largement dans l’amplitude que le seul choix du harnais peut faire varier sur un score. Ce que l’on peut dire est plus restreint, et toujours utile : le chiffre de North Mini Code a été vérifié par quelqu’un qui n’a pas construit le modèle, et celui de Flint ne l’a pas été. Si vous choisissez sur la base des preuves plutôt que des spécifications, c’est cette asymétrie qui compte.

Il y a un point de données de plus dans la colonne de North Mini Code qui n'est pas flatteur et qu'il vaut la peine de connaître : Artificial Analysis l'a signalé comme exceptionnellement verbeux, consommant environ 75 millions de tokens de sortie lors des tests, contre une médiane de catégorie proche de 25 millions. La verbosité est un multiplicateur de coût dans une boucle d'agent. Un modèle qui réfléchit à voix haute trois fois plus peut être moins cher par token et plus cher par tâche.

L'histoire de la vitesse change complètement sur les contextes longs.

Les deux modèles sont rapides sur des prompts courts, et tous deux ralentissent lorsque le contexte se remplit. La différence tient à l’ampleur.

• {{1}}Flint{{/1}} — Recursive affirme plus de 125 tokens par seconde sur un MacBook Pro M4 Pro et plus de 150 sur un RTX Spark de 64 Go, mesurés en contexte court avec le préremplissage exclu. Des tests indépendants ont rapporté environ 110 tokens par seconde sur des prompts courts, chutant à environ 9 tokens par seconde près de {{2}}115 000 tokens{{/2}} de contexte. C'est le chiffre en fonction duquel concevoir votre agent, car le codage agentique passe la majeure partie de son temps dans le régime des contextes longs.

• North Mini Code — environ 199 à 210 jetons de sortie par seconde sur l'API de Cohere, avec environ 0,25 seconde jusqu'au premier jeton, et environ 2,8 fois le débit de modèles petits comparables lors des mêmes tests. Sur du matériel local, les chiffres dépendent entièrement de votre moteur et de la quantification, mais la tendance est la même : rapide en contexte court, plus lent à mesure que la fenêtre se remplit.

La comparaison honnête n’est pas « lequel est plus rapide », mais « lequel est plus rapide pour la façon dont un agent fonctionne réellement ». Un modèle qui écrit un token en 8 millisecondes à 4K de contexte et en 110 millisecondes à 115K est un produit différent de celui qui se dégrade plus doucement. Aucun des deux fournisseurs ne publie de courbe. Si le travail agentique à long contexte est votre cas d’usage, mesurez-le sur votre propre dépôt avant de vous engager — c’est l’affaire d’un après-midi et cela vous en dira plus que l’un ou l’autre des articles de lancement.

Momentum versus fraîcheur

North Mini Code a dépassé les 150 000 téléchargements à la mi-août 2026, deux mois après sa sortie. C'est un signal tangible : un modèle qui a connu une telle adoption a tourné sur du matériel que ses auteurs n'ont jamais testé, a accumulé des correctifs grâce à la communauté, et ses aspérités ont été documentées par des personnes qui n'ont aucun intérêt à se montrer indulgentes. Cohere a communiqué ce chiffre : considérez-le donc comme fourni par l'éditeur, mais la tendance est corroborée par le volume de quantifications dérivées en circulation.

Flint a quatre jours. Il affiche de meilleures spécifications phares, un décodage plus rapide en contexte court, une fenêtre de contexte documentée plus longue et une histoire de développement plus intéressante. Il présente aussi un bug connu de gabarit de chat dans la voie GGUF pour llama.cpp, une chute brutale de débit en contexte long que personne n’a expliquée, et pratiquement aucun historique communautaire. Adopter précocement un modèle vieux de quatre jours est un pari sur sa trajectoire plutôt qu’une évaluation de l’artefact.

Que télécharger lundi

• Choisissez North Mini Code si vous voulez le modèle auquel est associé un score indépendant, si votre matériel est modeste, si vos tâches relèvent de l’ingénierie logicielle ordinaire dans un dépôt qui tient confortablement dans le contexte, et si vous préférez deux mois de rapports de bogues de la communauté à une architecture plus récente. Prévoyez sa verbosité.

• Choisissez Flint si vous disposez d'un ordinateur portable haut de gamme ou d'une carte de 24 Go, si vous voulez la fenêtre de contexte plus longue, si la vitesse en contexte court est ce que votre flux de travail sollicite réellement, et si vous êtes prêt à essayer en avance de phase en échange d'un modèle qui sera plausiblement le meilleur d'ici un mois.

• Ne choisissez aucun des deux comme seule option. Ce sont tous deux des modèles à 2,5 à 3 B de paramètres actifs. Ils sont excellents pour des tâches bien délimitées, et ce ne sont pas des assistants de codage de pointe, et Recursive en dit autant de son propre modèle. Le travail qu’aucun des deux ne fera bien est celui qui nécessite un modèle de pointe hébergé — et l’architecture raisonnable consiste en un modèle local par défaut avec une voie d’escalade, et non en un seul modèle auquel on demande d’être tout.

C’est sur ce chemin d’escalade que le routage justifie son utilité. OrcaRouter ne sert aucun de ces deux modèles ; rien ici ne vise donc à promouvoir une route vers eux. Ce qu’une couche de routage apporte à une configuration local-first va dans l’autre sens : elle permet d’intégrer les tâches qui nécessitent un modèle hébergé plus grand dans le même chemin d’appel, avec une chaîne de repli pour les requêtes où le modèle local bloque ou le contexte déborde. Bien configuré, le modèle local gère le travail courant et le modèle coûteux n’est sollicité que lorsqu’il est réellement nécessaire — ce qui est la seule version de cette architecture qui permette de faire des économies.

La réponse ennuyeuse est la bonne. Les deux fichiers sont gratuits, tous deux fonctionnent sur du matériel que vous possédez probablement, et le seul moyen de savoir lequel convient à votre dépôt est de les essayer tous les deux dessus. L'écart de performance entre eux est plus petit que l'écart entre l'un ou l'autre et votre charge de travail réelle.