Ornith-1.5's Self-Improvement Loop: How It Trains Without Fixed Tasks
Ornith-1.5 trains by jointly generating tasks, building scaffolds, and running rollouts. Here's how that self-improvement loop actually works.
What is Ornith-1.5’s self-improvement training loop?
Ornith-1.5 is a family of open-weight foundation models trained through a loop that generates its own training tasks, builds the scaffolding needed to attempt them, and runs reinforcement learning on the resulting rollouts, all without a fixed set of human-curated benchmarks. Instead of humans writing tasks and harnesses ahead of time, the system optimizes task generation, scaffold construction, and solution rollouts together, so the training data and the evaluation infrastructure evolve alongside the model itself.
TL;DR
- Ornith-1.5 removes the fixed-task bottleneck by generating new training tasks continuously rather than drawing from a static, human-curated dataset.
- The loop optimizes three things jointly: task generation, scaffold (harness) construction, and the rollouts used to train the policy via reinforcement learning.
- This is an evolution, not a rebuild: Ornith-1.0 already optimized scaffolds and rollouts, and 1.5 extends that loop to also cover how tasks themselves get created.
- The base models come from Qwen3.5 and Gemma4, with Ornith’s own continued pretraining, mid-training, and post-training stacked on top before self-improvement kicks in.
- The family spans a range of sizes, from a 9B dense model deployable on a single GPU (with a quantized mobile variant) up to a 35B mixture-of-experts model that activates only around 3B parameters per token.
- Benchmark gains show up mainly in coding and agentic tasks, including SWE-bench variants, Terminal-Bench 2.1, and tool-use evaluations like MCP-Atlas and Toolathlon-Verified.
- The full methodology for reward design and task/harness construction is documented separately in Ornith’s technical blog, not in the model cards themselves.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Why does self-improvement matter for training foundation models?
Most reinforcement learning pipelines for language models depend on a bank of tasks that people wrote by hand: coding problems with known solutions, benchmark suites, curated prompts. That approach has an obvious ceiling. Human-curated tasks are expensive to produce, they cover only what their authors thought to write, and once a model saturates them, there’s nowhere left to go without writing more.
Ornith-1.5’s approach treats task creation itself as something to optimize, not just something to consume. Rather than a static dataset, the system continuously produces new tasks, figures out effective strategies for attempting them, and feeds the results into policy improvement through reinforcement learning. In principle, this lets training scale with compute rather than with how fast humans can author new benchmarks. It also means the difficulty and variety of training tasks can move as the model itself gets stronger, since a fixed dataset can’t adapt to a model that’s already mastered it.
How does the loop actually work?
The Ornith documentation describes the loop as jointly optimizing three components:
- Task generation: creating new problems for the model to solve, rather than pulling from a fixed pool.
- Scaffold construction: building the harness, or the surrounding structure and tools, that the model uses to attempt a task.
- Solution rollouts: running the model against generated tasks through its scaffold, then using the outcomes as reinforcement learning signal to update the policy.
This is a step beyond Ornith-1.0, which already optimized scaffold and rollout construction but still relied on a fixed set of human-curated tasks. Ornith-1.5 folds task generation into the same loop, so all three pieces move together instead of one being frozen while the others adapt.
The practical effect is that the model isn’t just getting better at solving a known set of problems. It’s participating in defining what “a good problem” looks like, what “a good way to attempt it” looks like, and improving on both simultaneously through the reward signal generated by rollouts. The specifics of how tasks are scored and how rewards are shaped for harness design live in Ornith’s own technical writeup rather than in the model cards, but the model cards confirm the general shape: task generation, harness building, and rollout reward design are treated as parts of one optimization problem.
What foundation are the models built on?
Ornith-1.5 isn’t trained from scratch. It extends Ornith-1.0, which itself was built on top of Qwen3.5 and Gemma4 base models, with additional continued pretraining, mid-training, and post-training layered in before any self-improvement loop runs. That matters because it separates two different kinds of work: the conventional pretraining pipeline that gives the model its base language and reasoning capability, and the self-improvement loop that specifically targets agentic and coding competence on top of that foundation.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
In other words, self-improvement here isn’t a replacement for standard training. It’s an additional stage that kicks in after a competent base model already exists, using RL against self-generated tasks and scaffolds to push capability further in specific domains, particularly coding and tool use.
What does the model lineup look like?
The Ornith-1.5 family includes at least two published sizes:
- Ornith-1.5-9B, a dense model sized for single-GPU deployment, with a quantized Ornith-1.5-9B-Mobile variant aimed at edge and mobile hardware.
- Ornith-1.5-35B-A3B, a mixture-of-experts model that activates roughly 3B parameters per token despite its larger total size.
The mixture-of-experts design is notable because it decouples total parameter count from inference cost. Activating only about 3B parameters per token while carrying 35B total lets the model draw on a larger set of learned experts without paying the full computational cost of a dense 35B model on every token.
Is Ornith-1.5 actually better than comparable models?
According to the published model cards, Ornith-1.5-35B-A3B outperforms Qwen3.6-35B-A3B, a similarly structured peer, across coding and agentic benchmarks, and beats dense models like Gemma-4-31B and Muse-Glimmer-30B by wide margins on agentic coding tasks specifically. Reported benchmarks include Terminal-Bench 2.1 (under both the Terminus-2 harness and Claude Code), SWE-bench Verified, SWE-bench Pro, SWE-bench Multilingual, and agentic evaluations like MCP-Atlas and Toolathlon-Verified.
The smaller Ornith-1.5-9B shows the same pattern relative to Ornith-1.0-9B and Qwen3.5-9B: consistent gains on coding and agentic benchmarks, generally trailing larger models like Qwen3.6-35B-A3B on some agentic tasks but closing much of the gap despite its smaller size.
It’s worth being precise about what these numbers do and don’t show. They demonstrate that the self-improvement training approach produces models that score well on a specific set of coding and agentic benchmarks compared to named peers at similar scale. They don’t, by themselves, prove that self-generated tasks generalize better than human-curated ones in every domain, since the published comparisons focus on coding, reasoning, and agentic tool-use categories rather than the full range of language model capability.
What are the practical implications for people building with these models?
For teams evaluating open-weight models for coding agents or tool-using systems, the self-improvement angle is mostly relevant as an explanation for why Ornith-1.5 performs the way it does on agentic benchmarks, not as something end users interact with directly. Once released, the models are used like any other open-weight checkpoint: downloaded, served through inference infrastructure such as vLLM, and prompted normally.
The more interesting implication is directional. If joint optimization of task generation, scaffolding, and rollouts continues to produce measurable gains release over release, as it did moving from Ornith-1.0 to 1.5, that’s a signal that RL training pipelines are moving away from static benchmark-driven curricula and toward loops where the model’s own capability shapes what it trains on next.
Frequently Asked Questions
What makes Ornith-1.5 different from Ornith-1.0?
Ornith-1.0 optimized scaffold construction and solution rollouts against a fixed set of human-curated tasks. Ornith-1.5 extends that loop to also generate the tasks themselves, so all three components (tasks, scaffolds, rollouts) are optimized jointly.
What base models does Ornith-1.5 build on?
Ornith-1.5 extends Ornith-1.0, which was developed on top of Qwen3.5 and Gemma4 with additional continued pretraining, mid-training, and post-training before the self-improvement loop was applied.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
What sizes does the Ornith-1.5 family come in?
The published lineup includes a 9B dense model (with a quantized mobile variant) and a 35B mixture-of-experts model that activates about 3B parameters per token.
Does self-improvement mean the model trains itself with no human involvement?
Not entirely. Humans design the reward structures, the overall training methodology, and the base models used as a starting point. What’s automated is the generation of new tasks and harnesses during the RL loop, rather than relying solely on a static, human-written task set.
Where can I find the exact reward design and evaluation methodology?
The model cards point to Ornith’s own technical blog for details on task, harness, and rollout reward design. The model cards themselves confirm the general architecture of the loop but leave the granular methodology to that separate documentation.
