PaperlayerView exact revision on arXiv

Source-linked AI summary

CoTrace: Data Recipes for Training Terminal Agents with Harness-Model Co-Evolution

Jixuan Chen, Jiaxin Zhang, Qinyuan Ye, Yada Pruksachatkun, Haoxiang Zhang, Jingming Zhuo, Yifan Zhang, Yutong Dai, Juntao Tan, Xiangyu Peng, Silvio Savarese, Zeyuan Chen, Lianhui Qin, Chien-Sheng Wu

arXiv:2610.10426v1cs.CL

TL;DR

Terminal-agent co-evolution depends on both policy weights and the runtime harness, yet prior approaches leave the trajectory-data interface between their updates largely implicit. CoTrace alternates component updates while routing failures to harness search and matching policy training to the adopted runtime. Runtime compatibility shaped both training gains and external transfer, while the study’s evidence is bounded by a small number of single-run chains.

  • Problem

    Prior co-evolution work often leaves implicit how trajectories should flow between harness adaptation and policy training, although each update changes the conditions for collecting later data.

    Source: §1 · p. 1

  • Method

    CoTrace alternates harness search and policy training, routing failures to harness synthesis and training policies on verified runtime-matched experience or fresh online interactions.

    Source: §1 · p. 2, §2.2 · p. 3

  • Results

    Runtime compatibility shaped gains across training and transfer; on Tmax, CoTrace-SFT advanced Qwen3.5-9B from 78 to 88 solved tasks, while CoTrace-RL reached 90.

    Source: §1 · pp. 2–3

  • Takeaways & Limitations

    The findings identify trajectory provenance and model–harness compatibility as central design variables for terminal-agent post-training.

    Source: §6 · p. 10

    Evidence comes from a small number of single-run chains, one model family at two scales, one loop task source, and two external benchmarks.

    Source: B LIMITATIONS · p. 16

Abstract

from arXiv · show

Terminal-agent capability depends jointly on model weights and the runtime harness that formats prompts, binds tools, and handles error recovery. Existing harness-model co-evolution approaches improve both components, yet often treat trajectories produced during harness search as an undifferentiated replay buffer. This practice overlooks that a trajectory's value for model training depends on the harness under which it was generated. To systematically analyze this interface, we establish an alternating co-evolution framework that decouples harness search and policy training through component-wise promotion decisions. Within this framework, we introduce CoTrace, a harness-aware data recipe that explicitly governs trajectory routing, provenance matching, and curriculum refresh. Under CoTrace, recurring execution failures guide harness synthesis, while policy training is strictly conditioned on verified rollouts matched to the adopted runtime for supervised fine-tuning (SFT) or fresh online interactions for reinforcement learning (RL). On the Tmax promotion split, CoTrace advances Qwen3.5-9B from 78 to 88 solved tasks under supervised fine-tuning while an online reinforcement variant reaches 90. Specifically, a compact harness-matched corpus produces steady model gains at substantially lower compute than much larger corpora pooled across sibling harnesses. Furthermore, evaluations on Terminal-Bench 2.1 and SWE-bench Lite show that out-of-distribution transfer depends fundamentally on harness compatibility, where maintaining consistency between training and evaluation runtimes prevents procedural execution breakdowns observed under foreign scaffolds.

1 INTRODUCTION

Terminal-agent co-evolution couples policy weights with the harness that shapes execution, but prior work leaves the trajectory data shared between their updates largely implicit. CoTrace makes that interface explicit, and its results highlight runtime compatibility as central to policy gains and transfer.

