AlienKevin/SWE-ZERO-1k-trajectories-32k

---
language:
- en
- code
license: apache-2.0
size_categories:
- 1K<n<10K
task_categories:
- text-generation
tags:
- agentic
- code
- swe-bench
- multi-turn
- chat
- mini-swe-agent
dataset_info:
features:
- name: instance_id
dtype: string
- name: messages
list:
- name: role
dtype: string
- name: content
dtype: string
- name: repo
dtype: string
- name: exit_status
dtype: string
- name: exit_status_detail
dtype: string
- name: n_turns
dtype: int64
- name: n_messages
dtype: int64
- name: prompt_tokens
dtype: int64
- name: completion_tokens
dtype: int64
- name: duration_sec
dtype: float64
configs:
- config_name: default
data_files:
- split: train
path: data/train-*
---

# SWE-ZERO-1k-trajectories-32k

1,000 execution-free agentic rollouts from
[`ricdomolm/mini-coder-1.7b`](https://huggingface.co/ricdomolm/mini-coder-1.7b)
on 100 SWE-rebench V2 PRs (10 repos × 10 PRs × 10 rollouts each), generated
with a **32,768-token client-side context budget** as part of the SWE-ZERO MVP
for Marin
([marin-community/marin#4561](https://github.com/marin-community/marin/issues/4561)).

This is the **upgraded** version of
[`AlienKevin/SWE-ZERO-1k-trajectories`](https://huggingface.co/datasets/AlienKevin/SWE-ZERO-1k-trajectories)
(the original 8k-context Step 6 run). Bumping the per-rollout context cap from
8k → 32k tripled the clean-submission rate (15.4% → 48.6%) and gave the model
2.46× more usable completion tokens per rollout, in less wall time on the same
hardware. See the issue for the full perf analysis.

Each row is one rollout. The `messages` column is in the standard chat format
(list of `{role, content}`), so the HuggingFace dataset viewer renders each
trajectory as a multi-turn conversation between the agent and the sandboxed
bash environment.

## Schema

| field | type | description |
|---|---|---|
| `instance_id` | string | SWE-rebench V2 instance ID |
| `messages` | list[{role, content}] | the full chat trajectory (rendered by the HF viewer) |
| `repo` | string | `org/name` of the GitHub repo |
| `exit_status` | string | `Submitted` / `incomplete` / `errored` / `other` |
| `exit_status_detail` | string | full exit reason (truncated to 200 chars) |
| `n_turns` | int | assistant message count |
| `n_messages` | int | total message count (system + user + assistant) |
| `prompt_tokens` | int | total prompt tokens consumed across all turns |
| `completion_tokens` | int | total completion tokens generated |
| `duration_sec` | float | wall time of the rollout in seconds |

The `messages` column follows the mini-swe-agent v1 format: each assistant turn
is `THOUGHT: ...` followed by exactly one `\`\`\`bash` block; each subsequent
user turn is the bash subprocess output prefixed with `Observation:`. The
agent runs in a PATH-whitelisted sandbox (no language interpreters, no network)
against a real cloned checkout of the repo at the PR's `base_commit`.

## Generation details

- **Model**: `ricdomolm/mini-coder-1.7b` (Qwen3-1.7B fine-tuned on 400k
mini-swe-agent trajectories)
- **Inference**: vLLM-tpu on a v6e-8 worker (TP=4, fully sharded across 4 chips)
via the Marin Iris cluster
- **Sampling**: `temperature=1.0`, `max_total_tokens=32768`, `max_model_len=32768`,
`MAX_TURNS=30`
- **Sandbox**: per-rollout shallow git checkout + PATH whitelist (cat, grep,
sed, find, awk, ls, git, ...) with bash returning `command not found` for
anything else
- **Wall time**: 38 minutes for all 1,000 rollouts (vs 62 min for the 8k
baseline on the same family of hardware)

## Statistics

- **486/1000 (48.6%) cleanly submitted** via
`echo COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT` (vs 15.4% in 8k baseline — **3.16×**)
- 514/1000 (51.4%) ran out of turn budget mid-conversation
- **0/1000 errored** (RESERVE_TOKENS=768 fix landed; no HTTP 400 budget overshoots)
- Mean turns / rollout: ~26 (vs 13.3 in 8k baseline)
- **Mean completion tokens / rollout: 4,522** (vs 1,841 in 8k baseline — **2.46×**)
- **Total completion tokens (full corpus): 4.52M** (vs 1.84M in 8k baseline)
- **97.2% unique trajectories** at MinHash Jaccard < 0.5 (vs 87.4% in 8k baseline)
- **0 sandbox blocks** (PATH whitelist fully eliminated the regex-blocklist false positives)

## Comparison with the 8K baseline

| metric | 8K Step 6 | 32K Step 6 | Δ |
|---|---:|---:|---:|
| Wall time | 62 min | **38 min** | −39% |
| Submitted | 154 (15.4%) | **486 (48.6%)** | +3.16× |
| Errored | 14 (1.4%) | **0** | −100% |
| Mean completion tokens / rollout | 1,841 | **4,522** | +2.46× |
| Total completion tokens (corpus) | 1.84M | **4.52M** | +2.46× |
| Unique @ Jaccard<0.5 | 874 (87.4%) | **972 (97.2%)** | +9.8 pp |
| Blocked observations | 884 (7.0%) | **0** | −100% |

## Source

Generated by `experiments/swe_zero/run_swe_zero_mvp.py --step 6` on commit
[`3ba54f373`](https://github.com/marin-community/marin/commit/3ba54f373) of the
`kevin/swe-zero-mvp` branch of `marin-community/marin`. Raw input file:
`gs://marin-us-central2/experiments/swe_zero_mvp_32k/step6/rollouts.json`.

搜集汇总

数据集介绍

构建方式

在软件工程智能化研究领域，SWE-ZERO-1k-trajectories-32k数据集的构建体现了对代码生成与任务执行轨迹的高效采集。该数据集基于SWE-bench V2的100个拉取请求，通过ricdomolm/mini-coder-1.7b模型在严格沙箱环境中进行多轮对话式推演生成。每个推演过程采用32,768令牌的客户端上下文预算，模型在温度参数为1.0的采样策略下，于限定路径的沙箱内执行真实代码仓库的克隆操作，通过交互式对话记录完整的任务解决轨迹，最终形成包含1000条独立推演的数据集合。

特点

该数据集的核心特征在于其高完成度与轨迹多样性。相较于早期8k上下文版本，32k上下文预算使任务提交率从15.4%提升至48.6%，平均每轮推演生成的完成令牌数增长2.46倍，达到4522个。数据轨迹的独特性显著增强，97.2%的推演在MinHash Jaccard相似度阈值0.5下呈现唯一性。所有推演均实现零错误率，且沙箱路径白名单机制完全消除了误报阻塞，每条记录均包含完整的多轮对话消息、令牌消耗统计与执行时长等结构化元数据。

使用方法

该数据集适用于代码智能体行为分析与轨迹学习研究。研究者可通过HuggingFace数据集加载工具直接访问，其中messages字段采用标准聊天格式，可被渲染为智能体与沙箱环境的多轮对话。每条记录包含实例标识、仓库信息、退出状态及详细的令牌与时间指标，支持对智能体决策过程进行定量分析。数据集特别适用于训练或评估具有长上下文处理能力的代码生成模型，亦可用于研究软件工程任务中智能体与环境的交互模式与效率优化。

背景与挑战

背景概述

在软件工程智能化研究领域，自动化代码修复与任务执行已成为核心前沿方向。SWE-ZERO-1k-trajectories-32k数据集由Marin社区的研究团队于近期构建，作为SWE-ZERO最小可行产品的一部分，旨在探索大型语言模型在受限上下文预算下的代理行为轨迹。该数据集基于SWE-bench V2的100个拉取请求，通过ricdomolm/mini-coder-1.7b模型在严格沙盒环境中生成1000条无执行多轮对话轨迹，核心研究问题聚焦于提升模型在真实代码库环境中完成复杂软件工程任务的效率与成功率。其通过将上下文预算从8K提升至32K，显著提高了任务提交率与生成多样性，为代理智能体在代码生成与调试领域的评估与训练提供了高质量、可复现的基准数据。

当前挑战

该数据集致力于解决软件工程代理智能体在真实、复杂代码库环境中执行多步骤修复任务的挑战，其核心难点在于如何在有限的计算资源与严格的沙盒约束下，使模型能够通过多轮交互准确理解代码上下文、诊断问题并生成有效解决方案。构建过程中的挑战具体体现在：首先，需设计高效的上下文管理策略以平衡模型输入长度与任务完成度，原始8K上下文预算导致大量任务因令牌耗尽而中断；其次，沙盒环境需精确控制外部命令访问以避免安全风险与干扰，早期版本因正则表达式阻止列表误报导致大量观察被错误屏蔽；此外，确保生成轨迹的多样性与高质量亦面临采样策略与模型能力的双重约束，需通过调整温度参数与生成长度优化输出结果。

常用场景

经典使用场景

在软件工程智能化领域，SWE-ZERO-1k-trajectories-32k数据集为基于大语言模型的代码代理研究提供了关键支持。该数据集通过模拟真实GitHub仓库的拉取请求修复场景，记录了智能代理在沙盒环境中执行多轮对话与bash命令的完整轨迹。其经典使用场景在于训练和评估代码代理在受限上下文预算下的任务完成能力，尤其适用于研究代理如何通过迭代思考与操作来解决复杂的软件缺陷问题。数据集中的每条轨迹都以标准聊天格式呈现，便于直接用于模型微调或行为分析，推动了代码代理在长上下文环境下的性能优化研究。

衍生相关工作

围绕该数据集，已衍生出多项聚焦于代码代理效率与泛化能力的研究工作。例如，基于其上下文扩展策略，后续研究探索了不同令牌预算对代理任务完成率的影响机制，并开发了更高效的轨迹采样方法。同时，数据集启发了对mini-swe-agent架构的优化，如改进bash命令生成与观察处理的交互模式。这些工作进一步推动了如SWE-bench等基准测试的演进，促进了代码代理在真实软件工程任务中的评估标准化，为智能化软件开发工具的迭代创新奠定了数据基础。

数据集最近研究

最新研究方向

在软件工程智能体领域，SWE-ZERO-1k-trajectories-32k数据集代表了前沿探索方向，聚焦于提升代码生成智能体在复杂任务中的执行效率与鲁棒性。该数据集通过将上下文预算从8K扩展至32K，显著提高了任务提交率至48.6%，同时消除了错误率，体现了大上下文窗口对智能体多轮交互轨迹优化的关键影响。其生成过程结合了高效推理框架与沙盒环境，为研究智能体在真实代码库中的自适应行为、长序列决策建模以及资源受限下的性能权衡提供了高质量基准。这一进展不仅推动了自动化软件修复工具的发展，也为多模态智能体在工业级应用中的部署奠定了实证基础。