Summary of "Harness or Model? Isolating the Harness Effect in Agentic Coding with a Contamination-Controlled Private Suite"
Summary (Overview)
- This study directly measures whether vendor-native agent harnesses outperform neutral multi-provider harnesses when paired with the same language model on a private, contamination-controlled suite of 256 coding tasks.
- Using paired same-model contrasts (claude-opus-4-8 and gpt-5.5 each run under both their vendor-native SDK and the neutral deepagents harness), the study finds no resolvable average solve-rate advantage for either harness type: Opus difference = −1.25 pp (95% CI [−10.0, +7.5]), GPT-5.5 difference = +1.25 pp (95% CI [−4.4, +6.9]).
- A post-hoc workload interaction emerges on Opus 4.8: the native harness trails by 9.0 pp on repository tasks but leads by 23.7 pp on contest tasks (permutation p = 0.003), though this partition was chosen after seeing the data.
- The neutral harness costs 1.2–1.6× more per solved task on observed usage, takes longer, and hits the wall-clock ceiling far more often—22 of 81 ceilinged runs had already produced passing patches.
- A telemetry usage-semantics defect was discovered post-study: cache tokens were double-counted for the neutral harness, inflating its apparent cost by 4.8–7.7× in the original ledger; all cost figures were re-derived from raw per-turn events.
Introduction and Theoretical Foundation
An agentic coding system couples a language model to a harness: the tools, prompts, truncation policies, and control flow that convert a chat model into an autonomous software engineer. Vendors ship harnesses tuned to their own models, and practitioners commonly assume the vendor-native pairing solves more tasks. However, existing benchmarks either vary the model while holding the harness fixed, or report vendor harness and model as one opaque system—neither design answers the question of which harness software to use when the model is already chosen.
The study was planned in June 2026 and executed in August 2026 around two research questions fixed in the program plan before any scored run:
- RQ1: Does a vendor-native harness have a capability premium over a neutral harness on the same model? (Hypotheses H1–H3 cover existence, vendor dependence, and concentration by task type.)
- RQ2: Is the capability winner also the cost-per-solved-task winner? (Hypothesis H4)
Two methodological problems shape the design:
-
Contamination: Public benchmarks leak into training corpora, so the suite is private—179 repository tasks mined from four production codebases plus 77 contest tasks published after a mechanically derived eligibility date (2026-03-02 = newest binding cutoff among study models, Opus 4.8 at 2026-01-31, plus a 30-day buffer). A machine-readable cutoff registry was frozen before data collection, and a runtime drift gate verifies served model identity before every scored phase.
-
Cost measurement: Agent evaluations increasingly report dollar costs derived from harness-reported token usage. The study's own telemetry normalizer applied one SDK's convention for cache tokens to all three harnesses, producing a defect (§5.1) that inflated cost estimates for the neutral harness by 4.8–7.7×. This revision re-derives every cost figure from raw per-turn events.
Methodology
Experimental Design
Six cells cross three harnesses with four models:
| Cell | Harness | Provider | Model | Role |
|---|---|---|---|---|
| C1 | claude-sdk (claude-agent-sdk 0.2.130) | anthropic | claude-opus-4-8 | vendor-native |
| C2 | deepagent-sdk (deepagents 0.7.4 / LangGraph 1.2.10) | anthropic | claude-opus-4-8 | neutral, same model |
| C3 | codex-sdk (openai-codex 0.1.0b3, CLI 0.137.0a4) | openai | gpt-5.5 | vendor-native |
| C4 | deepagent-sdk | openai | gpt-5.5 | neutral, same model |
| C5 | deepagent-sdk | gemini-3.5-flash | cheap-frontier side cell | |
| C6 | deepagent-sdk | openrouter (DeepInfra pin) | deepseek/deepseek-v3.2 | open-weights side cell |
Key design features:
- Pool selection: A screening pass ran all 256 tasks under C1 and C3 at k=1. All 24 discordant tasks formed the "band"; remaining slots filled alternately from both-pass and both-fail pools to a target of 80 tasks (28+28), locked by hash.
- Repeats: k=2 for core cells C1–C4, k=1 for side cells C5–C6, giving 800 main-run keys.
- Execution substrate: One KVM microVM per run, identical repository seeds and prompts, a shared wire protocol, and an append-only canonical event ledger. Hypervisor isolation is the only sandbox.
- Wall-clock ceiling: 1,200 seconds; the driver cancels the agent and the oracle grades whatever patch is present at cancellation.
- Grading: Offline, Docker-isolated oracle with manifest-driven service sidecars (PostgreSQL, MSSQL, mock-OIDC), validated by polarity (gold passes, base fails) and determinism invariants.
Statistical Methods
- Primary uncertainty: Task-level bootstrap intervals (10,000 resamples of tasks)
- H1 test: Sign-flip permutation on per-task differences
- H2 test: GEE logistic model (pass ~ nativeness × vendor + workload, exchangeable within-task correlation, robust standard errors)
- H3 test: Workload label permutation (interaction null) and stratified sign-flip test
- Multiplicity: Benjamini–Hochberg FDR over primary tests
Empirical Validation / Results
Capability Results
Paired contrasts (n = 80 tasks each):
| Contrast | Model | Difference | Task-bootstrap 95% CI | Sign-flip p | McNemar discordant (p) | Clustered McNemar p |
|---|---|---|---|---|---|---|
| C1 – C2 | claude-opus-4-8 | -1.25 pp | [-10.0, +7.5] | 0.89 | 17:19 (0.87) | 0.78 |
| C3 – C4 | gpt-5.5 | +1.25 pp | [-4.4, +6.9] | 0.83 | 11:9 (0.82) | 0.65 |
Cell solve rates (frozen pool of 80 tasks):
| Cell | Harness / model | Solve rate | 95% CI (pp) |
|---|---|---|---|
| C1 | claude-sdk / Opus 4.8 | 48.8% | ±10.2 |
| C2 | deepagents / Opus 4.8 | 50.0% | ±10.3 |
| C3 | codex-sdk / GPT-5.5 | 55.6% | ±10.2 |
| C4 | deepagents / GPT-5.5 | 54.4% | ±10.5 |
| C5 | deepagents / Gemini 3.5 Flash | 44.9% | ±11.1 |
| C6 | deepagents / DeepSeek V3.2 | 19.7% | ±9.3 |
Workload split (exploratory, post-hoc):
| Model | Stratum | n | Native | Neutral | Diff. (pp) | Task-bootstrap 95% CI | p |
|---|---|---|---|---|---|---|---|
| Opus 4.8 | repository | 61 | 37.7% | 46.7% | -9.0 | [-17.2, -0.8] | 0.061 |
| Opus 4.8 | contest | 19 | 84.2% | 60.5% | +23.7 | [+2.6, +44.7] | 0.092 |
| Opus 4.8 | interaction | -32.7 | [-56.7, -9.7] |
The interaction test gives p = 0.003 for the workload-label permutation and p = 0.014 for the stratified sign-flip test. With Benjamini–Hochberg control over the four primary tests, the interaction has q = 0.013.
Correctness vs. autonomous completion: 22 of 81 graded runs that hit the wall-clock ceiling had produced passing patches (C2: 11 of 32, C4: 4 of 7, C5: 2 of 12, C6: 5 of 29). The neutral harness hit the ceiling far more often (C2: 32 of 160 final attempts vs. C1: 1; C4: 7 vs. C3: 0) and made about twice the tool invocations per session (medians C1 44.5 vs. C2 90.5; C3 51.5 vs. C4 75).
Cost Results
The telemetry defect: The host normalizer added cache-read and cache-write tokens to tokens_in when they appeared in usage records. This is correct for Anthropic's API (which reports input exclusive of cache) but double-counts for LangChain's usage_metadata (which reports input inclusive of cache). The result: the neutral harness's cache-read share appeared to be ~48% instead of the true 87–98%.
Corrected cost per cell (USD, list prices):
| Cell | Corrected estimate ($) | SDK-reported ($) | Passes | Corrected $ per solve |
|---|---|---|---|---|
| C1 | 242 | 295 | 78 | 3.10 (3.79 by SDK) |
| C2 | 406 | n/a | 80 | 5.07 |
| C3 | 251 | n/a | 87 | 2.88 |
| C4 | 292 | n/a | 86 | 3.39 |
| C5 | 164 | n/a | 35 | 4.67 |
| C6 | not estimable | n/a | 14 | not estimable |
Observed-cost ratios per solved task:
| Ratio | Pricing basis | Observed usage | Task-bootstrap 95% CI |
|---|---|---|---|
| C2 / C1 | both at list prices | 1.63 | [1.29, 2.09] |
| C2 / C1 | C1 at SDK-reported cost | 1.34 | [1.06, 1.71] |
| C4 / C3 | both at list prices | 1.18 | [1.05, 1.33] |
Account-level reconciliation: On the OpenAI account (only 6 rows without usage records), the corrected estimator reproduces billed spend within 2–4%. On the Anthropic account, a residual of 25–29% remains (58 rows without usage records). Allocating the unrecorded spend entirely to either cell moves the Opus ratio between 0.7 and 2.3, so the billed ordering on Anthropic is unresolved.
Theoretical and Practical Implications
-
Workload composition changes the aggregate comparison: The Opus contrast of −1.25 pp is 61/80 of a −9.0 pp repository effect plus 19/80 of a +23.7 pp contest effect. A single aggregate solve rate is not the quantity a deployment decision needs; teams should measure the harness effect under their own workload mix.
-
Correct output and autonomous completion are different endpoints: A benchmark that scores only the patch will call harnesses equivalent when a user waiting for the agent to finish would not. Both endpoints—solve rate and time-to-completion—should be reported together.
-
Measured token cost and billed operational cost need different evidence: Raw per-turn events identify what every recorded turn consumed, but billed spend includes turns that never produced a usage record. Researchers must pin usage semantics before applying prices, then reconcile against money that left the account.
-
A cap experiment needs demonstrated exposure to the cap: The truncation probe was inconclusive because the archive did not retain raw tool-output lengths, making the manipulation check impossible.
-
Methodological contribution: The study documents a usage-semantics defect where input-token fields are cache-inclusive on some SDKs and cache-exclusive on others—a normalizer assuming one convention doubles the other. This is a reproducible source-to-ledger reconciliation and account-level check against billed spend.
Conclusion
Neither same-model contrast resolved an average harness advantage on the private 80-task pool. The Opus 4.8 difference is −1.25 pp with a task-bootstrap interval of [−10.0, +7.5], and the GPT-5.5 difference is +1.25 pp with an interval of [−4.4, +6.9]. On Opus, the average combines a repository stratum favoring the neutral harness with a contest stratum favoring the native one—a post-hoc pattern with permutation p = 0.003 that a designed replication should test. The neutral harness reached the ceiling more often, made about twice the tool calls, and on observed usage at list prices cost 1.2–1.6× as much per solved task, with the billed ordering on Anthropic unresolved.
The study's central methodological takeaway: pin every SDK's usage semantics before pricing a token, compare raw per-turn events with the ledger, and compare the ledger with billed spend. The tasks remain private to preserve the suite's contamination-controlled status; the orchestrator, grading oracle, reanalysis code, and derived aggregates are released for replication.
Future directions: A designed replication should pre-specify the workload strata, power the contest stratum (19 tasks here), and use three repeats. Trajectory-level measurement is needed to determine whether correct patches exist earlier in ceilinged trajectories and whether stopping can be optimized safely.
Related papers
- ModularRSI: Modular and Generalizable Recursive Harness Self-Improvement
ModularRSI achieves generalizable recursive harness self-improvement by contrastively analyzing trajectories and evolving five independent harness modules, outperforming joint evolution and transferring across unseen tasks, domains, and foundation models.
- SWE-MeM: Learning Adaptive Memory Management for Long-Horizon Coding Agents
SWE-MeM trains agents to proactively compress their own context via a learned memory tool, achieving 60.2% on SWE-Bench Verified with a 30B model under a 32K budget, outperforming larger models and reducing token usage.
- An Empirical Study of Harness Design for Coding Agents
Harness components are conditional tools: context management matters most under tight budgets, planning scaffolds weak models but saves costs for strong ones, and action-space effectiveness depends on model bash proficiency.