SWE-Protégé: Collaborative Software-Repair Framework

• SWE-Protégé is a framework that post-trains small language models to act as software-repair agents while selectively consulting stronger expert models.
• It employs a two-phase pipeline—supervised fine-tuning on expert-augmented trajectories followed by reinforcement learning—to mitigate looping and enhance multi-turn decision making.
• The system achieves near-expert performance with sparse expert calls, improving Pass@1 results on SWE-Bench while reducing token usage and cost.

Searching arXiv for the specified paper to ground the article and citation. arxiv_search query="(Kon et al., 25 Feb 2026) SWE-Protégé" max_results=5 SWE-Protégé is a post-training framework for software-repair agents in which a small LLM is trained to operate as a “protégé” that selectively collaborates with a stronger “expert” model while remaining the sole decision-maker throughout the interaction loop. It targets long-horizon software engineering tasks in the SWE-Bench style, where small LLMs have historically lagged behind larger systems because of pervasive action looping and low resolution rates. The framework combines supervised fine-tuning on expert-augmented trajectories with agentic reinforcement learning that discourages degenerative looping and unproductive expert collaboration. In the reported instantiation, Qwen2.5-Coder-7B-Instruct is lightly post-trained to reach 42.4% Pass@1 on SWE-bench Verified, with sparse expert usage of approximately 4 calls per task and about 11% of total tokens (Kon et al., 25 Feb 2026).

1. Problem setting and formalization

SWE-Protégé is defined in the standard multi-turn software-repair setting, where an agent state $s \in \mathcal S$ includes the prompt, interaction history, tool outputs, and related context, and where each turn selects an action $a \in \mathcal A$ such as a shell command or a file edit. A trajectory is written as $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$ and terminates when the interaction ends; success is judged by external verification through unit tests (Kon et al., 25 Feb 2026).

The central reformulation is to cast software repair as a learned expert–protégé collaboration problem by extending the action space to include expert consultation:

$$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$

When the agent emits ${\tt ask\_expert}$, it poses a natural-language question to a strong expert LLM, which returns guidance $g$ that is appended to the agent state. The protégé remains the only policy that actually selects actions, including expert calls:

$$\pi_\theta(a\mid s)\;=\;p_\theta\bigl(y=a\mid s\bigr).$$

This formulation is technically significant because it does not outsource control to the expert. The expert provides textual guidance, but the protégé continues to choose every subsequent tool invocation and every further expert request. A plausible implication is that the framework is designed not as delegated execution, but as learned help-seeking under a single policy.

2. Agent architecture and collaborative decision process

SWE-Protégé is implemented under SWE-Agent’s ReAct scaffold, where at each step the protégé emits a “thought” and an “action.” All actions, including ${\tt ask\_expert}$, are sampled from the same small-model call rather than through a separate routing mechanism (Kon et al., 25 Feb 2026).

A key architectural detail is the asymmetry between the protégé’s context and the expert’s context. The protégé always conditions on the full state $s$, whereas the expert only receives a truncated compact context $\tilde s$ consisting of the most recent $a \in \mathcal A$0 turns. At inference time, when the protégé emits $a \in \mathcal A$1, the controller packages $a \in \mathcal A$2 together with the question into a system-plus-user prompt for the expert LLM, which returns a short guidance string $a \in \mathcal A$3. That guidance is then appended to the main state and is never elided by history processors.

The absence of a hard-coded gating function in Phase I is an important design choice. Expert invocation is instead learned implicitly through imitation during supervised fine-tuning and then refined through reinforcement learning. During reinforcement learning, however, the framework does introduce reward gating to prevent correctness signals from obscuring pathological looping or failure to act on expert advice. The trajectory-level reward is

$a \in \mathcal A$4

with $a \in \mathcal A$5.

This structure distinguishes learned collaboration from naive escalation. The expert is neither a fallback solver nor an omniscient controller in the action loop; instead, the protégé must learn when expert guidance is warranted, how to incorporate it, and when further requests are unproductive.

3. Two-phase post-training pipeline

Phase I is supervised fine-tuning on synthetic expert-augmented trajectories. These trajectories are generated with a strong LLM $a \in \mathcal A$6—specified as Claude Sonnet 3.7—acting both as agent and as expert, while having access to the gold patch but being explicitly barred from revealing it verbatim. The process yields approximately 4.8K successful trajectories containing sparse $a \in \mathcal A$7 calls. Qwen2.5-Coder-7B-Instruct is then fine-tuned by standard next-token cross-entropy:

$a \in \mathcal A$8

The reported hyperparameters are a 32K maximum sequence length, batch size 32, and full-parameter fine-tuning; LoRA and QLoRA were tried but underperformed (Kon et al., 25 Feb 2026).

Phase II applies on-policy agentic reinforcement learning starting from the supervised checkpoint. The optimization uses a GRPO-style objective. For each prompt $a \in \mathcal A$9, the system samples $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$0 rollouts and maximizes

$\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$1

where $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$2, $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$3, $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$4, and $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$5 is the group-normalized rollout reward. Training is run on 100 tasks from a SWE-Gym subset for 160 steps, with 6 rollouts per prompt and batch size 16, using a single node with 8 A100/H100 GPUs under SkyRL.

The overall training pipeline can be summarized as follows:

