After starting his business, Wang Yunhe has delivered his first major model.
According to Qbitai, Wang Yunhe, former head of Huawei's Noah's Ark Lab and lead of the Pangu Model, has founded Basic Rhythm (基元律动), which released its first Agent-Native model, NeoHorse.
This model is powered by the underlying infrastructure support and Infra optimization capabilities provided by Inifinichip (无问芯穹). Teams from Tsinghua University and Peking University participated in algorithm and training method research, jointly exploring ways to improve data utilization efficiency and training effectiveness for Agent post-training.
NeoHorse-1 includes two versions: 4B and 9B. It focuses on a set of capabilities required during the Agent's workflow, including tool invocation, reading environmental feedback, error detection, path adjustment, and ultimately task completion.
In evaluations covering 10 areas including Harness Agent, tool usage, coding, and instruction following, after Agentic Post-Training, the comprehensive performance of the 4B model has reached/slightly exceeded that of the 9B base model.
A company that has always emphasized multi-model collaboration—why is it now training its own model? Is Basic Rhythm preparing to join the foundational model arena?
Judging by the answer NeoHorse provides, the direction hasn't shifted in that way.
This model seems more like Basic Rhythm's accumulated experience with multi-model execution, now being encoded into the model parameters for the first time.
A Company That Helped Agents Choose Models, Now Also Trains Models
For a long time, benchmark scores have often been the primary basis for comparing models.
But when models are integrated into Agent systems to handle complete tasks, the explanatory power of a single score diminishes.
In a single task, a 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 also require different model capabilities.
From this, the Basic Rhythm team formed a judgment.
Model heterogeneity (non-convergence) will be a long-term structural feature of the AI industry.
The more models there are, the more specialized their roles, and the more pronounced the differences in price and capability, the more a system is needed to answer several questions—
Which model should be used for this step? Which stages can be assigned to lower-cost models? When is it necessary to upgrade to a model with stronger reasoning and execution capabilities? When an execution path is blocked, who should take over? Can multiple models propose solutions in parallel, then aggregate the results?
Wang Yunhe's team calls this layer of system the Routing Harness (their related open-source project, OpenSquilla, has already integrated multiple models, enabling fine-grained routing, model switching, and multi-model collaboration during Agent operation through a unified interface).
Similarly, based on this logic, Basic Rhythm seemed to have little strong reason to train its own model. The market already offers a sufficiently rich supply of models, making on-demand calling appear more flexible.
As the scheduling system runs continuously, another type of asset begins to accumulate, such as "what tasks require what capabilities," "where models are prone to fail," "what kind of repair paths are effective," and "what results can pass environmental verification."
This information can, on one hand, improve routing decisions, and on the other hand, begins to possess training value.
This is somewhat like a platform connecting numerous brands and consumers. The demand, reviews, and usage feedback accumulated during transactions can help products find more suitable users and also be fed back to product R&D.
The process of the platform serving the market thus becomes a data source for the next round of product improvement.
NeoHorse's role is to convert part of the execution experience Basic Rhythm accumulated in the Harness into model capability.
Encoding the Paths Taken by Multiple Models into an Agent-Native Model
NeoHorse's data sources are noteworthy.
Its core corpus combines the Agent execution signals generated by the Routing Harness with public data to construct a data system oriented towards Agent post-training.
When an Agent completes a task within the Harness, it leaves a complete execution record.
- Input task → Router judges required capabilities
- → Selects a model
- → Model performs reasoning and tool calls
- → Environment returns result
- → Model continues execution or encounters an error
- → System switches model or adjusts path
- → Task is eventually completed or fails
Common Q&A data often focuses on the two ends: "question" and "answer."
Routing Harness data contains several 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 judged that a task only required a regular model, but it failed continuously during execution, prompting an upgrade to a more capable model which then completed the task.
This trajectory contains far more information than a single failure.
The system can learn that the initial capability estimate might have been too low, where the model ran into problems, what strategy the stronger model adopted, which execution path ultimately passed environmental verification, and how many extra tokens/time were consumed to complete the task.
More importantly, what Basic Rhythm observed is not a single model's judgment of its own capabilities, but the horizontal performance left by multiple models facing similar tasks.
This includes both successful paths and execution records where a model failed midway and was subsequently taken over by another model.
From a training perspective, failure trajectories might even provide more information.
A final answer can show the model a feasible path, while failure and repair processes supplement two other types of knowledge: where things are prone to go wrong, and how to adjust after an error occurs.
"Learning not only the results given by multiple models but also the actual paths multiple models have taken in the task environment" is also a distinctive aspect of NeoHorse.
How Are Agent Work Logs Transformed into Model Capability?
Dumping all logs into training doesn't automatically yield a stronger Agent model.
Agent trajectories are typically long, containing a mix of system prompts, user requests, tool parameters, execution results, repeated attempts, error messages, and numerous intermediate outputs.
Some steps have training value, others are closer to noise. Some trajectories are complete in process, but the results themselves are incorrect.
Basic Rhythm first needs to address the question: 'Which data is worth the model learning?'
According to the technical report, each trajectory undergoes structural checks to ensure correspondence between the request, model response, tool calls, and environmental results.
Subsequently, the system evaluates execution quality from six dimensions: whether user goals were completed, instructions were followed, tool usage was reasonable, conclusions were evidence-supported, recovery occurred after errors, and whether the model terminated the task at an appropriate time.
Here, issues easily conflated in Agent training are also involved.
Task termination does not equal user goal fulfillment—a model outputting "task completed" only indicates the execution flow has stopped, not that the deliverable meets user requirements.
Therefore, completion status, goal fulfillment, environmental evidence, and user feedback need to be recorded as separate signals.
After data screening, routing signals begin to play another role.
The router estimates the capabilities required for a task, generating signals for different capability tiers. NeoHorse uses this during training to arrange sample order, first learning tasks requiring lower capabilities, then gradually adding more complex execution trajectories, while retaining coverage of basic tasks.
This method is called Routing-Guided Curriculum.
Put simply, routing signals determine online task assignment; during the training phase, they can also tell the model which tasks are better learned first and which later.
Besides conventional supervised fine-tuning, NeoHorse also employed On-Policy Distillation.
Think of it as letting the student first solve the problem their own way, then the teacher provides guidance based on the actual steps the student took.
This way, the teacher model addresses problems the student model encounters under its current distribution, rather than a pre-prepared set of standard errors.
After these stages, the experience accumulated from long-term multi-model task execution began to be used for NeoHorse's post-training.
What Is Improved After Post-Training?
Based on results from the current technical report, Agentic Post-Training brought stable improvements at both the 4B and 9B scales.
Among them, the comprehensive performance of NeoHorse-1-4B (macro-average score increased from 58.94 to 64.87) has reached SOTA for its scale—surpassing its base model Qwen3.5-4B on all comparable benchmarks, and leading comprehensively among similarly sized 4B comparison models.
But SOTA doesn't mean capabilities are evenly distributed.
A further breakdown shows that the improvements for the 4B model are mainly concentrated in one type of task.
These tasks typically have relatively clear workflows, observable environmental feedback, verifiable success/failure, and fairly clear final delivery criteria.
For example, in a project scheduling task, the base model found 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 outdated information and saved the file to the wrong location.
The post-trained model continues to read the new evidence, discovers the constraints have changed, recalculates the schedule, verifies the result, and then saves the deliverable to the correct location.
The difference lies in the Agent execution chain.
One model roughly knows how the task should be done; the other model can already string together gathering evidence, updating constraints, execution, verification, and delivery into a relatively complete workflow.
Achieving SOTA for its scale doesn't mean letting NeoHorse-1-4B handle all tasks. Basic Rhythm is more concerned with how to finely delineate the capability boundaries of different models.
Tasks that can be stably completed by a 4B model can reduce calls to larger models; tasks that can be done by a stronger model also don't need constant upgrades to the most expensive flagship models; when difficulty rises further, they can be handed over to more capable models in the model pool.
This connects directly to the relationship between the Routing Harness and in-house developed models.
The models continuously expand the cost range of tasks they can undertake, while the routing system, based on task difficulty and execution status, places different capabilities in appropriate positions.
Beyond API Call Fees, What Value Does This Model Offer?
At this point, the relationships between Basic Rhythm's product lines become clearer.
The first layer is OpenSquilla Open-Source Edition.
Through free, open-source, local deployment, and desktop products, Basic Rhythm lowers the barrier for developers to use multi-model Agents while connecting developers and task entry points.
The second layer is the TokenRhythm API.
Its positioning is close to a "Chinese version of OpenRouter," providing access to different models via a unified interface, catering to developer and enterprise model usage needs, while helping model vendors connect to more application scenarios.
Enterprises can more easily evaluate, select, and switch models without separately adapting to numerous model APIs.
The third layer is services and deployment capabilities for enterprises.
Industries like finance and manufacturing have different requirements for permissions, stability, private deployment, and service guarantees, forming further commercial space.
The fourth layer is NeoHorse.
NeoHorse first validates a key connection: effective experience generated during Harness execution, after screening and training, can indeed be transformed into the model's own capabilities.
Thus, for the first time, Basic Rhythm's previously proposed business flywheel shows results at the model level.
This also opens up possibilities for optimizing inference economics.
If NeoHorse can later stably handle a set of high-frequency, relatively well-defined Agent tasks, the platform gains an additional supply of capabilities it can autonomously schedule.
These tasks can further optimize inference costs, response speed, and stability, also making model supply configuration more flexible. As the model iterates further, the range of tasks it can cover has room for expansion.
From this perspective, what Basic Rhythm aims to do resembles process accumulation in a manufacturing system.
External model ecosystems provide different capabilities, the Harness organizes execution; experience formed during execution then feeds into the next round of model improvement.
From connecting models and providing services, to transforming experience generated from services into model capabilities, and further improving efficiency and quality—this is the extra step Basic Rhythm has taken beyond being an API aggregation platform.
Beyond Models, What Is Basic Rhythm Building?
The envisioned cycle at Basic Rhythm can roughly be strung together by several business lines:
- Routing Harness connects developers with Agent tasks
- → TokenRhythm API connects model supply with invocation demand
- → Harness organizes execution, accumulating routing and task trajectories
- → Usable trajectories are screened for model training
- → Updated models return to Harness, participating in task adaptation
- → Improving task experience, exploring better response speed and cost efficiency
- → Continued usage, payment, and operational efficiency improvements
- → Supporting the next round of service refinement and R&D investment
A key change here is that trajectories generated by models no longer remain solely in the consumption and invocation phase; they may also become a source for the next round of model training.
Every time an Agent completes a task, the Harness gains another observation about capability boundaries.
A model fails? The system learns where the capability gap might be. Another model successfully takes over? The system gains a new repair path. The user ultimately accepts or rejects the result? That provides another layer of external feedback.
More tasks accumulate? Routing judgments may become more accurate. More accurate routing judgments? The training trajectories screened become closer to actual tasks. Models become more suited to tasks? API services have the opportunity for better cost and experience.
If this cycle can be sustained long-term, the difference between Basic Rhythm and regular API aggregation platforms will gradually shift from routing rules and model lists into training task design, training methods, and model parameters.
Finally manifesting in product performance.
How Far Is It from RSI?
The above is the context for Basic Rhythm starting to discuss RSI (Recursive Self-Improvement).
Currently, the scope of RSI validated by Basic Rhythm is closer to an engineering closed loop, which can be split into two parts.
The first is Data-RSI.
Models continuously execute tasks within the Harness; every routing decision, tool call, failure recovery, and final result generates new structured records.
After screening and processing, these records can enter the data pool for subsequent training. Therefore, training data doesn't have to rely entirely on manually prepared data and can increase as the system continues to be used.
The second is Model-RSI.
The system identifies the current model's capability shortcomings based on evaluation results, adjusts the next round's training data distribution, updates the model, and puts the new model back into the Harness for execution.
In other words, the model learns from execution experience; the updated model, through new task execution, generates new feedback for the next round of training.
However, based on currently public information about NeoHorse, this system cannot yet be considered full RSI.
The technical report currently verifies a single "Execution → Evaluation → Selection → Update" closed loop. Signal design, reward design, and training processes are still set by humans. Whether stable gains can continue after multiple model iterations also requires more experimental confirmation.
Therefore, a more accurate statement is that this NeoHorse release has completed two layers of validation.
One is commercial: data accumulated by the system can enter model training and be transformed into measurable capability improvements.
The other is technical: Wang Yunhe's startup team has completed a single-round engineering validation oriented towards the RSI direction.
The More Models, the More Valuable This Company?
Of course, for Basic Rhythm's story to hold, several hurdles need to be crossed.
First, whether the open-source ecosystem can consistently translate into API usage and revenue.
Second, as task types increase, whether the system can continuously obtain sufficiently high-quality Agent trajectories suitable for training.
Third, after model capabilities improve, whether they can stably translate into better task experience and execution efficiency, and further reflect in operational data.
Fourth, after multiple model iterations, how long can capability gains be sustained.
These questions require longer-term observation.
And there's an unavoidable variable—model vendors like DeepSeek, Qwen, MiniMax are also extending into Harness and Agent products; the trend of vertical integration between models and Agent infrastructure is becoming increasingly evident.
Taking Basic Rhythm as an example, one current differentiator for this company is model neutrality and the horizontal comparison data formed during cross-model execution.
But if capability differences between models become large enough, cross-model scheduling could become an independent business; if leading models gradually cover more tasks, or vendors bundle Routing, tool calling, and Agent frameworks themselves, the space for the middle layer would be compressed.
When upstream capabilities become stronger and cheaper, why is this middle layer still needed?
For Basic Rhythm, NeoHorse at least provides a new perspective on this question.
In the past, it proved it could "use models"; now it's beginning to attempt to prove that the data accumulated from long-term model usage can also be solidified into its own model capabilities.
If this path succeeds, Basic Rhythm's moat isn't just in routing strategy; if it doesn't succeed, it still faces the problems all model middle layers encounter.
GitHub:https://github.com/TokenRhythm/NeoHorse
Hugging Face:https://huggingface.co/collections/TokenRhythm/neohorse-1
This article is from the WeChat public account "QbitAI," author: Heng Yu