1 INTRODUCTION

  • Policy and harness updates are coupled because each changes the conditions under which later trajectories are collected, making data flow a central co-evolution question.Terminal agents combine a language-model policy with a harness that formats prompts, binds tools, manages context, and recovers from execution errors.Source: §1 · pp. 1–2
  • Runtime compatibility governs model gains: CoTrace-SFT advances Qwen3.5-9B from 78 to 88 solved tasks on the Tmax promotion split, while CoTrace-RL reaches 90.The recipes pair verified, adopted-harness-matched demonstrations with fresh rollouts for SFT, or use fresh online interactions for RL.Source: §1 · pp. 2–3
  • CoTrace explicitly governs trajectory routing, provenance matching, and curriculum refresh, with component-wise promotion decisions separating harness and model updates.Recurring execution failures guide harness synthesis, while policy supervision uses verified successes matched to the adopted runtime.Source: §1 · pp. 2–3
  • A compact harness-matched corpus uses 30–50 trajectories for consistent gains, while pooling 149–308 sibling-harness successes yields zero accepted model updates.The matched recipe has the lowest reported per-iteration training cost: 47 GPU-hours.Source: §1 · p. 2
  • On Terminal-Bench 2.1 and SWE-bench Lite, out-of-distribution transfer depends on the co-evolved model–harness pair, with runtime compatibility suppressing early execution faults and no-patch failures.The reported runtime consistency avoids execution breakdowns associated with foreign scaffolds.Source: §1 · p. 3

2 METHOD

The method treats terminal-agent learning as alternating optimization over policy weights and an execution harness, coupled through the trajectories each update produces. CoTrace coordinates that exchange through routing, component-wise promotion, and curriculum refresh.

2.1 PROBLEM FORMULATION: MODEL–HARNESS CO-EVOLUTION

  • Terminal-agent learning alternates harness and policy updates, with each step producing trajectories that supply data to the next.The task objective evaluates verified terminal outcomes under the rollout distribution induced by the policy–harness pair.Source: §2.1 · p. 3

2.2 COTRACE: DATA RECIPE FOR CO-EVOLUTION

  • CoTrace replaces undifferentiated replay with Route, Ratchet, and Refresh over a versioned trajectory bank.The operations separate failure evidence for harness synthesis, matched successes for policy training, component attribution, and frontier progression.Source: §2.2 · p. 3

2.2.1 ROUTE: SEPARATE EVIDENCE FOR EACH OPTIMIZER

  • Route clusters runtime failures for harness synthesis and restricts policy demonstrations to verified, well-formed examples matched to the adopted runtime.CoTrace-SFT prioritizes current successes, bounds historical replay and repeated task examples, and adds fresh rollouts when coverage is insufficient; CoTrace-RL instead uses fresh on-policy rewards under the adopted harness.Source: §2.2 · p. 3, §2.2.1 · p. 4

2.2.2 RATCHET: ISOLATE AND PRESERVE COMPONENT GAINS

  • Ratchet evaluates each candidate with the complementary component fixed and promotes it only when newly solved tasks exceed newly broken tasks on the frozen split.Accepted increments are attributed to the component changed; rejected policy candidates prompt collection of new experience for the next attempt.Source: §2.2.2 · pp. 4–5

2.2.3 REFRESH: TRACK THE LEARNING FRONTIER

  • Refresh retires tasks only after they are solved and their verified trace is harvested, then replenishes the evolve set from a reservoir.For online reinforcement, which has no persistent corpus, behavioral success alone determines retirement.Source: §2.2.3 · p. 5

3 EXPERIMENTS

The experiments compare harness and policy contributions on Tmax at two model scales, then test which data recipes produce accepted model updates. At 9B, CoTrace-SFT reaches 88 solved tasks and CoTrace-RL reaches 90, while a smaller harness-matched corpus yields accepted model gains where pooled sibling-harness data does not.

3.1 SETUP

  • The setup uses disjoint Tmax promotion, rotating evolve, and reservoir splits, with external transfer tests on Terminal-Bench 2.1 and SWE-bench Lite.Candidates are evaluated with the counterpart component held at its best-so-far incumbent, isolating the marginal effect of one component.Source: §3.1 · p. 5

3.2 MAIN CO-EVOLUTION RESULTS

  • On the 102-task Tmax promotion split, CoTrace-SFT reaches 88 from 78 and CoTrace-RL reaches 90; mixed-siblings reaches 86 with no accepted model gain.CoTrace-SFT’s cumulative gains are +4 from harness updates and +6 from model updates; CoTrace-RL’s are +5 and +7, respectively.Source: Table 1 · p. 6, §3.2 · p. 6
  • At 4B, CoTrace-SFT reaches 69 from 65 entirely through harness updates, while reinforcement moves from 67 to 79 entirely through model updates.All three CoTrace-SFT model updates and every reinforcement harness candidate are rejected.Source: §3.2 · p. 6

