Wang Yunhe's startup launches NeoHorse, the first agent-native model.

After starting his venture, Wang Yunhe has delivered his first major model achievement.

Quantum Bit reports that the former director of Huawei's Noah's Ark Lab, Pangu Large Model Founded by Wang Yunhe, Ji Yuan Lü Dong has launched its first Agent-Native model, NeoHorse.

The model is supported by underlying infrastructure and Infra optimization technologies provided by Wuwen Xinqiong, with research on algorithms and training methods contributed by teams from Tsinghua University and Peking University, jointly exploring ways to enhance data utilization efficiency and training effectiveness in post-training of agents.

NeoHorse-1 comes in two versions, 4B and 9B, and is specifically designed to support a set of capabilities required during Agent workflows, including tool invocation, reading environmental feedback, detecting errors, adjusting paths, and ultimately completing tasks.

After Agentic Post-Training, the 4B model achieves performance on par with or slightly exceeding the 9B base model across 10 evaluation metrics, including Harness Agent, tool usage, code generation, and instruction following.

A company that has always emphasized multi-model collaboration—why is it now beginning to train its own models? Is Primordial Rhythm preparing to join the foundational model table?

According to NeoHorse's answer, the direction has not changed in this way.

This model more closely reflects the accumulated multi-model execution experience of Primordial Rhythm, entering model parameters for the first time.

Traditionally, scores have often been the primary basis for comparing models.

However, when models are integrated into agent systems and tasked with completing full workflows, the explanatory power of a single score diminishes.

In a task, the model must not only provide a seemingly reasonable answer but also continuously read environmental feedback, handle errors, and adjust subsequent paths based on actual progress; different stages have varying requirements for the model’s capabilities.

As a result, the Primitive Rhythm team formed a judgment.

The lack of model normalization will remain a structural feature of the AI industry for the long term.

The more models there are and the more specialized their roles, the more pronounced the differences in price and capability become, making it essential to have a system that answers several key questions—

Which model should be used for this step? Which stages can be delegated to lower-cost models? When should you upgrade to a model with stronger reasoning and execution capabilities? If one execution path is blocked, who should take over? Can multiple models generate solutions in parallel, with their results aggregated afterward?

Wang Yunhe's team refers to this layer as the Routing Harness (the associated open-source project, OpenSquilla, has integrated multiple models and enables fine-grained routing, model switching, and multi-model collaboration during Agent execution through a unified interface).

Similarly, based on this reasoning, there seems to be little reason for Primal Rhythm to train its own models. The market already offers a sufficiently rich selection of models, making on-demand usage appear more flexible.

As the scheduling system continues to operate, another category of assets begins to accumulate, such as “what tasks require which capabilities,” “at which step models are prone to failure,” “which repair pathways are effective,” and “what results can pass environmental validation.”

This information not only enhances routing decisions but also begins to offer training value.

It’s somewhat like a platform connecting numerous brands with consumers. The demand, reviews, and usage feedback accumulated during transactions can help products reach more suitable users and provide further insights to product development.

The process of the platform's service marketplace becomes a data source for the next round of product improvements.

NeoHorse is responsible for transforming a portion of the execution expertise accumulated in Harness into model capabilities.

The data sources for NeoHorse are worth noting.

Its core corpus combines Agent execution signals generated by the Routing Harness with public data to build a data system tailored for post-training of Agents.

When an agent completes a task in Harness, it leaves a complete execution record.

1. Input task → Router determines required capabilities
2. → Select a model
3. The model performs reasoning and tool calls.
4. → Environment returned result
5. → Model continues execution or encounters an error
6. → System switches models or adjusts paths
7. → Task completed or failed

Frequently asked question data often focuses on the "question" and "answer" ends.

The Routing Harness data also includes additional layers of information: what capabilities the task requires, what execution decisions the system made, and what feedback the environment ultimately provided.

For example, the router initially determines that a task requires only a basic model, but after consecutive failures during execution, it upgrades to a more capable model, successfully completing the task.

This trajectory contains far more information than just a failure.

The system can determine whether the initial capability assessment was too low, at which step the model encountered issues, what strategies the stronger model employed, which execution path ultimately passed environmental validation, and how many additional tokens and time were consumed to complete the task.

More importantly, the primitive rhythm observes not a single model's assessment of its own capabilities, but the横向 performance across multiple models when faced with similar tasks.

It includes both successful paths and execution records that failed midway and were subsequently taken over by other models.

From a training perspective, failure trajectories may even provide more information.

The final answer shows the model a viable path, while the failure and repair processes add two additional types of knowledge: where errors are likely to occur and how to adjust after they happen.

Another distinctive feature of NeoHorse is that it learns not only the outcomes provided by multiple models, but also the actual paths taken by these models within the task environment.

Throwing all logs into training will not naturally result in a stronger agent model.

Agent trajectories are typically long and contain system prompts, user requests, tool parameters, execution results, repeated attempts, error messages, and a large amount of intermediate output.

