Qwen3.8-27B-pi: Effort-Ordered Reasoning for Agentic Coding

Models: BF16 · FP8 · GGUF · Collection

TL;DR

Qwen3.8-27B-pi is Qwen3.8-27B fine-tuned for coding work in the Pi agent harness: reading repositories, editing files, running tools and working through their feedback.

The problem: Base didn't keep its effort levels in order. Low often spent more reasoning than medium, and on Terminal-Bench 2.1 medium passed fewer tasks than low. Pi addresses that in two stages:

1. SFT on curated, successful Pi sessions to teach the complete coding workflow.
2. RL (GRPO) with a success-conditioned reward: get the task right first, and a lower effort level should not reason for longer than a higher effort level does on the same task.

Pass rate against reasoning tokens per attempt for Base and Pi (FP8 weights). L/M/X = low, medium, xhigh.

• Effort ordering holds. Pi's mean reasoning tokens and pass rate are non-decreasing from low → medium → xhigh on Terminal-Bench 2.1, GPQA Diamond and SciCode (on Terminal-Bench, low and medium reasoning are near parity).

• Terminal-Bench 2.1. Pi at medium matches Base at xhigh (67/89) with about 41% fewer output tokens.

• SciCode. Pi solves more subproblems at every effort level. At xhigh it uses about 23% fewer output tokens than Base.

• Formats. BF16, FP8 (about 30.4 GB), and 17 GGUF variants (about 9–29 GB) calibrated on complete Pi agent sessions.

Background

What is Pi?

Pi is an open-source (MIT), terminal-based coding agent by Mario Zechner, and the harness this model is built for. It keeps a deliberately small core and pushes everything else into extensions.

• Four tools: read, write, edit and bash, behind a short system prompt.
• The loop: inspect the code, make a change, check the result, and let tool feedback decide the next step.
• Effort levels: a requested thinking level trades responsiveness for deeper problem-solving; this report uses off, low, medium and xhigh.
• Open by design: runs against hosted providers or local models, and is extended through TypeScript extensions, skills and prompt templates.

Effort ordering on Base

Terms: an effort level is the thinking level requested from the harness. Reasoning tokens are tokens inside thinking blocks, excluding answer text, tool calls and observations. Unless noted, figures are means over a task set.

Preliminary evaluations of Qwen3.8-27B showed that the requested effort level didn't reliably order how much it reasoned. Averaged across five evaluation sets:

Base Qwen3.8-27B. Reasoning tokens per task at each effort level, over all attempts and over passed attempts only. Unweighted means across five evaluation sets; tokens per task ≈ reasoning tokens per turn × turns per task.

Three things stand out:

1. Low spent more than medium. Low used about 1.5× more reasoning per task than medium, yet passed less often (68.5% vs. 70.7%).
2. It isn't just failures running long. Counting only passed attempts, low still spent about 1.3× medium's reasoning to reach the same result.
3. Xhigh works as intended. It has the highest pass rate and the highest spend in both views.

The requested effort level wasn't a reliable proxy for reasoning spent. At low, the model didn't spend fewer tokens; it spent them less efficiently.

Target property: effort ordering

For a given task set, moving to a higher effort level should spend at least as much reasoning and solve at least as many tasks:

$${\bar{T}}_L\le {\bar{T}}_M\le {\bar{T}}_H,p_L\le p_M\le p_H\backslash bar\; T\_L\; \backslash le\; \backslash bar\; T\_M\; \backslash le\; \backslash bar\; T\_H,\; \backslash qquad\; p\_L\; \backslash le\; p\_M\; \backslash le\; p\_H$$

where $LL$, $MM$ and $HH$ are low, medium and xhigh, ${\bar{T}}_e\backslash bar\; T\_e$ is mean reasoning tokens per task and $p_{e}p\_e$ is pass rate at effort level $ee$. A lower level spending more than a higher one is an ordering violation.

Base satisfied this only at xhigh. Low cost more than medium without solving more, and removing that violation is what the rest of this work set out to do.

SFT

Data

Collecting sessions

Before collecting at scale, I ran the untuned model through the complete Pi workflow on a small set of tasks to confirm the harness, tools and verifiers worked end to end. Collection then covered two kinds of tasks:

