Skip to content

Orchard: An Open-Source Agentic Modeling Framework

🕒 Published (v1): 2026-05-14 16:35 UTC · Source: Arxiv · link

Why this paper was selected

Orchard: open-source agentic modeling framework addressing open-research bottleneck

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

Orchard is an open-source framework for scalable agentic model training built around a thin, Kubernetes-native environment service (Orchard Env) that decouples sandbox execution from any particular agent harness, trainer, or inference backend. Three domain recipes (SWE, GUI, personal assistant) are instantiated on top of this common substrate, achieving state-of-the-art open-source results. The central claim is that harness-agnostic environment abstraction enables trajectory data, SFT recipes, and RL rollouts to transfer across domains and harnesses.

Problem

Open-source agentic training infrastructure is either tightly coupled to a specific training stack (ProRL Agent, MegaFlow), managed/proprietary (E2B, Daytona), or broadly scoped without a clean service boundary (ROCK). This coupling makes trajectory datasets, training recipes, and evaluation pipelines non-transferable: data collected under one harness cannot trivially be evaluated or fine-tuned under another, and new domains must rebuild infrastructure from scratch.

Method

Orchard Env is a three-layer Kubernetes-native service: 1. Client SDK — sync/async Python (SandboxClient / AsyncSandboxClient) issuing REST calls. 2. Orchestrator — FastAPI deployment managing sandbox lifecycle via Kubernetes Pods; uses a PodWatcher (LIST+WATCH stream) for readiness, direct Pod-IP routing for execution (bypassing kubectl exec/WebSocket), per-sandbox locks, and heartbeat-based cleanup. 3. In-Pod Agent — lightweight FastAPI server injected into arbitrary Docker images at runtime via a Kubernetes init container, exposing /exec, file I/O, and health endpoints.

This design achieves harness-agnosticism: any trainer, harness, or task domain calls the same REST surface. On top of Orchard Env, three recipes are applied: - Orchard-SWE: 107K trajectories distilled from frontier MoE models (MiniMax-M2.5, Qwen3.5-397B) across SWE-rebench/Scale-SWE using both OpenHands and mini-swe-agent harnesses; credit-assignment SFT applies retrospective value estimation to extract productive "rise segments" from unresolved trajectories; Balanced Adaptive Rollout (BAR) assembles reward-balanced groups for sparse-reward RL. - Orchard-GUI: 2.6K tasks (0.4K distilled + 2.2K open-ended) training a 4B VLM with a generic ReAct-style browser harness; SFT+RL. - Orchard-Claw: 0.2K synthetic tasks; trained once, evaluated across a ReAct harness and the ZeroClaw harness at inference time to test cross-harness transfer.

Key Contributions

  • Orchard Env: a thin, self-hostable, Kubernetes-native sandbox service that is agnostic to harness, trainer, and domain; runtime agent injection enables zero-modification support for heterogeneous Docker images.
  • Credit-assignment SFT: converts partially-failed trajectories into supervision by extracting value-estimated productive segments.
  • Balanced Adaptive Rollout (BAR): online rollout allocation strategy for sparse-reward RL in SWE settings.
  • Cross-harness generalization (Orchard-Claw): demonstrates that a model trained under one harness transfers to a stronger inference harness (ZeroClaw) without retraining.
  • Cost benchmarking: Orchard Env at on-demand rates is 53% cheaper than Daytona/E2B; with spot instances, 90% cheaper ($673 vs. $7,078 for 128 sandboxes × 240 h).
  • Full release: environment service, training recipes, and trajectory datasets for three domains.

Results

  • Orchard-SWE (Qwen3-30B-A3B-Thinking): 64.3% SWE-bench Verified after SFT, 67.5% after SFT+RL — new open-source SOTA at comparable scale; OpenSWE-72B is next at 66.0%.
  • Orchard-GUI (4B backbone): 74.1% WebVoyager, 67.0% Online-Mind2Web, 64.0% DeepShop → 68.4% average — new open-source SOTA; outperforms OpenAI CUA (51.3%) and GPT-5 Axtree (51.1%); competitive with Gemini CUA (69.3%).
  • Orchard-Claw (Qwen3-30B-A3B-Thinking, 0.2K tasks): 31.7% pass³ / 59.6% pass@3 under ReAct harness; 41.0% pass³ / 73.9% pass@3 when paired with ZeroClaw harness at inference (+19.9 pp pass@3 over base model).
  • Orchard Env latency: 0.28s avg command execution — matches SkyPilot Code Sandbox (0.284s), 2.7× faster than E2B (0.747s), 7.3× faster than Modal (2.046s).
  • Reliability: 100% success rate across 1,000 concurrent sandboxes; 26s end-to-end (≈154 cmds/s).
  • Functional equivalence: no statistically significant regression vs. direct Docker baseline on Terminal-Bench 2.0 across three models.

Limitations

  • Orchard Env requires a Kubernetes cluster; this is more operationally complex than managed sandboxes (E2B, Daytona) for researchers without cloud/k8s expertise.
  • Cross-harness transfer is demonstrated only for Orchard-Claw; SWE and GUI results are harness-specific (mini-swe-agent and a single ReAct browser harness, respectively).
  • Credit-assignment SFT relies on retrospective value estimation from the same model family used for distillation; quality of extracted segments is bounded by the teacher.
  • BAR for sparse-reward RL is described but its ablation against simpler rollout allocation is not fully detailed in the excerpt.
  • Comparisons in Table 1 are based on public documentation as of April 2026 and may not reflect all system capabilities.

Relevance to Harnesses / Meta-Harnesses

Orchard directly instantiates the meta-harness design pattern: a single environment service layer that multiple harnesses (OpenHands, mini-swe-agent, ReAct browser, ZeroClaw) can compose with interchangeably, without coupling data collection to evaluation or RL to SFT. The Orchard-Claw cross-harness experiment is particularly germane — it empirically validates that a model trained under one harness at SFT time can be upgraded at inference time by substituting a stronger harness, a key property for harness-composable pipelines. The runtime agent-injection mechanism (Kubernetes init container) is a concrete engineering solution to the harness portability problem that meta-harness architects will want to study.