NeoHorse marks Wang Yunhe’s first model release since founding TokenRhythm
Wang Yunhe has released his first large model since starting a new company.
According to QBitAI, TokenRhythm, founded by the former director of Huawei Noah’s Ark Lab and the lead of the Pangu large model project, has unveiled NeoHorse, its first agent-native model. The model is supported by underlying infrastructure and Infra optimization technology from Infinigence AI, while teams from Tsinghua University and Peking University participated in research on algorithms and training methods to explore how to improve data efficiency and training outcomes in agent post-training.
NeoHorse-1 comes in 4B and 9B versions. It is built around a set of capabilities needed during agent work, including tool calling, reading feedback from the environment, detecting errors, adjusting the execution path, and finishing tasks.
In 10 benchmarks covering Harness Agent, tool use, coding, and instruction following, the article says that after Agentic Post-Training, the 4B model’s overall performance reached or slightly surpassed that of a 9B base model.
Why a company focused on multi-model orchestration started training its own model
TokenRhythm has long emphasized multi-model collaboration. The article argues that once models are placed inside agent systems and asked to handle full tasks, a single benchmark score no longer explains enough.
In that setting, a model has to do more than produce a plausible answer. It must keep reading environmental feedback during execution, deal with errors, and adjust its path as conditions change. Different steps in the workflow also demand different abilities.
That led the team to a conclusion: model non-unification will remain a long-term structure in the AI industry. The more models there are, the finer the division of labor becomes, and the wider the gaps in cost and capability grow, the more a system is needed to answer practical questions. Which model should be used at this step? Which parts can be handled by a cheaper model? When should the system escalate to a stronger reasoning and execution model? If one execution path is blocked, which model should take over? Can multiple models work in parallel and then have their outputs aggregated?
Wang’s team calls that layer Routing Harness. Its related open-source project, OpenSquilla, has already connected multiple models through a unified interface for fine-grained routing, model switching, and multi-model collaboration during agent execution.
Under that logic, TokenRhythm would not appear to have a strong reason to train its own model. The market already offers a large supply of models, and calling them on demand looks more flexible.
Still, as the orchestration system keeps running, another kind of asset starts to accumulate: what tasks require what capabilities, where a model tends to fail, which repair paths work, and what kinds of outputs can pass environmental verification. Those signals can improve routing decisions, but they also begin to carry training value.
The article compares this to a platform that connects large numbers of brands and consumers. Data gathered during transactions, including demand, reviews, and usage feedback, can help products reach more suitable users and also feed back into product development. In that sense, operating the platform becomes a source of data for the next round of product improvement.
NeoHorse is meant to turn part of the execution experience TokenRhythm accumulated in its Harness system into model capability.
Training an agent-native model on paths taken by multiple models
NeoHorse’s data source is one of the central points in the report. Its core corpus combines agent execution signals produced by Routing Harness with public data to build a post-training data system for agents.
Each time an agent completes a task inside Harness, it leaves a full execution record: task input, the router’s judgment about required capabilities, model selection, reasoning and tool use by the model, environmental results, continued execution or failure, system-driven model switching or path adjustment, and the final outcome of success or failure.
Typical question-answer datasets focus on the two ends of the exchange, the question and the answer. Routing Harness data contains additional layers: what capability the task required, what execution decision the system made, and what feedback the environment returned.
For example, the router may initially judge that a task only needs an ordinary model. After repeated failures, the system upgrades the task to a stronger model and the task is finally completed. That trajectory contains much more information than a single failed attempt. The system can see that the first capability judgment may have been too low, identify where the model failed, examine the strategy used by the stronger model, note which path passed environmental validation, and record the extra token cost and time spent to finish the task.
More important, TokenRhythm is not looking at how one model judges itself. It is observing side-by-side behavior from multiple models on similar tasks. Those records include successful paths as well as runs that failed midstream and were later taken over by other models.
From a training perspective, failed trajectories may even be more informative. A final answer can show one workable path. Failure and repair add two other kinds of knowledge: where errors are likely to happen, and how to adjust after they appear.
The article says NeoHorse learns not only from results produced by multiple models, but also from the actual paths those models took inside task environments. That is presented as one of the model’s distinguishing features.
How agent logs are filtered and converted into model ability
Feeding all logs directly into training would not naturally produce a stronger agent model. Agent trajectories are usually long and contain system prompts, user requests, tool parameters, execution results, repeated attempts, error messages, and large amounts of intermediate output. Some steps are useful for training. Some are closer to noise. Some trajectories are complete in form but wrong in result.
The first issue TokenRhythm needs to solve is which data the model should learn from. According to the technical report, each trajectory goes through structural checks to confirm that requests, model responses, tool calls, and environmental outcomes line up correctly.
The system then evaluates execution quality across six dimensions: whether the user’s goal was completed, whether instructions were followed, whether tool use was appropriate, whether conclusions were supported by evidence, whether the model could recover from errors, and whether it stopped the task at the right time.
The article also separates several signals that are often conflated in agent training. A task ending does not mean the user’s goal has been met. If a model outputs that the task is complete, that only shows the execution process stopped. It does not prove the deliverable satisfies the user. Completion status, goal satisfaction, environmental evidence, and user feedback therefore need to be recorded as different signals.
Once the data is filtered, routing signals take on a second role. The router estimates the level of capability each task requires and creates signals for different capability bands. NeoHorse uses those signals to arrange sample order during training, learning lower-capability tasks first and then gradually moving to more complex trajectories while keeping coverage of basic tasks.
This method is called Routing-Guided Curriculum. In plain terms, the same routing signal that decides online which model should handle a task can also tell the training pipeline which tasks should be learned earlier and which should come later.
NeoHorse also uses On-Policy Distillation in addition to standard supervised fine-tuning. The article describes it as letting the student solve problems in its own way first, then having the teacher guide the student based on the steps the student actually took. That means the teacher model is dealing with problems the student model really encounters under its current distribution, rather than a fixed set of prewritten errors.
Through those steps, the experience accumulated over long periods of multi-model task execution is fed into NeoHorse’s post-training process.
What improved after post-training
Based on the current technical report, Agentic Post-Training brought stable gains at both 4B and 9B scales.
For NeoHorse-1-4B, the macro-average score rose from 58.94 to 64.87, reaching state-of-the-art performance at its scale. The article says it outperformed its base model, Qwen3.5-4B, on all comparable benchmarks and ranked first overall among comparable 4B models.
That does not mean the gains are spread evenly across every kind of task. A closer breakdown shows that the 4B model’s improvement is concentrated in tasks with relatively clear workflows, observable environmental feedback, verifiable success or failure, and explicit delivery standards.
The article gives a project scheduling example. The base model found files in the working directory but failed to read an email containing updated dependency constraints. As a result, it generated a plan based on outdated information and wrote the file to the wrong location. The post-trained model kept reading new evidence, detected that the constraints had changed, recalculated the schedule, verified the result, and saved the deliverable to the correct place.
The difference appears in the agent execution chain. One model roughly knows what the task should look like. The other can connect evidence gathering, constraint updates, execution, verification, and delivery into a more complete workflow.
Even with state-of-the-art results at its scale, TokenRhythm is not positioning NeoHorse-1-4B as a model that should take over all tasks. The company is more focused on how to draw capability boundaries between different models with greater precision.
Tasks that a 4B model can finish reliably can reduce calls to larger models. Tasks that stronger models can handle do not always need to be pushed to the most expensive flagship models. As difficulty rises further, they can be passed to stronger models in the broader pool.
That is where the relationship between Routing Harness and in-house models comes into view. Models push outward the cost range of tasks they can handle, while the routing system places different capabilities where they fit best based on task difficulty and execution conditions.
How NeoHorse fits with OpenSquilla, TokenRhythm API, and enterprise services
The article also lays out how TokenRhythm’s product lines connect.
The first layer is the open-source version of OpenSquilla. Through free access, open-source code, local deployment, and desktop products, TokenRhythm lowers the barrier for developers to use multi-model agents while connecting developers to task entry points.
The second layer is TokenRhythm API, which the article describes as positioned close to a Chinese version of OpenRouter. Through a unified interface, it offers access to different models, serves model usage needs from developers and enterprises, and helps model vendors reach more application scenarios. Enterprises do not need to adapt to large numbers of model interfaces one by one, making evaluation, selection, and switching easier.
The third layer is enterprise-oriented service and deployment capability. Sectors such as finance and manufacturing have different requirements for permissions, stability, private deployment, and service guarantees, creating additional commercial room.
The fourth layer is NeoHorse. The model is presented as a test of a key connection: useful experience generated during Harness execution can, after filtering and training, be converted into the model’s own capability.
In the article’s framing, that gives the company’s previously proposed commercial flywheel a result at the model layer for the first time, and opens up the possibility of improving inference economics.
If NeoHorse can reliably take on a group of high-frequency agent tasks with relatively clear standards, the platform gains an additional supply of capability it can schedule itself. Those tasks could improve inference cost, response speed, and stability, while making the model supply mix more flexible. As the model continues to iterate, the range of tasks it can cover may expand further.
From that angle, TokenRhythm is trying to build something similar to process accumulation in manufacturing. External model ecosystems provide different capabilities. Harness organizes execution. Experience generated during execution then feeds into the next round of model improvement.
From API aggregation to model capability accumulation
The business loop described in the article runs like this: Routing Harness connects developers and agent tasks; TokenRhythm API connects model supply and model demand; Harness organizes execution and accumulates routing signals and task trajectories; usable trajectories are filtered and used for model training; updated models return to Harness and take part in task matching; task experience improves while better response speed and cost efficiency are explored; continued use, paid usage, and operational efficiency improve; and those gains support the next round of service refinement and research spending.
One key change is that model-generated trajectories no longer stop at the consumption and calling layer. They can become the source of the next round of model training.
Each completed task gives Harness one more observation about capability boundaries. When one model fails, the system gets a clue about where a capability gap may sit. When another model successfully takes over, the system gains a new repair path. When users accept or reject the result, that adds another layer of external feedback.
The more tasks accumulate, the more accurate routing judgments may become. As routing becomes more accurate, the training trajectories selected by the system may better reflect real tasks. As models become better suited to tasks, the API service has a chance to deliver better cost and user experience.
If that loop can hold over time, the difference between TokenRhythm and a standard API aggregation platform may gradually move beyond routing rules and model lists into training task design, training methods, and model parameters, and then show up in product performance.
How close is this to RSI?
This is the background for TokenRhythm’s discussion of RSI, or Recursive Self-Improvement.
At this stage, the company’s RSI validation is described as closer to an engineering loop and can be split into two parts.
The first is Data-RSI. As models keep executing tasks inside Harness, each routing choice, tool call, failed recovery, and final result produces new structured records. After filtering and processing, those records can enter the later training pool. That means training data does not have to depend entirely on manually prepared datasets and can grow as the system continues to be used.
The second is Model-RSI. The system identifies the current model’s capability weaknesses through evaluation results, adjusts the distribution of data used in the next round of training, updates the model, and then puts the new model back into Harness for execution. In other words, the model learns from execution experience, and the updated model then generates new feedback for the next round of training through fresh task runs.
Even so, based on what has been made public about NeoHorse so far, the article says the setup should not yet be treated as a full RSI system. The technical report verifies one loop of execution, evaluation, selection, and update. Signal design, reward design, and training processes are still set by humans, and it remains unclear whether multiple generations of model iteration can continue to produce stable gains.
The article therefore describes the release as validating two layers. One is commercial: data accumulated by the system can enter model training and be turned into measurable capability gains. The other is technical: Wang Yunhe’s startup team has completed a single-round engineering validation aimed in the direction of RSI.
Questions that still need time
The article also lists several hurdles TokenRhythm still needs to clear.
- First, whether the open-source ecosystem can keep turning into API usage and revenue.
- Second, whether the system can continue to obtain enough high-quality agent trajectories suitable for training as task types increase.
- Third, whether improved model ability can reliably turn into better task experience and execution efficiency, and then show up in operating metrics.
- Fourth, how long capability gains can continue after multiple rounds of model iteration.
Those questions require more time to answer.
There is also a competitive variable that cannot be ignored. DeepSeek, Qwen, and MiniMax are also extending toward Harness and agent products, and the trend toward vertical integration between models and agent infrastructure is becoming more visible.
For TokenRhythm, one current differentiator is model neutrality and the cross-model comparison data formed during multi-model execution. But if performance gaps between models become large enough, cross-model orchestration may stand as an independent business. If leading models gradually cover more tasks, or if vendors package routing, tool calling, and agent frameworks together themselves, the room left for the middle layer will shrink.
As upstream capability becomes stronger and cheaper, why should the middle layer continue to exist? For TokenRhythm, NeoHorse at least adds another angle to that question. The company had previously tried to prove it could use models well. It is now trying to show that data accumulated from long-term model usage can also settle into model capability of its own.
The article closes on a simple split. If that path works, TokenRhythm’s moat will not rest only on routing strategy. If it does not, the company will still face the same structural questions confronting every middle layer in the model stack.
GitHub: https://github.com/TokenRhythm/NeoHorse
Hugging Face: https://huggingface.co/collections/TokenRhythm/neohorse-1
This article was originally published by the WeChat official account QBitAI and written by Heng Yu.