Reinforcement learning demonstrates state-of-the-art results on software engineering tasks¹ ², yet it presents significant infrastructure challenges beyond simple compute scale. It requires complex MLOps workflows, including simultaneous stages of inference (collecting traces from the latest policy) and training (updating the policy) that typically require asynchronous setups for efficiency, as well as fine-grained experimentation to resolve instabilities and achieve high performance.

In contrast, behavioral cloning and model distillation, where models learn directly from curated demonstrations, require only standard supervised fine-tuning (SFT) pipelines and serve as a powerful baseline. Among these approaches, rejection fine-tuning (RFT) has proven particularly effective: by training on successful trajectories filtered from multiple solution attempts, RFT captures high-quality behavior without the infrastructure overhead of RL.

While our research primarily focuses on RL, given the strong performance of RFT, we are contributing our accumulated trajectories to support this approach. To expand the set of available datasets containing multi-turn trajectories based on open-source scaffoldings and models, we release nebius/SWE-rebench-openhands-trajectories: 67,074 agent trajectories solving GitHub issues across 1,823 Python repositories from SWE-rebench. The trajectories were generated using Qwen3-Coder-480B-A35B-Instruct³ running on OpenHands (v0.54.0)⁴, one of the most widely adopted open-source agent scaffolding frameworks.

To demonstrate the dataset’s utility, we release RFT checkpoints at two scales:

• 30B (fine-tuned from Qwen3-30B-A3B-Instruct-2507³): Matches the specialized Qwen3-Coder-30B-A3B-Instruct at 50.3% Pass@1 on SWE-bench Verified.

• 235B (fine-tuned from Qwen3-235B-A22B-Instruct-2507³): Achieves 61.7% Pass@1 — outperforming the 30B coding specialist model (50.0%) while using half the parameters of Qwen3-Coder-480B-A35B-Instruct (66.5%).

Dataset: 67,074 trajectories | 3,792 resolved issues | 1,823 repositories
Models: 30B, 235B checkpoints
License: cc-by-4.0 for data, Apache-2.0 for models

DatasetDataset

We collected trajectories from GitHub issues across Python repositories sourced from SWE-rebench, a collection of real-world software engineering tasks.

Model configuration: All trajectories were generated using Qwen3-Coder-480B-A35B-Instruct, one of the most powerful open-source code generation models available to date.

Agent scaffolding: We used OpenHands (v0.54.0), which provides a comprehensive framework for repository exploration, file editing, command execution and test validation.

Trajectory format: Each trajectory contains a sequence of messages with roles of system, user, assistant or tool:

• Assistant messages contain function calls in structured tool format, which often yields superior performance on modern architectures compared to the string-formatted commands.

• The agent maintains a linear message history, allowing efficient training on the complete sequence of steps.

• arguments are serialized to string format for storage efficiency. When training on this data, you may need to deserialize it first to ensure chat templates apply the same formatting (including any additional tags or text) during both training and inference.

The exit_status field contains submit in case the agent completes trajectory with a terminating action, or an error message from the OpenHands agent otherwise.

Filtering process: We removed all trajectories where the generated code patches failed to apply to the target repository state. This ensures every trajectory represents a valid solution attempt.

After filtering, our dataset contains 32,161 successful trajectories with 67,074 total solution attempts.

Table 1: Comparison of statistics across different datasets containing multi-turn trajectories of agent interactions with executable SWE environments. (Scroll to the right).

*Statistic value could not be derived from available data.

Our dataset provides 3× more successful trajectories and covers 1.5× more Python repositories than existing alternatives solving real-world issues, all while relying on fully open-source infrastructure.

Models and resultsModels and results

We evaluate our fine-tuned models on two complementary benchmarks.

1. SWE-bench Verified: A challenging, widely adopted benchmark containing 500 curated issues. Due to infrastructure difficulties in applying golden patches for 16 instances, we report results on the subset of 484.

   While we cannot definitively determine whether base models encountered this data during pretraining, we explicitly excluded all SWE-bench Verified issues and repositories from our training data to ensure that observed improvements stem from fine-tuning rather than data leakage.

