OpenBench M3 — Harness Comparison

Five coding-agent harnesses on the same model (gpt-5.5-medium), 3 tasks × 5 trials each, run locally on 2026-07-02.

A shakedown of the benchmark pipeline on a real 75-run spend — read it as “the harness works and here is what it found,” not a leaderboard.

1Speed per harness — mean wall-time with 95% CI

The one axis on which the harnesses actually separate. Bars are sorted fastest→slowest; whiskers are the 95% confidence interval of the mean (n=15). Where whiskers overlap, the difference is not resolved at this sample size.

2Correctness — success matrix with Wilson 95% intervals

Every real harness solved every task on every trial. Identical intervals mean they are statistically indistinguishable on success; only the null control (which makes no edits) separates — confirming the checkers actually discriminate.

Success = checker exit 0. Wilson 95% interval on the overall rate.

3Does the speed order hold across tasks?

Same five harnesses, one panel per task, shared time axis. pi and cursor stay fast everywhere; the slow trio (devin, codex, opencode) reshuffles task to task — the visual signature of a cluster that isn’t cleanly ordered.

4The honest view — every trial’s wall-time

All 15 raw timings per harness. pi and cursor are tight; codex and opencode are wide (sd ≈ 23 s), which is why their means blur together. The vertical tick marks each harness’s mean.

5Timing table (the table view)

Mean ± 95% CI half-width, n=15 per harness. “Separated” pairs have non-overlapping mean intervals.

M3.5The harness tax in tokens — added 2026-07-02

The matrix re-run (3 trials) with token capture on every adapter. Correctness is still a tie (all 9/9), so the story is cost per solved task. The token tax spans ~8× — wider than the wall-time spread — and the token order is not the time order.

Tokens per solved task — with 95% CI

Two different axes — wall-time vs token tax

Each harness placed by mean wall-time (x) and tokens per solve (y). If the two axes agreed, the points would fall on a line; they don’t.

opencode and codex sit at nearly the same wall-time yet codex spends ~2× the tokens; devin is the slowest but not the heaviest. pi alone is both fast and lean.


M4.5Harder tasks — frontier still saturates — added 2026-07-03

Three harder, partial-credit tasks (make-ci-green, add-feature, misleading-error), 3 trials. The correctness ceiling held: the four clean harnesses each scored 9/9, mean-score 1.0 — separation on correctness was not achieved at gpt-5.5-medium, and a pilot predicted it (every pilot cell hit 1.0, missing the 20–80% band high). So M4.5 is again an efficiency story — this time on genuinely multi-step tasks.

devin is excluded from all M4.5 rankings — flaky, data unreliable. After an adapter regression (invalid effort-pinned model id → 0/9 instant fails, caught by the anomaly scan & fixed) the re-run was still untrustworthy: intermittent instant exit-1, two 900 s hangs (persistent-process pipe issue), and token counts internally inconsistent ~20× (716k vs 33k on the same task). Service-side instability is a credible contributor (account model access changed mid-evening). Retained in the raw data for honesty; a daytime investigation is queued.

Tokens per solved task — the clean four, 95% CI


M4Open models — most reach frontier parity — added 2026-07-03

Four open models (first-party APIs) on the same three hard tasks GPT-5.5-medium saturated in M4.5, via pi + opencode. The question: does a weaker model finally break the ceiling and show partial scores? Answer: 3 of 4 reach parityglm-5.2, deepseek-v4-flash, and kimi-k2.7-code (via pi) all score a clean 1.00, matching the frontier. Only glm-4.7-flash (free, small) drops below with genuine partial credit.

The efficiency thesis in one number: all 72 real agent runs (4 open models × 2 harnesses × 3 hard tasks × 3 trials) cost ~$1.02 total — frontier-comparable open-model coding for about a dollar.

The dashboard below puts GPT-5.5-medium in the same panels as the reference. It is a legitimate head-to-head: the frontier rows come from the M4.5 run on the same three tasks, through the same pi harness, at the same 3×3 trial grid (n=9 per model). GPT-5.5 is drawn in neutral ink as the baseline; the open models carry their own hues.

Two apparent harness gaps are an opencode adapter bug, not model capability. 8 of 72 cells are exceptions from one bug in opencode.py’s 900 s timeout handler (concatenates bytes stdout with str). They’re 7× glm-4.7-flash:opencode + 1× kimi:opencode — opencode runs these models so slowly (glm-4.7-flash 789 s vs pi’s 102 s; kimi 371 vs 68) that they time out constantly and hit the crash. So the “glm-flash pi 0.47 vs opencode 0.22” gap and the kimi:opencode 0.67 are largely infra artifacts. kimi is fully capable (kimi:pi = 1.00). The 8 cells are excluded from the capability scores below; the bug is filed.

Mean score — four open models meet the frontier reference

Tokens per solve — parity at comparable-or-fewer tokens

Wall-time per solve

Cost per solve — measured open spend vs frontier list price

Per-task score — parity isn’t a pooling artifact

The numbers (table view)

Per model, pi-only, n=9 (3 tasks × 3 trials). GPT-5.5-medium is the frontier reference (M4.5 run). $/solve is measured API spend for the open models; the GPT-5.5 figure is an estimate at OpenAI list price (see cost chart).