The open model that writes its own homework

The thing that made me stop scrolling

Most model launches this year read like a spec sheet contest — bigger checkpoint, higher number on some benchmark, one more decimal of inevitability. Ornith-1.5 is different, and the difference is not the benchmarks. It's the sentence buried in the middle of the announcement:

“The model proposes new tasks, generates task-specific scaffolds, and produces solution rollouts for reinforcement learning.”

Read that again. The model is generating its own training curriculum. Not a lab's data team curating another million hand-labeled examples. The model looks at what it can't do yet, proposes harder versions of it, scaffolds its own tooling to attempt it, and runs reinforcement learning on its own attempts. Repeat.

Ornith-1.5 comes in three flavors — 397B MoE, 35B MoE, and 9B dense — all open weights under the MIT license, with quantized versions (FP8, GGUF, MLX, NVFP4) so you can actually run them. It posts Claude-Opus-4.8-comparable numbers on Terminal-Bench 2.1 (86.1) and DeepSWE (56.0). But the reason this matters to you has nothing to do with beating a closed frontier lab on a leaderboard. It's that this is the shape of the thing that breaks the training-data bottleneck — and it's in your datacenter, not locked behind an API.

Then there's the spec that explains how it gets there — and why the economics of intelligence just moved.

The argument — the data wall was always the real wall

For the last three years, everyone assumed compute was the moat. Then reasoning models scaled, and the actual constraint showed up: curated, high-quality training data degrades as you scale— the web is finite, human labeling is expensive, and the frontier keeps outrunning the quality of what's sitting in the training set. Frontier labs papered over this by paying for more annotations, more RLHF, more private distillation from other models.

Ornith's bet is the opposite: stop hand-building the curriculum, teach the model to build its own. Each training cycle is a three-stage closed loop:

1. Task proposal — the model proposes progressively harder tasks than anything it's already solved, exposing capability gaps.
2. Scaffold generation — it builds the task-specific harness: the instructions, tools, decomposition, and orchestration to actually attack the problem.
3. Solution rollout — it solves, and the reward propagates back through all three stages.

So the model isn't just getting better at answers — it's getting better at asking useful questions and building better tools to answer them. That's a genuinely different thing to optimize, and it's why the result is a moving frontier: as the policy strengthens, the tasks it generates get harder, and the whole loop keeps learning.

The reward design is the part I actually respect, because it's where a sloppy team would have shipped something self-deceiving. They use a multiplicative task reward of three signals:

• Validity — is the task well-formed and verifiable? (Hard-gated: invalid task → zero reward.)
• Frontier difficulty — is it calibrated to the model's current ability, tuned to a success rate near ~20%? Hard enough to teach, easy enough to produce learning signal.
• Novelty — is it genuinely new relative to previously generated tasks? (Deliberately secondary — they want to reduce redundancy, not reward arbitrarily weird questions.)

Same discipline on the harness reward: alignment, reward fidelity, and resistance to reward hacking. The details matter here because self-improvement is the fastest way to build an echo chamberif you get the reward wrong. They've built in explicit drift-control — the difficulty tracks the model's own rollouts, so the curriculum evolves with capability instead of going stale or going off the rails.

The other half: a 35B model that thinks like it's 3B

The self-improvement loop is the training story. The deployment story is the spec people keep underreading:

Ornith-1.5-35B has 35B parameters, but only ~3B active per token. Reportedly runs with 4–8GB VRAM + 16GB RAM with CPU offloading, ~30 tok/s with a GPU, ~15 tok/s CPU-only, and up to ~150 tok/s on 16GB+ VRAM — and performs surprisingly well on programming and agentic tasks.

One model. Two numbers that shouldn't rhyme: 35 billion parameters resident, ~3 billion active per token. That gap is why MoE (mixture-of-experts) is suddenly the most interesting architecture in local AI.

