RadixArk Miles Reaches v0.1, but Production-Scale RL Still Needs Proof

RadixArk Miles reached version 0.1 on August 18, 2026, nine months after its first public release. The milestone turns a young repository into a broader system for reinforcement learning, agent training, and distributed model post-training.

That distinction matters because starting an RL experiment is easier than keeping one correct across many machines. Rollout engines generate experience, trainers update the model, and new weights must return to inference workers without corrupting the process.

The project recently appeared at rank 14 in a GitHub Trending hot-list snapshot. However, that aggregator supplied no verified publication time, so the ranking is not the underlying event. The confirmed news is RadixArk's v0.1 release and its detailed production claims.

Miles enters a crowded field of open training systems, including the slime framework from which it evolved. Its real contest is therefore not one repository against another. It is open, inspectable infrastructure against the custom internal stacks that advanced AI teams still build for themselves.

RadixArk Miles v0.1 Is the Confirmed Event

The important change is not a temporary trending position. RadixArk has attached a numbered release and a production narrative to Miles.

RadixArk and its ecosystem partners published the Miles v0.1 release on August 18, 2026. They described it as a full-stack system for frontier model post-training. That description remains a project claim, not an independent certification.

The date resolves the uncertainty in the trending feed. The repository did not suddenly appear in September. Miles was initially announced on November 19, 2025, then developed publicly before reaching the v0.1 milestone.

The original Miles release positioned the project as an enterprise-oriented extension of slime. Slime had emphasized a small, modifiable architecture. Miles retained that foundation while adding infrastructure for larger mixture-of-experts models and production workloads.

A mixture-of-experts model, or MoE, activates selected expert components for each token instead of using every parameter. That design can improve computational efficiency, but it complicates routing, training consistency, and distributed execution.

Version 0.1 attempts to cover the complete post-training loop. SGLang generates trajectories, either NVIDIA Megatron-LM or PyTorch FSDP trains the policy, and a synchronization layer returns updated weights to rollout workers.

That scope is more significant than a new algorithm implementation. Organizations can already find code for PPO, GRPO, supervised fine-tuning, and related methods. The difficult work begins when those methods meet long agent sessions, changing policies, hardware failures, and uneven workloads.

RadixArk says Miles supports synchronous and fully asynchronous reinforcement learning. In the asynchronous path, inference workers continue generating samples while the trainer consumes completed groups and updates the model.

The project also includes integrations for agent environments and sandbox providers. Those connections let a training job run coding or computer-use tasks, record the resulting trajectories, and pass verifier scores back as rewards.

The public Miles repository supplies the code, recipes, tests, documentation, issues, and development history behind those claims. Its Apache 2.0 license gives teams broad rights to inspect and adapt the implementation.

That openness makes technical examination possible. It does not guarantee that another organization can reproduce RadixArk's largest runs without comparable hardware, networking, and operational expertise.

Version 0.1 should therefore be read as a maturity marker. RadixArk has consolidated its architecture, documented reference workloads, and declared a production target. Wider deployment evidence remains the next test.

Why Agentic RL Creates a Systems Problem

Agent training turns ordinary model post-training into a coordination problem spanning inference, tools, sandboxes, rewards, and continuously changing weights.

A simple language-model rollout can generate one answer from one prompt. An agentic rollout may open a terminal, inspect files, call tools, recover from errors, and continue across many turns.

Those trajectories rarely finish together. One coding task might fail quickly, while another may spend minutes executing commands. A synchronous trainer waits for the slowest members before advancing, leaving expensive hardware idle.

Miles addresses that imbalance with sample-level scheduling. When one trajectory finishes, another can occupy the available slot immediately. Completed trajectory groups enter a bounded buffer for the trainer.

This design separates rollout cadence from optimizer cadence. It also creates a difficult question: how old can an experience sample become before the updated policy makes it unsuitable for training?

In asynchronous reinforcement learning, policy lag measures how far the model generating a sample trails the current training policy. More concurrency can raise hardware use, but excessive lag can weaken the on-policy assumptions behind an algorithm.

Miles exposes controls for accepting, retrying, discarding, or rejecting stale samples. That flexibility helps researchers define their own boundary, but it transfers an important correctness decision to the operator.

Agentic training introduces another mismatch. Tool calls and chat templates can alter how messages become tokens between turns. The trainer may then receive a slightly different sequence from the sequence used during inference.

