Ornith 1.0-35B MoE: The Sweet Spot in the Ornith 1.0 Family

July 5, 2026 · 9 min read

The Ornith 1.0-35B MoE occupies an unusual position in the model landscape: it is simultaneously larger and faster than its smaller sibling, more accurate than models twice its size, and the single best choice for most developers who want to self-host an agentic coding model. Understanding why requires looking closely at Mixture-of-Experts architecture and what DeepReinforce AI’s self-scaffolding training achieves at this scale.

This deep dive covers the ornith 1.0 35b architecture, benchmark results, hardware requirements, and when this model is — or isn’t — the right pick.

What Is Ornith 1.0-35B MoE?

Ornith 1.0-35B is a Mixture-of-Experts (MoE) model in DeepReinforce AI’s Ornith 1.0 family, released June 25, 2026 under MIT license. It has 35B total parameters but activates only approximately 3B of them per token during inference. The base architecture is Qwen 3.5 MoE, post-trained with the same self-scaffolding reinforcement learning that runs across the entire Ornith 1.0 family.

The full model lineup — 9B Dense, 31B Dense, 35B MoE, and 397B MoE — is documented on the models page. The 35B MoE is marked as “Best Value” and “Recommended for most users” for reasons this article makes concrete.

Why MoE Makes the 35B Faster Than the 9B Dense

This is the fact that surprises most people encountering Ornith 1.0 35b for the first time: the 35B MoE generates tokens faster than the 9B dense model, despite having nearly 4× more parameters.

The explanation is architectural. In a dense model like the 9B, every inference step activates all 9 billion parameters. In a Mixture-of-Experts model, the router selects only a subset of “expert” layers for each token. With ~3B parameters active per token, the 35B MoE performs fewer floating-point operations per forward pass than the dense 9B — while having access to a vastly larger pool of learned representations stored across the full 35B.

Put simply:

• Dense 9B: 9B params computed per token
• MoE 35B: ~3B params computed per token, 35B total available

The MoE design means you get 35B worth of “knowledge” activated selectively, at the inference cost of a ~3B model. This is why MoE has become the dominant architecture for large, efficient models, and why the ornith 1.0 35b occupies such a strong position on the efficiency frontier.

Ornith 1.0-35B Benchmark Results

Here is the full picture from DeepReinforce AI’s official evaluation (scores are self-reported; independent verification was pending as of mid-2026):

The standout result: 64.2 on Terminal-Bench 2.1 beats Qwen 3.5-397B (53.5) — a model with more than 11× the parameter count — with just 35B total parameters. On SWE-Bench Verified, 75.6 is a strong result for a single-consumer-GPU model. See the complete benchmarks page for the full comparison including the 397B flagship and frontier models.

The Terminal-Bench lead over Qwen 3.5-397B is particularly striking. Terminal-Bench measures agent-loop behavior in a terminal environment — exactly the domain where self-scaffolding RL training has the most impact. The 35B’s behavioral training translates into a 20-point advantage over a much larger but conventionally trained model.

The Hardware Sweet Spot: 24GB+ Consumer GPUs

Ornith 1.0-35B has a practical VRAM footprint of ~25 GB at Q5_K_M quantization. This targets the single-GPU consumer market:

For a 24 GB GPU like the RTX 4090, Q4_K_M at roughly 20 GB is the practical choice. Q5_K_M at 25 GB is a tight fit that may require careful management of KV cache allocation via --gpu-memory-utilization 0.85 in vLLM. A small amount of layer offloading to CPU RAM is also an option if you have fast DDR5 memory.

If you are deciding between the 9B and 35B, the ornith 9b vs 35b comparison covers the trade-offs in detail.

Running Ornith 1.0-35B with vLLM

For production or multi-user setups, vLLM is the recommended serving framework:

vllm serve deepreinforce-ai/Ornith-1.0-35B \
--served-model-name Ornith-1.0-35B \
--host 0.0.0.0 --port 8000 \
--max-model-len 262144 \
--gpu-memory-utilization 0.85 \
--enable-prefix-caching \
--enable-auto-tool-choice --tool-call-parser qwen3_xml \
--reasoning-parser qwen3 \
--trust-remote-code

Note: use qwen3_xml for vLLM and qwen3_coder for SGLang — the parsers are not interchangeable. Using the wrong parser may degrade tool-calling reliability.

Running Ornith 1.0-35B with SGLang

SGLang has optimized scheduling for MoE models and can be the better choice when running Ornith 35B in batch scenarios:

python -m sglang.launch_server \
--model-path deepreinforce-ai/Ornith-1.0-35B \
--served-model-name Ornith-1.0-35B \
--host 0.0.0.0 --port 8000 \
--context-length 262144 \
--mem-fraction-static 0.85 \
--tool-call-parser qwen3_coder \
--reasoning-parser qwen3