Ornith-1.5-35B is an MoE model: the full 35B of weights are loaded into memory, but for any given token only a small fraction of experts do the work — about 3B parameters' worth. You're paying the memory cost of a 35B model and the compute cost of a ~3B model. That's why it behaves like a big model on quality and like a small model on speed.

The numbers people are reporting in the wild (all community-reported, treat as directional):

• 4–8GB VRAM + 16GB RAM — runs via CPU offloading; llama.cpp pushes attention onto the GPU and handles MoE experts on the CPU (that's the --cpu-moe flag you'll see in the run command)
• ~30 tok/s with a GPU in the loop on that modest setup
• ~15 tok/s CPU-only — slow for chat, arguably fine for batch or background agent work
• ~150 tok/s on 16GB+ VRAM — the fully-offloaded sweet spot where the model physically fits on one card
• Vision is included: there's a multimodal build for image input

And here's the honest catch, from the local-LLM crowd who actually run these things: all 35B parameters still have to sit in memory, even though only ~3B activate per token. A 35B MoE needs more RAM than a 9B dense model, not less. The “4–8GB VRAM” claim is real only because it assumes you're offloading the rest of the model into 16GB of system RAM. Treat the guidance as: 8GB VRAM + 16GB RAM = runs; 16GB+ VRAM = fast.

MoE didn't make 35B fit in a phone — it made 35B usable on a mid-range gaming box. That distinction matters for anyone deciding what to buy or what to promise a client.

Why that math is the trillion-dollar problem

Here's the part that connects the training loop to the balance sheets.

The big closed providers are not just selling models. They're selling a particular arrangement: intelligence as a metered service. The capability lives behind an API, the pricing is per token, the data flows through their gateway, and the moat is three things — the training data you can't get, the compute you can't afford, and the distribution you can't replicate. The trillion-dollar valuations the closed labs trade on are built on the assumption that those three moats hold, and that the meter stays on.

The Ornith family is a sharp little counterexample to all three:

1. The data moat. If a model can generate its own curriculum — valid, appropriately-hard, novel tasks, scaffolded and rolled out by itself — then the marginal cost of capability stops scaling with human annotation labor. The moat was never really compute; it was the curated datapipeline. That's the thing self-improvement attacks directly, and it's why the method matters more than this release cycle's benchmark table.
2. The compute moat. The A3B pattern means the inferenceeconomics don't degrade with capability the way they used to. You pay the memory cost of a 35B once, and then every token after that costs like a 3B. On hardware people already own: 15–30 tok/s on a mid-range box, no rate limits, no data leaving the building. The claim “you need a datacenter to run frontier-ish” is quietly becoming “you need a gaming rig.”
3. The distribution moat. MIT license, weights downloadable, quantized for everything from a phone (the 9B) to a server. The capability isn't gated by the API, and the weights can legally sit inside a client's datacenter. When “cheaper access to intelligence” means you can own the thing that thinks, the meter-based business model starts looking fragile.

None of this says the closed labs die tomorrow — they have frontrunners, enterprise relationships, and genuinely big models. But their valuations rest on a scarcity assumption, and this is the first open release in a while that challenges all three scarce things at once. Cheaper access to intelligence isn't a pricing tweak; it's an architectural shift — and the architecture shift won't wobble when the speed claims drift.

Reader's guide — which Ornith, which build, ten-minute test

Grab the weights: everything lives on the Ornith-1.5 HuggingFace collection — MIT license, no waiting list, no “contact sales.” The community GGUF builds of the 35B are on AtomicChat's Ornith-1.5-35B-A3B page — quantized, ready for llama.cpp, with public calibration data and eval logs.

Pick your size by hardware, not by hype:

