Flint v1.0 vs North Mini Code: Two Open Coding MoEs Fighting Over Your Laptop

Most "versus" pages on this site pair things that were never really rivals. This one is different. Recursive Flint v1.0 and Cohere North Mini Code are the same kind of object: sparse mixture-of-experts coding models, published under Apache 2.0, small enough to run on hardware a developer already owns, and both positioned as the local option rather than the frontier one. Flint arrived on 21 October 2026 with 39.8 billion total parameters and about 2.5 billion active per token. North Mini Code arrived on 9 June 2026 with 30 billion total and 3 billion active. That is close enough that the choice comes down to what is in the file and what has actually been measured — and on both counts, the answer is not the one the launch coverage implies.

The two files, dimension by dimension

Start with what is in the box, because for two self-hosted models this is the comparison that survives contact with reality.

• Total parameters — Flint: 39.8B. North Mini Code: 30B.

• Active parameters per token — Flint: about 2.5B, with 2.2B in the body and the rest in the output head. North Mini Code: 3B. Nearly identical, and this is the number that governs inference cost.

• Expert routing — Flint: 256 routed experts, 6 selected per token plus 1 shared, across 47 MoE layers and 2 dense layers. North Mini Code: 128 experts, 8 active per token.

• Attention — Flint: a mix of sliding-window and global layers with attention sinks. North Mini Code: a 3:1 sliding-window-to-global ratio. Both are making the same bet, that most tokens only need local attention and a few need the whole window.

• Context — Flint: 262,144 tokens documented on the model card, with the announcement citing up to 512K and recommending 256K. North Mini Code: 256K in, 64K maximum output.

• Modality — Flint: text in, text out. North Mini Code: text in, text out. Neither takes images, which matters if your work involves screenshots.

• Licence — both Apache 2.0, weights included, no revenue gate.

• Published formats — Flint: BF16, int4 safetensors, int4 GGUF, NVFP4 GGUF. North Mini Code: BF16, FP8 and W4A16.

• Disk and memory — Flint: 79.59 GB in BF16, 22.86 GB as NVFP4, and roughly 24 GB of memory to run. North Mini Code: around 20 to 24 GB quantised, with Cohere's own demo running on a Mac Studio at about 20 GB.

Memory is the first cut, and it is closer than the parameter counts suggest

The naive reading of 39.8B versus 30B is that Flint needs a third more memory. It does not, because both are sparse and both publish aggressive quantised builds. What you are actually choosing between is a 22.86 GB NVFP4 file and a roughly 20 GB quantised build — close enough that the same 24 GB card will run either, and close enough that neither is the obvious pick on footprint alone.

What differs is the headroom. North Mini Code has been reported running a 4-bit GGUF on a Ryzen 7 with 32 GB of DDR4 — a genuinely ordinary desktop, not a workstation. Flint's laptop claim is more specific: Recursive's throughput figures are measured on an M4 Pro MacBook Pro and on a 64 GB RTX Spark, both of which are premium machines. The 22.86 GB file will load on a 24 GB card. Whether it runs at a speed you would tolerate is a separate question, and it depends heavily on the engine.

If your constraint is "the machine I already own," North Mini Code has more reports of running on unremarkable hardware. If your constraint is "the best machine I own," Flint is the newer architecture and the faster one at short context.

One of these has an independent scoreboard

This is the part of the comparison that most write-ups skip, and it is the part that should decide a procurement.

North Mini Code has been measured by Artificial Analysis. It scores 33.4 on the AA Coding Index and 27.6 on the AA Intelligence Index, with SWE-bench Verified at 67.6 pass@1 and 80.2 pass@10, and 61.0 on mini-SWE-Agent. Those are third-party measurements produced on a consistent protocol, which means they can be compared to other models on the same index without a footnote about harnesses.

Flint has no Artificial Analysis entry. Its published scores — 74.2 on SWE-bench Verified, 89.7 on SWE-bench Pro v2, 54.9 on Terminal-Bench 2.1 — come from Recursive's own harness, and nobody has re-run them. The methodology is disclosed, which is to Recursive's credit: mini-swe-agent with no internet for the SWE-bench runs, Terminus 2 with internet for Terminal-Bench but any web-retrieved solution counted as a failure, pass@1 averaged over at least five attempts. Disclosed methodology is not verified methodology.

