What if an AI model didn't just learn from a fixed set of problems, but learned to create new problems, design ways to solve them, evaluate the results, and use those experiences to improve?

That is the idea behind Ornith-1.5, a new family of open-source AI models built around what its creators call end-to-end self-improvement.

The claim needs to be stated carefully. Ornith is not an AI that independently rewrites its own neural network weights whenever it feels like it. Its self-improvement happens through a designed training pipeline involving task generation, scaffold generation, solution rollouts, rewards, and reinforcement learning.

But that distinction doesn't make the idea less interesting. It makes it more technically interesting.

Instead of humans deciding everything the model should practice, Ornith attempts to make the training process itself adaptive. (Ornith AI)

What is Ornith?

Ornith is a family of open-source models designed primarily for agentic tasks, particularly coding, reasoning, tool use, and computer-based workflows.

The latest generation, Ornith-1.5, comes in three main sizes:

• Ornith-1.5-9B, a dense 9-billion-parameter model
• Ornith-1.5-35B-A3B, a 35-billion-parameter Mixture-of-Experts model that activates about 3B parameters per token
• Ornith-1.5-397B, a roughly 397-billion-parameter Mixture-of-Experts flagship model (Ornith AI)

All three share the same broad philosophy.

The interesting part isn't simply the parameter count.

It's how the models are trained.

The problem with traditional AI training

Imagine you're training a student to become a programmer.

You could give them 100,000 programming problems.

They solve them.

You grade them.

They improve.

But there's a problem.

Who created the 100,000 problems?

Humans did.

And that means the training curriculum is largely determined in advance.

As the student becomes better, many of those problems become useless. They're too easy.

So you need harder problems.

Then even harder ones.

Eventually, you have humans constantly trying to figure out:

"What should we make the AI practice next?"

This is one of the problems Ornith is attacking.

Instead of keeping the training distribution static, Ornith-1.5 tries to generate new training experiences based on the model's current abilities. (Ornith AI)

Ornith's core idea: AI generates its own curriculum

The simplest way to understand Ornith-1.5 is as a loop:

Generate task

↓

Generate strategy / scaffold

↓

Attempt solution

↓

Evaluate

↓

Reward

↓

Improve

↓

Generate harder task

And repeat.

The model therefore isn't only being trained to answer questions.

It is also being trained to participate in creating the environment from which it learns. (Ornith AI)

This is what makes the term self-improvement show up in Ornith's description.

But again, there is an important distinction.

This isn't "the model decides to modify its own weights."

The research team has built a training system around the model. The generated tasks and scaffolds feed into reinforcement learning, which updates the policy during training.

So a better mental model is:

A model inside an automated training loop that can generate increasingly useful experiences for itself.

That's much more accurate than saying "the AI trains itself."

So what exactly does Ornith generate?

This is where Ornith-1.5 gets particularly interesting.

There are three major pieces.

1. The task

The system generates a new problem.

But it doesn't want random problems.

The goal is to generate tasks that are:

• valid
• verifiable
• difficult enough to be useful
• still solvable
• sufficiently novel

The system uses the model's previous solving history and information about the environment to propose progressively harder tasks. (Ornith AI)

Think of it like an adaptive exam.

If you score 100% on algebra questions, the system shouldn't keep giving you basic algebra.

It should push you toward harder problems.

2. The scaffold

This is one of the more unusual parts.

A scaffold is essentially the structure used to help an agent solve a task.

It can include things such as:

• instructions
• tools
• task decomposition
• orchestration
• strategies for approaching the problem

Ornith-1.5 doesn't simply use one fixed scaffold.

It can generate or refine task-specific scaffolds for the problems it creates. (Ornith AI)

That matters because solving a difficult coding problem isn't just about having a smarter language model.

The way the model uses tools, breaks down the task, checks its work, and recovers from mistakes can dramatically affect performance.

Ornith tries to optimize that layer too.

3. The solution rollout

Once the system has a task and a scaffold, the model attempts to solve it.

That attempt is called a rollout.

The resulting performance generates a reward.

That reward can then be propagated back through the training process.

So the system isn't only learning:

"Was my answer correct?"

It can also learn:

"Was this a useful problem?"

and

"Was this a useful strategy for solving it?"

That's the core shift.

How does Ornith decide whether a generated task is useful?

This is where the paper gets much more technical.

Ornith defines the task reward using three signals:

Validity × Frontier Difficulty × Novelty

(Ornith AI)

That's a surprisingly important detail.

Because if you simply tell an AI:

"Generate difficult problems."

you can get garbage.

The system might produce impossible tasks.

Or badly specified tasks.

Or variations of the same problem over and over.

Or tasks that are technically difficult but teach the model almost nothing.

Ornith therefore tries to optimize three properties simultaneously.

