The Harness Became the Training Environment
Most agent training still has a quiet mismatch at its center: the model is trained in a laboratory scaffold, then deployed inside a real harness with different tools, state transitions, and failure modes.
A new OpenEnv workflow attacks that mismatch from the other direction. In a post on October 5, Hugging Face CEO Clement Delangue said the project can run Claude Code, Codex, Hermes, Pi, OpenCode, and other coding harnesses as reinforcement learning environments without changing the harnesses or the training code.
The claim is worth treating as an announcement until the artifacts and independent runs are examined. But the mechanism is concrete. The harness talks to what it thinks is a model API. A capture proxy records the interaction, forwards requests to vLLM, preserves sampled token IDs and log probabilities, and hands the resulting sequences to TRL.
The harness is no longer a wrapper around training. It is the environment being trained against.
The proxy is the product boundary
The obvious way to train an agent inside a coding harness is to reimplement the harness as an environment. That is also the way to quietly create a benchmark that no longer resembles the thing people use.
The OpenEnv approach described by Delangue inserts a proxy instead:
real coding harness
|
v
model API capture proxy
|
+--> vLLM inference
|
+--> token IDs and log probabilities
|
v
TRL reinforcement learning
The proxy speaks four API formats named in the announcement: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Gemini. That matters because the harness remains the object under test. Its tool loop, message formatting, retries, context handling, and stop conditions stay in the path.
A training scaffold can tell you whether a model learns a task. Training through the real harness can tell you whether the model learns to operate under the same control loop that production will enforce.
The numbers are about transfer
The announcement includes a useful comparison. Delangue reports that the same model and weights scored 62 percent under Mini-SWE-Agent and 33 percent under Claude Code before the new training setup.
That gap is not a footnote. It is a measurement of harness dependence.
The post reports the following results for LFM2.5-2.6B:
| Training setup | Reported result | What it suggests |
|---|---|---|
| OpenCode, one harness | 34% to 58% | Strong improvement where training occurred |
| Four harnesses at once | 42% to 54% | More transfer across harness boundaries |
| SFT on 3,189 Qwen3.8-27B rollouts | Plateau at 47.5% | Static demonstrations underperformed the reported RL runs |
| Solved tasks with a tool-call bonus | 31% fewer calls | Reward shaping changed behavior beyond task completion |
These are reported results from the announcement, not an independent benchmark. They still point at the right systems question: does training improve the agent, or does it improve one narrow implementation of an agent?
The four-harness result is the more important one. A model that improves only inside the harness that generated its rollouts may have learned interface habits. A model that improves across multiple harnesses has stronger evidence of transferable behavior, though four harnesses are not a proof of generality.
Reward functions reach into the harness
The most revealing detail is the tool-call bonus.
Delangue says a small reward for solving a task in fewer tool calls produced 31 percent fewer calls on tasks the model already solved, in every harness, and about half under Codex. That is a compact demonstration of why agent training cannot be evaluated only by final answer accuracy.
The harness exposes a sequence of choices:
- whether to inspect a file or guess,
- whether to run a test or edit immediately,
- whether to retry a failed command,
- whether to ask for more context,
- and when to stop.
A reward that counts only task completion leaves those choices unconstrained. A reward that also counts tool calls shapes the control policy. It may reduce waste, but it can also teach an agent to stop too early or avoid a tool that would have made the result safer.
That is the verifier problem in a new location. The training system needs a reward contract that measures the behavior operators actually want, not only the artifact that is easiest to score.
The harness is where capability becomes operational
Agent capability is often described as a model property. In practice it is a path through a harness.
The model generates a message. The harness decides whether that message becomes a tool call. The tool returns an observation. The harness decides how much of it enters context. The model proposes the next action. A terminal error, a timeout, or a hidden approval gate can change the entire trajectory.
Training the model outside that loop creates a distribution shift that is easy to miss. The model may learn to solve tasks with a tool abstraction that production never exposes. It may learn a context format the deployed harness does not produce. It may optimize for a stop condition that disappears once a real approval gate is added.
A capture proxy does not solve every problem. It makes the real loop visible to training, which is a better starting point than rebuilding a shadow version and hoping the two stay aligned.
The security boundary moves with the trace
There is also a security consequence.
If the harness becomes the environment, the training system captures more than model text. It captures tool requests, observations, error paths, and potentially sensitive state. The proxy and environment layer now sit on a trust boundary between the model, the repository, external services, and the trainer.
Operators should ask:
- Which tool outputs are recorded, and for how long?
- Are secrets removed before traces reach the trainer?
- Can a model influence the reward through a side channel?
- Are file changes and network actions replayable in an isolated environment?
- Does the capture proxy preserve enough context to audit a successful task?
- Can the harness be trained against production credentials, or only disposable ones?
Open source code helps answer those questions, but it does not answer them automatically. A transparent capture path is useful only when the operator can inspect its data retention, isolation, and replay boundaries.
Why this matters for open models
Open weights are frequently evaluated as if the checkpoint were the unit of openness. Agent training makes that definition too small.
A useful open agent stack needs at least four inspectable layers:
| Layer | What must be visible |
|---|---|
| Model | Weights, tokenizer, configuration, and license |
| Harness | Tool schemas, state transitions, retries, and stop rules |
| Environment | Sandboxing, fixtures, network access, and task setup |
| Verifier | Reward calculation, success criteria, and failure classification |
The OpenEnv repository describes itself as an interface library for reinforcement learning with environments, and its public project includes sandboxed environment patterns and integrations. The capture-proxy workflow described in the announcement extends that idea to harnesses that were not written as training environments in the first place.
That is the architectural shift. The path from open model to useful open agent runs through the environment and the harness, not around them.
What operators should measure
When adopting this workflow, do not report only the model’s task score. Record at least:
- success rate by harness,
- transfer from one harness to another,
- tool calls per successful task,
- recovery rate after tool errors,
- trace completeness,
- reward variance across environments,
- and the percentage of failures caused by infrastructure rather than reasoning.
A lower tool-call count is not automatically better. A faster agent that skips validation can be less reliable than a slower one that leaves a reproducible trail.
The verifier should therefore score both the result and the path. If the path is unobservable, the training loop is optimizing a number the operator cannot fully audit.
The harness is no longer a wrapper
The announcement’s largest consequence is not that another open project can connect to TRL. It is that the boundary between model training and agent operations is getting thinner.
The next generation of agent models will be shaped by the environments that record their actions, the harnesses that expose their tools, and the graders that decide whether a trajectory counts.
That makes the harness part of the model’s effective behavior. It also makes the harness part of the training data, the security boundary, and the evaluation claim.
If you train in a fake loop, you get a model for the fake loop.
Sources
- Hugging Face OpenEnv repository (public environment interface and project documentation)
- Clement Delangue’s X announcement (capture proxy, supported API formats, reported results, and tool-call reward experiment)
- OpenEnv Harbor environment documentation (harness integration documentation)
- TRL repository (reinforcement learning training library referenced by the announcement)