• 9B dense → the edge / phone play. This is the one that runs on a phone (there's a quantized mobile variant that still beats Gemma 4-31B and Qwen 3.6-35B — vendor-reported, but still). Best when the data can't leave the device: on-device agents, offline assistants, anything where privacy is the spec.
• 35B MoE → the local workhorse. Activates only ~3B params per token, which is why it's the sweet spot for a personal agent harness on a single consumer GPU — or on Apple Silicon via the MLX build. This is the one to start with if you run agents locally.
• 397B MoE → the frontier rig. Real capability at the top end. You're only pulling this one if you have serious hardware or a lab behind you; for everyone else it's the benchmark, not the daily driver.

Which 35B build to take (approximate sizes, rough guidance):

• 16GB+ VRAM — take the bigger Q5_K / Q4_K quant and run it fully on GPU (-ngl 99); this is the ~150 tok/s setup
• 8GB VRAM — Q4_K-class quant, let llama.cpp offload experts to CPU (-ngl 99 --cpu-moe); ~30 tok/s class
• 4–6GB VRAM — drop to the compressed IQ3_XXS / IQ2 builds; slower, but they exist precisely for this
• Apple Silicon — the MLX build, if that's your stack (same model, native format)

Pick your format by your stack. The quantized builds are named by the hardware they target, and the mismatch is the classic first stumble: GGUF runs everywhere via llama.cpp (CPU fallback included), MLX is Apple Silicon, FP8 and NVFP4are NVIDIA Tensor-Core GPUs. Grab the format that matches the machine you're actually using, not the one that sounded cool.

The ten-minute test. Pull the 35B (or the 9B if you're on a laptop) and run:

llama-server -m Ornith-1.5-35B-A3B-AD-Q5_K-Q4_K.gguf \
  -ngl 99 --cpu-moe -c 8192 -fa on --jinja \
  --temp 0.6 --top-p 0.95 --top-k 20 --port 8080

Point any OpenAI-compatible client at localhost:8080 (the server is a drop-in chat API) and throw a real task at it — a refactor with a constraint, a small script with an error you've seen before. Watch the token rate, then decide the honest question: is your use-case fine at 30 tok/s? Interactive chat: yes, comfortably. A multi-step agent loop making hundreds of calls: still yes, but the math changes. That 15–30 tok/s band is the true local trade — no rate limits, no data leaving the box, in exchange for less sheer speed than a cloud API. (You'll need a recent llama.cpp with qwen3_5_moe support; there's also an APEX-MTP build that adds speculative decoding against a bundled draft head if you want to squeeze tokens out of big-RAM machines.)

The so-what

The benchmark table will be obsolete in six weeks. That is normal and fine. What won't be obsolete is the method, because the method is the correction to the real constraint — and the architecture that carries it, because A3B is how that correction reaches ordinary hardware.

The people who figure out how to make models train themselves without human-curated datadon't just win this release cycle — they change the economics of the whole industry. If a model can generate its own valid, appropriately-hard, novel curriculum, then the marginal cost of capability stops scaling with human annotation labor. And if that capability runs on a mid-range gaming box under an MIT license, then “cheaper access to intelligence” stops being a feature of the market and becomes a property of the hardware — and the trillion-dollar valuation story, which depends on intelligence staying scarce and metered, has to be re-priced.

Close

I keep telling people the frontier isn't the models — it's what you're allowed to do with them and who they belong to. Ornith-1.5 is a small, sharp demonstration of both at once: a model that improves itself, released to everyone, small enough to run in your pocket. The old playbook said the moat was compute you couldn't buy. This says the moat is a training loop you can execute, and this one happens to be MIT.

If you're building agents, it's worth pulling the 35B and seeing what it does inside your own harness — the self-scaffolding loop is the blueprint, and the weights are now yours. Grab them from the Ornith-1.5 collection, or read the launch announcement yourself and make up your own mind.

Sources: Ornith launch tweet (@ornith_) · Ornith-1.5 tech blog · HuggingFace collection · AtomicChat GGUF card · mudler APEX-MTP build · r/LocalLLaMA thread · TestingCatalog numbers. Benchmarks and speed figures are as reported by Ornith and the community; treat all as directional.