Reinforcement learning (RL) updates a model using feedback on its attempts. Xiaomi’s public MiMo dashboard lets you connect that idea to real charts: the model tries tasks, graders score the attempts, and training changes the model’s behavior. This is a window into training, not an end-user training tool.

The page checked on September 27, 2026 shows both mimo-v2.6-pro and mimo-v2.6-flash ended at step 30. That matters: its counters are a dated record of a training run, not a live promise about the next checkpoint or your API results.

What the dashboard is showing

Read the training loop in this order:

  1. Xiaomi selects prompts from mixed code, general-agent, visual, cybersecurity, and chat sources. A harness wraps each task and its tools; an environment provides the sandbox or application; a grader or validator checks the result.
  2. The policy generates multiple rollouts: attempted trajectories through that task. Xiaomi’s model card describes 1,568 prompts × 16 rollouts per update, or 25,088 attempted sequences in the dashboard’s trained_step total.
  3. Tests, validators, and graders turn outcomes into rewards. A reward is a training signal for this batch, not a universal quality score.
  4. Training updates the model’s policy: how it chooses its next tokens and actions. An RL step is an update cycle, not one prompt or one tool call. Xiaomi describes group-relative policy optimization (GRPO), which compares attempts within a group.
  5. Xiaomi repeats the process across steps and checks separate evaluations. The dashboard plots dynsam/avg@n, the average fraction of successful attempts per prompt, plus pass-rate buckets, token volume, context length, agent turns, timing, and infrastructure failures.

The Overview shows run status, selected charts, the dynamic sampler and batch composition. Metrics is the searchable tree of diagnostic charts; click a chart title to open its description. The About text still advertises an upcoming release, so use the run’s ended status and dated release sources when interpreting it.

How to read the useful metrics

  • Mean pass rate: dynsam/avg@n: Average each prompt’s fraction of successful attempts. A rise is not general intelligence; the sampled tasks and grading can change.

  • Pass-rate buckets: zero: no attempts passed. one: every attempt passed. More solved prompts can reflect an easier batch, not just a better policy.

  • Reward: critic/rewards/mean: Average reward on trajectories used for an update. Reward is defined by the grader; it does not guarantee factual accuracy or user satisfaction.

  • Entropy and gradient diagnostics: Entropy tracks how spread out token choices are; gradient norm tracks update magnitude. Neither a lower loss nor a smaller gradient is automatically better task performance.

  • Train/inference KL: Compares the inference engine’s and trainer’s probabilities on the same tokens. This consistency diagnostic is not a benchmark or a hallucination rate.

  • Staleness: Policy-version lag between generating a trajectory and training on it. Asynchronous work can lag without proving the run is broken.

  • Batch composition and sampler: Shows which task sources contributed and which samples were accepted or discarded. The sampler’s accepted count is not a count of successful customer tasks.

Start with the same run and task group, leave smoothing off, and check the step/time axis before comparing curves. Xiaomi’s notices record restarts, grader-network problems and data filtering. Read those alongside the curves: infrastructure errors and changing task mixtures can change an aggregate.

Why grading matters: Xiaomi describes GRS (Groupwise Reward Synthesis) for building rubrics from contrasting attempts, and GAR (Groupwise Advantage Redistribution) for ranking passing attempts. Two solutions can both pass tests while differing in quality or efficiency. A rising reward still needs a separate task evaluation to establish useful progress.

What the benchmark and cost numbers prove

The dashboard’s DeepSWE v1.1 card is labelled mini-swe-agent, avg@3. Its step-30 points were 72.57 for Pro and 65.68 for Flash in this snapshot. Xiaomi’s release note separately summarizes roughly 58.4 → 72.6 for Pro and 48.8 → 65.7 for Flash. The Flash model card lists another evaluation table, 71.9 for Pro and 67.9 for Flash. Keep those rows labelled: benchmark version, checkpoint, agent, and evaluation recipe can differ. None is an AIHackers repository result or a cost-per-accepted-result measurement. Use How to Read AI Benchmarks before turning a score into a buying decision.

The dashboard estimated about $2.62 million for Pro and $854,000 for Flash; Xiaomi reports the same rounded figures. That is training compute for Xiaomi’s run. It is not your hosted API bill, a self-hosting quote, or proof that a task will be cheaper than Luna. Xiaomi calls V2.6 fully open-sourced, and the Hugging Face cards list MIT licenses, reports, and deployment paths. For the distinction between a downloadable checkpoint and a reproducible training stack, see Open Weights vs Open Source. Open weights improve inspectability and give you a self-hosting option, but the 309B-total Flash MoE and larger Pro still require serious storage, hardware, serving software, and operations.

Use the MiMo model guide for access and price checks, and the cost-saving playbook for routing. The dashboard shows the feedback process used to train a model: environments, graders and repeated attempts. Your decision still needs the same task set, measured retries, token use, review time, and accepted-result rate across MiMo, DeepSeek, GLM, and Luna.

Sources checked: Xiaomi’s V2.6 release, the Hugging Face collection, the Flash-RL card, and the RL dashboard. The run and dashboard state can change independently from hosted pricing and model availability; recheck those before purchase or production routing.