Recursive Flint vs Ornith 1.5: We Ran Both as a Local Coding Agent

Recursive released Flint on October 21, 2026: a 40B mixture-of-experts model with about 2.5B active parameters, Apache 2.0. Its closest rival is Ornith 1.5 35B-A3B, out since August 18 under MIT. Full specs and setup for Flint alone are in our Recursive Flint guide.

On paper Ornith wins: it scores higher on both benchmarks the two vendors share. We wanted to see if that holds inside a real agent, so we ran both on the same six tasks, three times each, on one RTX 5090 the day after Flint shipped.

Our test: one RTX 5090 32 GB, Atomic Agent v0.6.10 in external mode, upstream llama.cpp build 11825, Flint UD-Q4_K_XL and Ornith Q4_K_M, n=3 per task, October 22, 2026.

Which is better for local coding, Flint or Ornith 1.5?

Ornith 1.5, if you care most about getting the answer right. In our test it passed 14 of 18 runs against 12 of 18 for Flint, and it scored 30/32 hidden tests on the hardest task every time. Flint is the faster pick: 375 seconds for all 18 runs against 1,749 for Ornith, with more mistakes.

The difference shows up in how each model works. Ornith reads, checks, and re-runs, sometimes far too much: one of its runs hit our 20 minute limit after 622 steps. Flint takes a few steps and stops, and on two tasks it stopped before the job was done.

Model IDs

• Flint weights: RecursiveSI/flint (BF16), GGUF from unsloth/flint-GGUF, terelabs/flint-GGUF (template modified for older llama.cpp builds), lmstudio-community/flint-GGUF
• Flint on Ollama: flint (23 GB). On OpenRouter: recursive/flint-v1.0:free
• Ornith weights: ornith-ai/Ornith-1.5-35B-A3B, GGUF ornith-ai/Ornith-1.5-35B-A3B-GGUF
• Ornith on Ollama: ornith-1.5:35b (23 GB). Not on OpenRouter.

How did they do in our agent test?

Both models passed every run of the three easy tasks. They split on the rest: Ornith counted log errors correctly 3 of 3 times where Flint got 0 of 3, Flint renamed a function cleanly 3 of 3 times against 2 of 3 for Ornith, and neither model passed all 32 hidden tests on the hardest task in any run.

How we tested

We used the same six offline tasks as in our earlier local model runs, each in a fresh workspace with the agent’s state reset between runs:

• t1 read the database port from a YAML config (not the cache port) and write it to a file
• t2 write and run a small stats.py
• t3 fix a slugify function against hidden test cases
• t4 count ERROR lines across three log files and find the most frequent error (correct answer: 43)
• t5 rename a function across three files without changing the program’s output
• t6 a small Python package from a spec: fix planted bugs, implement settle(), add a command-line tool. It passes only at 32 of 32 hidden pytest cases.

Limits were 600 seconds per run for t1 to t5 and 1,200 seconds for t6. Everything ran on one rented machine with an NVIDIA RTX 5090 32 GB on October 22, 2026. The agent was Atomic Agent v0.6.10 in external mode with default settings, except the completion budget, which we raised to 96,000 tokens. Sampling was the agent’s default for both models: temperature 0.2, top_p 0.95, top_k 40.

The engine was upstream llama.cpp build 11825 (commit 19ab5a5e6), started with --jinja -fa on -ngl 999 -c 131072 --parallel 1. Files: flint-UD-Q4_K_XL.gguf (25.05 GB) from Unsloth with the llama.cpp chat template from terelabs, and Ornith-1.5-35B-Q4_K_M.gguf (21.71 GB) from ornith-ai with its built-in template.

Results

One RTX 5090, n=3 per task, our six tasks, Atomic Agent v0.6.10 external mode, llama.cpp build 11825, Flint UD-Q4_K_XL, Ornith Q4_K_M. t5 rescored as described below.

Where each model failed