django__django-10097, matplotlib__matplotlib-20488, psf__requests-1724, psf__requests-1766, psf__requests-1921,
psf__requests-2317, psf__requests-2931, psf__requests-5414, pylint-dev__pylint-4661, pytest-dev__pytest-5262, 
pytest-dev__pytest-7521, scikit-learn__scikit-learn-12973, scikit-learn__scikit-learn-14710, sphinx-doc__sphinx-10466, 
sympy__sympy-13091, sympy__sympy-22714

2. SWE-rebench September⁵: A smaller but temporally fresh evaluation set collected after all model training cutoffs, ensuring zero contamination at the issue level. Our training data similarly excludes all SWE-rebench September instances.

We applied rejection sampling fine-tuning (RFT) with a maximum sequence length of 131k tokens.

Table 2. Pass@1 with standard error of the mean and Pass@5 for OpenHands agent with the maximum number of turns set to 100 and 500. Deltas vs. base models are shown in parentheses for fine-tuned models. Metrics are reported in percentages. (Scroll to the right).

Reproducing OpenHands evaluationReproducing OpenHands evaluation

Evaluation results for agent-based systems are highly sensitive to both model and scaffolding configurations. As OpenHands continues to evolve, results can vary significantly between releases. To ensure reproducibility, we pin our evaluation to a specific library version (v0.54.0) and document all key configuration parameters:

Tool call format: Tool calls in messages from OpenHands agents used as inputs to LLMs can be formatted as strings or lists of dictionaries — different inference engines expect different formats, which affects behavior. This is controlled by the native_tool_calling parameter (None, true or false). To avoid relying on automatic heuristics for input tool call formatting (default None behavior), we recommend explicitly setting this parameter (we used true since all our models supported tool formatting on the inference engine’s side).

Tool call post-processing for Qwen3-Coder-30B-A3B-Instruct: While the larger Qwen3-Coder-480B-A35B-Instruct correctly formatted tool calls for the OpenHands scaffolding, the smaller Qwen3-Coder-30B-A3B-Instruct struggled, causing tool formatting errors. To match the quality reported by the Qwen3 team for the smaller coder model¹², we applied an additional post-processing for assistant steps on OpenHands side¹³.

Security settings: The security_risk parameter introduced in v0.55.0 controls which operations the agent can perform and requires the agent to manually set a new environment variable (see bug report. To avoid this, we stick to v0.54.0.

History management: To maintain the linear message history required for efficient training, we disabled history truncation when the LLM hits its maximum sequence length (enable_history_truncation=false, enable_default_condenser=true, condenser.type=noop) and prevented LLM access to the truncation tool (enable_condensation_request=false).

Infrastructure stability: The OpenHands README cautions that max_workers>1 is not well-tested. We observed that higher parallelism introduces infrastructure instability, particularly Docker build failures due to timeouts. To facilitate data collection, we increased timeouts during bootstrapping 2–10×, which enabled operation at max_workers=75, but this didn’t guarantee successful trajectory collection for all parallel instances. We recommend max_workers=1 for reliable evaluation.

Patch application: OpenHands-generated patches require specific post-processing to be applied correctly. Using evaluation pipelines not designed to handle OpenHands predictions can result in valid patches being rejected. We implement the required post-processing, resulting in a near-zero patch application failure rate.

While max_iterations (the maximum number of turns) is commonly reported, it alone is insufficient for full reproduction. To enable reproduction of the reported results, we provide a completed reproducibility checklist for our experiments and encourage researchers to use the same checklist when reporting results:

Table 3. Reproducibility checklist. (Scroll to the right).

*We used sequence length of 262k for Qwen3-235B-A22B-Instruct-2507 opposite to the value of 131k for all others, but it never exceeded 131k tokens during evaluation, thus its results should be comparable.

Our fine-tuning methodologyOur fine-tuning methodology

We applied standard RFT training using exclusively successful trajectories (those having resolved=true) with the following configuration:

Table 4. Fine-tuning hyperparameters