Hugging Face's Harness Adapters Train Local Models for the Agent You Actually Use

Hugging Face’s harness-hub team has released harness-specific LoRA adapters: small additions to a base model trained inside the coding agent that will use them. Its November 6 community announcement describes reinforcement learning inside unmodified pi, OpenCode and Hermes harnesses, with early smoke tests reporting fewer tool calls while maintaining or improving held-out accuracy.

For developers running local coding agents, the consequential change is the unit of adaptation. Instead of replacing the entire model or modifying an agent’s implementation, they can evaluate an adapter trained for that model-and-harness combination. The authors also publish the surrounding recipe: verifiable tasks, shared model serving and checks intended to stop training from rewarding shortcuts. Final training runs were described as streaming live; the early results should not be read as completed final-run benchmarks.

Adapt to the harness, not just the task

A harness supplies tools, prompts and control flow. Changing it changes the environment in which a model decides what to do next. That makes a generally capable coding model an incomplete description of the agent readers actually run.

The release uses one LoRA adapter per model and harness. Its training lineup includes Liquid AI’s LFM2.5-24B-A2B and LFM3-1.7B, plus TwIL-8B as an experiment. The authors describe TwIL as a reasoning model not previously trained on agentic data, making that run an exploration of whether this recipe can teach agent behavior.

Serving is part of the practical argument. One vLLM instance holds the base weights and serves multiple named adapters. During training, each harness’s trainer requests its own adapter; during evaluation, checkpoints can share the same base model. This gives teams a way to compare specialized policies without separately serving a full copy of the base weights for each checkpoint. It does not remove the hardware requirements of the base model itself.

Efficiency has to follow correctness

The training reward combines the task verifier with a small tool-call efficiency bonus, awarded only on correct rollouts. That ordering matters: fewer calls are useful when the agent still completes the work. An agent that stops early and fails is not an efficiency improvement.

The evaluation design holds out 40 Repo2RLEnvs tasks and 150 SmolDataEnvs tasks. However, the new trajectory-derived collection is narrow: 253 of its 270 tasks are build tasks, with 11 repair tasks, six extension tasks and no question-answering tasks. Most also come from one trajectory dataset. These limitations make the release a promising experiment for local-agent developers, rather than evidence of general improvement across repository maintenance.

Readers comparing adapters should therefore keep the harness fixed and measure successful completion alongside calls per solved task. Repair-heavy teams need repair-heavy evaluations of their own. For a broader framework, see our guide to evaluating agents.

Block shortcuts before they become training rewards

The accompanying safeagents repository documents a proxy that checks model tool calls before the harness receives them. It supports OpenAI Chat Completions and Anthropic Messages interfaces, including streaming. Detected blocked calls become text notices, so the harness receives no executable call for that attempt.

In the reported training setup, rule-based checks target undeclared tools, previously unmentioned hosts and detected misuse such as test tampering or attempts to retrieve published answers. Task-specific plugins identify answer sources that generic rules would not know about. A rollout containing a blocked-call notice receives zero reward.

These are targeted controls, not proof that every shortcut is caught. The announcement also describes a false-positive fix: an overly broad grader-file rule conflicted with a legitimate task to build an auto-grading library. Teams adopting the approach need to check both prohibited behavior and legitimate work against their rules.

A reproducible path, with work still required

The broader Repo2RLEnv project turns existing development material into Harbor tasks for training and evaluation. Its documentation explicitly calls generated tasks a starting point, with reference solutions, controls and evaluation labels recording how far verification has progressed. The announcement’s trajectory-derived environments are being moved into that project.

For local-agent builders, the useful next step is a controlled comparison of a matching adapter against its base model on representative tasks. Training a new adapter is a larger undertaking: it requires trustworthy environments, held-out evaluation and rules tailored to the task’s possible shortcuts. The release makes that workflow inspectable and reusable. Its strongest immediate contribution is a concrete way to specialize a model for its harness while measuring whether the specialization actually helps.