3.3 DATA RECIPES AND MODEL-SIDE UPDATES

  • Under controlled 9B tournament search, mixed-siblings supplies 149–308 trajectories per iteration but yields no accepted model update, while 30–50 winner-only + SFT-gen trajectories yield two accepted updates totaling +6.The recipes differ in multiple construction choices, and their trajectory counts do not translate into a five-fold difference in training examples or gradient compute.Source: §3.3 · p. 7, Table 2 · p. 7

4 ANALYSIS

The analysis finds that transfer depends on the runtime paired with a checkpoint, while useful model updates depend on trajectory construction and training regime. Across co-evolution chains, harness and model gains can contribute at different stages, and the moving curriculum becomes harder as solved tasks retire.

4.1 RQ1: HOW DO THE TWO OPTIMIZATION CHANNELS CONTRIBUTE OVER A CO-EVOLUTION CHAIN?

  • In the CoTrace-SFT chain, a model update and subsequent harness update each contribute +4; the cross-evaluation finds the gains additive, with I = 0.Across the two CoTrace chains, only 9 of 17 search-winning harness candidates improve the promotion split.Source: §4.1 · pp. 7–8, Table 3 · p. 8
  • As solved tasks retire, the evolve set hardens while promotion scores rise: one chain moves from 34 to 26 to 17 of 50 evolve tasks against 75 to 81 to 83 of 102 promotion tasks.The authors interpret late-stage deterioration as curriculum saturation rather than a limit of either optimizer.Source: Figure 3 · p. 7, §4.1 · p. 8

4.2 RQ2: WHICH TRAJECTORY ATTRIBUTES PRODUCE USEFUL MODEL UPDATES?

  • With tournament search and training protocol held constant, 149–308 mixed-siblings trajectories yield zero accepted model updates, whereas 30–50 winner-only + SFT-gen trajectories yield +6 through two installed updates.At 4B, sparse clean successes leave offline imitation without an accepted update, while online reinforcement moves the same policy from 67 to 79.Source: §4.2 · pp. 8–9

4.3 RQ3: HOW DOES THE HARNESS SHAPE CROSS-DOMAIN TRANSFER?

  • On SWE-bench Lite, pairing checkpoints with their adopted harness improves every resolved-rate result; SFT rises from 24.7% to 35.0%, while its no-patch outcomes fall from 155 to 64.On Terminal-Bench 2.1 under the baseline harness, the supervised checkpoint’s 18.3 ± 2.5 tasks solved is near the base model’s 18.7 ± 1.5, within trial variation.Source: §4.3 · p. 9, Figure 5 · p. 9

5 RELATED WORK

Prior work has optimized agent scaffolds and policies jointly or separately, while post-training data strategies include verified self-training, curated data, on-policy sampling, and adaptive curricula. CoTrace makes trajectory routing, runtime provenance matching, and curriculum scheduling explicit for co-evolving systems.

Harness evolution and model–harness co-evolution

  • Agent-system optimization progressed from prompt and pipeline tuning to executable scaffold search, and terminal-agent studies optimized tools, observations, prompts, and recovery under frozen policies.Recent systems also jointly update policies and harnesses, but their trajectory routing remains implicit in contrast to CoTrace.Source: §5 · p. 9

Data recipes for agent post-training

  • Post-training data selection spans verified self-training, rejection sampling, compact curated datasets, on-policy sampling, and adaptive task curricula.These approaches commonly assume a static runtime, leaving rollout conditions and provenance fixed.Source: §5 · pp. 9–10
  • Because co-evolution changes the runtime during training, compatibility and provenance become part of data selection; CoTrace explicitly filters, matches, and schedules trajectories.This distinguishes its focus from data strategies designed around a fixed execution runtime.Source: §5 · pp. 9–10

6 CONCLUSION

