Qwen3.8-27B edges past Fable 5 by passing itself notes

A 27-billion-parameter open-weight model, served on local hardware, climbed from 69.2% to 92.4% pass@1 on the 100 latest hard LiveCodeBench problems, and nobody retrained anything. The trick was splitting the work between fresh copies of the same model and letting them leave each other notes on disk; the code, the paper and the run data are published as GVS5H on Github.

At a glance

• The paper calls the method ledger-based zero-shot self-orchestration: a training-free scaffold tested across nine open and closed-weight models, yielding gains of up to 23.2 percentage points on pinned backends.
• On the cloud side the win is price rather than accuracy, with orchestrated GPT-5.6-Terra reaching 88.0% pass@1 against Claude Fable 5's 90.4%, at 19% of the cost.
• The authors are explicit that the gains are not universal: across the nine models tested, some came out unchanged and some came out worse under exactly the same scaffold.

If you have not followed this benchmark: LiveCodeBench collects contest problems from LeetCode, AtCoder and Codeforces and stamps each with a release date, so models can be tested only on problems published after their training cutoff, according to its own documentation. That documentation also reports that closed API models generally beat open ones, and that the open models clearing the bar are fine-tuned variants of 30-plus-billion-parameter models.

Qwen3.8-27B finishes at 92.4%, Fable 5 at 90.4%

The open-weight number is the one people will repeat. Qwen3.8-27B, served locally, goes from 69.2% to 92.4% pass@1 on the 100 latest hard problems, slightly above Fable 5. The weights are untouched; only the wrapper around them changed.

The cloud route buys cost, not a lead. Orchestrated GPT-5.6-Terra lands at 88.0% pass@1 against Fable 5's 90.4%, at 19% of the cost. The arXiv paper also reports the pair at 85.0 against Fable 5's single-call 87.4, with p = 0.59.

The same paper prices that comparison at $11.71 against $61.11 per 100-problem pass, with p below 10⁻⁴. The abstract frames the result as two routes to frontier accuracy: cheaper on closed weights, slightly better on self-hostable ones.

How does a model get better by writing itself notes?

Because the notes are the memory. A fresh instance acts as manager: it reads the problem, decomposes it, and writes into a shared filesystem workspace holding three things, a plan, notes and the current solution. Short worker calls, all of them the same model, each take a slice and write back.

Think of a kitchen ticket rail. No cook holds the whole order in their head, the slip does, and each station reads the slip instead of remembering the last twenty minutes. The paper's transcript analysis, as quoted on arXiv, names two recurring mechanisms:

context management, in which short worker calls and shared notes organize state and reduce truncation, and problem decomposition.

None of that comes free. The paper's own accounting, according to arXiv, puts the cost of running a manager at roughly triple the token bill of the single-pass baseline it is compared against.

Anthropic has reported a similar arrangement in production: per its engineering write-up, a lead agent with Claude Opus 4 and Claude Sonnet 4 subagents beat single-agent Opus 4 by 90.2% on an internal research eval, credited to subagents running in parallel with their own context windows.

Across nine models the gain reaches 23.2 points, and for some it goes the other way

The nine-model panel, as the arXiv paper describes it, is five open-weight models spanning 9B to roughly 2.8T parameters plus four frontier closed models. The abstract's up-to-23.2-point figure is scoped to pinned backends; individual results in the paper run both higher and below zero.

Per the paper, Qwen3.6-35B with reasoning off moved by −1 to −9, which the authors call null or negative. Kimi-K3 gained 30.4 points and Minimax-M3 gained 11.0 over five paired passes with reasoning off, both at p below 10⁻⁴.

In a single pass at a 128 000-token cap, the same two models came in at +42 and +12. The highest score in the study, per the paper, belongs to Opus-5 with a manager, at 91% in one pass.

Two flags separate the manager from the baseline

The repo ships the harness, not a demo. You need uv and a key for the backend you want; the run pins LCB_RELEASE=release_v6, a 128 000-token cloud cap and a 7 200-second timeout, then calls run_bench.py over 100 problems with eight parallel workers.

One argument does the switching: --engine multiagent runs the manager, --engine single the one-call baseline. Other backends use anthropic, dashscope and openrouter prefixes, each with its own key; scores print at the end and workspaces land in runs/ws/. Code is MIT, the paper and run data CC BY 4.0.

Everything here rests on one paper and one repo, and the abstract does not name which of the nine models came out unchanged or worse. In our view the honest line is the tripled token bill: the local route's edge appears to be bought with volume.

Whether the 23.2 points replicate

According to arXiv, the paper went up on 27 August 2026, submitted by Sang Won Lee. What happens when the problem set rolls forward is open: the harness pins release_v6 and the newest hundred hard problems, and no date is named for a run on a later release.