Pith. sign in

REVIEW 4 major objections 3 minor 45 references

DCAS: Decoupling CLI Agent Scaffolding to Internalize Planning across Scaffolds

T0 review · 4 major / 3 minor · reviewed 2026-08-07 · deepseek-v4-flash

Pith's one-line read The paper argues that the steep cross-scaffold performance drop in open CLI coding agents is a planning-convention mismatch, and that fine-tuning on planning-aware trajectories internalizes planning as a transferable model capability.

desk verdict Useful infrastructure and a real empirical pattern, but the headline planning-causality claim outruns the controls. read the letter →

arxiv 2608.06113 v1 pith:76SD6JTO submitted 2026-08-06 cs.SE

classification cs.SE
keywords CLIagentssoftwareengineeringscaffoldgeneralizationexplicitplanningimplicitsupervisedfine-tuningplanning-awaretrajectoriescross-scaffoldevaluation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

CLI coding agents are harnesses that turn a language model into an autonomous terminal-based programmer, and most open models are fine-tuned on trajectories collected under a single harness, OpenHands. This paper claims that the steep performance drop these models show when deployed under a different harness is not mostly a capability deficit but a mismatch in planning conventions: each harness has its own way of structuring a pre-execution plan and its own turn-by-turn habits for how work is decomposed, tools are sequenced, and failures are handled. The paper introduces DCAS, an interception layer that lets any model run inside any harness without modifying the harness, and uses it to show that plan quality is a high-leverage variable, that fine-tuning on a small set of planning-aware trajectories installs the missing conventions, and that the learned planning skill transfers to harnesses the model never saw during training. If the claim is right, scaffold-portable coding agents can be trained with small datasets instead of requiring separate retraining for every deployment environment.

What carries the argument

The central object is DCAS, a backend-substitution interception layer that routes API traffic between any CLI scaffold and any backend model without modifying the scaffold, enabling cross-scaffold evaluation and planning-aware trajectory collection. The argument is carried by the two-sense decomposition of planning, explicit and implicit, together with two supervised fine-tuning dataset variants built from DCAS-collected trajectories: PlanOnly, which trains only on the planning phase, and Plan+Exec, which trains on both the planning and execution phases. The inference that scaffolds share a ReAct-style act/observe loop supplies the capacity premise that lets the paper attribute the gap to conventions rather than capability.

What would settle it

A token-matched supervised fine-tuning control on the same 576 trajectories with the planning turns removed, using only execution turns, would settle the attribution: if it reproduces the Plan+Exec gains, the improvement comes from imitating successful trajectories rather than from internalizing planning structure.

Watch

Extended reading notes

Core claim

The paper's central claim is that the cross-scaffold deployment gap in CLI software-engineering agents is, to a substantial degree, a planning-convention mismatch. It distinguishes explicit planning, a pre-execution plan produced as a first-class artifact, from implicit planning, the structural conventions that shape execution turn by turn, and argues that fine-tuning under one scaffold installs that scaffold's particular blend of the two. The supporting evidence is a chain of controlled comparisons: untrained base models show only small score spreads across four wrappers while fine-tuned models show much larger spreads; holding the executor model and wrapper fixed, changing only the plan source moves SWE-bench Verified Pass@1 from 42.8 percent with no plan to 57.8 percent with a Claude Sonnet 4.5 plan; fine-tuning on 576 verified Plan+Exec trajectories lifts the model to 55.8 percent with self-generated plans on the training wrapper and to 57.2 percent on a newer wrapper release, 49.4 percent on OpenCode, and 42.4 percent on mini-swe-agent, both unseen during training. The paper concludes that planning can be moved from a fixed scaffold artifact to a learned model capability and that what is learned generalizes across deployment scaffolds.

Load-bearing premise

The central claim depends on treating the shared act/observe loop across scaffolds as proof that performance drops are convention mismatches rather than capability gaps, a premise the paper only partly isolates because tool-call format incompatibilities and context-length conflicts also drive failures in its own data.

Editorial extensions