CoTrace treats trajectory provenance and model–harness compatibility as central to post-training, within an inspectable co-evolution framework. The related work distinguishes this approach from frozen-weight harness search and co-evolution methods that consume trajectories as a single buffer.

6 CONCLUSION

  • CoTrace routes failures to harness search, trains on verified runtime-matched experience, refreshes the curriculum, and promotes model and harness components independently.Across supervised and reinforcement chains, compact matched corpora yielded gains where larger sibling-pooled corpora did not; runtime choice also shaped checkpoint performance.Source: §6 · p. 10

A.1 HARNESS AND SCAFFOLD OPTIMIZATION WITH FROZEN WEIGHTS

  • Frozen-weight harness optimization reports performance conditional on a fixed policy and does not examine the training value of search trajectories; CoTrace adds promotion-tested model updates.Those updates change the failure distribution the next harness search must explain.Source: §A.1 · p. 15

A.2 MODEL–HARNESS CO-EVOLUTION AND SELF-IMPROVING AGENTS

  • Prior co-evolution systems generally treat trajectories between optimizers as one buffer, while CoTrace focuses on which trajectories train the model, under which harness, and when.The paper holds search, trainer, and promotion rule fixed while varying the data construction.Source: §A.2 · p. 15

A.3 DATA RECIPES FOR AGENT POST-TRAINING

Agent post-training commonly uses verified successes as supervised data, but these recipes generally keep the harness fixed. CoTrace instead conditions training data on the runtime provenance that changes during co-evolution.

A.3 DATA RECIPES FOR AGENT POST-TRAINING

  • The dominant agent-training recipe turns a model’s verified successes into supervised data, often followed by reinforcement learning against verifiable rewards.Prior work also studies outcome filtering, per-task caps, on-policy samples, compact corpora, and frontier-driven curricula.Source: §A.3 · pp. 15–16
  • With a changing harness, a trajectory can shift from on-distribution to off-distribution because it is matched to the model–harness pair that generated it.Earlier recipes hold the harness fixed during training, so provenance is not a variable they condition on.Source: §A.3 · p. 16
  • The recipe keys data to the deployed harness fingerprint, prioritizes current data with capped history, and retires tasks after they are solved and harvested.In the reported comparison, larger sibling-harness-pooled corpora yield no accepted model gain, while the smaller harness-matched recipe does.Source: §A.3 · p. 16

B LIMITATIONS

The study’s evidence is limited by single-run chains, evaluation variability, and a narrow set of models, task sources, and runtimes. Its experimental setup uses disjoint task roles and a rotating curriculum, with chain results reported under explicit comparison rules.

B LIMITATIONS

  • Each co-evolution chain runs once, and single evaluations vary by roughly ±2 tasks; one- or two-task differences between chains should not be read as rankings.The study covers one model family at two scales, one loop task source, and two external benchmarks; SFT and RL were not compute-matched, and harness search uses a proprietary meta-agent.Source: B LIMITATIONS · p. 16

C EXPERIMENTAL SETUP

  • The workflow alternates harness search, verified trajectory generation, SFT or RL, and a model update that starts the next harness-search round.A meta-agent searches for an improved harness, which the task agent then executes.Source: Figure 6 · p. 16

C.1 CHAIN PROTOCOL AND REPORTING RULES

  • A chain runs from a fixed anchor through outer iterations and reports its anchor and final incumbent; within-chain stage changes are more trustworthy than cross-chain absolute scores.Scores are pass counts on the frozen 102-task Tmax promotion split, and ties require a clean candidate evaluation.Source: §C.1 · p. 17

C.2 TASK POOL AND SPLITS

  • The loop separates a 50-task rotating evolve set, a frozen 102-task promotion split, and a refill reservoir; task identifiers are checked to prevent overlap with promotion.Usable Tmax tasks require a natural-language description, final-state test, and buildable container definition.Source: §C.2 · p. 17, Table 4 · p. 17

C.3 CURRICULUM ROTATION AND EXECUTION LIMITS

  • Curriculum rotation retires solved tasks and refills the evolve set, deliberately making the refreshed set harder; runs abort if fewer than 20 tasks remain.One measured rotation kept 14 unsolved tasks, drew 36 new ones, and lowered the refreshed set’s baseline pass rate to 0.40.Source: §C.3 · p. 17