Miles calls its response Token-In-Token-Out, or TITO. The session server preserves the generated token identifiers while adding only newly appended messages. Loss masks exclude tokens that the model did not generate.

This mechanism targets a subtle failure mode. If rollout and training disagree about tokens, probabilities, or expert routing, the optimizer learns from a reconstructed interaction rather than the actual experience.

The repository's public TITO roadmap also reveals the limits of current support. Named model families require explicit configuration, and the system does not automatically detect every template.

That detail is healthy evidence of an active engineering project. It shows that token fidelity depends on model-specific contracts, tests, and integrations. The feature is not a universal switch that makes every external agent harness correct.

Miles also supports isolated environments for coding and computer-use episodes. Each task can receive a fresh sandbox containing its own files, processes, and verifier.

Isolation matters because one failed episode should not contaminate another. It also increases orchestration work, especially when thousands of environments must start, execute, report rewards, and terminate predictably.

These problems explain why the v0.1 release arrived now. AI development is shifting from single-response tuning toward agents that act over longer periods. The training infrastructure must capture those actions without losing the exact context that produced them.

Developers evaluating the project should focus on this systems layer. Algorithm support is necessary, but reproducible trajectories, scheduling behavior, and failure recovery will determine whether a long run produces useful evidence.

Teams documenting their own experiments also need searchable records of configurations, failures, and evaluation results. A structured engineering knowledge base can preserve that operational context outside the training framework.

The Core Mechanism Connects Rollout, Training, and Weight Updates

RadixArk Miles is betting that one coordinated loop can reduce the mismatches created by separate inference and training stacks.

The loop begins with SGLang, an open inference engine designed for high-throughput model serving. Miles uses it to generate long, multi-turn trajectories and reuse cached prefixes across agent sessions.

Prefix caching stores reusable attention state for text already processed by the model. Keeping later turns on the same suitable worker can avoid repeatedly computing the shared conversation history.

Miles routes new sessions toward less-loaded workers while trying to preserve that cache locality. This approach targets the long-tail problem, where a few lengthy tasks consume disproportionate capacity.

The trainer then processes completed groups using Megatron-LM or FSDP. Megatron-LM supports several forms of model parallelism, while FSDP shards model state across data-parallel workers.

Offering both paths widens the potential audience. Teams with established Megatron deployments can use its distributed controls. Teams closer to Hugging Face model implementations can use FSDP without the same conversion process.

The abstraction does not erase backend differences. Megatron recipes can split work across tensor, pipeline, context, and expert dimensions. The FSDP path uses a different distribution model and may require architecture adaptations.

After training, Miles must move changed weights back to the rollout fleet. That step can dominate iteration time when models span many accelerators and inference uses a different sharding layout.

For directly connected clusters, the project offers peer-to-peer transfers over RDMA. Remote direct memory access lets machines write data into remote memory with limited CPU involvement.

RadixArk reports that this path reduced a Kimi-K2 trillion-parameter weight update from 53.3 seconds to 7.2 seconds. The result comes from the project's own reference workload and needs reproduction under other network layouts.

Miles also provides disk-delta updates when direct NCCL or RDMA connectivity is unavailable. The system publishes changed portions of the policy instead of sending a complete checkpoint after every step.

In a reported GLM-4.7-Flash run, RadixArk says this reduced each payload from 62.4 GB to between 0.69 GB and 0.83 GB. The associated generation pause stayed between three and five seconds.

Those figures describe different deployment paths, not one universal performance promise. Peer-to-peer transfer depends on fast networking and compatible topology. Disk deltas depend on how many bytes change between policy versions.

Low-precision computation adds another layer. Miles includes recipes using FP8, MXFP8, NVFP4, and INT4 quantization-aware training across supported models.

Quantization represents values with fewer bits to reduce memory use and increase throughput. However, the inference and training sides must apply compatible rules, or their numerical differences can alter policy behavior.

That issue becomes sharper for MoE models. Tiny numerical changes can select a different expert for a token, changing both the forward computation and the parameters receiving gradients.

Miles addresses this with Rollout Routing Replay, called R3. It records expert-routing choices during inference and replays them during the trainer's forward pass.

This is the clearest expression of the project's central mechanism. The framework does not merely connect independent tools. It attempts to preserve the decisions made across the complete RL loop.

The same principle supports on-policy distillation and zero-KL alignment. On-policy distillation trains a student from teacher signals collected under the student's current behavior. Zero-KL alignment targets numerical agreement between rollout and training.