Running Ornith 1.0-35B with Ollama

For quick local testing without Python setup:

ollama run hf.co/deepreinforce-ai/Ornith-1.0-35B-GGUF

Ollama pulls the GGUF and starts a chat session. The full how-to-run guide covers connecting the server to Claude Code, OpenHands, and other agent frameworks.

The 262K Context Window at 35B Scale

Like all Ornith 1.0 models, the 35B supports up to 262,144 tokens of context. At 35B scale, this large context window becomes practically useful for repository-level tasks: you can feed a substantial chunk of a codebase into context alongside the task description and let the model reason over actual source code rather than summaries.

Enable the full window with:

--max-model-len 262144      # vLLM
--context-length 262144     # SGLang
-c 262144                   # llama.cpp

Be aware that very long contexts increase KV cache memory requirements significantly. On a 24 GB GPU, you may need to balance context length against batch size.

Self-Scaffolding at 35B: Where the Gains Show Up

The self-scaffolding RL training benefits compound with scale. At 9B, the model can plan and execute simple multi-step tasks. At 35B, the behavioral patterns are noticeably more robust:

• Multi-file edits with consistent context tracking across files
• Longer tool-call chains with more reliable error recovery
• Better code diff generation that respects surrounding context
• Decomposition of ambiguous tasks into explicit subtasks before execution

The Terminal-Bench 2.1 methodology gives a concrete measure of this: tasks run with a 4-hour timeout, 32 CPU cores, and 48 GB RAM — conditions designed to stress agentic behavior across many sequential actions. Ornith 35B’s 64.2 score reflects genuine multi-step agent capability, not single-shot code generation.

Ornith 1.0-35B vs 31B Dense: Which to Choose?

The Ornith 1.0-31B (Dense, Gemma 4 base) exists as an intermediate option with ~62 GB VRAM at bf16 or ~20 GB at Q4. The 35B MoE is almost always the better choice:

• Faster inference (MoE vs dense at similar VRAM)
• Higher benchmark scores on agentic coding tasks
• Same 262K context window
• Better quantization story (Q5_K_M at ~25 GB vs Q4 at ~20 GB for the 31B)

The 31B may appeal if you specifically want a Gemma 4 base model or need single-precision inference on an 80 GB GPU. For agentic coding, the 35B MoE is the better pick.

When to Look Beyond the 35B

The 35B is recommended for most users, but there are scenarios where the 397B is worth the hardware investment:

• Production agent pipelines where every percentage point of SWE-Bench accuracy translates to real cost savings
• Large codebase analysis requiring the highest-quality multi-hop reasoning
• Organizations with existing 8× GPU infrastructure

The ornith 1.0 397b api guide covers the infrastructure requirements and when the 397B becomes worth its cost.

FAQ

Why is Ornith 1.0-35B the recommended model?

DeepReinforce AI marks it as “Best Value” because it is both faster and more accurate than the 9B dense model. Thanks to MoE architecture with only ~3B active parameters per token, inference speed exceeds the 9B while accuracy significantly improves — making the 35B a strict upgrade for any user with 24 GB+ VRAM.

Does the 35B run on a single RTX 4090?

Yes, but with constraints. At Q4_K_M (~20 GB), it fits comfortably. At Q5_K_M (~25 GB), you will need to reduce KV cache allocation or context length to stay within 24 GB. The Q4_K_M quantization retains most accuracy and is the practical choice for 24 GB GPUs.

Is Ornith 1.0-35B available as GGUF?

Yes. DeepReinforce AI publishes GGUF quantizations on Hugging Face at deepreinforce-ai/Ornith-1.0-35B-GGUF. Multiple quantization levels are available, including Q4_K_M and Q5_K_M.

How does Ornith 1.0-35B compare to the 397B flagship?

The 35B scores 64.2 vs the 397B’s 77.5 on Terminal-Bench 2.1, and 75.6 vs 82.4 on SWE-Bench Verified. The accuracy gap is real, but the hardware gap is enormous: 35B runs on a single consumer GPU while the 397B requires 8× 80 GB GPUs. For most teams, the 35B is the right balance.

Why Ornith 1.0-35B Is the Default Recommendation

The ornith 1.0 35b MoE is not just a competent small model — it redefines what “small” means in the context of agentic coding. Beating Qwen 3.5-397B on Terminal-Bench while running on a single RTX 4090 is a genuine architectural achievement. The self-scaffolding RL training amplifies the efficiency advantage of MoE into a behavioral advantage at agent-loop tasks.

For the developer who has 24 GB of VRAM and wants the best open-source agentic coding model that doesn’t require a GPU cluster, ornith 1.0 35b is the answer in 2026. Check the alternatives page if you’re still comparing against other open models, or jump to the how-to-run guide to get started.