C.4 COMPUTE AND COST PER LEVER

Evaluation and harness search dominate much of the chain cost, while the gradient step is small; the paper argues that data routing adds little cost relative to the surrounding loop. Single-evaluation variation motivates paired, within-chain comparisons.

C.4 COMPUTE AND COST PER LEVER

  • The harness-only 9B chain costs 25 GPU-hours overall and 6 GPU-hours per installed task; reinforcement reaches a peak at 21 GPU-hours per task and costs 35 once regression is counted.The retry-enabled chain spends 51 GPU-hours per task, while the mixed-siblings chain costs 18.Source: §C.4 · p. 18
  • Harness search accounts for 14–57% of chain cost and promotion or stage evaluations for 37–57%, while the gradient step accounts for 4%.The reinforcement stage accounts for 63% where run, and SFT-generation top-up for 2–35%.Source: §C.4 · p. 17, Table 5 · p. 18

C.5 REPRODUCIBILITY AND EVALUATION NOISE

  • Single-evaluation noise is roughly ±2 tasks, with a worst observed excursion of five tasks, motivating paired within-chain analysis.Accepted harness configurations are released for each iteration so promotion evaluations can be reproduced without rerunning search.Source: §C.5 · p. 18

C.6 HYPERPARAMETERS

  • Table 6 lists the search, corpus-construction, training, and promotion settings, while the reinforcement-stage settings correspond to Figure 2(b) and its rollout budget is in Table 15.The supplied configuration descriptions identify where these settings are reported, but do not state their individual values.Source: §C.6 · p. 18, Table 6 · p. 19

D METHOD DETAILS

This section details CoTrace’s operational workflow, trajectory routing and refresh, policy updates, harness-search safeguards, and the runtime and prompts used to constrain harness and policy behavior. It also documents promotion decisions and evaluation variability, including how outcomes depend on model–harness pairing and policy scale, to qualify which trajectories and runtime configurations support reliable gains.

D.1 CO-EVOLUTION LOOP IN PSEUDOCODE

  • CoTrace keeps the promotion split disjoint and evaluates component changes with the other component fixed, routing matched verified successes to SFT or fresh rollouts to online RL.The SFT recipe uses completion-only LoRA updates with retries on rejection; the RL recipe samples 100 tasks, scores grouped online rollouts with binary verifiers, and uses outcome-only rewards.Source: §D.1 · pp. 19–20

D.2 CURRICULUM REFRESH AND BASELINE RECIPES

  • The curriculum retires tasks only after incumbent success and verified training inclusion, then replenishes the evolve set to 50 through domain-stratified sampling.All-evolve pools search successes without fingerprint conditioning, whereas Mixed siblings pools verified successes across tournament candidates at an expanded per-task cap while retaining exploratory prompts.Source: §D.2 · p. 21

D.3 BASELINE HARNESS CONFIGURATION

  • The hand-written HarnessX scaffold is a manually tuned baseline, and harness search can edit its processors, tool registry, and system-prompt file but not evaluator, sandbox, or tracer.The paper cautions that measuring gains against a thin scaffold would roughly double the apparent effect.Source: §D.3 · p. 21

D.4 SCREENS AND ADMISSIBILITY CHECKS IN HARNESS SEARCH

  • Harness candidates pass heuristic ranking, predicted-impact scoring, and probe screens, followed by checks for valid configuration, processor behavior, hook contracts, evidence, and replay.Screens fail open on errors, preserve candidates affected by infrastructure faults without penalty, and log each rejection; probes drop candidates that break more than one parent-solved task.Source: §D.4 · p. 22

D.5 FAILURE ATTRIBUTION AND ROUTING

  • The router attributes the earliest unrecovered failure, quarantines low-confidence classifications, and excludes environment and grader faults from both training and search evidence.A failed tool observation counts as recovered if a later observation for the same command family succeeds; wrapper or unsurfaced errors and repeated actions receive different prescriptions despite indistinguishable reward.Source: §D.5 · p. 22, Table 7 · p. 23