If this is right

  • Models fine-tuned on planning-aware trajectories under one scaffold can gain on unseen scaffolds, so scaffold-portable training does not require collecting data under every deployment target.
  • Reported SWE-bench-style scores should be read as scaffold-specific, since the same fine-tuned model can differ by tens of points depending on the deployment wrapper.
  • The two senses of planning are separable in training data, so datasets and recipes can target implicit planning conventions alone or additionally teach the productive use of an explicit planning turn.
  • Small planning-rich trajectory collections, here 576 verified runs, can rival much larger single-scaffold collections, changing the economics of data collection.
  • Plan quality is a high-leverage variable even without fine-tuning, so routing plans from a well-calibrated planner can improve a fixed executor model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper leaves open whether an execution-only fine-tuning control would reproduce the Plan+Exec gains; if token-matched SFT without planning turns matched the 13-point improvement, the gains would come from imitating successful trajectories rather than from internalizing planning structure.
  • The economics argument implies a testable scaling rule: holding dataset size fixed, trajectories collected under a planning-rich scaffold should beat trajectories collected under a planning-poor scaffold, which could be checked by varying only the collection wrapper.
  • The planner-executor calibration result suggests that the optimal external planner shifts as the executor model scales, an implicit prediction that could be tested by repeating the plan-source intervention with a larger backend model.
  • Because the transfer evidence covers only ReAct-style CLI wrappers, extending the interception layer to GUI or IDE-integrated agents would reveal whether the learned planning skill is universal or tied to terminal action spaces.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 3 minor

Summary. The paper investigates why fine-tuned CLI software-engineering agents degrade when deployed under a scaffold different from the one used for training. It introduces DCAS, an interception layer that routes API traffic between a CLI scaffold and a substitute backend model, enabling controlled cross-scaffold evaluation and planning-aware trajectory collection. The central hypothesis is that the cross-scaffold gap is, to a substantial degree, a planning-convention mismatch, and that planning can be internalized via supervised fine-tuning and then transfers across scaffolds. RQ1 varies only the source of an explicit plan (no plan, self-plan, or external frontier/open-weight plans) under a fixed scaffold; RQ2 fine-tunes Qwen3-Coder-30B on PlanOnly and Plan+Exec trajectory datasets collected under Claude Code; RQ3 evaluates the Plan+Exec model on a newer Claude Code version, OpenCode, and mini-swe-agent. Headline results are a plan-injection gain from 42.8% to 57.8% in RQ1, a Plan+Exec self-plan score of 55.8% on the training scaffold, and cross-scaffold self-plan gains of +3.4% on OpenCode and +7.0% on mini-swe-agent relative to the base model without a plan.

Significance. If the planning-attribution claim holds, this is a valuable contribution: it identifies a fine-tuning-induced generalization failure that single-scaffold leaderboards miss, introduces reusable open infrastructure (DCAS), and releases trajectories, weights, and raw HTTP logs. The PlanOnly versus Plan+Exec design is a genuinely clever way to try to separate explicit and implicit planning, and the base-model comparison in Table 1 is a clean demonstration that the cross-scaffold gap is installed by training. However, the central attribution to planning is not yet established: the paper lacks an execution-only or token-matched SFT control, the parser/context-window confounds visible in Table 1 are acknowledged but not quantified, and several RQ3 deltas are small single-run differences. These issues are fixable within the manuscript's scope, so the paper merits major revision rather than rejection.