Each feature attacks a form of divergence. Together, they make Miles more than a collection of training scripts. They also create a larger surface that must remain correct across model families and hardware generations.

Open Infrastructure Is Challenging Private Training Stacks

Miles pressures organizations that still treat reinforcement-learning infrastructure as an internal advantage that every serious model team must rebuild.

RadixArk's position is straightforward. Open inference improved through shared systems such as SGLang, and post-training infrastructure should follow a similar path.

The company launched publicly on May 5, 2026, with $100 million in seed financing at a stated $400 million post-money valuation. Accel led the round, with Spark Capital serving as co-lead.

Its open infrastructure strategy names SGLang and Miles as two foundations. SGLang handles inference, while Miles covers reinforcement learning and model post-training.

That financing changes the context around the repository. Miles is not only a volunteer experiment. It is a strategic asset for a funded company that intends to build managed products around open infrastructure.

The primary opponent is therefore the private RL stack. Frontier laboratories often assemble internal combinations of rollout services, trainers, data buffers, evaluators, and checkpoint systems.

Those internal platforms can reflect years of operational learning. They may include proprietary schedulers, optimized kernels, specialized observability, and recovery procedures unavailable in public repositories.

Miles tries to narrow that gap by putting an integrated baseline in the open. A startup could begin with maintained recipes and extension points instead of connecting every subsystem from scratch.

This does not eliminate integration work. A team must still prepare environments, rewards, datasets, model checkpoints, networking, storage, and evaluation criteria.

The difference lies in where engineering begins. Without an integrated framework, the team first builds the basic loop. With Miles, it can start by testing whether the provided loop matches its workload.

The project also competes indirectly with simpler research frameworks. Slime remains an important reference because Miles originated from its design and says many changes flow back upstream.

That relationship complicates any winner-versus-loser narrative. A small framework can remain preferable for research that values transparency and rapid modification. A larger system can serve teams needing more built-in operational controls.

Miles must preserve both qualities to justify its position. Too much infrastructure can make debugging harder, even when the framework describes itself as modular.

The company highlights typed interfaces and replaceable components for rollout, rewards, losses, filters, and data sources. Those extension points matter only if users can understand failures across their boundaries.

Commercial incentives also deserve attention. RadixArk benefits when the open projects become widely adopted, since managed infrastructure and support can grow around that adoption.

That model is common in open-source infrastructure. It can fund maintenance and hardware validation. It can also create tension over which capabilities remain easy to operate independently.

The Apache 2.0 license reduces some lock-in concerns because teams can fork and modify the code. Operational dependence can still form through deployment services, proprietary tooling, or specialized expertise.

For buyers, the relevant question is not whether Miles is open. The question is whether another organization can operate it reliably without becoming dependent on RadixArk's private knowledge.

For developers, the repository offers immediate value as a readable map of the RL systems problem. Its architecture exposes where rollout fidelity, scheduling, precision, and synchronization interact.

For AI product teams, that infrastructure can affect experimentation speed. Faster loops allow more agent environments, reward designs, and data strategies to be tested within the same hardware budget.

What the Reference Runs Do Not Prove

RadixArk has published unusually concrete system claims, but most performance evidence still comes from the team building the framework.

The flagship v0.1 example trained a GLM-5.2 744B-A40B model on terminal-use tasks across 64 NVIDIA GB300 GPUs. RadixArk assigned 32 GPUs to rollout and 32 to training.

The reference configuration used a maximum sequence length of 65,000 tokens and a batch size of 64. The company reported 100 stable rollout steps with training steps lasting about 4.5 minutes.

It also reported an average policy lag of 1.7 steps and a 96 percent prefix-cache hit rate. Memory optimizations reportedly saved more than 30 GB of HBM per GPU in that workload.

These figures are valuable because they give evaluators specific targets. They remain measurements from one model, cluster, software version, task distribution, and tuning configuration.

A 100-step run is evidence that the system can operate under that setup. It does not establish long-duration reliability across thousands of updates, intermittent failures, or changing environment loads.

The performance profile may also differ on smaller clusters. Features optimized for dozens of recent accelerators can add complexity without producing the same benefit on eight GPUs or mixed hardware.

The project's asynchronous design introduces an unavoidable tradeoff. Keeping rollout and training busy raises utilization, but older trajectories can drift further from the current policy.