D.6 PROMPTS AND META-AGENT BRIEFS

  • Training examples carry the system prompt associated with their generating harness, while RL rollouts must follow the trainer’s one-bash-call format preceded by a reasoning section.The SWE-bench Lite transfer prompt likewise requires exactly one bash command in its specified block; format violations can produce errors and, after repeated misses, an empty patch.Source: §D.6 · pp. 23–25
  • Meta-agent briefs anchor sibling proposals to failures and require reusable, non-task-specific mechanisms, while synthesis combines complementary pivot mechanisms and resolves conflicts.The brief requires a failure cluster, causal mechanism, exact patch, predicted affected tasks, and rollback condition; generalization requires checking other trajectories when available and avoiding task-specific triggers.Source: §D.6 · pp. 23–24

E.1 PROMOTION LEDGER OF EVERY CHAIN

  • In the 9B reinforcement chain, the first three checkpoints improved the incumbent and were installed, while the fourth scored below it and was rejected.Table 8 presents the promotion ledger in decision order, including harness and model candidate decisions.Source: §E.1 · p. 25, Table 8 · p. 26

E.2 SEQUENTIAL-SEARCH CHAINS

  • The two pre-tournament sequential-search 9B chains gained mostly through model updates, showing pooled trajectories can support accepted updates when rejected sibling harnesses do not dominate the pool.These chains use the all-evolve recipe and are not controlled comparisons with tournament-search rows.Source: §E.2 · pp. 25–26, Table 9 · p. 26

E.3 CORPUS MANIFESTS

  • The 4B winner-only chain trained on just 2, 3 and 2 matched trajectory sets across its iterations, below the top-up floor.The corpus manifests behind Table 2 are listed in Table 10.Source: §E.3 · p. 26, Table 10 · p. 27

E.4 PAIRED RECORDS OF THE REINFORCEMENT LINE

  • Paired records show evaluation churn beneath small net changes: fourteen tasks flipped for zero net at the first harness stage, and twenty-three flipped for a net gain of four at the second reinforcement stage.Paired comparisons use promotion evaluations, whereas plotted stage scores come from separate executions; one-to-two-task differences reflect single-evaluation noise.Source: §E.4 · pp. 26–27, Table 11 · p. 27

E.5 SWE-BENCH LITE UNDER BOTH HARNESSES

  • Promoted edits transferred as general execution safeguards: loop and repeated-command breakers (53%), budget and self-verification guards (26%), and dependency guards (21%).The official SWE-bench harness graded every arm; co-evolved rates are floors by at most one point because unresolved patch-apply and hanging-test errors remained.Source: §E.5 · pp. 27–28
  • Under adopted HarnessX pairs, reinforcement beat base by 31 wins to 20 losses and supervised by 36 to 18; versus supervised p = 0.02, while mini-swe-agent’s 6-instance margin over base was nonsignificant (p = 0.52).The paired-instance analysis treats each co-evolved model–harness configuration as the evaluated system; under mini-swe-agent, the checkpoints resolve 54.2%, 51.0% and 50.9% of instances conditional on reaching the verifier.Source: §E.5 · p. 27, Table 12 · p. 28

E.6 CHAINS AT OTHER POLICY SCALES

  • Policy scale bounded model-channel productivity: the 2B chain anchored at 10 with essentially no successful trajectories, while the 27B chain anchored at 97/102 near the split ceiling.At 4B, the winner-only chain moved from 65 to 69 after installing a +4 harness, but rejected model updates scored -5, -5 and -6; other 4B chains also show that the model channel did not move at this scale.Source: §E.6 · p. 28

E.7 ROUND-LEVEL TRACES AND THE PROMOTION ABLATION

The traces show why promotion must separate harness and model changes: it preserves scaffold gains amid noisy candidates, while training outcomes also depend on corpus matching and curriculum state. Accepted harness edits concentrate on control processors, and the reward-path debugging record shows how a data-path defect can appear to be a capability bottleneck.