Flint on t4. In all three runs Flint listed the three log files (60 lines each), read them, and wrote a number without running a count. It wrote 12, 14 and 17; the right answer is 43. It picked the most frequent error correctly in two of the three runs. Ornith ran a grep count first and wrote 43 every time. In a warm-up run that we left out of the table, Flint also wrote the word PLACEHOLDER into a result file on t2 and reported success.

Flint on t6. Flint passed 25 to 31 of the 32 hidden tests, with a wide spread between runs. Its fastest run took 24 seconds and 10 steps and got 31 right, one test short of a pass.

Ornith on t5. In one run Ornith left the old function name in main.py.

Ornith on t6. Ornith passed exactly 30 of 32 hidden tests in all three runs. In the third run it kept rewriting and re-testing the same files for 20 minutes: 370 file writes, 234 file reads, and 196 shell commands over 622 steps, until the time limit stopped it.

Our agent’s role. Atomic Agent has a no-progress detector that blocks a tool call when the model repeats itself. It fired in 8 of Ornith’s 18 runs (12 times in the timeout run alone) and in 1 of Flint’s. Some of those blocks hit calls that were fine to repeat, which cost Ornith extra steps. We count that part of Ornith’s time against Atomic Agent, not against the model.

The t5 rescore. Our stock checker counted Python’s __pycache__/*.pyc cache files as extra files containing the new name, so the check that the new name appears in exactly 3 files failed every t5 run. We rechecked the .py files plus the program’s output instead, which is what the task asks. Ornith’s one failed run is a real miss: it left the old name in main.py. Without t5, the score is 9/15 for Flint and 12/15 for Ornith.

Limits of this test. One machine, one GPU, three runs per task, five small offline tasks and one mid-size coding task, agent defaults, external llama.cpp. Other agents, quants, sampling settings or longer projects can rank these models differently.

Repeat this test on your repo. Take a task from your own codebase with a clear finish line, run it three times per model in Atomic Agent, and compare passes, steps and time instead of a single run. Setup is below.

Which one is faster?

Per token, neither: on the same RTX 5090 Flint decoded at 145.7 tok/s and Ornith at 149.4 tok/s, and Ornith processed prompts faster (3,964 against 3,433 tok/s). Per task, Flint: it generated 41K tokens across 18 runs against 173K for Ornith, so it finished in 375 seconds against 1,749.

llama.cpp timings for every request in the run, same box and settings as above.

So Flint’s lead comes from doing less work, not from generating faster. The 20 minute timeout inflates Ornith’s total. Drop that run and Flint’s matching run, and the totals are 548 seconds for Ornith against 351 for Flint, still about 1.6x in Flint’s favour.

Two reasons Flint’s per-token speed here is lower than Recursive’s numbers. First, Flint support in llama.cpp (PR #30928) includes an activation scaling workaround that the PR author says costs 10 to 30% of speed. Second, Recursive’s vendor-published figures (over 125 tok/s on an M4 Pro MacBook Pro, over 150 tok/s on an RTX Spark) come from its own rec engine. For Ornith, a community report on Hugging Face puts decode at about 250 to 270 tok/s on a 5090; our 149 tok/s is measured inside an agent loop where the prompt keeps growing.

How much VRAM do Flint and Ornith 1.5 need?

At 4 bits with a 131K context and f16 KV cache, Flint took 27.4 GB and Ornith 22.8 GB on our RTX 5090 (nvidia-smi: 28,044 and 23,344 MiB). Flint’s 4-bit file is larger, 25.1 GB against 21.7 GB, so the Flint file we tested fits a 32 GB GPU but not a 24 GB one. On 24 GB, a smaller 4-bit Flint file (terelabs IQ4_XS at 22.2 GB or the official NVFP4 at 22.9 GB) may load with a short context, which we haven’t tested, and 3-bit builds, which Unsloth sizes at 16 to 20 GB, fit. On a 32 GB Mac it’s tight, because macOS limits GPU memory by default; a 3-bit build or a ~22 GB 4-bit file with a shorter context is safer, also untested.

Ornith’s 23,344 MiB sits right at the edge of a 24 GB card, so lower the context if you run other things on the GPU. The full quant list and what fits where for Flint is in our Recursive Flint guide.

How do I run Flint or Ornith 1.5 in Atomic Agent?

Run a llama.cpp server yourself and point Atomic Agent at it in external mode. You need llama.cpp build 11803 or newer for Flint (we used 11825). On those builds Flint’s built-in template parses with --jinja; we passed the terelabs copy of it instead, which renders the same. Ornith works with its built-in template. That’s how we ran this test.

Flint needs external mode for now: the llama.cpp build inside Atomic Agent’s managed engine (b10298) predates Flint support. We ran both models the same way so the comparison stays fair.

Build llama.cpp (on Apple Silicon, drop the CUDA flag; Metal is on by default):

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON
cmake --build build -j --target llama-server

Start Flint the way we ran it. The terelabs template download and the --chat-template-file line are optional on build 11803 or newer: we passed them in every run, and you can drop both to use the template inside the GGUF (we expect that to work, but we didn’t run it):

hf download unsloth/flint-GGUF flint-UD-Q4_K_XL.gguf --local-dir models
hf download terelabs/flint-GGUF chat_template_llamacpp.jinja --local-dir models   # optional on 11803+

./build/bin/llama-server \
  -m models/flint-UD-Q4_K_XL.gguf \
  --chat-template-file models/chat_template_llamacpp.jinja \
  --jinja -fa on -ngl 999 -c 131072 \
  --host 127.0.0.1 --port 8080

Or start Ornith 1.5:

hf download ornith-ai/Ornith-1.5-35B-A3B-GGUF Ornith-1.5-35B-Q4_K_M.gguf --local-dir models

./build/bin/llama-server \
  -m models/Ornith-1.5-35B-Q4_K_M.gguf \
  --jinja -fa on -ngl 999 -c 131072 \
  --host 127.0.0.1 --port 8080

Install Atomic Agent and point it at the server in ~/.atomic-agent/config.json:

curl -fsSL https://atomicagent.io/install | sh

{
  "localModels": {
    "mode": "external",
    "url": "http://127.0.0.1:8080",
    "completionMaxTokens": 96000
  }
}

If your config already has an llm block, also change the url of the built-in local-llama provider.

Then start atomic-agent in your project folder (or use /model http://127.0.0.1:8080 in the TUI). On Windows, install with irm https://atomicagent.io/install.ps1 | iex in PowerShell, or get the desktop app. Full flag reference is in our llama.cpp guide.

Prefer Ollama? See the Ollama guide and our Ollama vs llama.cpp comparison. We didn’t test either model through Ollama for this article.

Repeat this test. Run your own task three times with each server, swapping only the -m line, and compare the results the same way we did.

What are the known problems?

Flint has two setup traps in llama.cpp: it needs its reasoning kept in the chat history, and it wants an output budget of 32K tokens or more on hard problems. Ornith’s issues are softer: an Ollama tag not marked for tools, and community reports of looping that matched our timeout run.

Flint

• Reasoning in history. Flint always reasons first. If your client drops reasoning_content from earlier turns, multi-turn tool use gets worse.
• Output budget. On hard problems, leave 32K+ tokens for output. We ran with 96,000.
• Older llama.cpp builds. If you’re on a llama.cpp build from before October 21, 2026, including pre-merge builds of the Flint PR, the template inside the official, Unsloth and LM Studio GGUFs fails to parse with --jinja because of replace("\x00",""). Builds 11803 and newer handle it. On older builds, use --chat-template-file with chat_template_llamacpp.jinja from terelabs, or the terelabs GGUF, which embeds it.
• Quantization. Community measurements put top-1 agreement at about 85 to 88% around 4 bits per weight. Avoid a q4_0 KV cache, which raised divergence on code in those reports.
• Speed in llama.cpp. The current activation scaling workaround costs 10 to 30%, per the PR author. Expect this to change in later builds.
• Recursive itself notes the model “may need more guidance than larger closed models.” In our t4 runs Flint read the logs and wrote a number without running a count.

Ornith 1.5

• Ollama tag. A community setup guide says the ornith-1.5:35b tag isn’t marked for tools and suggests pulling hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M instead.
• Looping. Threads on the Hugging Face model page report constant looping. In our test Ornith triggered the agent’s no-progress detector in 8 of 18 runs, and one run hit the 20 minute limit.
• Benchmark skepticism. Another Hugging Face thread is titled “Don’t believe the benchmarks in the model card.” Our results put Ornith ahead of Flint, but neither model passed the hardest task.

How do they score on vendor benchmarks?

Ornith scores higher on both benchmarks the two vendors share: 79 against 74.2 on SWE-bench Verified and 67.8 against 54.9 on Terminal-Bench 2.1, both vendor-published. The harnesses and sampling may differ, so treat this as direction rather than an exact gap.

Vendor-published, from Recursive’s launch post and the Ornith 1.5 model card. Not our tests. Recursive’s numbers are average pass@1 over at least 5 attempts at temperature 1.0.

The SWE-bench Pro row isn’t comparable: Recursive names its version “v2”, and its 89.7 is far above the 59.6 Ornith reports, which points to a different benchmark version or setup. Per MarkTechPost’s summary of Recursive’s chart, the dense Qwen 3.8 scores 73.0 on Terminal-Bench 2.1 and 90.3 on LiveCodeBench, well ahead of Flint. For a dense model in the same memory range, see our Qwen 3.8 27B local agent test.

Can you try Flint without a GPU?

Yes. Flint costs $0 on OpenRouter as of Oct 22, 2026 under the ID recursive/flint-v1.0:free, rate-limited, served only by Recursive at BF16 with a 262,144 token context and up to 235,929 output tokens. Ornith 1.5 isn’t on OpenRouter, so to compare the two you run Ornith locally.

The weights for both are open: Flint under Apache 2.0, Ornith 1.5 under MIT. Hosted terms for Recursive’s API are separate from the weights license. Keep in mind that the OpenRouter route runs BF16, while our numbers above come from 4-bit files, so results can differ.

Which one should you pick?

Pick by the work you do and the hardware you have. On our six tasks Ornith 1.5 was more accurate (14/18 against 12/18) and Flint was faster per task (375 s against 1,749 s in total). VRAM narrows it further.

• Quick edits and small scripted jobs: Flint. It finished most runs in under 10 seconds and passed every run of t1, t2, t3 and t5. Check its answers on anything that needs counting or verification; it got t4 wrong 3 of 3 times.
• Careful multi-file work: Ornith 1.5. It scored 30/32 on the hardest task every run and checked its work with tools. Budget time for it, and cap the steps if your agent allows, because one run used 622 steps.
• A 24 GB GPU: Ornith 1.5 at Q4_K_M, with a shorter context if you need headroom. The Flint file we tested took 27.4 GB, so it doesn’t fit; on 24 GB use a 3-bit Flint build, or try a ~22 GB 4-bit file with a short context. We tested neither.
• A Mac: neither has been tested by us there. Recursive’s vendor-published figure is over 125 tok/s on an M4 Pro on its own rec engine, and Recursive recommends 48 GB or more for full context. On a 32 GB Mac memory is tight, because macOS limits GPU memory by default: Ornith’s 21.7 GB Q4_K_M, a 3-bit Flint build, or a ~22 GB 4-bit Flint file with a shorter context are the safer files.
• No local GPU: Flint on OpenRouter, while it’s at $0. Ornith has no hosted route there.

You don’t have to choose once. In Atomic Agent the model is one server line away, and the tools and prompt stay the same. For other agent options, see our list of open-source Claude Code alternatives.