major comments (4)
  1. [Section 9.1, Table 5] The RQ2 conclusion that PlanOnly installs implicit planning and Plan+Exec installs explicit planning is underdetermined without an execution-only or token-matched SFT control. Section 9.1 concedes that the measured gains "reflect planning structure combined with general exposure to successful in-domain trajectories" and that controls such as execution-only, token-matched, or degraded-plan training are left for future work. This matters because a model fine-tuned on any successful trajectory could improve no-plan performance through generic imitation of tool use and problem solving, not through planning structure per se. The PlanOnly and Plan+Exec datasets also differ in size (14,162 versus 36,259 per-turn samples), so their similar no-plan gains are not directly comparable. Please add an execution-only condition (the same 576 trajectories with planning turns removed) and, ideally, a token-matched control with plan turns replaced by non-plan content, and report the resulting no-plan and self-plan scores.
  2. [Section 2.3, Section 10, Table 1] The load-bearing premise that the four scaffolds share a ReAct-style act/observe loop, and therefore that the cross-scaffold gap cannot be a capability deficit and must be a planning-convention mismatch, is contradicted by the paper's own observations. Table 1 shows a 44-point collapse for SWE-Lego-Qwen3-32B on OpenCode (52.6% to 8.4%) attributed to tool-call format incompatibility, and two models required context-length rescaling (YaRN) because of conflicts with Claude Code's context ceiling. Section 10 acknowledges that the paper does not isolate the contribution of these parser and context-window effects, but the central claim that the gap is "to a substantial degree, a planning-convention mismatch" needs either a quantitative decomposition of these confounds or a narrower claim. Please report, for the models in Table 1, the fraction of failed instances attributable to parse errors and context failures versus other behavioral differences, or otherwise bound the contribution of non-planning factors.
  3. [Section 3.4, Table 4] RQ1's claim that "the only difference between conditions is the source and quality of the plan" is weakened by an asymmetric turn budget. The self-plan and external-plan conditions allow an additional planning phase of up to 500 turns, while the no-plan condition has no planning phase; although these turns make no code changes, they provide extra codebase exploration that can improve later execution performance independently of plan quality. Please either give the no-plan condition an equivalent exploration-only pre-phase that does not produce a plan, or measure and report the distribution of planning-phase turns and its effect on outcomes. In addition, the default-selection rows of Table 4 may include internal routing to lighter models (acknowledged in Section 4.1), so the unqualified statement that the +15% gain is "attributable solely to plan quality" should be restricted to the fixed-selection rows.
  4. [Tables 5 and 6, Section 6] No confidence intervals, repeated runs, or significance tests are reported anywhere, and several RQ3 cross-scaffold deltas are small single-run differences. For a 500-instance benchmark with Pass@1 near 50%, the binomial standard error is roughly two percentage points, so the reported gains of +1.6 (OpenCode no-plan), +3.4 (OpenCode self-plan), and +3.8 (mini-swe-agent no-plan) are within one standard error of zero under a single run. Please report confidence intervals from repeated evaluation runs (or bootstrap over instances) and, ideally, multiple SFT seeds, before concluding that the learned capability "gains consistently" across scaffolds.
minor comments (3)
  1. [Section 6.2.2, Table 6] The headline comparison "the SFT model with self-generated plans outperforms the base model without a plan" uses a favorable baseline; the more interpretable comparisons are SFT versus base under the same planning condition. For example, on OpenCode the SFT self-plan gain over base self-plan is +2.0 percentage points, not +3.4. Please report all four pairwise comparisons explicitly.
  2. [Section 9.3] The construct-validity section notes that gains under the self-plan condition could arise partly from improved execution behavior rather than improved planning; given that direct plan-quality scoring is listed as future work, consider adding at least a small qualitative or automatic evaluation of plan adherence for the fine-tuned models.
  3. [Table 2] The table caption refers to "Teal deltas," but color-only indicators are not accessible in print or for color-blind readers; please add explicit plus signs or boldface in addition to color.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the planning hypothesis is tested by controlled external interventions and SWE-bench Verified benchmark measurements; the acknowledged missing execution-only control is an internal-validity limitation, not a definitional or self-citation loop.

full rationale

I find no significant circularity. The central claim—that the cross-scaffold deployment gap is largely a planning-convention mismatch and that planning can be internalized through fine-tuning—is supported by three independent empirical investigations rather than by definitions or fitted parameters. RQ1 is a controlled plan-source intervention that holds the executor model, scaffold, and benchmark fixed and varies only the plan source; the outcome (Pass@1 on SWE-bench Verified) is not defined in terms of the plan source. RQ2 fine-tunes on trajectories collected under Claude Code and evaluates on SWE-bench Verified, with training data drawn from SWE-Lego Real Data that the paper states is decontaminated against the test set; the gain is measured against an untrained base model, not against a quantity derived from the training data. RQ3 evaluates the fine-tuned model on an unseen scaffold version and two unseen scaffolds, and the transfer pattern is a falsifiable prediction. The paper's Section 9.1 explicitly concedes that gains 'reflect planning structure combined with general exposure to successful in-domain trajectories' and that controls such as 'execution-only, token-matched, or degraded-plan training' are left for future work. That is a genuine internal-validity and attribution limitation, but it is not circularity: the missing control does not mean the training or evaluation quantities reduce to the paper's inputs by construction. The self-citations in the paper are data/model/replication-package releases [25, 26, 27] and are not load-bearing for the argument. The Section 2.3 assumption that all scaffolds share a ReAct-style loop and the broad definition of 'implicit planning' are potential weaknesses, but the paper derives separable empirical predictions from them (PlanOnly no-plan gains without self-plan benefit, Plan+Exec self-plan gains on top, and transfer to unseen scaffolds), so the conclusion is not equivalent to the hypothesis by definition. No fitted parameter is renamed as a prediction, and no load-bearing uniqueness theorem or ansatz is imported from the authors' prior work. The correct finding is therefore no significant circularity.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The paper's claims rest on domain assumptions about scaffold loop structure, external evidence for plan quality, decontamination of the training split, and construct validity of Pass@1, rather than on fitted theoretical parameters. The empirical choices that most affect the central claim are the plan step cap, turn caps, and rejection-sampling threshold. No new theoretical entities are introduced; DCAS is a released software artifact, not an invented theoretical construct.