So can you compare 67.6 with 74.2? Not responsibly. They were produced by different organisations on different harnesses with different rules, and the gap — 6.6 points — is well inside the range that harness choice alone can move a score. What you can say is narrower and still useful: North Mini Code's number has been checked by someone who did not build the model, and Flint's has not. If you are choosing on evidence rather than on specifications, that is the asymmetry that matters.

There is one more data point in North Mini Code's column that is unflattering and worth having: Artificial Analysis flagged it as unusually verbose, consuming roughly 75 million output tokens in testing against a class median near 25 million. Verbosity is a cost multiplier in an agent loop. A model that thinks out loud three times as much can be cheaper per token and more expensive per task.

The speed story changes completely at long context

Both models are fast at short prompts, and both slow down when the context fills. The difference is how much.

• Flint — Recursive claims 125-plus tokens per second on an M4 Pro MacBook Pro and more than 150 on a 64 GB RTX Spark, measured at short context with prefill excluded. Independent testing reported about 110 tokens per second at short prompts falling to roughly 9 tokens per second near 115,000 tokens of context. That is the number to design your agent around, because agentic coding spends most of its life in the long-context regime.

• North Mini Code — around 199 to 210 output tokens per second on Cohere's API with roughly 0.25 seconds to first token, and about 2.8 times the throughput of comparable small models in the same testing. On local hardware the numbers depend entirely on your engine and quantisation, but the pattern is the same: fast at short context, slower as the window fills.

The honest comparison is not "which is faster" but "which is faster for the way an agent actually works." A model that writes a token in 8 milliseconds at 4K context and 110 milliseconds at 115K is a different product from one that degrades more gently. Neither vendor publishes a curve. If long-context agentic work is your use case, measure it on your own repository before you commit — it is an afternoon's work and it will tell you more than either launch post.

Momentum versus freshness

North Mini Code passed 150,000 downloads by mid-August 2026, two months after release. That is a real signal: a model with that much adoption has been run on hardware its authors never tested, has accumulated fixes in the community, and has had its rough edges documented by people with no incentive to be kind. Cohere reported the figure, so treat the number as vendor-supplied, but the direction is corroborated by the volume of derivative quantisations in circulation.

Flint is four days old. It has better headline specifications, a faster short-context decode, a longer documented context window, and a more interesting development story. It also has a known chat-template bug in the GGUF path for llama.cpp, a throughput cliff at long context that nobody has explained, and essentially no community history. Early adoption of a four-day-old model is a bet on the trajectory rather than an assessment of the artefact.

What to download on Monday

• Pick North Mini Code if you want the model with an independent score attached, if your hardware is modest, if your tasks are ordinary software engineering in a repository that fits comfortably in context, and if you value two months of community bug reports over a newer architecture. Budget for its verbosity.

• Pick Flint if you have a premium laptop or a 24 GB card, if you want the longer context window, if short-context speed is what your workflow actually exercises, and if you are willing to be an early adopter in exchange for a model that is plausibly the better one a month from now.

• Pick neither as your only option. Both are 2.5-to-3B-active models. They are excellent at scoped tasks and they are not frontier coding assistants, and Recursive says as much about its own model. The work that neither will do well is the work that needs a hosted frontier model — and the sane architecture is a local default with an escalation path, not one model asked to be everything.

That escalation path is where routing earns its keep. OrcaRouter does not serve either of these models, so nothing here is a plug for a route to them. What a routing layer does for a local-first setup is the other direction: it lets you compose the tasks that need a larger hosted model into the same call path, with a fallback chain for the requests where the local model stalls or the context overflows. Configured well, the local model handles the routine work and the expensive model is reached only when it is actually needed — which is the only version of this architecture that saves money.

The boring answer is the right one. Both files are free, both run on hardware you probably have, and the only way to know which suits your repository is to try both on it. The benchmark gap between them is smaller than the gap between either one and your actual workload.