NeoHorse-1 is a family of agent-native models that actually implements the loop in which an AI observes its own capabilities and turns those observations into the raw material for its next round of learning. The core idea is to attach "intelligent routing" to a pool of several models, recording—on every user turn—which capabilities are required, which tier of model got picked, and how the ensuing interaction unfolded, then feeding that record back as training data. According to the abstract, post-training lifted the macro-average across the benchmark suite from 58.94 to 64.87 at 4B, and from 65.60 to 69.04 at 9B.
"Recursive Self-Improvement" (RSI)—the idea that an AI repeatedly makes itself better—is an old and somewhat distant goal. The trouble is that the phrase usually stays a slogan. "It gets better on its own" sounds plausible, but without a concrete machinery for exactly what gets observed and through what path that observation flows into the next round of training, there's nothing there.
Here's an analogy. Someone who goes to the gym and merely resolves "I'll get stronger every week" is doing something entirely different from someone who records the weight, reps, and next-day soreness for every set and designs next week's program from that data. A lot of prior discussion of self-improvement leaned toward the former—the resolution. What NeoHorse-1 is after is the latter: building a real loop that "measures, then rewrites the next training plan."
The word "harness" comes up a lot here. The harness is not the model itself but the execution shell that wraps and drives the model—the operational apparatus for tool calls, routing, context management, and so on. In the paper's own phrasing, what this work aims at is "harness-mediated RSI." That is, the improvement loop flows not from magic inside the model but from the records left behind by the shell that operates it.
The whole picture starts from "a heterogeneous model pool plus intelligent routing."
Gather models of varying capability and size into one place (the heterogeneous model pool), and for each incoming request, a router makes a judgment. Picture a company with juniors, mid-level staff, and specialists all mixed together, where an intake clerk looks at the difficulty of a task and decides whom to assign it to. At this point the router leaves behind three things.
This record becomes the raw material for the next round of learning. But the conversation isn't used for training as-is. When the record is converted into training examples, the interleaved state of the intermediate reasoning, tool calls, and harness context is preserved intact. The way an agent actually works is interleaved—"think → call a tool → report the result, think → call another tool"—and the intent is that preserving this grain is what lets the model learn to behave like an agent.
Raw material isn't accepted wholesale either. It has to pass three layers of inspection.
It's like a quality manager inspecting raw material by form, by content, and by individual detail, and sending only passing items down the line.
Training proceeds on the data filtered this way, and here too the routing signal holds the baton.
And the final piece that closes the loop is "capability-guided allocation." It converts evaluation feedback into the next training mixture. In other words, when evaluation reveals which capability is currently weak, more of that is folded into the next blend of training data. The paper calls this the "evaluation-selection-update loop." It's a feedback structure in which what the system has learned to do determines what it learns from next. Back to the gym analogy: it's as if a coach who looks at last week's log and adds more work for the weak muscle groups into next week's program has been built into the model.
The figures the abstract presents are as follows. Across a suite of benchmarks spanning harness-based agents, tool use, coding, and instruction following, post-training raised the macro-average like so.
| Model size | Before post-training | After post-training |
|---|---|---|
| 4B | 58.94 | 64.87 |
| 9B | 65.60 | 69.04 |
A point worth noting is one the abstract specifically calls out: the aggregate gap between the post-trained 4B model and the 9B base model before NeoHorse's post-training was applied was substantially narrowed. Put simply, if you run a small model well and feed its records back into training, it comes fairly close—on a total-score basis—to an already-trained base model more than twice its size. It's a signal that beyond simply scaling up parameters, there's real room in the path of turning operational records back into learning.
That said, the figures explicitly stated in the abstract are the table above and the benchmark coverage itself, and that's all. Concrete numbers like individual benchmark scores, dataset size, routing accuracy, or trends by iteration count aren't in the abstract, so we won't assert them here.
The paper itself describes this not as a finished RSI but as an "initial prototype" and a "path toward harness-mediated RSI." That restrained self-definition itself hints at the limitations.
ONTLE's structure dispatches an AI PM to each client project to manage everything from request intake to service delivery. The reason this paper is welcome is that its skeleton overlaps with what we already do, or aim to do.
First, model routing. ONTLE's company-wide standard routing assigns chat and intake to a top-tier model, the execution stage by difficulty (s/m/l), and revisions and deployment to a lightweight model. This is exactly the same idea as NeoHorse-1's "predicted capability demand → tier selection." The takeaway from this paper goes one step further: treat the judgments the router makes and their outcomes not as mere logs but as training material. ONTLE's routing logs and work histories are operational records today, but they could become an asset for feeding back "what goes well and what gets stuck" down the road.
Second, preserving interleaved context. NeoHorse-1 keeps the grain of interleaved reasoning, tool calls, and harness context intact for training. An AI PM's work is likewise interleaved—"client request → analysis → tool execution → mid-stream judgment → re-execution." Only by keeping this flow in its original structure rather than as a summary can any later improvement actually reflect the grain of the real work.
Third, the evaluation-selection-update loop is an ideal form of the product-improvement cycle. But as the paper cautions itself, feedback can also amplify bias. The lesson from ONTLE's vantage point is clear: even if you introduce an automated improvement loop, you must keep the quality gate (structural validation, semantic evaluation) open to human audit, and you must consciously guard, at the allocation stage, against the trap of "making what's already good even better." For teams running RAG or agent pipelines, it means you have to watch not only your performance metrics but also "what you're leaving out of training."
No. The paper frames NeoHorse-1 not as a finished RSI but as an "initial prototype" and a path toward harness-mediated RSI. It's a stage that has actually implemented one cycle of the iterative loop, and whether improvement accumulates over many repetitions is an open question.
Per the abstract, the macro-average across the benchmark suite rose from 58.94 to 64.87 at 4B and from 65.60 to 69.04 at 9B. The abstract also states that the aggregate gap between the post-trained 4B model and the 9B base model before NeoHorse's post-training was substantially narrowed. Detailed figures such as individual benchmark scores aren't in the abstract, so we don't cover them here.
The harness is not the model itself but the execution shell that wraps and operates the model (routing, tool calls, context management). It means the design makes the improvement loop flow not from a capability inside the model but from the records that shell leaves behind as it drives the model (capability demand, tier selection, interaction).
The idea is worth drawing on right away. The direction is to treat routing judgments and outcomes not merely as logs but as material for learning and improvement, preserve interleaved work context in its original form, and feed evaluation results back into the next improvement priorities. That said, the risks of feedback-loop bias and evaluation reliability come along with it, so a design that keeps the quality gate open to audit is a prerequisite.