Some steps have training value, while others are closer to noise. Some trajectory sequences are complete, yet the results themselves are incorrect.

Primitive rhythm first needs to address the question of "which data are worth learning for the model."

According to the technical report, each trajectory undergoes structural validation to ensure alignment between the request, model response, tool calls, and environmental outcomes.

The system will then evaluate execution quality across six dimensions: whether the user’s goal was achieved, whether instructions were followed, whether tools were used appropriately, whether conclusions are supported by evidence, whether the system can recover from errors, and whether the model terminates the task at the appropriate time.

This also involves issues that are often confused in Agent training.

Task completion does not mean the user's goal has been satisfied—the model outputting "task completed" only indicates that the execution process has stopped, not that the deliverables meet the user's requirements.

Therefore, completion status, goal satisfaction, environmental evidence, and user feedback must be recorded as separate signals.

After the data has been filtered, the routing signal begins to serve another function.

The router estimates the capabilities required for each task and generates signals corresponding to different capability levels. NeoHorse uses these signals during training to sequence samples, starting with tasks requiring lower capabilities and gradually progressing to more complex execution trajectories, while maintaining coverage of foundational tasks.

This method is called Routing-Guided Curriculum, or routing-guided curriculum learning.

In simple terms, the routing signal decides online which task to assign to which component, and during training, it can also guide the model on which tasks are better to learn first and which to learn later.

In addition to conventional supervised fine-tuning, NeoHorse also employs on-policy distillation.

It can be understood as first allowing students to solve problems in their own way, and then having the teacher provide guidance based on the actual steps the students have taken.

This way, the teacher model addresses issues that the student model is likely to encounter under its current distribution, rather than a pre-defined set of standard errors.

After these steps, the experience accumulated from long-term execution of multi-model tasks begins to be used for NeoHorse's post-training.

Based on the results from the current technical report, Agentic Post-Training delivers consistent improvements across both the 4B and 9B scales.

Among them, NeoHorse-1-4B's overall performance (macro average score improved from 58.94 to 64.87) has reached the state-of-the-art for models of its size, outperforming its base model Qwen3.5-4B on all comparable benchmarks and leading comprehensively among all 4B-scale comparative models.

But SOTA does not mean that capabilities are evenly distributed.

Further breakdown of the results shows that the improvements in the 4B model are primarily concentrated in one category of tasks.

These tasks typically have a relatively clear workflow, observable environmental feedback, verifiable success and failure outcomes, and well-defined delivery criteria.

For example, in a project scheduling task, the base model located the files in the working directory but did not proceed to read an email containing the latest dependency constraints.

As a result, it generated a plan based on expired information and saved the file to the wrong location.

The post-trained model continues to ingest new evidence, detects changes in constraints, recalculates schedules and validates results, then saves the deliverables to the correct location.

The difference lies in the agent execution chain.

One model has a general understanding of how to perform the task, while the other model can already string together a more complete workflow involving evidence gathering, constraint updating, execution, verification, and delivery.

Achieving SOTA performance at the same scale does not mean that NeoHorse-1-4B should take over all tasks. Primordial Rhythm is more concerned with precisely defining the capability boundaries of different models.

Tasks that can be reliably completed by a 4B model should reduce the need to invoke larger models; tasks that require a stronger model do not need to continuously escalate to the most expensive flagship model; as difficulty increases further, tasks are passed on to stronger models within the model pool.

This perfectly connects the relationship between the Routing Harness and our proprietary model.

The model continuously expands the cost range of tasks it can handle, while the routing system assigns different capabilities to appropriate positions based on task difficulty and execution performance.

At this point, the relationship between the various product lines of Primordial Rhythm becomes increasingly clear.

The first layer is the OpenSquilla open-source version.

Primal Rhythm lowers the barrier for developers to use multi-model agents through free, open-source, on-premises, and desktop products, while connecting developers with task entry points.

The second layer is the TokenRhythm API.

Its positioning is similar to "China's OpenRouter," providing unified interface access to various models to meet the model usage needs of developers and enterprises, while helping model providers connect to more application scenarios.

Enterprises can more easily evaluate, select, and switch models without having to separately adapt to numerous model interfaces.

The third layer consists of enterprise-oriented services and deployment capabilities.

Industries such as finance and manufacturing have different requirements for permissions, stability, private deployment, and service guarantees, creating further business opportunities as a result.

The fourth layer is NeoHorse.

NeoHorse first verified a key connection: effective experiences generated during the Harness execution, after being filtered and trained, can indeed be transformed into the model's own capabilities.

As a result, the business flywheel previously proposed by Primordial Rhythm has produced results at the model level for the first time.

This also opens up the possibility of optimizing the economics of inference.

If NeoHorse can subsequently reliably handle a batch of high-frequency, clearly defined Agent tasks, the platform will gain an additional capacity for autonomous orchestration.