• Repository tasks: inspecting, editing and testing code in real repositories.
• Terminal tasks: multi-step work carried out in a shell.

Sessions were collected at all four reasoning levels (off, low, medium and xhigh). Each one is a complete session (inspecting the code, making edits, running tools and responding to their feedback), not an isolated answer.

What made a session usable

Every session had to pass three gates:

1. Correct completion: the task's verifier passes.
2. Valid structure: well-formed turns and tool calls that train cleanly.
3. Eligibility: the session fits the collection's rules. Being short did not make an example useful on its own.

Sessions that failed any gate were excluded. The accepted sessions were split into a training set and a held-out validation set used for checkpoint evaluation.

Training

SFT was a BF16 LoRA run over all linear layers, roughly one pass over the collection, with tool observations masked from the assistant loss. The adapter touches under 1% of the model's parameters and stays mergeable into the base weights.

Checkpoint selection: loss is not agent success

Every 5 steps, the checkpoint was evaluated as an agent on a held-out panel of 16 tasks at three reasoning levels (48 trials per checkpoint), for 21 checkpoints in total.

Top: validation loss. Bottom: agent pass rate pooled across low, medium and xhigh; the dashed line is Base (C0).

Better token-level loss did not mean a better agent. Validation loss fell steadily (0.2817 at C5 → 0.2749 by C80), while pass rate wandered between 52% and 63% and the final checkpoint (C96) ended below Base.

Reasoning tokens per turn at each effort level across SFT checkpoints.

More SFT didn't restore ordering. Low spent more reasoning than medium at 19 of 21 checkpoints, including Base and C5, while xhigh stayed on top. Removing that violation needed a different objective.

Per-checkpoint results: Appendix B.

With loss ruled out as a guide, I shortlisted three candidates by agent behavior:

• C5: early behavioral efficiency (fewer output tokens per turn than Base)
• C90: minimum validation loss
• C95: strongest late-training agent performance

These went to a larger screening run on all 89 Terminal-Bench 2.1 tasks at medium reasoning, scored as pass@1:

C5 passed the most and spent efficiently, so it became the SFT candidate. That isn't proof that five steps is optimal in general.

How SFT changed behavior

Base against C5 on the medium-reasoning Terminal-Bench 2.1 screening run (89 tasks, pass@1):

• Tighter turns: about 21% fewer output tokens per turn and 13% fewer turns per task, with a slightly higher pass rate.
• Less looping when stuck: on tasks it didn't solve, C5 stopped after about 35 turns instead of 51.
• Same working style: the tool mix barely moved, with about 80% of calls in bash for both. SFT tightened the Pi loop rather than changing how the model works.
• The effort pattern came along too: the accepted sessions had low reasoning more per turn than medium, and SFT imitated it. On the checkpoint panel, low's reasoning per turn rose from 141 to 206 at C5 while medium's fell from 86 to 67, widening the cost-ordering violation examined next.

What SFT fixed, and what it didn't

Effort ordering has two parts: accuracy ordering (a higher level solves at least as many tasks) and cost ordering (a lower level spends no more). On Terminal-Bench 2.1, SFT satisfied the first but not the second.

Accuracy ordering holds after SFT. C5 solved more than Base at every level, rising 73.0% → 74.2% → 77.5%. Base violated it: medium passed fewer tasks than low.

Cost ordering is still violated. SFT made medium cheaper, but not low:

• Base: low and medium cost about the same (~46k output tokens per task).
• C5: medium dropped to 34.8k while low stayed at 46.3k, a third more than medium for slightly fewer solves and only marginally less time (10.8 vs. 11.5 min).
• Both: xhigh stays the most thorough and most expensive setting.

In practice, C5's medium is both better and cheaper than its low, so low offers no reason to choose it. Restoring cost ordering, without giving up the accuracy gains at medium and xhigh, became the goal of RL.

RL

The guiding question

SFT left one clear gap: cost ordering between low and medium. RL was built around a single, per-task question:

If successful higher-effort attempts solve a task with a certain amount of reasoning, should a successful lower-effort attempt on the same task spend more?

Once medium or xhigh has shown how much reasoning a task actually needs, low shouldn't spend more, and medium shouldn't spend more than xhigh. That becomes four principles:

