Ornith 1.5 35B-A3B: Local Deployment, VRAM, and Real-World Tests
Ornith 1.5 35B-A3B is a mixture-of-experts model with 3B active params. Here's how it runs locally on an A100, and how it handles agentic and reasoning tests.
What is Ornith 1.5 35B-A3B?
Ornith 1.5 35B-A3B is a mixture-of-experts (MoE) language model from Deep Recurse, built on a Qwen3.5-MoE architecture with 35 billion total parameters but only about 3 billion active per token. It’s positioned as a general-purpose model spanning coding, reasoning, and agentic tasks, a shift from the original Ornith 1, which was scoped more narrowly. The model is trained with a self-improvement loop that jointly optimizes task generation, scaffold construction, and solution rollouts, rather than depending purely on fixed, human-curated training tasks.
TL;DR
- Ornith 1.5 35B-A3B is a mixture-of-experts model with 35B total parameters and roughly 3B active per token, aimed at coding, reasoning, and agentic workloads rather than a single narrow task.
- The model’s training uses a self-improvement loop that jointly evolves task scaffolds, generates multiple solution rollouts, and applies GRPO reinforcement learning to reward both the scaffold and the solutions together.
- In a local test on a single Nvidia A100 (80GB), the model plus KV cache consumed around 74GB of VRAM when served through vLLM, leaving little headroom without tuning the cache size down.
- In a hands-on agentic test, the model was given an open-ended goal (add a real-time price alert feature to a live full-stack crypto dashboard) with no step-by-step instructions, and it planned, built, tested, and self-verified the feature before declaring it done.
- The model showed targeted tool use, including detecting a port conflict caused by vLLM itself and running its own test suite to confirm pass/fail results before finishing the task.
- On a stress-test reasoning prompt requiring multilingual output (Japanese and Spanish), in-character roleplay, and a clear decision under conflicting ethical constraints, the model produced a coherent, structured, and dignity-preserving resolution.
- The creator reports Ornith 1.5 leading benchmark comparisons against the similarly sized Qwen3.5 35B across coding and agentic tasks, and narrowing the gap against much larger dense models on some agentic benchmarks.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
How does the self-improvement loop work?
Ornith 1.5’s training design centers on a loop that ties together three pieces: task generation, scaffold construction, and solution rollouts. Instead of training only on a static set of human-written tasks, the model builds its own task scaffolds, generates multiple candidate solutions against each scaffold, and scores those solutions based on how well they perform. That reward signal feeds back through GRPO (Group Relative Policy Optimization), a reinforcement learning method, to improve the scaffold and the solution generation process together rather than in isolation.
The practical effect shows up at inference time as a “generate, plan, execute” pattern. When given a task, the model doesn’t just output code; it appears to construct an internal task definition, explore the relevant context, plan an approach, execute it, and then check its own output before considering the job finished. This self-verification step is the part most distinct from a typical instruction-following coding model, which usually stops as soon as it produces an answer rather than checking whether that answer actually works.
What does running Ornith 1.5 locally require?
The 35B-A3B variant was served locally using vLLM on a single Nvidia A100 GPU with 80GB of VRAM. In that configuration, the model combined with its KV cache used close to 74GB of VRAM, leaving a fairly thin margin on an 80GB card. Anyone running this on smaller hardware, or wanting more headroom for longer contexts or concurrent requests, would need to reduce the KV cache allocation, which trades off some context length or throughput for lower memory use.
Because only about 3 billion parameters are active per token despite the 35 billion total, the compute cost per generated token is much lower than a dense model of similar total size, even though the full weight set still has to be resident in memory. That’s the core MoE tradeoff: memory footprint scales with total parameters, but inference speed scales more closely with active parameters. On a single 80GB GPU, this makes a 35B MoE model practical to run, whereas a dense 35B model with similar VRAM overhead would offer less compute headroom for the same footprint.
The model’s Hugging Face repository lists it as an image-text-to-text and text-generation model built on the qwen3_5_moe architecture, released under an MIT license, distributed as 16 safetensors shards.
How does it perform on agentic coding tasks?
The most telling test wasn’t a benchmark number but an open-ended build task. The setup was a live, already-functioning full-stack crypto price tracker: a FastAPI backend, a frontend, an Nginx proxy, a WebSocket price feed, and a Redis-backed history layer, all running as Docker services. The application had no bugs and was already operational, pulling live price data for multiple tokens.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
The instruction given to Ornith 1.5 wasn’t a checklist. It was a single open-ended goal: build a real-time price alert feature end-to-end and prove it works before stopping. From there, the model worked through its own plan: exploring the existing codebase, deciding on an approach, second-guessing and refining that approach for cleanliness, breaking the implementation into code chunks by architectural section, and then building it out.
Along the way it demonstrated targeted tool use, including recognizing that a port it wanted to use was already occupied by vLLM itself and adjusting accordingly. After finishing the build, it wrote and ran its own tests, reporting pass/fail results before confirming the feature was complete. The end result, verified in the browser, was a working alert system with live price updates, editable thresholds, and toggleable alerts across multiple tracked coins, matching the original claim that this model can independently plan, execute, and verify its own work rather than needing a human to specify every step.
Is Ornith 1.5 good at reasoning and multilingual tasks?
To test general-purpose reasoning rather than coding, the model was given a deliberately convoluted roleplay prompt: play a character in a specific personal and professional bind, face simultaneous conflicting confessions that both carry a company-policy risk, and resolve the situation with a clear, scoreable decision. The added difficulty was that the response had to be delivered in formal Japanese and natural Spanish while staying in character throughout.
The model held together under this pressure. It reasoned through the competing constraints, arrived at a single clear decision (declining both parties) with a stated rationale, and delivered coherent replies in Japanese and Spanish alongside an English translation for verification. That combination, structured decision-making, multilingual fluency, and sustained character consistency, is a harder bar than most single-language reasoning benchmarks, since it tests whether the model’s reasoning quality holds up once it’s also managing language switching and tone.
Is Ornith 1.5 35B-A3B worth running locally?
For anyone with access to a single 80GB GPU, Ornith 1.5 35B-A3B is a realistic model to self-host for agentic coding and general-purpose reasoning work. Its MoE design keeps active compute low relative to its total parameter count, and the demonstrated behavior, planning, self-checking, and running its own tests, matters more for real workflows than raw benchmark leaderboard position. The tradeoff is memory: near-74GB usage on an 80GB card doesn’t leave much room to also push for long context windows or serve multiple concurrent sessions without tuning the KV cache down.
Whether it’s “worth it” depends on whether the workload benefits from a model that verifies its own output rather than one that needs a human to catch its mistakes. For open-ended agentic tasks like the crypto dashboard test, that self-verification loop is the differentiator, not just raw accuracy.
Frequently Asked Questions
What does the “A3B” in Ornith 1.5 35B-A3B mean?
It refers to the mixture-of-experts design: the model has 35 billion total parameters but activates only about 3 billion of them per token, which is why it’s labeled “35B-A3B” (35 billion total, 3 billion active).
How much VRAM does Ornith 1.5 35B-A3B need to run?
In a local deployment on an Nvidia A100 with 80GB of VRAM using vLLM, the model plus its KV cache used close to 74GB. Lowering the KV cache size reduces memory use further, at the cost of context length or concurrency.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
How is Ornith 1.5 different from Ornith 1?
Ornith 1 was built for a narrower scope and wasn’t designed as a general-purpose model. Ornith 1.5 extends the self-improvement training loop to target strong performance across reasoning, agentic, and coding tasks together, rather than specializing in one area.
What is GRPO and why does it matter here?
GRPO (Group Relative Policy Optimization) is the reinforcement learning method used to train Ornith 1.5. It takes the reward signal from scored solution rollouts and uses it to improve both the task scaffold and the solutions jointly, rather than optimizing them separately.
Can Ornith 1.5 verify its own work?
Yes. In the agentic test described here, the model planned its approach, built the feature, wrote and ran its own tests, checked the results, and only stopped once it confirmed the implementation worked, without being told the exact steps to follow.
