Don't overlook Ornith: this 35B local model activates 3B, runs fast, and sometimes overthinks itself into trouble
Ornith-1.5-35B-A3B is a roughly 35B-parameter MoE coding-agent model that activates about 3B parameters per token. Its official Terminal-Bench 2.1, SWE-bench Verified, SWE-bench Pro and NL2Repo results are well above Qwen3.6-35B-A3B. An independent RTX 4070 test reached about 63.7 tok/s with a repaired MTP head, but that is a single-machine experiment with specific quantization and settings. Community reports include successful real tasks, severe overthinking and a larger model failing to recover on a long task. It is worth testing locally, not yet a universal Qwen or DeepSeek replacement.
Bottom line
A name that does not look like another leaderboard release is starting to surface in local coding-agent circles: Ornith-1.5-35B-A3B.
It has roughly 35B total parameters, while the model card says about 3B parameters are activated per token. The reported Terminal-Bench 2.1 scores are 67.8 with Terminus-2 and 68.5 with Claude Code; SWE-bench Verified is 79.0, SWE-bench Pro is 59.6 and NL2Repo is 46.2. The Qwen3.6-35B-A3B figures in the same table are 52.5, 49.2, 73.4, 49.5 and 29.4.
The scores are high, but the community did not immediately dismiss the model as a paper-only trick. One user ran a quantized build on three real development tasks and reported that it completed all three at about twice the speed of Qwen3.8-27B. Another RTX 4070 test reached about 63.7 tok/s after repairing the MTP head. Other users reported severe overthinking, and a larger Ornith model failed to recover on a long task.
My view: it is worth testing on your own repository, but it is too early to call it a universal Qwen or DeepSeek replacement. The interesting question is whether low active parameters, training scaffolds, quantization and Agent harnesses can make a local model keep working for long enough to matter.
Why the official scores invite skepticism
Ornith 1.5 is a mixture-of-experts model. 35B is the total parameter count; about 3B is the active count per token. A lower active count can reduce compute under the same context and runtime. It does not mean the machine only has to load a 3B checkpoint.
The official model card lists strong coding and Agent results:
- Terminal-Bench 2.1 (Terminus-2): 67.8;
- Terminal-Bench 2.1 (Claude Code): 68.5;
- SWE-bench Verified: 79.0;
- SWE-bench Pro: 59.6;
- NL2Repo: 46.2.
The team also documents the harnesses, context limits, temperatures and timeouts. Several results are averages over five independent runs. For SWE-bench, network access is disabled and Git history is removed to reduce the chance of retrieving prior answers. That makes the results easier to inspect, but they remain results from configurations selected by the model team.
There is no evidence to call the scores fake, and no reason to accept them without independent checks. The useful interpretation is a strong signal that deserves outside testing.
The first local users did not reach one verdict
In a LocalLLaMA discussion, one user ran the Q4_K_M build on three tasks: adding a field to an existing customer entity with API and UI changes, auditing authorization in a large B2B application, and porting ninfer to Windows Native. They reported that all three were completed, with overall speed around twice that of Qwen3.8-27B.
That is three tasks from one user with one setup, so it cannot prove that Ornith beats Qwen overall. But a real repository, cross-stack changes and a platform port are closer to daily work than another vendor chart.
Another user described Ornith as one of the most severe overthinking models they had tested. A single answer could burn tens of thousands of reasoning tokens, and one run hit a 32K context wall without finishing. Fewer active parameters do not prevent a model from generating more tokens.
That is the local-agent bill people miss: speed depends on decode rate, but also on how long the model thinks before finishing.
What 63.7 tok/s on an RTX 4070 actually means
The independent testing repository records a quantized Ornith build with a repaired MTP head. The author argues that the vendor MTP head was not properly trained, replaced it with a continued-trained head, and measured about 63.7 tok/s on an RTX 4070. The build passed 11 of 12 standard tests with an average task latency of 15.3 seconds.
In the same author's earlier records, tuned Ornith 1.5 averaged about 23.1 seconds and vanilla Qwen3.6 about 41.5 seconds. This is useful evidence, but it should not be written as “every RTX 4070 reaches 63.7 tok/s.” Hardware, quantization, context, sampling and MTP settings differ, and the test battery is maintained by one author.
The more important lesson is that an open model's final experience is not determined by the checkpoint alone. MTP heads, quantization, runtimes, sampling and Agent harnesses can decide whether it feels like a breakthrough or a headache.
A larger model can still lose a long task
The same community discussion includes the opposite kind of report: a user tested Ornith-1.5-397B Q8 and did not finish a complex task, while DeepSeek V4 and Qwen3.8-27B recovered from errors and completed the same task.
This is not a general model ranking or a systematic 397B evaluation. It does show why Agent quality is about more than getting one step right. The system must detect a wrong turn, recover and continue. More parameters and better single-turn ability do not automatically produce a better long-horizon experience.
The genuinely new part is the training route
Ornith 1.5 emphasizes more than MoE. The team describes an end-to-end self-improvement loop that jointly optimizes task generation, scaffold construction and solution rollouts. The system keeps generating new training tasks, discovers strategies for solving them and updates the policy through reinforcement learning.
That differs from training on a fixed task set with a fixed harness. It is closer to teaching the model how to face a class of work and how to build a workflow for it.
If this works, local coding-agent competition may depend less on parameter count alone and more on who can generate realistic work traces, maintain context, call tools, retry and recover.
Is it worth downloading now?
If you already use Qwen3.8-27B or Qwen3.6-35B-A3B, or you have an RTX 4070, 4090, 5090, Mac Studio or a high-memory Mac, I think it is worth trying. The model card lists a 262,144-token context window and recommends recent Transformers, vLLM or SGLang versions; a quantization ecosystem is already appearing.
Do not test it only on one LeetCode problem. Take five real tasks from last week and record completion, wall-clock time, generated tokens, rework rounds, manual corrections and recovery after failure. Then run exactly the same tasks through Qwen or DeepSeek.
What to watch next
- Larger independent coding-agent tests from different authors;
- the gap between default and tuned sampling parameters;
- whether the repaired MTP head reaches mainstream quantizations and runtimes;
- how overthinking changes total time and context budgets;
- failure recovery in the 397B and 35B versions;
- tool calling and reasoning-parser support across Ollama, llama.cpp and vLLM.
FAQ
Does 35B-A3B need the memory of a 3B model?
No. About 3B is the active count per token; the weights still contain roughly 35B parameters. The model card lists about 70GB for bf16 weights, while quantization is what makes smaller local machines practical.
Do the official scores prove that it already beats Qwen?
No. They show that Ornith is strong on those benchmarks and configurations. Independent samples are still small, and real experience depends on quantization, runtime, sampling and harnesses.
Can every RTX 4070 reach 63.7 tok/s with the repaired MTP build?
No. That is one author's result on a particular RTX 4070 with specific quantization and runtime settings. Treat it as a signal of potential, not a hardware guarantee.
Our judgment
The most interesting thing about Ornith 1.5 is not that it has already become the new local-model champion. It puts a concrete route on the table: the knowledge capacity of a 35B model, the compute path of roughly 3B active parameters, self-improvement training and a local Agent toolchain.
If it can solve overthinking, recovery and runtime compatibility, low-active MoE could become a practical direction for local coding agents. For now, do not crown it. Run it against your own repository and find out whether it is fast, smart, or simply faster at thinking too much.