1. Correctness comes first. A failed attempt earns nothing, however short it is, so brevity is never rewarded on its own.
2. Xhigh is left alone. It gets no length pressure and stays the model's full-capability setting.
3. Medium stays within xhigh. When xhigh solves a task, medium shouldn't reason more than xhigh did on it.
4. Low stays within the levels above it. When medium or xhigh solves a task, low shouldn't reason more than the leaner of the two.

The goal isn't a fixed token budget or forced gaps between levels. It's that, on the same task, a successful lower-level attempt doesn't exceed what successful higher-level attempts needed.

Algorithm: effort-ordering reward

In plain terms.

• Every attempt is graded on correctness first.
• A correct low or medium attempt is then compared with the reasoning successful higher-effort attempts needed on the same task.
• At or under that amount earns full credit; going over costs a little, never as much as a wrong answer.
• Xhigh is graded on correctness alone.

The method keeps GRPO's group-relative structure but swaps its binary outcome reward for a success-conditioned, effort-ordered reward. The rollout design is what makes that comparison possible.

Rollout design

Each collection runs every task at all three effort levels with the same policy:

• Task batch: a batch of tasks $XX$ is drawn for the collection.
• Effort grid: each task $x\in Xx\; \backslash in\; X$ runs at low, medium and xhigh, with a group of independent attempts per level. An attempt is a complete multi-turn Pi session, scored once by the task's verifier.
• Admission: only training-eligible attempts (complete, well-formed, verifier-scored) are kept. The admitted attempts for task $xx$ at level $e\in \{L,M,H\}e\; \backslash in\; \backslash \{L,\; M,\; H\backslash \}$ form the group ${\mathcal{G}}_{x,e}\backslash mathcal\; G\_\{x,e\}$.
• One update per collection: references, rewards and advantages come from that collection alone and feed a single policy update.

How this shapes the algorithm:

• References are per task and on-policy. Because all levels attempt the same task in the same collection, a lower level is measured against what the current policy needed at a higher level on that exact task, not against a fixed budget or older runs.
• Hard tasks fall back to correctness. A reference needs enough successes at a level. If a task is rarely solved above, lower levels on it are graded on correctness alone.
• Uniform groups carry no signal. If every attempt in a group earns the same reward, for example all fail, its advantages are zero.
• Xhigh supplies references but receives none. It anchors the ordering without being pushed shorter.

Reward and advantage

(1) Successful reasoning lengths. For attempt $ii$, let $v_i\in \{0,1\}v\_i\; \backslash in\; \backslash \{0,1\backslash \}$ be its verifier outcome and $T_{i}T\_i$ its reasoning tokens summed over all turns. Only successes define what a task needs:

$$S_{x,e}=\{T_j:j\in {\mathcal{G}}_{x,e},v_j=1\}S\_\{x,e\}\; =\; \backslash \{\backslash ,\; T\_j\; :\; j\; \backslash in\; \backslash mathcal\; G\_\{x,e\},\backslash \; v\_j\; =\; 1\; \backslash ,\backslash \}$$

(2) Reference length. Given at least $n_{\min }n\_\{\backslash min\}$ successes, the reference is their median, floored at $b_{\min }b\_\{\backslash min\}$:

$$B_{x,e}=\max (b_{\min },\mathrm{median}(S_{x,e}))B\_\{x,e\}\; =\; \backslash max\backslash big(b\_\{\backslash min\},\backslash \; \backslash operatorname\{median\}(S\_\{x,e\})\backslash big)$$

The median resists single long outliers, and the floor keeps trivially short successes from setting an unreachable bar. With fewer than $n_{\min }n\_\{\backslash min\}$ successes, $B_{x,e}B\_\{x,e\}$ is undefined.

(3) Applicable reference. Let $e_{i}e\_i$ be the level of attempt $ii$, and $\mathcal{U}(e)\backslash mathcal\; U(e)$ the levels above $ee$: $\mathcal{U}(L)=\{M,H\}\backslash mathcal\; U(L)=\backslash \{M,H\backslash \}$, $\mathcal{U}(M)=\{H\}\backslash mathcal\; U(M)=\backslash \{H\backslash \}$, $\mathcal{U}(H)=\mathrm{\varnothing }\backslash mathcal\; U(H)=\backslash varnothing$. Each attempt is held to the leanest defined reference above its level:

$$B_i=\min \{B_{x,e^{\mathrm{\prime }}}:e^{\mathrm{\prime }}\in \mathcal{U}(e_i),B_{x,e^{\mathrm{\prime }}}\text{ defined}\}B\_i\; =\; \backslash min\backslash \{\backslash ,\; B\_\{x,e\text{'}\}\; :\; e\text{'}\; \backslash in\; \backslash mathcal\; U(e\_i),\backslash \; B\_\{x,e\text{'}\}\; \backslash text\{\; defined\}\; \backslash ,\backslash \}$$

If that set is empty (xhigh, or no higher level has a reference), no reference applies.

(4) Reward. The relative excess $z_i=\max (0,T_i\mathrm{/}{B}_i-1)z\_i\; =\; \backslash max\backslash big(0,\backslash \; T\_i\; /\; B\_i\; -\; 1\backslash big)$ measures how far a success runs past its reference. A smooth, decreasing shaping function $\varphi \backslash phi$, with $\varphi (0)=1\backslash phi(0)=1$ and $\varphi (z)\to 0\backslash phi(z)\backslash to\; 0$, turns it into a bounded penalty:

1. Correctness dominates. Any success scores at least $\frac{1}{2}\backslash tfrac12$; any failure scores $00$.
2. No bonus for going under. $z_i=0z\_i\; =\; 0$ at or below the reference, so all such attempts get full reward and the model isn't pushed toward terse, brittle reasoning.
3. Gentle, bounded penalty. Exceeding the reference lowers reward smoothly rather than cutting it off.

The reward constrains successful attempts on each task, relative to that task's references. The evaluations below measure effort ordering in aggregate, as means over a benchmark.

(5) Advantage. Mean-centered within each task–effort group, without standard-deviation normalization:

$$A_i=R_i-\frac{1}{\mathrm{\mid }{\mathcal{G}}_{x,e_i}\mathrm{\mid }}\sum _{j\in {\mathcal{G}}_{x,e_i}}{R}_{j}A\_i\; =\; R\_i\; -\; \backslash frac\{1\}\{|\backslash mathcal\; G\_\{x,e\_i\}|\}\; \backslash sum\_\{j\; \backslash in\; \backslash mathcal\; G\_\{x,e\_i\}\}\; R\_j$$

Standard-deviation normalization would inflate small efficiency differences between successful attempts into full-sized updates; mean-centering keeps the penalty proportionate. Effort levels interact only through the references in (3).

Policy update. The policy ${\pi }_{\theta }\backslash pi\_\backslash theta$, a LoRA adapter on C5, is updated once per collection with a clipped policy-ratio objective and rollout importance correction; tool and environment observations are masked from the loss. Details: Appendix A.

Algorithm 1  Effort-ordering GRPO (one collection)
─────────────────────────────────────────────────────────────────
Input: policy π_θ, task batch X, levels E = {L, M, H}
 1: for each task x ∈ X and level e ∈ E:                  ▷ rollout
 2:     run a group of attempts from π_θ(· | x, e); verify each
 3:     G_{x,e} ← admitted (training-eligible) attempts
 4: for each (x, e):                                        ▷ (1)–(2)
 5:     S_{x,e} ← { T_j : j ∈ G_{x,e}, v_j = 1 }
 6:     if |S_{x,e}| ≥ n_min: B_{x,e} ← max(b_min, median S_{x,e})
 7: for each admitted attempt i:                            ▷ (3)–(4)
 8:     if v_i = 0:           R_i ← 0
 9:     elif no ref above e_i: R_i ← 1
10:     else: B_i ← min defined B_{x,e'} over e' ∈ U(e_i)
11:           R_i ← ½ + ½ · φ(max(0, T_i / B_i − 1))
12: A_i ← R_i − mean_{j ∈ G_{x,e_i}} R_j                   ▷ (5)
13: one clipped policy-gradient update of π_θ on admitted attempts

QA-flow: making the reward signal trustworthy

The reward is only as good as the verifier deciding "success." Task and trace reviews found tasks that passed incorrect work and tasks that rejected valid solutions, and either one teaches the model the wrong thing. So alongside RL, I built QA-flow, a task-quality pipeline inspired by RIVER (Learning Generalizable Behaviors for Terminal Agents).

Each stage is handled by a separate agent, so no step grades its own work. Stage-by-stage details: Appendix C.

Training consistency

Before trusting any update, I checked that the training stack preserved how Qwen3.8-27B learns, not just that loss looked similar.

Kernels. In a controlled gradient comparison, Liger SwiGLU matched the reference closely, but Liger RMSNorm changed gradients by ~82% while the reported loss stayed similar.

¹ Relative L2 difference on one fixed 3,944-token input with FP32 output projection. These were diagnostic gradient tests, not optimizer updates, and they apply to the tested input and runtime.

Rollout → trainer. The trainer must receive exactly the tokens and log-probabilities produced during rollouts.

These checks support the tested paths; they don't establish exact agreement across all workloads.

The RL run

Each policy update was trained on a fresh collection of tasks, so these metrics describe training behavior, not held-out checkpoint quality. Collections are grouped by how far through training they fell.

Attempts admitted: share of scheduled attempts that were training-eligible. Pass rate is over admitted attempts, pooled within each range. Reasoning tokens exclude prompt prefill, delimiters, answer text, tool-call bodies and observations.

Pass rate by effort level across training. Bars are 95% confidence intervals; overlapping bars mean differences are within noise.

Reasoning tokens per attempt (left) and per turn (right) by effort level across training.

Reasoning at the lower level divided by the higher level. Above 1.0 is an ordering violation.

Medium stayed under a third of xhigh's reasoning throughout. The low/medium ratio stayed at 1.1–1.25× in every range, so ordering was not reached within training collections, and low's per-turn reasoning eased only slightly (~225 → 205 tokens).

Candidate selection

C5 and three RL checkpoints, named by how far through training they were saved (P20, P70 and P80), were compared on a mixed panel. Within each effort level, every candidate was scored on the same matched set of tasks:

Task sets differ between effort levels, so compare candidates within a level, not across levels. Output tokens include reasoning.

Every RL candidate spent less than C5 at every level, with pass rates within a few points.

• P80: least output and reasoning at medium and xhigh, and the best pass rate at low.
• GPQA Diamond subset (medium): RL candidates used ~40% fewer output tokens than C5 at similar pass rates.

Evaluation

The released checkpoint (Pi) was evaluated against Base on Terminal-Bench 2.1 (89 tasks), GPQA Diamond (198 questions × 4 attempts) and SciCode (80 tasks, 337 subproblems) at low, medium and xhigh. All Pi evaluations used the FP8 weights.

Terminal-Bench 2.1

Terminal-Bench 2.1 is the closest match to how Pi is used: multi-step work in a real terminal. All 89 tasks are scored at each level for Base, C5 and Pi, checking both accuracy ordering and cost ordering.

Accuracy by effort level

Accuracy ordering holds. Pi rises 71.9% → 75.3% → 79.8%, while Base dips at medium. Pi at medium matches Base at xhigh (75.3%) with ~41% fewer output tokens.

Cost by effort level

Cost ordering holds: low is now the cheapest level.

• Pi's low: 36.1k output tokens per task, ~21% less than Base's low and 22% less than C5's.
• Low vs. medium: C5's low cost a third more than its medium; Pi's sits just under (36.1k vs. 37.4k), and medium buys three more solves.
• Xhigh: still the most expensive setting, but ~12% cheaper than Base's.

Ordering before and after RL

Mean reasoning at the lower level divided by the higher level. Above 1.0 is an ordering violation.

RL's main effect here is restoring cost ordering, not raising the score. SFT left low at 1.37× medium's reasoning; RL brought it to 0.97×, near parity but ordered, while keeping medium well under xhigh. Against C5, Pi loses one task at low and gains one at medium and two at xhigh.

Full results

GPQA Diamond

GPQA Diamond is graduate-level science answered through the agent harness, the clearest test of whether more reasoning buys accuracy. Each of the 198 questions was attempted four times per level, comparing Base and Pi.

Accuracy vs. reasoning by effort level

Each arrow steps from low (L) to medium (M) to xhigh (X).

Pi keeps both orderings: each higher level spends more and scores higher, ending at 86.4%, the best result of either model.

• Base violates both: low reasoned slightly more than medium while scoring lower, and xhigh spent the most while scoring lowest.
• Base's edge: a small lead at medium (84.7% vs. 83.7%).

Marginal return per effort level

On Pi, xhigh is where extra reasoning pays off.

• Low → medium: +452 reasoning tokens for +0.8 points.
• Medium → xhigh: about 3× the reasoning for 3.5× the gain, +2.7 points.
• Per point: both steps cost about the same, ~550–600 tokens.

For science questions, medium is a small upgrade; xhigh is worth it when accuracy matters most.

Full results

Question-level pass@4: a question counts as solved if any of its four attempts passed.

SciCode

SciCode asks the agent to implement scientific routines split into test-checked subproblems, so partial credit matters. The panel has 80 tasks and 337 subproblems; the score is the share of subproblems passed, comparing Base and Pi.

Pi scores higher at every level

Pi passes more subproblems at every setting: 37.7 / 46.3 / 48.4% against 36.2 / 42.1 / 45.4%, with more whole tasks too (15 / 19 / 22 vs. 12 / 17 / 21). The biggest gain is at medium, +14 subproblems.

What each solved subproblem costs

Output tokens across all 80 tasks divided by subproblems passed.

Spend divided by what it bought:

• Low: Pi is cheaper per solve (10.4k vs. 11.7k).
• Xhigh: Pi is much cheaper (30.8k vs. 42.8k), solving more with ~23% fewer total tokens.
• Medium: the exception, at ~40% more per solve.

On Pi, low is the budget option, xhigh buys the top score at a large discount to Base, and medium reaches 96% of xhigh's score for ~70% of its tokens.

Full results

An 80-task / 337-subproblem agentic panel, not the official SciCode protocol.

How the behavior differs

Turns spent vs. pass rate

Each arrow steps from low (L) to medium (M) to xhigh (X). Turn scales differ by benchmark.

Pi puts its extra turns where they pay off. At lower effort it works in fewer turns; at higher effort it spends more and converts them into passes.

• Terminal-Bench 2.1: Pi uses fewer turns than Base at low (29.6 vs. 33.7) and medium (33.9 vs. 37.2) while passing more. It spends more only at xhigh (45.1 vs. 43.7), where it gains the most.
• GPQA Diamond: both models answer in about three turns, so Pi's gains come from better reasoning within a turn, not more interaction. Base's extra turns at low and medium don't buy accuracy.
• SciCode: Pi uses fewer turns at low, far more at medium (18.1 vs. 11.5), and the same at xhigh (21.5) with a higher score. Medium is where Pi's extra interaction, and its extra cost, goes.

Deployment formats

FP8

Fine-tuned BF16 weights were converted to block-wise E4M3 FP8 (128 × 128 blocks, one scale each), following the official Qwen3.8-27B FP8 format. The vision tower and other excluded components stay in BF16; the main download is about 30.39 GB.

GGUF

To support local deployment across memory budgets, Pi was converted into 17 GGUF variants spanning ~9–29 GB, including standard K-quants and importance-aware IQ formats.

Calibration. The importance matrix comes from complete agent trajectories across repository work, terminal tasks, scientific coding and question answering, including successes and failures, with state reset between sessions. A separate task-disjoint set measures fidelity.

Fidelity. Teacher-forced perplexity on the held-out trajectories:

Which one should I use?

• 4-bit and above: within ~1% of BF16 perplexity; recommended if it fits.
• 3-bit: ~3–4% higher perplexity.
• 2-bit: ~8–15% higher, and the lowest agent scores below.

Sizes are weights only; leave headroom for the KV cache and context.

Agent smoke test. Eight variants were run as agents at medium reasoning with a 16,384-token output cap on subsets of Terminal-Bench 2.1 (16 tasks), GPQA Diamond (198 questions) and SciCode (175 subproblems across 48 tasks).

Any attempt that didn't pass counts as a failure. Treat this as a smoke test, not a quant ranking: the output cap sits below what SciCode needs, the subsets are small, and rankings didn't follow perplexity.

Limitations

• Student budget. I built this as a student, on rented compute paid for out of pocket, so every stage was sized to what I could afford rather than to what a full study would need. In practice that meant:

  • a shorter RL run with a single training seed, and no reward or hyperparameter ablations;
  • small checkpoint-selection panels and subset evaluations instead of repeated full-benchmark runs.

  The results show what this recipe did at this scale, not where it would plateau with more training.

• Benchmark headroom. Terminal-Bench 2.1 is close to saturated for frontier models, so it has less room to separate strong agents; Pi and Base already pass 70–80% of its tasks. I'd have preferred Terminal-Bench 4.1, but running it at every effort level was beyond my budget. GPQA Diamond and SciCode were added as accompanying evaluations to cover reasoning and scientific coding, where there's more room between models.

• Attribution. Base vs. Pi combines SFT, RL and checkpoint selection. Nothing here isolates the reward as the sole cause of any improvement.

• Efficiency scope. The reward shapes reasoning tokens only. Lower reasoning doesn't guarantee lower total output, fewer tool calls or shorter wall time (Pi's low on TB2.1 was slower than Base's).

• Small panels. Checkpoint-selection and GGUF panels are small; one Terminal-Bench task in the GGUF subset moves the score by 6.25 points.

• Vision and MTP. These components are preserved, not jointly fine-tuned or qualified.

Lessons learned

1. Validation loss was not a good predictor of agent success. Select SFT checkpoints by running them as agents.
2. Pass/fail rewards waste your best groups. When every attempt succeeds, a success-conditioned reference still produces a learning signal.
3. Think before standardizing advantages. For gentle shaping penalties, mean-centering without standard-deviation scaling kept small penalties small.
4. Check gradients, not loss. A fused kernel (Liger RMSNorm, on this setup) matched loss while changing gradients by ~82%.
5. Perplexity was not a good predictor of quantized agent performance, and agent evaluations of quants are sensitive to runtime settings such as output caps.
6. Report results per effort level. Putting reasoning spend beside pass rate at each level is what exposed the ordering violation in the first place.

Future work

Most of these follow directly from the budget limits above: the first two finish what this run started, the third tests whether the recipe transfers, and the last two extend it to deployment.

• A full-scale RL run. This run was sized to my budget. Without compute constraints I'd train for longer, across multiple seeds, with ablations of the reward shaping and the references, to see how the effort-ordering reward affects the policy over a full run: whether ordering holds or keeps improving, and what it does to accuracy at each level.
• Run QA-flow over the entire training pool. Every stage relies on independent agents (auditors, repair agents, designers and solvers), and at current agent API prices I could only afford to run it on part of the pool. Auditing and repairing every task would mean the reward signal rests on reviewed verifiers throughout, not just where QA-flow reached.
• A smaller model through the same pipeline. I'd like to run Qwen3.5-9B through the same SFT, QA-flow and effort-ordering RL process, to see whether a model about a third the size can learn the same effort ordering for agentic work, and to make the result practical on more modest local hardware.
• How the importance matrix affects capability preservation. The GGUF variants were calibrated on complete agent trajectories, but I haven't isolated what that choice does. I'd compare importance matrices built from agent trajectories, generic text and none at all on the same agent evaluations, to see which capabilities calibration protects (tool use, long multi-turn work, reasoning at each effort level) and whether effort ordering survives quantization.
• Training and quantizing the speculative drafters (MTP and DFlash2). Pi keeps the base model's multi-token prediction (MTP) heads as-is, and its DFlash2 companion drafter isn't retrained on Pi's own outputs. Because a drafter only helps when it predicts what the target model will say, both should improve if trained on Pi's long agent sessions. I'd like to fine-tune them for long context lengths, then study how quantization and importance-matrix calibration of the drafters affect acceptance rate, speed and task performance.

Acknowledgements

This release is the culmination of my recent work and experiences. My first fine-tune releases reached more than 740,000 downloads in three months, which I never would have expected. I built the first one as a side project during my third year of college, thinking only a handful of people would ever see it, let alone use it.

Since then, that experience has opened opportunities I never would have imagined, and it laid the groundwork and the motivation for Qwen3.8-27B-pi. To me, this release is proof of how far a stubborn, personal curiosity can take you.

None of this would have been possible without the support of the community, as well as Tongyi Lab for taking the time to highlight the work of an unknown student to hundreds of thousands of people worldwide. Thank you for the overwhelming response and feedback on my first release, and a special thank you to the developers and researchers whose dedication keeps the frontier accessible to all.

References

• Qwen3.6 Pi tune report
• Learning Generalizable Behaviors for Terminal Agents (RIVER)
• Environment Evolution for Terminal Agents

Appendix A: Policy optimization details

At the token level, the core surrogate is

$${\mathrm{\ell }}_{i,t}(\theta )=-\min [{\rho }_{i,t}(\theta )A_i,\mathrm{clip}({\rho }_{i,t}(\theta ),1-ϵ,1+ϵ\left)A_i\right]\backslash ell\_\{i,t\}(\backslash theta)\; =\; -\backslash min\backslash left[\; \backslash rho\_\{i,t\}(\backslash theta)\backslash ,A\_i,\backslash ;\; \backslash operatorname\{clip\}\backslash bigl(\backslash rho\_\{i,t\}(\backslash theta),\backslash ,1-\backslash epsilon,\backslash ,1+\backslash epsilon\backslash bigr)\backslash ,A\_i\; \backslash right]$$

where $ϵ\backslash epsilon$ is the clipping range and ${\rho }_{i,t}\backslash rho\_\{i,t\}$ is the ratio of the trainable policy's probability to the old policy's. Separately, capped token-level rollout importance correction addresses the probability mismatch between serving and training. The loss averages over supervised generated tokens within each trajectory, then over admitted trajectories. Tool and environment observations are excluded.

Although the reward measures reasoning tokens only, the trajectory advantage applies to all supervised model actions, including answers and tool calls. No separate credit is assigned to individual reasoning steps or tool actions.

Each collection produces a single policy update.

Appendix B: SFT checkpoint sweep

Agent pass rate is pooled across low, medium and xhigh. Reasoning tokens are per turn.

Appendix C: QA-flow in detail

QA-flow is an evidence-driven system for turning existing executable tasks into reviewed, repaired, optionally evolved and reproducibly distributed training environments.

RIVER (Learning Generalizable Behaviors for Terminal Agents) argues that in terminal-agent RL, verifier quality determines which behaviors get reinforced. QA-flow applies that idea to an existing task pool in four stages. This stage is related to off-policy environment evolution (Environment Evolution for Terminal Agents), which grows task difficulty along novelty, skill rarity and execution length; QA-flow's evolution targets a different axis, the dependencies between a task's outputs.

1. Audit: a task is a contract

Each task is treated as a contract between its instructions (what the agent is asked to do), its environment (what it can work with) and its verifier (how success is measured). An independent auditor tests both sides of that contract:

• Can incorrect work pass? This catches weak or gameable tests.
• Can a valid solution fail? This catches unclear requirements, missing resources and rules the instructions never state.

Fresh runs add evidence: an untouched workspace must fail, and a valid reference solution must pass.

2. Repair: separate roles, bounded rounds

When the auditor finds a defect, a separate repair agent revises the task and sends it back for re-audit.

• Example: a check that only confirms a file exists becomes one that runs the artifact and verifies its behavior.
• Separate roles: the repair agent only changes; the auditor only judges.
• Bounded and traceable: rounds are capped, every revision and finding is kept, and unresolved findings stay visible instead of being silently passed.

3. Evolve: outputs that must agree

For selected repaired tasks, a designer maps requirements and verifier coverage into a dependency graph, showing which outputs are independent, which share state and which links are actually tested. It then adds links that force coordinated work: a plan, execution log and final report must agree with each other and with the final state.

4. Qualify: finishing evolution is not approval

Evolution can finish with audit findings still open, so completing it doesn't qualify a task. Admission requires all the evidence to agree:

• Evolver and auditor: the new task is implemented, then its rules and verifier are checked independently.
• Reference author: writes an executable solution.
• Solver attempts: independent runs test whether the task is actually solvable.

Admitted tasks keep their lineage and the evidence that admitted them.