Stage	Core operation	Reported configuration
Phase I	SFT on expert-augmented trajectories	$\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$6K trajectories, seq len 32 762, batch 32
Phase II	On-policy GRPO-style RL	100 tasks, 6 rollouts/prompt, batch 16, 160 steps
Inference	SWE-agent + expert interaction	75 step limit, $2 cost budget, max 6 expert calls

In methodological terms, the two-phase design separates induction of expert-use behavior from optimization of long-horizon collaborative behavior. This suggests that sparse consultation alone is not the target; the target is robust pair-programming behavior under tool use, verification, and budget constraints.

4. Reward shaping, loop suppression, and follow-through

The reinforcement-learning stage uses a composite rollout reward comprising correctness, a similarity fallback, a loop penalty $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$7, an expert-deferral quality term $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$8, and a follow-through term $\tau=(s_0,a_0,o_1,s_1,a_1,\dots)$9 (Kon et al., 25 Feb 2026). The loop penalty is sharpened once repeated-command streaks exceed thresholds $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$0 and $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$1:

$$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$2

with $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$3 and, in Stage I, $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$4.

The expert-related terms are designed not merely to reward asking for help, but to shape the quality of help-seeking and the quality of response utilization. The expert term uses the expert’s warranted scores $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$5 and includes anti-spam penalties for back-to-back calls. The follow-through term uses scores $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$6. Over multiple turns, the protégé is trained to follow the expert’s actionable suggestions in $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$7 and to “report back” by referencing the prior guidance before issuing a new expert request. Successful follow-through yields a high $$\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$$8 score.

This reward design addresses a specific failure mode of small models on software-repair benchmarks: repetitive, low-yield action loops. The paper reports that reward gating is introduced so that correctness signals do not mask pathological looping or poor follow-through. A plausible implication is that the framework treats competent collaboration as a temporally extended behavioral property rather than a single-step decision problem.

5. Empirical performance and efficiency profile

On SWE-Bench Verified, described as 500 real-repo tasks with no test-time sampling, the reported Pass@1 results are as follows (Kon et al., 25 Feb 2026):

System	Pass@1	Relative note
SWE-agent-LM-7B	17.0%	Baseline open-weight SLM
SWE-Protégé-7B + Sonnet 4.5	41.0%	+24.0 pp
SWE-Protégé-7B + Opus 4.1	42.4%	+25.4 pp
SWE-agent-LM-32B	40.2%	Prior SOTA open-weight

The reported best setting, SWE-Protégé-7B with Opus 4.1 as expert backend, reaches 42.4% Pass@1. The expert remains sparse in use, at approximately 4 calls per task, and expert tokens account for approximately 11% of total tokens. Phase II reinforcement learning is reported to cut total tokens by approximately 40%, attributed to elimination of loops. In cost terms, per-task expert-token cost drops by up to 8.2× relative to direct expert-only solving, while accuracy is described as near-expert.

The reported gains from reinforcement learning over the pure-SFT checkpoint are consistent across expert backends: +1.2 percentage points with Sonnet 3.7, +6.2 percentage points with Sonnet 4.5, and +2.8 percentage points with Opus 4.1. These results indicate that performance improvement is not solely a consequence of supervised imitation; the RL phase contributes additional gains, particularly when collaboration quality and loop control materially affect long-horizon execution.

A common misconception in this area is that small models benefit from stronger models only through dense delegation. The SWE-Protégé results do not support that characterization. Instead, the reported system attains its best performance with sparse expert interaction and with the small model remaining the sole decision-maker.

6. Ablations, reproducibility, and broader implications

The ablation analysis isolates several design dependencies. Loop detection with forced escalation, labeled the “Loop heuristic,” helps only when the expert sees full context; otherwise performance does not improve. Passive or fixed-interval escalation underperforms, with reported values between 19.6% and 24.2%, which the paper interprets as evidence for the necessity of learned expert invocation. “In-place” insertion of expert calls into existing SWE-smith traces yields only 14.2%, supporting the claim that coherent, freshly generated expert-augmented data are essential. In-house experts, including SWE-Protégé-7B and SWE-Protégé-32B variants fine-tuned on the same data, underperform frontier Sonnet and Opus backends, although larger in-house experts help modestly (Kon et al., 25 Feb 2026).

The RL ablations further separate the roles of the two shaping stages. Stage I alone eliminates looping, described as driving the loop reward to 0, but yields only marginal accuracy gains. Stage II, which combines loop and follow shaping, is reported as necessary to instill true multi-turn collaboration and to unlock the bulk of the Pass@1 improvements. This suggests that nontrivial software-repair gains depend not only on avoiding pathological repetition but also on learning how to incorporate external guidance over multiple turns.

The reproducibility notes specify the main implementation envelope: a single node with 8× A100/H100 80 GB GPUs; base model Qwen-2.5-Coder-Instruct–7B; inference through vLLM; an off-the-shelf SWE-agent scaffold with a 75-step limit, $\mathcal A' \;=\;\mathcal A\;\cup\;\{\tt ask\_expert\}.$9u_i${\tt ask\_expert}$0f_i$. History processors are modified to never elide expert guidance.

In broader context, SWE-Protégé occupies a specific position within software-engineering agents: it is neither a pure small-model baseline nor an expert-only solver. Its contribution is the learned selective-collaboration regime. A plausible implication is that the framework may be most relevant where cost, latency, and adaptability favor small models, but where long-horizon software tasks still require intermittent high-quality guidance.