These tasks can further optimize reasoning costs, response speed, and stability, while also enabling more flexible model provisioning configurations. As the models continue to evolve, the range of tasks they can cover has potential for further expansion.

From this perspective, what Primitive Rhythm aims to do is somewhat like the process accumulation in manufacturing systems.

The external model ecosystem provides diverse capabilities, while Harness coordinates and executes them; the insights gained during execution feed into the next round of model improvements.

From connecting models and delivering services to transforming the insights gained from those services into enhanced model capabilities, thereby further improving efficiency and quality, this represents another step forward for Primordial Rhythm beyond its API aggregation platform.

The cycles envisioned in the Primitive Rhythm concept can generally be connected by several business lines:

1. The Routing Harness connects developers with Agent tasks.
2. → TokenRhythm API connects supply with demand for model invocation
3. → Executed by the Harness organization, accumulating routing and task trajectories
4. Available trajectories have been filtered for model training.
5. → The updated model returns Harness to participate in the adaptation task.
6. → Enhance task experience by exploring better response speeds and cost efficiency
7. → Continued usage, payment, and improved operational efficiency
8. → Support the next round of service improvements and R&D investment

One key change is that the trajectories generated by the model are no longer limited to consumption and invocation phases—they may also become a source for the next round of model training.

Each time the agent completes a task, Harness gains another observation about the boundaries of its capabilities.

One model fails, and the system knows where the capability gap may lie; another model successfully takes over, and the system gains a new repair pathway; the user ultimately accepts or rejects the result, providing an additional layer of external feedback.

The more tasks accumulated, the more accurate the routing decisions become; as routing becomes more accurate, the training trajectories selected will better reflect actual tasks; and as the model becomes better suited to the tasks, the API service can achieve improved cost efficiency and user experience.

If this cycle can be sustained long-term, the differences between primitive oscillations and conventional API aggregation platforms will gradually extend from routing rules and model lists to training task design, training methods, and model parameters.

Finally, it is reflected in the product's performance.

The above is the context in which Elemental Rhythm began discussing RSI (Recursive Self-Improvement).

The current validation of RSI by Elemental Rhythm more closely resembles a closed engineering loop, which can be divided into two parts.

The first one is Data-RSI.

The model continuously executes tasks within Harness, generating new structured records for each routing step, tool call, failure recovery, and final result.

After being filtered and processed, these records can be added to the training data pool. As a result, the training data does not need to rely entirely on manual preparation and can grow continuously as the system is used.

The second is Model-RSI.

The system identifies the current model's performance gaps based on evaluation results, adjusts the distribution of training data for the next round, updates the model, and deploys the new model back into the Harness for execution.

In other words, the model learns from its execution experience, and the updated model performs new tasks to generate fresh feedback for the next training round.

However, based on the current publicly available information about NeoHorse, this system cannot yet be considered a complete RSI.

The current technical report validates a single "execute-evaluate-select-update" loop. Signal design, reward design, and training procedures are still set by humans, and further experiments are needed to confirm whether sustained gains can be maintained after multiple generations of model iteration.

Therefore, a more accurate statement is that NeoHorse's latest release completed two layers of verification.

The first layer is commercial: data accumulated by the system can be used for model training and translated into measurable improvements in capability.

Another layer is technical: Wang Yunhe led a startup team to complete a single-round engineering validation focused on the RSI direction.

Of course, for the story of primal rhythm to hold true, several hurdles must be overcome.

First, can the open-source ecosystem continue to translate into API usage and revenue?

Second, as the number of task types increases, can the system continue to obtain sufficient high-quality agent trajectories for training?

Third, after improving the model's capabilities, can these enhancements consistently translate into better task experiences and execution efficiency, and further reflect in business metrics?

Fourth, how long will the performance gains last after multiple rounds of model iteration?

These issues require further observation over a longer period.

And there is another unavoidable variable— DeepSeek Qwen MiniMax Model providers are also expanding into Harness and Agent products, and the trend toward vertical integration of models and Agent infrastructure is becoming increasingly evident.

Taking Primitive Rhythm as an example, one of the company’s current differentiators is model neutrality and the cross-model comparative data generated during execution.

However, if the capability differences between models are significant enough, cross-model scheduling could become a standalone business; if leading models gradually take on more tasks, or if vendors bundle routing, tool invocation, and agent frameworks together, the space available for intermediate layers will be compressed.

When upstream capabilities become stronger and cheaper, why does this middle layer still need to exist?

For primitive rhythm, NeoHorse adds at least one new perspective to this issue.

In the past, it proved it could "use models"; now it is beginning to demonstrate that data accumulated through long-term model usage can also evolve into its own model capabilities.

If this path succeeds, Element Rhythm’s moat will extend beyond routing strategies; if it fails, it will still face the same challenges encountered by all model intermediate layers.

GitHub: https://github.com/TokenRhythm/NeoHorse

Hugging Face: https://huggingface.co/collections/TokenRhythm/neohorse-1

This article is from the WeChat public account "Quantum Bit," authored by Hengyu.