free parameters (5)
  • Plan step cap = 8 steps
    The self-plan and external-plan prompts restrict plans to at most eight steps (Section 3.2), which shapes plan quality in RQ1.
  • Planning phase turn cap = 500 turns
    Maximum number of turns for plan generation before execution begins (Section 3.4); affects plan quality and the content of collected planning trajectories.
  • Execution turn cap = 100 turns
    Maximum turns for execution, identical across all conditions (Section 3.4).
  • Rejection-sampling threshold = Patch verified as resolving the issue
    Only successful trajectories are retained (576 of about 5,000 instances), biasing training toward easier instances (Sections 3.3 and 9.1).
  • SFT learning rate = 4.0e-6
    Hyperparameter for full-parameter SFT (Section 3.5); standard value, not fitted to the benchmark.
assumptions (5)
  • domain assumption All four scaffolds in the study run a ReAct-style act/observe loop, so the cross-scaffold gap is not a capability deficit.
    Section 2.3 makes this the key inferential move: if the loop is shared, the gap must be a convention mismatch. This is argued, not measured.
  • domain assumption Plan quality and plan adherence are the primary drivers of resolution rate (Liu et al., 16,991 trajectories).
    External result adopted in Section 2.3 to narrow the candidate mechanism to planning.
  • domain assumption SWE-Lego Real Data is decontaminated against SWE-bench Verified.
    Section 3.3 relies on this so training does not leak the test set used in Sections 4 to 6.
  • domain assumption Claude Code versions 2.0.76 and 2.1.73 are stable enough for controlled comparison despite being closed-source.
    The paper pins versions but cannot guarantee internal routing behavior; discussed in Section 9.3.
  • domain assumption Pass@1 on SWE-bench Verified is a valid measure of the capability of interest.
    Construct validity is discussed in Section 9.3; the metric does not capture trajectory efficiency or intermediate reasoning quality.

how reviews work

0 comments
Cite this review

Pith. "Pith review of DCAS: Decoupling CLI Agent Scaffolding to Internalize Planning across Scaffolds." pith.science (2026). https://pith.science/paper/76SD6JTO

@misc{pith2026260806113,
  author       = {Pith},
  title        = {Pith review of: DCAS: Decoupling CLI Agent Scaffolding to Internalize Planning across Scaffolds},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/76SD6JTO}},
  note         = {Machine review of arXiv:2608.06113}
}
read the original abstract

CLI-based software-engineering agents have matured rapidly, yet the open ecosystem has converged on a single training environment: trajectory datasets used to fine-tune open models are collected almost exclusively under OpenHands. Models fine-tuned on this data score well under OpenHands but degrade substantially when deployed under any non-training scaffold. Untrained base models do not show this divergence, indicating the gap is fine-tuning-induced and tied to the conventions of the training scaffold. We argue that a load-bearing scaffold-specific behavior is planning structure, in two senses this paper distinguishes: explicit planning, a pre-execution plan produced as a first-class artifact, and implicit planning, the structural conventions that shape execution throughout the agent loop. Under this hypothesis, closing the gap requires moving planning from a fixed scaffold artifact to a learned model capability. We introduce Decoupling CLI Agent Scaffolding (DCAS), a backend-substitution interception layer that routes API traffic between any CLI scaffold and any backend model without modifying the scaffold, enabling cross-scaffold evaluation and planning-aware trajectory collection. Using DCAS, a controlled plan-source intervention confirms planning quality is a high-leverage component, with gains exceeding the cross-scaffold drops we observe. A model fine-tuned on a small set of DCAS-collected planning-aware trajectories under a single scaffold gains consistently across non-training scaffolds, and the two senses of planning are empirically separable in training data.

Figures

Figures reproduced from arXiv: 2608.06113 by the authors.

