This Model Writes Its Own Training Tasks. DeepSWE: 8 to 56.

TL;DR

Ornith-1.5 landed on August 19 as three MIT-licensed open-weight models: a 9B dense, a 36B mixture-of-experts that activates about 3B parameters per token, and a 397B MoE. The interesting part is not the sizes, it is the training loop. Where Ornith-1.0 learned to write its own agent scaffold around a fixed set of human-curated tasks, 1.5 writes the tasks too, then the scaffold, then the solution, and the reward from the solution flows back into all three. On the lab's own numbers the 397B posts 86.1 on Terminal-Bench 2.1 against Claude Opus 4.8's 85.0, and jumped from 8 to 56 on DeepSWE in one generation. Weights are on Hugging Face and there are Ollama tags tonight.

The loop, and why the task generation is the news

Reinforcement learning on code has a supply problem. You need hard, verifiable tasks, and humans curate them slowly and expensively. Every open lab eventually hits the same wall: the model saturates the task set long before it saturates the method.

Ornith-1.5's answer is to make task creation part of the policy. The published loop runs in three stages. The model is handed an environment or codebase, high-level instructions about the task type, and its own history of what it has already solved. From that it proposes a new task deliberately harder than what it has cleared. Then it generates a scaffold for that specific task: the tools, the decomposition, the orchestration. Then it produces a solution rollout. The reward from that rollout is propagated across all three stages, so the gradient reaches the task proposer, the scaffold builder, and the solver at once.

The relatable version: imagine a student who sets the exam, writes the study plan, and then sits the paper, and gets marked on all three. A model grading its own homework is a familiar failure mode. This one also writes the homework, which is either the fix or the punchline, depending on how much you trust the verifier underneath.

Why it does not just collapse

The obvious objection is reward hacking: a model free to invent its own tasks will invent easy ones. What keeps this honest is that the tasks are grounded in real environments and codebases with executable outcomes, and the proposer is conditioned on the solve history, so it is explicitly pushed past what already works. Whether that holds at scale is a question the blog post does not answer, and neither does anyone else yet.

The number that actually moved

Benchmark deltas between model generations are usually a couple of points of noise dressed up as progress. This one is not that. On DeepSWE, the 397B went from 8.0 to 56.0. That is not an improvement, it is a capability that previously was not there.

Frontier-Bench v0.1 tells the same story in miniature: 2.7 to 13.5. Both benchmarks are the hard, long-horizon end of the coding spectrum, exactly the regime where a fixed human task set runs out of road first. If you wanted a single piece of evidence that generated curricula do something, this is it.

Where it still loses

The headline comparison is Opus 4.8, and the honest scoreboard is closer than the launch tweet suggests. Across the seventeen benchmark rows the lab publishes for the 397B, Ornith-1.5 wins seven and Opus 4.8 wins ten.

Ornith takes both Terminal-Bench 2.1 harnesses (86.1 vs 85.0 under Terminus-2, and 85.2 vs 78.9 under the Claude Code harness, which is a fun result to publish), SWE-bench Verified by a hair at 86.0 vs 85.8, SWE-bench Multilingual, WideSearch, BrowseComp and ClawEval.

Opus 4.8 keeps SWE-bench Pro (68.0 vs 65.1), DeepSWE, Frontier-Bench, NL2Repo (69.7 vs 59.5, a 10-point gap on writing a repository from a natural-language spec), SWE Atlas QnA, both Humanity's Last Exam variants, GPQA Diamond (93.6 vs 92.8), MCP-Atlas and Toolathlon. Kimi K3, at 2.8T parameters, still tops the table on Terminal-Bench 2.1 at 88.3.

Read that as parity in the agentic-coding lane and a real deficit on long-horizon planning and hard reasoning, from a model roughly a seventh of Kimi K3's size that you can download.

The 35B is the one you will actually run

The 397B is 800GB in bf16 and 242GB as an Ollama pull, so for most people it is a leaderboard entry, not a deployment. The 36B MoE is the release that matters locally. It activates about 3B parameters per token, ships at roughly 70GB in bf16 and 23GB via Ollama, and beats every dense model in its weight class on the agentic evals.