RadixArk exposes staleness controls and reports lag in its example. Independent users must determine whether those controls preserve learning quality for their algorithms and reward distributions.

Low-precision claims deserve similar scrutiny. RadixArk says its reward curves closely track BF16 baselines while reducing rollout time. That result cannot automatically transfer to every model, optimizer, or task.

Quantized training can be sensitive to activation distributions and particular layers. Miles allows selected components to remain in BF16, but choosing those exceptions requires model-specific validation.

Model support is another moving target. The repository lists many dense, MoE, multimodal, and agentic recipes. A listed recipe does not mean every combination of backend and precision receives equal testing.

The public issue tracker makes that uncertainty visible. Open reports cover synchronization behavior, configuration semantics, LoRA details, routing alternatives, and support for additional modalities.

That activity is not evidence that Miles is unusually defective. Distributed training projects normally expose complex failure modes. It does show why the phrase "production-ready" should be tested against each buyer's requirements.

Fault tolerance remains especially important. A cluster-scale run can lose hours when one worker fails, a transfer stalls, or a checkpoint becomes inconsistent.

The original 2025 roadmap explicitly identified better elasticity around GPU failures as future work. Version 0.1 includes more operational machinery, yet users should still test recovery rather than infer it from successful runs.

Security also extends beyond the trainer. Agentic environments execute model-generated actions, sometimes including shell commands and network requests.

Fresh sandboxes reduce cross-episode contamination, but operators must review image provenance, credentials, network boundaries, logs, and retained artifacts. A training framework cannot define every organization's threat model.

The correct conclusion is measured. Miles has moved beyond a minimal demonstration, and its reference runs are technically meaningful. Broad production maturity still requires independent reproduction and longer operational histories.

Three Signals Will Decide Whether RadixArk Miles Lasts

The next stage depends on reproducibility, fault recovery, and adoption beyond teams already connected to RadixArk or SGLang.

The first signal is independent reproduction of the large reference workloads. Researchers do not need an identical 64-GPU cluster, but they should publish comparable utilization, policy-lag, and convergence results.

Successful reproduction would strengthen RadixArk's claim that its coordination mechanisms generalize. Large unexplained gaps would suggest that private tuning or unusual topology accounts for more of the published performance.

The second signal is evidence from long-running failure recovery. Users should watch for documented tests involving interrupted workers, stalled inference engines, damaged environments, and checkpoint restoration.

Reliable recovery would support the production label more strongly than another peak-throughput chart. Repeated synchronization or resumption failures would weaken the case for using Miles in expensive unattended runs.

The third signal is adoption by teams that did not help build or announce the framework. Independent case studies should explain model size, hardware, task type, modifications, and the operational problems encountered.

Logos and testimonials provide useful leads, but detailed reports carry more weight. The strongest evidence would show what Miles replaced, what engineering remained, and how much time the team saved.

Repository activity will also provide context for all three signals. Maintainers need to close correctness issues while supporting new models, precisions, hardware, and agent environments.

That workload can create a familiar open-source tension. Rapid support attracts users, while too much expansion increases regression risk across combinations that are difficult to test.

The most durable version of Miles would define a tested core and communicate experimental boundaries clearly. Users can then distinguish supported production paths from promising extensions.

RadixArk also needs to show that community contributions influence the roadmap. A repository tied closely to one company's priorities can remain open while becoming difficult for outsiders to steer.

For smaller teams, the immediate decision does not require accepting every scale claim. They can test one supported model, one environment, and one backend against an existing workflow.

That evaluation should measure more than tokens per second. Teams should record failed episodes, stale-sample rates, reward reproducibility, checkpoint recovery, and the effort required to diagnose problems.

The current verdict is that RadixArk Miles has become a serious open attempt at production-scale agent training. Its August v0.1 release, not an undated trending rank, is the event worth tracking.

The next proof will come from users. Can independent teams reproduce the reported behavior, recover failed runs, and extend the system without hidden operational knowledge?

Teams considering RadixArk Miles should begin with a bounded workload and publish what they find. Compare synchronous and asynchronous runs, inspect token fidelity, and test recovery before scaling. Record every configuration change and failed assumption. That evidence will matter more than repository momentum alone. If those results converge across different models and clusters, Miles can become a shared foundation for open post-training. If they remain difficult to reproduce, the project will still be a useful systems reference, but not yet a replacement for private infrastructure.