1. Validity

First:

Does the task actually work?

A generated problem isn't useful if its evaluation environment is broken.

Ornith checks whether:

• the task is coherent
• the scaffold executes correctly
• strong solutions pass
• clearly incorrect solutions fail
• the evaluation actually matches the task specification (Ornith AI)

If a task isn't valid, its task reward can effectively collapse to zero.

This is important because self-generated training data creates a nasty problem:

The model can generate its own garbage.

A self-improvement system is only as good as the feedback it receives.

2. Frontier difficulty

The next question is:

Is the problem actually challenging the model?

Ornith doesn't simply want impossible tasks.

If a model solves 99% of the generated problems, they're probably too easy.

If it solves 0%, they're probably too hard to provide useful reinforcement-learning signals.

Ornith targets a success rate around 20% for generated tasks. (Ornith AI)

That means the system is looking for problems sitting near the model's current capability frontier.

As the model improves, yesterday's difficult problem can become easy.

Its value as a training task falls.

The task generator can then search for harder problems.

This creates an adaptive curriculum.

3. Novelty

There's another problem.

Suppose the model discovers a type of task that sits exactly at its capability frontier.

It could simply generate 10,000 slightly different versions of the same thing.

That isn't a very good curriculum.

So Ornith adds a novelty signal.

Generated tasks are compared against previously generated or trained-on tasks, with the system rewarding tasks that aren't overly redundant. (Ornith AI)

The result is supposed to be a training distribution that keeps moving.

Harder.

Different.

Still learnable.

But there's another problem: reward hacking

This might be the most important part of the entire system.

Whenever you give an AI a reward function, you create an opportunity for the AI to find shortcuts.

If the objective says:

"Get a high score."

the model doesn't necessarily care about doing what humans intended.

It cares about finding a path to the score.

This is known as reward hacking.

Ornith explicitly accounts for this.

Its harness reward considers:

Task alignment

Reward fidelity

Hack resistance

The goal is to make sure the generated evaluation environment actually measures what the task is supposed to measure, rather than giving the model easy ways to exploit the evaluator. (Ornith AI)

This is a major issue for any system that generates its own training environments.

If the AI learns to fool the grader, the entire self-improvement loop can become meaningless.

What is GRPO doing here?

Ornith says task generation, scaffold generation, and solution rollouts are optimized using GRPO, or Group Relative Policy Optimization.

You don't need to understand every mathematical detail to understand its role.

At a high level:

The model generates multiple candidate behaviors.

Those behaviors receive rewards.

The training algorithm uses the relative performance of those candidates to update the model's policy.

In Ornith's setup, this reinforcement-learning machinery is applied across the task-generation, scaffold-generation, and solution-generation stages. (Ornith AI)

So the system isn't just saying:

"Here's another dataset. Train on it."

It's closer to:

"Generate an experience, evaluate that experience, and use the outcome to improve the policy."

Then do it again.

Ornith-1.0 vs Ornith-1.5

This distinction is worth understanding.

Ornith-1.0 introduced the idea of self-scaffolding.

Its system jointly optimized the scaffold and the solution rollouts.

Ornith-1.5 expands the loop.

Now the system jointly optimizes:

Task generation

Scaffold construction

Solution rollouts

(Ornith AI)

That's why the team describes 1.5 as moving from self-scaffolding to self-improvement.

The model isn't simply learning how to answer a fixed set of tasks better.

The training system is also trying to learn:

What should I practice?

and

How should I approach it?

How capable is Ornith-1.5?

This is where the numbers get interesting.

The flagship Ornith-1.5-397B reports:

BenchmarkOrnith-1.5-397BTerminal-Bench 2.186.1SWE-bench Verified86.0SWE-bench Pro65.1SWE-bench Multilingual79.6DeepSWE56.0GPQA Diamond92.8BrowseComp86.6MCP-Atlas80.0

These figures come from Ornith's published evaluation results. The team says its Ornith-1.5 results are averaged over five independent runs. (Ornith AI)

The model isn't dominant on every benchmark.

That's important.

For example, Ornith reports 86.1 on Terminal-Bench 2.1, compared with 85.0 for Claude Opus 4.8 in its comparison table.

But on DeepSWE, Ornith reports 56.0, versus 59.0 for Claude Opus 4.8.

On GPQA Diamond, it reports 92.8 versus 93.6 for Opus 4.8.

So "Ornith beats Claude" would be a misleading headline.

A more accurate statement is:

Ornith-1.5-397B is competitive with frontier closed models on several reported benchmarks, while being open source.

That's the interesting claim. (Ornith AI)

The 35B model is arguably even more interesting

The flagship gets most of the attention because of its 397B parameter count.

But look at the Ornith-1.5-35B-A3B.