E.7 ROUND-LEVEL TRACES AND THE PROMOTION ABLATION

  • Only 9 of 17 harness candidates improved the promotion split, with a mean effect of +0.18 tasks; evolve-set search wins did not guarantee promotion gains.The authors hypothesize that a model update can internalize early procedural patterns before harness search targets a smaller residual.Source: §E.7 · pp. 28–29
  • 26.7% →0.0% without component-wise promotion versus a 23–29% band with promotion on the 4B evolve set shows promotion retaining a working scaffold.The mixed-siblings chain’s harness won twice (+6, +3), while every model update was rejected.Source: §E.7 · p. 28, Figure 7 · p. 29

E.8 DETAILS BEHIND THE ANALYSIS

  • In the CoTrace-SFT transition, the model and harness each added +4, and the harness gained +4 under either policy (I=0).The base policy under the updated harness scored 82, supporting additivity for this transition.Source: §E.8 · p. 29
  • By one chain’s fourth iteration, 32 of 50 evolve tasks were carried-over failures; another iteration retired 40 of 50 tasks at once.At the same point, the success-filtered corpus covered 96 unique tasks, only 14 from the current evolve set.Source: §E.8 · p. 29
  • At 9B, mixed-sibling model updates scored −2, −2, and −4 tasks, while matched-corpus supervised updates scored +4 and +2.At 4B, the CoTrace-SFT chain’s three updates scored −5, −5, and −6.Source: §E.8 · p. 29

E.9 ACCEPTED AND REJECTED HARNESS EDITS

  • Accepted harness edits were 53% loop or repeat breakers, 26% budget or self-verification guards, and 21% dependency guards; no added tool was accepted.The two highest-scoring harnesses retained the stock prompt and reached 86 using control processors alone.Source: §E.9 · p. 30

F.1 OPTIMIZER AND DEPARTURES FROM TMAX

  • The 9B RL stage retained DPPO’s core but used 8 rollouts per prompt, 2-step asynchrony, β=0.01, and 16K responses, collecting online under the adopted harness.The regime used a budget of 2,304 episodes per stage and sampled from the evolving task frontier.Source: §F.1 · p. 30

F.2 REWARD-PATH DEBUGGING RECORD

  • Increasing the response budget cut truncation from 0.88 to 0.00 without submissions; fixing the prompt schema and sandbox directory made reward non-zero.The task template and submission instruction had been absent from the policy’s input.Source: §F.2 · pp. 30–31

F.3 OUTCOME AND SETTINGS OF THE REINFORCEMENT LINE

The reinforcement line raised the model–harness pair’s promotion-split score from 78 to 90 before a later round regressed. It achieved these gains with substantially fewer episodes and a smaller compute setup than the reference recipe.

F.3 OUTCOME AND SETTINGS OF THE REINFORCEMENT LINE

  • 78 →90 on the promotion split: alternating reinforcement and harness updates added +5 through the harness and +7 through the weights before a later round regressed to 85.The run used 2,304 episodes on 100 tasks on a single node, compared with roughly 128k episodes across eight nodes in the reference recipe.Source: §F.3 · p. 31
  • The reinforcement line’s task plane came from the taxonomy and was disjoint from the promotion split.Frontier exploration reserved a fixed fraction of each round for tasks the current pair had not solved.Source: Table 15 · p. 31

G.1 ROUTING PILOT ON TERMINAL-BENCH 2.1

The routing pilot compared corpus-selection strategies at equal corpus size on a small Terminal-Bench 2.1 evaluation. A separate case study illustrates grounded harness edits but is not part of the terminal-task record.

G.1 ROUTING PILOT ON TERMINAL-BENCH 2.1

  • 6.00 for capability-routed selection exceeded 4.33 for taxonomy-balanced selection and 4.00 for an undifferentiated mix at equal corpus size.The pilot used Qwen3.5-9B with the baseline harness on 15 tasks, averaging 3 runs.Source: §G.1 · pp. 31–32, Table 16 · p. 32

G.2 CASE STUDY OF GROUNDED HARNESS EDITS

  • The four-edit case study used a different policy family and was not part of the terminal-task record; every diagnosis was correct, but not every intervention helped.Source: §G.2 · p. 32, Table 17 · p. 32
Loading 2610.10426v1…