Figure 1
Figure 1. The DCAS interception layer routes API traffic be [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

45 extracted references · 22 canonical work pages

  1. [1]

    Anthropic. 2024. Claude Code: Agentic Coding in Your Terminal. https://claude. com/product/claude-code. Accessed April 2026

  2. [2]

    Alpay Ariyak, Junda Zhang, Junxiong Wang, Shang Zhu, Federico Bianchi, San- jana Srivastava, Ashwinee Panda, Siddhant Bharti, Chenfeng Xu, John Heo, Xiaoxia Shirley Wu, James Zou, Percy Liang, Leon Song, Ce Zhang, Ben Athi- waratkun, Zhongzhu Zhou, and Qingyang Wu. 2026. CoderForge-Preview: SOTA Open Dataset for Training Efficient Agents. Accessed April 2...

  3. [3]

    Ibragim Badertdinov, Alexander Golubev, Maksim Nekrashevich, Anton Shevtsov, Simon Karasik, Andrei Andriushchenko, Maria Trofimova, Daria Litvintseva, and Boris Yangel. 2025. SWE-rebench: An Automated Pipeline for Task Collection and Decontaminated Evaluation of Software Engineering Agents. arXiv:2505.20411 [cs.SE] https://arxiv.org/abs/2505.20411

  4. [4]

    Ruisheng Cao, Mouxiang Chen, Jiawei Chen, Zeyu Cui, Yunlong Feng, Binyuan Hui, Yuheng Jing, Kaixin Li, Mingze Li, Junyang Lin, Zeyao Ma, Kashun Shum, Xuwu Wang, Jinxi Wei, Jiaxi Yang, Jiajun Zhang, Lei Zhang, Zongmeng Zhang, Wenting Zhao, and Fan Zhou. 2026. Qwen3-Coder-Next Technical Report. arXiv:2603.00729 [cs.CL] https://arxiv.org/abs/2603.00729

  5. [5]

    Dong Chen, Shaoxin Lin, Muhan Zeng, Daoguang Zan, Jian-Gang Wang, Anton Cheshkov, Jun Sun, Hao Yu, Guoliang Dong, Artem Aliev, Jie Wang, Xiao Cheng, Guangtai Liang, Yuchi Ma, Pan Bian, Tao Xie, and Qianxiang Wang. 2024. CodeR: Issue Resolving with Multi-Agent and Task Graphs. arXiv:2406.01304 [cs.SE] https://arxiv.org/abs/2406.01304

  6. [6]

    Jimenez, John Yang, Leyton Ho, Tejal Patwardhan, Kevin Liu, and Aleksander Madry

    Neil Chowdhury, James Aung, Chan Jun Shern, Oliver Jaffe, Dane Sherburn, Giulio Starace, Evan Mays, Rachel Dias, Marwan Aljubeh, Mia Glaese, Carlos E. Jimenez, John Yang, Leyton Ho, Tejal Patwardhan, Kevin Liu, and Aleksander Madry. 2024. Introducing SWE-bench Verified. Accessed April 2026. https: //openai.com/index/introducing-swe-bench-verified

  7. [7]

    DataCamp. 2026. OpenCode vs Claude Code: We Compare Cost, Privacy, and Speed. https://www.datacamp.com/blog/opencode-vs-claude-code. Accessed April 2026

  8. [8]

    DEV Community. 2026. OpenCode vs Claude Code: Which AI CLI Coding Agent Wins in 2026? https://dev.to/tech_croc_f32fbb6ea8ed4/opencode-vs-claude-code- which-ai-cli-coding-agent-wins-in-2026-45md. Accessed April 2026

Show all 45 references
  1. [9]

    Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, et al. 2025. DeepSeek-R1 Incentivizes Reasoning in LLMs Through Reinforcement Learning.Nature645 (2025), 633–638. doi:10.1038/s41586-025-09422-z

  2. [10]

    Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R. Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-world GitHub Issues?. InThe Twelfth International Conference on Learning Representations. https://openreview.net/foru...

  3. [11]

    Kimi Team. 2025. Kimi K2: Open Agentic Intelligence. arXiv:2507.20534 https: //arxiv.org/abs/2507.20534

  4. [12]

    Jimenez, John Yang, and Ofir Press

    Kilian Lieret, Carlos E. Jimenez, John Yang, and Ofir Press. 2025. Mini-SWE- Agent: Minimalistic Agent for Resolving GitHub Issues. Accessed April 2026. https://github.com/SWE-agent/mini-swe-agent

  5. [13]

    Shuyang Liu, Saman Dehghan, Jatin Ganhotra, Martin Hirzel, and Reyhaneh Jabbarvand. 2026. Evaluating Plan Compliance in Autonomous Programming Agents. arXiv:2604.12147 [cs.SE] https://arxiv.org/abs/2604.12147

  6. [14]

    Michael Luo, Naman Jain, Jaskirat Singh, Sijun Tan, Ameen Patel, Qingyang Wu, Alpay Ariyak, Colin Cai, Tarun Venkat, Shang Zhu, Ben Athiwaratkun, Manan Roongta, Ce Zhang, Li Erran Li, Raluca Ada Popa, Koushik Sen, and Ion Stoica. 2025. DeepSWE: Training a Fully Open-Sourced, S...

  7. [15]

    Jim McMillan. 2025. Claude Code, Gemini, and Codex SWE-bench Runner. Inspiration and code basis for the DCAS interception layer. https://github.com/ jimmc414/claudecode_gemini_and_codex_swebench

  8. [16]

    Nex-AGI Team. 2025. Nex-N1: Agentic Models Trained via a Unified Ecosystem for Large-Scale Environment Construction. arXiv:2512.04987 [cs.CL] https: //arxiv.org/abs/2512.04987

  9. [17]

    OpenAI. 2024. Learning to Reason with LLMs. https://openai.com/index/learning- to-reason-with-llms/. Accessed April 2026

  10. [18]

    Albert Örwall. 2024. MoatlessTools: A Scaffolding for Specialized Software Engineering Workflows. Accessed April 2026. https://github.com/aorwall/ moatless-tools

  11. [19]

    Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, and Yizhe Zhang. 2025. Training Software Engineering Agents and Verifiers with SWE-Gym. InProceedings of the 42nd International Conference on Machine Learning. arXiv:2412.21139 https://arxiv.org/abs/2...

  12. [20]

    Abhinav Rastogi et al. 2025. Devstral: Fine-tuning Language Models for Coding Agent Applications. arXiv:2509.25193 [cs.SE] https://arxiv.org/abs/2509.25193

  13. [21]

    Ethan Shen, Danny Tormoen, Saurabh Shah, Ali Farhadi, and Tim Dettmers

  14. [22]

    SST. 2025. OpenCode: A Powerful AI Coding Agent Built for the Terminal. Accessed April 2026. https://github.com/anomalyco/opencode

  15. [23]

    Wannita Takerngsaksiri, Jirat Pasuksmit, Patanamon Thongtanunam, Chakkrit Tantithamthavorn, Ruixiong Zhang, Fan Jiang, Jing Li, Evan Cook, Kun Chen, and Ming Wu. 2025. Human-In-the-Loop Software Development Agents. arXiv:2411.12924 [cs.SE] https://arxiv.org/abs/2411.12924

  16. [24]

    Chaofan Tao, Jierun Chen, Yuxin Jiang, Kaiqi Kou, Shaowei Wang, Ruoyu Wang, Xiaohui Li, Sidi Yang, Yiming Du, Jianbo Dai, Zhiming Mao, Xinyu Wang, Lifeng Shang, and Haoli Bai. 2026. SWE-Lego: Pushing the Limits of Supervised Fine- Tuning for Software Issue Resolving. arXiv:260...

  17. [25]

    Kishanthan Thangarajah et al. 2026. DCAS Fine-Tuned Model Weights. https: //huggingface.co/kishanthan/models

  18. [26]

    Kishanthan Thangarajah et al. 2026. DCAS GLM-4.7 Distilled Trajectory Dataset. https://huggingface.co/datasets/kishanthan/dcas_glm4.7_distill

  19. [27]

    2026.DCAS Replication Package

    Kishanthan Thangarajah et al . 2026.DCAS Replication Package. doi:10.5281/ zenodo.19930073

  20. [28]

    Maria Trofimova, Anton Shevtsov, Ibragim Badertdinov, Konstantin Pyaev, Simon Karasik, and Alexander Golubev. 2025. OpenHands Trajectories with Qwen3- Coder-480B-A35B-Instruct. Accessed April 2026. https://nebius.com/blog/posts/ openhands-trajectories-with-qwen3-coder-480b

  21. [29]

    Bairi, Aditya Kanade, and Nagarajan Natarajan

    Nalin Wadhwa, Atharv Sonwane, Daman Arora, Abhav Mehrotra, Saiteja Utpala, Ramakrishna B. Bairi, Aditya Kanade, and Nagarajan Natarajan. 2024. MASAI: Modular Architecture for Software-engineering AI Agents. InNeurIPS 2024 Work- shop on Open-World Agents. https://openreview.net...

  22. [30]

    Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, and Heng Ji. 2024. Executable Code Actions Elicit Better LLM Agents. InForty- first International Conference on Machine Learning. arXiv:2402.01030 https: //arxiv.org/abs/2402.01030

  23. [31]

    Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H

    Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brenna...

  24. [32]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. 2022. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. InAdvances in Neural Information Processing Systems, Vol. 35. 24824–24837. https://arxiv...

  25. [33]

    Yuxiang Wei, Olivier Duchenne, Jade Copet, Quentin Carbonneaux, Lingming Zhang, Daniel Fried, Gabriel Synnaeve, Rishabh Singh, and Sida I. Wang. 2026. SWE-RL: Advancing LLM Reasoning via Reinforcement Learning on Open Soft- ware Evolution. InThe Thirty-ninth Annual Conference ...

  26. [34]

    Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang

  27. [35]

    Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R

    John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R. Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer Inter- faces Enable Automated Software Engineering. InThe Thirty-eighth Annual Con- ference on Neural Information Processing System...

  28. [36]

    Jimenez, Alexander Wettig, Kabir Khandpur, Yanzhe Zhang, Binyuan Hui, Ofir Press, Ludwig Schmidt, and Diyi Yang

    John Yang, Kilian Lieret, Carlos E. Jimenez, Alexander Wettig, Kabir Khandpur, Yanzhe Zhang, Binyuan Hui, Ofir Press, Ludwig Schmidt, and Diyi Yang. 2025. SWE-smith: Scaling Data for Software Engineering Agents. InProceedings of the 39th Annual Conference on Neural Information...

  29. [37]

    Zonghan Yang, Shengjie Wang, Kelin Fu, Wenyang He, Weimin Xiong, Yibo Liu, Yibo Miao, et al . 2025. Kimi-Dev: Agentless Training as Skill Prior for SWE-Agents. arXiv:2509.23045 [cs.SE] https://arxiv.org/abs/2509.23045

  30. [38]

    Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629 [cs.CL] https://arxiv.org/abs/2210.03629 ASE ’26, October 12–16, 2026, Munich, Germany Thangarajah et al

  31. [39]

    Z.ai. 2025. GLM-4.7: Open-Weight Model for Agentic Coding, Reasoning, and Tool Use. https://huggingface.co/zai-org/GLM-4.7. Released December 22, 2025

  32. [40]

    Mario Zechner. 2025. claude-trace: Intercept and Log All Claude Code HTTP Traffic. Accessed April 2026. https://www.npmjs.com/package/@mariozechner/ claude-trace

  33. [41]

    Liang Zeng, Yongcong Li, Yuzhen Xiao, Changshi Li, Chris Yuhao Liu, Rui Yan, Tianwen Wei, Jujie He, Xuchen Song, Yang Liu, and Yahui Zhou. 2025. Skywork-SWE: Unveiling Data Scaling Laws for Software Engineering in LLMs. arXiv:2506.19290 [cs.AI] https://arxiv.org/abs/2506.19290

  34. [42]

    Yaowei Zheng, Richong Zhang, Junhao Zhang, Yanhan Ye, and Zheyan Luo

  35. [45]

    InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations), Yixin Cao, Yang Feng, and Deyi Xiong (Eds.)

    LlamaFactory: Unified Efficient Fine-Tuning of 100+ Language Models. InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations), Yixin Cao, Yang Feng, and Deyi Xiong (Eds.). Association for Computational Linguist...

  36. [2024]

    arXiv:2407.01489 [cs.SE] https://arxiv.org/abs/2407.01489

    Agentless: Demystifying LLM-based Software Engineering Agents. arXiv:2407.01489 [cs.SE] https://arxiv.org/abs/2407.01489

  37. [2026]

    arXiv:2601.20789 [cs.CL] https://arxiv.org/abs/2601.20789

    SERA: Soft-Verified Efficient Repository Agents. arXiv:2601.20789 [cs.CL] https://arxiv.org/abs/2601.20789

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.