Orchard-Agentic: an open environment service for training and evaluating coding agents

A collection with a naming convention, and why the distinction matters

Orchard-Agentic is a collection of open-source work on agentic modeling. It brings together research projects, shared infrastructure, datasets, training recipes and evaluation artifacts, and it includes the foundational paper, Orchard: An Open-Source Agentic Modeling Framework, along with subsequent projects such as OpenWebRL and OpenForge RL.

The naming is carefully defined and worth getting right before reading anything else. Orchard Env, Orchard-SWE, Orchard-GUI and Orchard-Claw are established names introduced by the Orchard research and retained in the collection. Throughout the repository, Orchard-Agentic refers to the broader collection, while Orchard refers to the original paper and framework.

That distinction is the first thing to understand, because it tells you what kind of artefact this is. A library has one API and one version. A collection has a set of projects at different stages, some of which are papers with code, some of which are infrastructure, and some of which are datasets. The projects/ directory indexes every project built on Orchard Env, and there is a documented process for adding your own.

The paper is on arXiv as Orchard: An Open-Source Agentic Modeling Framework by Peng et al., with the identifier 2605.15040, and the research data is published on Hugging Face as the microsoft/Orchard dataset, with a swe subset of 107K SWE trajectories and a gui subset of 3,070 multimodal browser-navigation rollouts.

The project is MIT licensed, the primary language is Python, the default branch is main, and the last push to the repository was on 2026-10-09. There are no GitHub releases, and the documentation site is at microsoft.github.io/Orchard-Agentic.

The four layers, and the one sentence that explains the design

The architecture is a four-layer table, and the explanatory sentence above it is the clearest statement of the design intent: Orchard Env provides a stable service rather than a piece of any one training stack.

The layers are:

| **Recipes** | The research. Open SFT + RL recipes explored on top of the foundation — Orchard-SWE, Orchard-GUI, and Orchard-Claw — plus follow-on work such as OpenWebRL and OpenForge RL. Everything built on Orchard is indexed in [`projects/`](projects/). |
| **Orchard Env** ([`orchard_env/`](orchard_env/)) | The foundation. A Kubernetes-native sandbox service + Python SDK that spins up thousands of isolated containers on demand and drives multi-turn agent ↔ sandbox interaction (exec, file I/O, git patches) over HTTP. |
| **Orchard Eval** ([`orchard_eval/`](orchard_eval/)) | Evaluation. Runs any agent harness — `codex`, `pi`, `mini-swe-agent`, … — against SWE-bench Verified on Orchard Env sandboxes, graded by the official SWE-bench harness. See [Evaluation](#evaluation). |
| **Trainer** (`trainer/slime/`) | RL training stack — a [slime](https://github.com/THUDM/slime) fork vendored as a git submodule ([MSR-Orchard/slime](https://github.com/MSR-Orchard/slime)), with Orchard rollout code under [`examples/orchard_swe/`](https://github.com/MSR-Orchard/slime/tree/main/examples/orchard_swe) and [`examples/orchard_gui/`](https://github.com/MSR-Orchard/slime/tree/main/examples/orchard_gui). See [Training](#training). |

The consequence of the stable-service idea is stated directly: research reuses the same substrate for trajectory distillation, on-policy RL rollouts and evaluation, so datasets, training recipes and evaluation protocols stay portable across harnesses, domains and projects instead of being rebuilt for each new study.

That is the thing that makes the collection worth more than a single paper's worth of code. Without a shared environment service, every new study rebuilds its sandbox layer, and a result in one study is not comparable with a result in the next because the environments differ. With one, the environment is a dependency like a database, and a recipe is a set of scripts on top of it.

The naming reflects the layering too. Orchard Env is the substrate, and it is the layer that a project outside the collection would most plausibly adopt, because the evaluation and training layers are tied to a particular research question while the environment is not.

The three original recipes, and what each one is for

The three studies from the Orchard paper are different domains, different harnesses and different reward mechanisms, over one environment service.

Orchard-SWE is the software engineering one, with a Qwen3.5-35B-A3B backbone and 107K distilled trajectories as training data. Its techniques are listed in full: credit-assignment supervised fine-tuning, balanced adaptive rollout, on-policy distillation, rubric-based process reward, and value-model reranking. The headline result is 73.0 percent on SWE-bench Verified.

Orchard-GUI is the browser one, with a Qwen3-VL-4B backbone, and the document lists the GUI dataset subset of 3,070 multimodal browser-navigation rollouts as its training data.

Orchard-Claw is the third, and the name gives away its domain, which is CLI and tool agents.

Three domains with three different reward mechanisms is the point. A framework that proved itself on one task type would leave the question open about the others, and the fact that the recipes share only the environment underneath is the evidence that the environment is doing the heavy lifting rather than any particular reward trick.

The headline numbers are the ones to look at when comparing with other work, and they are stated in the table alongside the technique that produced them, which is more useful than a bare figure. The evaluation is done through the Orchard Eval layer against SWE-bench Verified on Orchard Env sandboxes, graded by the official SWE-bench harness, so the grading is not the authors' own.

That last point is the one that decides whether you can believe the number. A benchmark graded by a harness you wrote is a measurement of your harness, and a benchmark graded by the official one is a measurement that another group can reproduce.

OpenForge RL: training inside the harness you actually deploy with

The July 2026 release, OpenForge RL, is the most recent piece of work in the collection and the one with the most interesting argument.

It extends Orchard to train agents inside their real deployment harnesses, ZeroClaw, OpenClaw and Codex, instead of the simplified reimplementations that open training stacks usually require, and the stated effect is removing the train and deploy mismatch.

That mismatch is a real and widely discussed problem. A model trained against a simplified environment learns the simplification, and the first time it meets the real harness it behaves differently, and the difference shows up as a benchmark number that does not transfer to production. The fix here is structural: a lightweight proxy records the harness's own inference calls and reconstructs them into samples for any RL codebase, for example veRL, while Orchard Env launches each rollout as a remote container, so any harness pairs with any environment.

The sandbox design is what makes that possible, and the documentation says so directly: every sandbox ships with popular agent harnesses, codex, claude, pi, opencode and hermes, already on the PATH, so switching the harness you train or evaluate against is a change of command, not a change of image.

That is an elegant piece of infrastructure design. A sandbox image that pinned one agent tool would force a rebuild for every new tool, and the training and evaluation harnesses would drift apart. With the tools on the PATH, the harness is a parameter.

The reported results are in the same release note. OpenForge-GUI at 8B reaches 37.7 on OSWorld-Verified and 72.3 on WebVoyager. OpenForge-Claw at 30B-A3B reaches 33.7 on QwenClawBench and 28.1 on MCPAtlas.

The code is at MSR-Orchard/OpenForge-RL with a paper on arXiv at 2607.21557 and details in the projects directory.

OpenWebRL, and the honest problem of training on live websites

The June 2026 release, OpenWebRL, takes a different tack: it extends Orchard-GUI into a full online multi-turn reinforcement learning study on live websites, rather than on a simulated or archived version of the web.

The list of what that requires is the interesting part, because each item is a failure mode of live-web training. There is supervised initialization, multimodal context management, trajectory-level success judging, and multi-turn policy optimization. And the environment itself is a fault-tolerant live-browser environment built on Orchard Env, with navigation retries, timeout handling and structured failure attribution, so that unstable website behaviour stays separable from model behaviour at training scale.

That last clause is the hard part of the whole idea. When an agent fails during training, the question is whether the model made a bad decision or the website served a broken page, a modal, or a redirect, and a training run that cannot separate those two learns from noise. Structured failure attribution is the mechanism, and it is the piece a reader should look at in the code.

The reported numbers are OpenWebRL-4B reaching 67.0 percent on Online-Mind2Web and 64.0 percent on DeepShop, from only 0.4K initialization trajectories and 2.2K open-ended RL tasks. The documentation describes that as a new open-source state of the art on live-web benchmarks, competitive with OpenAI CUA and Gemini CUA.

That is a small data budget next to a SWE-bench run, and the reason is visible in the design: a live-web task is expensive because each rollout touches real servers, so the project has to get more out of each one, and 2.2K tasks with a 0.4K initialization set is a very different ratio from 107K distilled trajectories in the SWE recipe.

The code is at OpenWebRL/OpenWebRL and the paper is on arXiv at 2606.02031.

Where Orchard-Agentic is the wrong tool

The first limit is the infrastructure. Orchard Env is a Kubernetes-native sandbox service that spins up thousands of isolated containers on demand, and that is a cluster cost with a cluster's operational surface. A team that wanted a small evaluation harness for a dozen tasks does not need it, and a team that wants one needs to be able to run Kubernetes and pay for the nodes.

The second is that the training layer is a fork. The Trainer is a slime fork vendored as a git submodule, with the Orchard rollout code living in the examples directory of that fork, and a .gitmodules file in the repository. Forking a training framework is a normal research move, because the training loop is exactly where a research group needs to change things, but it means upstream changes arrive as submodule bumps rather than as merges, and any divergence you introduce is yours to maintain.

The third is that the collection is a moving target. The projects are indexed in a directory, the naming has been adjusted to fit the collection, and a follow-on project can add a name to the established list at any time. The documentation does provide a process for adding a project, which is the right thing, and a collection that grows is the point, but it means the surface you depend on is defined by a directory listing rather than by a versioned API.

The fourth is the model sizes and the cost. The recipes run backbones in the tens of billions of parameters, and the results reported are for those backbones. A team with a smaller model, or with a different one, gets the environment and the evaluation, not the result, and reproducing the headline numbers means reproducing the training budget too.

And the fifth is that this is research infrastructure rather than a product. There is no GitHub release, there is no stable version, and the pieces that would make it usable as a service, the autoscaling of the sandbox pool, the cost accounting, the authentication, are the parts a research group needs but does not necessarily build. The licence and the code are open, so building on it is allowed, and building a service on it is the work.

Editorial conclusion

Orchard-Agentic is worth studying if you are building training or evaluation infrastructure for coding and browser agents, because the separation between the environment service and the research recipes is the design decision that makes results portable, because the sandbox ships with several popular agent harnesses already on the PATH so switching harness is a command rather than an image, and because the follow-on projects show the same substrate reused for a live-website RL study and for training inside real deployment harnesses. It is the wrong tool if you want a library to call, and it is the wrong tool if you are not prepared to run Kubernetes. Before you build on it, check three things: that you have the infrastructure, because Orchard Env is a Kubernetes-native sandbox service and a Python SDK, and the thousands of isolated containers it spins up on demand are a cluster cost rather than a local process; that you understand the training stack is a fork, since the Trainer layer is a slime fork vendored as a git submodule with the Orchard rollout code living in its examples tree, so a change to that submodule is a change to your trainer; and that you read the evaluation layer's design, because Orchard Eval runs any harness against SWE-bench Verified on Orchard Env sandboxes and grades with the official SWE-bench harness, which is what makes the numbers comparable rather than self-reported.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/Orchard-Agentic on GitHub
4. Project website
5. README