NeoHorse-1: Agentic Post-Training With a Routing Harness

What NeoHorse-1 actually ships

Two checkpoints, not a framework. NeoHorse-1-4B and NeoHorse-1-9B are causal language models post-trained from Qwen3.5-4B and Qwen3.5-9B respectively, released under Apache-2.0 as Safetensors weights in BF16. The README describes them as text input and text output models for self-hosted inference, targeting text-based agent harnesses, tool use, coding and instruction following. The repository also publishes GGUF builds of both sizes, each containing 16-bit BF16 weights plus 8-bit, 5-bit and 4-bit quantizations, and mirrors the checkpoints on ModelScope alongside Hugging Face. There are no releases retrieved for the repository itself, so the checkpoints on the model hubs are the distribution channel rather than versioned artifacts here. The stated context length is 262,144 tokens natively, with the base capability described as extensible up to 1,010,000 tokens. That second number is a property inherited from the Qwen3.5 base, not a configuration the repository demonstrates.

The routing harness is the part worth reading the report for

The mechanism the README describes is a loop, not a model feature. A routing harness assigns incoming tasks to a heterogeneous pool of models, records tool interactions and their outcomes, estimates capability demand from that record, and routes capability-level feedback into the next training mixture. Training signal comes from execution trajectories: the README states the post-training uses routing-guided curriculum SFT and routing-guided on-policy distillation, and that these preserve execution and harness context rather than stripping it. Updated models can be returned to the harness, closing an evaluation-selection-update cycle. The honest framing in the README is that this is a prototype loop and that extending it across successive iterations is the next step toward recursive self-improvement. So the harness is the interesting artifact, and the models are its first output. Treat the RSI framing as a research direction, since nothing in the README shows a second full iteration completing.

Data pipeline claims and what they imply

The training data path gets more detail than most releases at this size. The README lists exact and near-duplicate removal, evaluation decontamination, structural validation, a six-dimensional semantic evaluation, and subscene-level Scene/Goal/Outcome labeling. The decontamination step matters if you intend to compare the published evaluation numbers against benchmarks you also run, because it is the project's own claim that benchmark overlap was removed before training. The Scene/Goal/Outcome labeling is the more unusual choice: it implies trajectories are segmented into subscenes and annotated with intent and result, which is what makes capability-level feedback possible downstream. None of this is independently verifiable from the repository. It is a description of a pipeline, and the technical report on arXiv is where the details would live. If data provenance decides your adoption, the report is the document to read, not the README.

Running the weights

The README does not include a quickstart snippet, an install command, or a config key. What it does specify is the interface and the format: text in, text out, Safetensors in BF16, with GGUF variants at 16-bit, 8-bit, 5-bit and 4-bit published for both sizes. In practice that means the deployment path is the standard one for a Qwen3.5-derived checkpoint: load the Safetensors weights with a Hugging Face transformers-compatible server, or point a llama.cpp-family runtime at the GGUF file when you want the quantized versions on smaller hardware. The model cards are where the README directs you for model-specific evaluation tables and deployment notes. Two things to check before you plan capacity: whether your serving stack actually supports the 262,144-token native context without silent truncation, and which quantization level holds up on your tasks, since the README gives no per-quantization quality figures. The 9B is described as the higher-capacity option on the same text-first serving interface, so switching between the two should not require a different integration.

Where this is the wrong tool

Three boundaries are visible. First, the models are text-only. There is no vision or audio path in the model details table, so anything requiring image input is out. Second, the release is a post-trained checkpoint, not a harness implementation you can deploy. If you want the routing behavior, the README describes it as part of the training methodology and points to the technical report; the repository does not present a runnable router with a documented configuration surface. Third, the RSI claim is explicitly a prototype. A team that adopts NeoHorse-1 because it wants a self-improving system will be disappointed, because the loop described has not been shown running across successive iterations. The realistic use case is narrower: you want a 4B or 9B Apache-2.0 model that was tuned on execution trajectories and harness context, and you will supply the harness yourself.

Against a general-purpose Qwen3.5 release

The obvious comparison is the base models. NeoHorse-1-4B and 9B start from Qwen3.5-4B and Qwen3.5-9B, so the difference is entirely in post-training. A stock Qwen3.5 checkpoint is trained for broad instruction following and general chat; NeoHorse-1 is trained on execution trajectories with tool interactions and outcomes retained in the training signal, and the README frames the target as text-based agent harnesses, tool use and coding. The trade-off runs the other way too. Post-training on a narrower distribution can cost you on tasks outside that distribution, and the README does not publish a comparison against the base checkpoints on general benchmarks. It reports a ten-benchmark protocol grouped by capability, with results in the technical report and per-model tables on the model cards. If your workload is mostly chat and document processing with occasional tool calls, the base Qwen3.5 weights are the safer default. If your workload is a harness that runs tools in a loop, the post-training target is a better match.

Maintenance, licensing and the cost of moving

The last push to the repository was on 2026-09-10, four days before this writing, and the checkpoints, GGUF builds and ModelScope mirrors all landed between 2026-09-07 and 2026-09-09. That is a fresh release, not a track record. Apache-2.0 covers the weights and the repository, which permits commercial use and modification, but it also means you carry the compliance work: attribution and licence-notice obligations travel with redistribution, and the Qwen3.5 base lineage may carry its own notice requirements that the README does not enumerate. That is a question for your own legal review, not something the repository settles. The upgrade cost is the part to plan for. Because these are fine-tuned derivatives rather than a serving framework, adopting a future NeoHorse iteration means re-validating your prompts and tool schemas against new weights, and the repository has no release history yet to show how disruptive those updates will be. The GGUF quantization set does soften the hardware side: 4-bit and 5-bit builds let you evaluate the model on hardware that could not hold BF16 weights.

Editorial conclusion

Adopt NeoHorse-1-4B or 9B if you are already serving Qwen-family weights and want an Apache-2.0 checkpoint tuned for tool-calling and harness context, with GGUF and 8-bit, 5-bit and 4-bit quantizations published for local hardware. Do not adopt it expecting a working recursive self-improvement system: the README describes the evaluation-selection-update loop as a prototype and says extending it across successive iterations is the next step. Before committing, verify the per-checkpoint evaluation table on the model card against your own task suite, and check whether your serving stack honors the 262,144-token native context rather than truncating it.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. TokenRhythm/NeoHorse on GitHub