It's a Mixture-of-Experts model with 35B total parameters, but only around 3B parameters activated per token.

On Terminal-Bench 2.1, Ornith reports:

68.5

when evaluated with Claude Code.

For comparison, its table reports:

• Qwen3.6-35B-A3B: 49.2
• Gemma-4-31B: not reported in that configuration
• Muse-Glimmer-30B: not reported in that configuration (Ornith AI)

On SWE-bench Verified, the 35B model reports 79.0.

That matters because it suggests the self-improvement approach isn't only useful at enormous scale.

And then there's the 9B model

This is probably the most interesting model for developers who don't have access to massive GPU clusters.

Ornith-1.5-9B is a dense 9B model.

Its reported results include:

47.0 on Terminal-Bench 2.1

70.6 on SWE-bench Verified

86.4 on GPQA Diamond

The official model documentation also provides a quantized Ornith-1.5-9B-Mobile version intended for deployment on mobile devices. (Ornith AI)

That's a pretty wild contrast.

One family spans from a model requiring serious multi-GPU infrastructure to a 9B model targeting edge and mobile deployment.

Wait, is the 397B model really "397 billion parameters"?

Yes, with an important clarification.

Ornith-1.5-397B is a Mixture-of-Experts model.

So saying "397 billion parameters" doesn't mean every token necessarily activates all 397B parameters.

The model card identifies it as a roughly 397B MoE model. Its official serving documentation describes the model as requiring multi-GPU serving, with the full bf16 model estimated around 800 GB. (Hugging Face)

That's why parameter count alone isn't enough to compare its computational requirements with a dense 397B model.

Mixture-of-Experts architectures activate only a subset of experts for each token.

This can provide a large total parameter capacity without paying the full compute cost of activating every parameter on every token.

Is Ornith open source?

Yes.

The Ornith repository states that both generations are MIT licensed. Model checkpoints are available through Hugging Face. (GitHub)

The ecosystem currently includes formats such as:

• BF16
• FP8
• NVFP4
• GGUF
• MLX

The project also provides models intended for local inference, including Apple Silicon and llama.cpp/Ollama-compatible formats. (GitHub)

That makes Ornith particularly interesting for the open-model ecosystem.

You're not just reading about a research model.

You can actually download the weights and experiment with them.

What can you actually use Ornith for?

The models are particularly aimed at agentic workflows.

That means tasks where the AI needs to do more than produce one text response.

For example:

Coding agents

Give the model a repository and ask it to:

• understand the codebase
• find a bug
• modify files
• run tests
• debug failures
• iterate until the task is complete

The 9B model documentation specifically describes it as being optimized for terminal-based coding agents. (Hugging Face)

Tool-using agents

An agent might need to:

• inspect files
• execute commands
• call APIs
• search information
• manipulate a development environment
• verify its own work

This is fundamentally different from asking an LLM:

"Write me a Python function."

Local AI

The smaller models can be run locally, with GGUF and MLX variants available.

The 9B mobile variant is particularly interesting for developers exploring on-device AI agents. (GitHub)

But there's a huge caveat with the benchmark numbers

This is where a lot of AI coverage gets sloppy.

You shouldn't read:

"Ornith scored 86.1 on Terminal-Bench."

and conclude:

"Ornith is better than every model that scores 85."

That's not how these benchmarks work.

Terminal-Bench 2.1 measures agent performance in terminal environments, and the result depends on the model, harness, tools, configuration, task environment, timeouts, and other evaluation details. The benchmark itself requires multiple trials per task. (GitHub)

Ornith's own evaluation specifies its particular setups, including Terminus-2 and Claude Code, context lengths, temperatures, timeouts, hardware resources, and other configuration details. (Ornith AI)

So a benchmark number should always be read as:

Model + configuration + agent harness + benchmark version

not simply:

Model = number

That's especially important because Terminal-Bench has been actively revised.

Terminal-Bench 2.1 fixed issues in 28 tasks from version 2.0, including problems involving external dependencies, resource mismatches, and task specification. (GitHub)

And the benchmark ecosystem has already moved beyond 2.1, with Terminal-Bench 3.0 released in July 2026 and Terminal-Bench 4.0 released in August 2026. (TERMINAL-BENCH)

So 86.1 on Terminal-Bench 2.1 is impressive, but it shouldn't be presented as a permanent universal ranking of AI intelligence.

There's another important limitation: the results are primarily vendor-reported

Ornith's published results are its own evaluation results, averaged over five runs.

That is useful evidence.

But it isn't the same thing as having a large body of independent replication.

A recent third-party analysis explicitly notes that the Ornith benchmark figures come from the team's published results and that independent replication was not yet established. (SaaSCity)

That doesn't mean the results are false.

It means you should phrase them correctly.

Instead of:

"Ornith is objectively better than Claude."

Say:

"Ornith reports performance comparable to Claude Opus 4.8 on several benchmarks."

That distinction matters.

Why Ornith matters beyond Ornith

The most interesting part of Ornith isn't necessarily the model itself.

It's the training philosophy.

For years, a lot of AI progress has looked roughly like this:

Collect more data

→

Train larger models

→

Build better post-training

→

Improve benchmarks

Ornith is exploring another lever:

Improve the training environment itself.

If an AI can generate useful problems for itself, construct appropriate tools and scaffolds, attempt those problems, evaluate the results, and feed those experiences back into reinforcement learning, then the training distribution doesn't have to remain static.

It can evolve with the model.

That's a very different idea.

Think about what happens if this scales

Suppose a model is initially bad at debugging distributed systems.

A normal training pipeline might contain some examples of distributed-systems debugging.

Ornith's approach aims to do something different.

The system can identify where the model is weak.

Generate a task around that weakness.

Build an environment in which the task can be tested.

Have the model attempt it repeatedly.

Measure the outcomes.

Then use those outcomes for reinforcement learning.

Once the model gets good at that class of problem, the task generator can search for something harder.

Then repeat.

Weakness → task → attempt → feedback → improvement → harder task.

That's an adaptive curriculum.

And the model's capabilities can influence what it practices next.

Does this mean we're close to self-improving AI?

Not necessarily.

This is where the hype needs to stop.

Ornith is an important experiment in automated curriculum generation, self-scaffolding, and reinforcement-learning-based self-improvement.

It does not demonstrate unrestricted autonomous intelligence.

The system still depends on:

• a designed training environment
• reward functions
• evaluation mechanisms
• compute
• human-designed constraints
• reinforcement-learning algorithms
• carefully constructed safeguards

And the model isn't freely rewriting its architecture or deciding its own goals.

The term self-improvement here has a specific technical meaning.

That's still a big deal.

But it's very different from saying:

"The AI has learned how to recursively improve itself."

We're not there.

The real bottleneck may be the evaluator

There's a deeper issue hiding underneath all of this.

If AI systems increasingly generate their own training data, evaluation becomes incredibly important.

Imagine this loop:

AI generates problem.

AI generates grader.

AI solves problem.

AI grades itself.

AI improves.

If the grader is weak, the system can optimize the wrong thing extremely efficiently.

That's why Ornith spends significant effort on:

validity

difficulty

novelty

task alignment

reward fidelity

hack resistance

The better these evaluators become, the more useful the self-improvement loop becomes. (Ornith AI)

In other words:

The future of self-improving AI may depend as much on better evaluation environments as it does on better models.

That's one of the most important lessons from Ornith.

Ornith vs traditional LLM training

A simplified comparison looks like this:

Traditional approachOrnith-style approachFixed training curriculumAdaptive curriculumHuman-generated tasksModel-generated tasksFixed agent scaffoldsGenerated/refined scaffoldsStatic difficultyFrontier-based difficultyFixed task distributionContinuously evolving distributionSolution optimizationTask + scaffold + solution optimizationHuman-designed experiencesModel-generated learning experiencesStatic feedback loopIterative reinforcement-learning loop

It's not that traditional training disappears.

Ornith-1.5 itself builds on an existing pretrained foundation and uses continued pretraining, mid-training, and post-training. (Ornith AI)

The difference is what happens during the self-improvement portion.

What makes Ornith-1.5 particularly interesting right now?

Three things.

1. It's open

You can inspect the project, download the weights, run the models, and build on them under the MIT license. (GitHub)

2. It targets agents

The models aren't designed simply to be chatbots.

They're optimized around coding, tool use, reasoning, and agentic environments.

3. The training loop itself is part of the research

This may be the most important one.

The interesting research question isn't simply:

"How big should the model be?"

It's:

"Can the model help create the training experiences that make the next version of the model better?"

Ornith-1.5 is an attempt to answer yes.

Whether that idea scales dramatically remains an open question.

Final takeaway

Ornith-1.5 isn't interesting because it has 397 billion parameters.

There are already enormous models.

It's interesting because it asks a more fundamental question:

What happens when an AI model isn't limited to the curriculum humans prepared for it?

Ornith's answer is to build a loop where the system can:

generate tasks → generate scaffolds → attempt solutions → evaluate them → learn → generate harder tasks.

That doesn't mean the model is independently redesigning itself.

It doesn't mean we've reached AGI.

And the benchmark results still need to be interpreted with care.

But it does point toward a potentially important direction for AI research:

Instead of only building better models, build systems that get better at generating the experiences from which models learn.

If that approach continues to scale, the next major gains in AI may come not just from more parameters or more data, but from better training loops.

And that's the part of Ornith worth paying attention to.