It posts 79.0 on SWE-bench Verified against Muse Glimmer-30B's 76.0 and Qwen3.6-35B-A3B's 73.4, and 59.6 on SWE-bench Pro against their 51.2 and 49.5. On DeepSWE it scores 22.0, where both Ornith-1.0-35B and Qwen3.6-35B-A3B scored a clean 0.0, which is at least an unambiguous baseline.

The 9B is the laptop tier: 46.2 on Terminal-Bench 2.1, 70.6 on SWE-bench Verified, 86.4 on GPQA Diamond, and a 6.6GB Ollama pull. For context, Qwen3.5-9B managed 21.3 on the same terminal benchmark.

Running it

• Context: 262,144 tokens native across the family, extendable to roughly 1M with YaRN at 4.0x scaling. Ollama exposes 256K.
• Inputs: text and image, per the Ollama model cards.
• Engines: transformers 5.8.1+, vLLM 0.19.1+, SGLang 0.5.9+, plus llama.cpp, Ollama, LM Studio, Jan and Docker Model Runner.
• Hardware: the 9B fits a single 80GB card unquantized at full context. The 35B card recommends 2x 80GB for 256K with headroom, or a quant if you are on one GPU.
• License: MIT on every model card, which after a month of licenses with revenue-share clauses and geographic tripwires is genuinely the easiest sentence in this post.

Caveats worth holding onto

Every number above is the lab's own, published on launch day with no third-party evaluation yet. The methodology notes are better than most: results are averaged over five independent runs, git history is stripped from the repository image during SWE-bench evaluation to block the obvious cheat, and network access is disabled on certain benchmarks.

The comparison set has a hole in it. The tables benchmark against Qwen3.6-35B-A3B, Qwen3.5-397B, Qwen3.5-9B, Gemma 4-31B and Muse Glimmer-30B. Qwen3.8, which shipped open weights last week, does not appear anywhere. That is the most obvious rival for the 35B and its absence is conspicuous.

And "self-improvement" is doing heavy lifting as a phrase. The Hacker News thread, 164 points in, is largely people asking whether the gains are in the weights or in a cleverer harness, and one commenter's verdict lands: another day, another startup claiming some vague version of recursive self-improvement. The DeepSWE delta is real and reported against a fixed evaluation, so the harness-only reading does not obviously hold. It is also one lab's table. Wait for someone else to run it.

One more oddity: the 1.0 release came from a lab called DeepReinforce. The 1.5 blog post is signed only "the Ornith Team" on a new domain, with no named authors and no technical report. The method deserves a paper. It got a webpage.

Key Takeaways

• Ornith-1.5 shipped August 19 in 9B dense, 36B MoE (3B active) and 397B MoE sizes, all MIT-licensed, with weights on Hugging Face and Ollama tags at 6.6GB, 23GB and 242GB.
• The training loop now includes task generation: the model proposes progressively harder tasks, builds a scaffold per task, solves it, and reward flows back into all three stages.
• The 397B went from 8.0 to 56.0 on DeepSWE and 2.7 to 13.5 on Frontier-Bench v0.1 in one generation, the clearest evidence yet that generated curricula unlock long-horizon coding.
• Against Claude Opus 4.8 across seventeen published rows the 397B wins seven and loses ten, taking both Terminal-Bench harnesses and SWE-bench Verified while losing NL2Repo by ten points.
• The 36B is the practical release: 67.8 on Terminal-Bench 2.1 and 79.0 on SWE-bench Verified, ahead of every dense 30B rival, on 3B active parameters.
• All numbers are lab-reported with no independent evaluation yet, and the comparison tables omit Qwen3.8 entirely.

Sources: Ornith-1.5 technical blog post, Ornith-1.5-397B model card, Ornith-1.5-35B-A3B model card, Ornith-1.5-9B model card, Ollama library listing, TestingCatalog, Hacker News discussion