# GVS5H: a filesystem ledger for one model, and a comparison that spans two scaffolds

> The method is training-free and routes fresh instances of a single model through a shared directory holding a plan, notes and the current solution. The evidence is thinner than the title: the headline comparison crosses scaffolds, and the one documented command runs a model the title does not name.

**slee-persis/GVS5H** — GVS5H: Five Qwen3.8-27B Models Match Claude Fable 5 on LiveCodeBench Hard  |  Fable 5 Level Coding for a Fifth the Price - or on a Single GPU

- Repository: https://github.com/slee-persis/GVS5H
- Stars: 746 · Forks: 92
- Language: Python
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/slee-persis-gvs5h

## The coordination layer is a directory on disk

GVS5H calls its method ledger-based zero-shot self-orchestration, and the ledger is doing real work. Fresh instances of one model are spun up per problem, and they coordinate only through a shared filesystem holding a plan, notes and the current solution. Nothing is fine-tuned: the same weights that answer one question also decide how the work splits, and the split survives between instances because the state sits in files rather than in a context window.

That choice shows up in the repository layout. Run artifacts land in two fixed places, `runs/results.json` for the numbers and `runs/ws/` for the workspaces, and `runs/` sits at the top level beside `codebase/` and `paper/`. Neither path is configurable through the documented flags. The abstract credits the gain to decomposition and persistent context, which are precisely the two properties a file-based ledger supplies: decomposition because a plan written down can be handed to a fresh instance, and persistence because notes outlive a call that would otherwise end.

## The headline number spans two different scaffolds

The repository states this in one italic line above the abstract: Opus 5 ran on an earlier version of the scaffold, in a single pass served through OpenRouter rather than five on a pinned backend. The comparison the title advertises, five Qwen3.8-27B models matching Claude Fable 5 on LiveCodeBench Hard, is therefore not a matrix where every cell ran the same harness. The abstract puts Fable 5 at 90.4% pass@1 against 93.0% for orchestrated Qwen3.8 Flash Next at 9% of the cost, and puts locally served Qwen3.8-27B at a rise from 66.8% to 92.4%.

What the page calls its Results section contains no results table. It contains the abstract, a pointer to `paper/paper_latest.pdf`, and that caveat. Eleven open and closed-weight models and the 100 latest hard LiveCodeBench problems are described, with gains of up to 25.6 percentage points on pinned backends, and the same paragraph warns that gains are not universal because some models come out unchanged or worse. The per-model numbers live in the PDF and in the committed `runs/` directory, not on the front page.

## The only command shown does not run the models in the title

The single invocation the project gives targets a different model than the one its title is about. It exports `OPENAI_API_KEY`, sets `MULTIAGENT_MODEL=openai:gpt-5.6-terra`, and runs `python escalation/run_bench.py --engine multiagent --only lcb --lcb 100 --parallel 8` from a directory named `codebase/v2-current`. Neither Qwen3.8 Flash Next nor Qwen3.8-27B appears anywhere in it.

```bash
cd codebase/v2-current
export OPENAI_API_KEY=...

LCB_RELEASE=release_v6 \
ESCALATION_CLOUD_MAX_TOKENS=128000 \
ESCALATION_CLOUD_TIMEOUT=7200 \
MULTIAGENT_MODEL=openai:gpt-5.6-terra \
uv run --no-project --python 3.12 --with 'datasets<4' --with numpy --with anthropic \
  python escalation/run_bench.py --engine multiagent --only lcb --lcb 100 --parallel 8
```

The routes for the title models are named in the three bullets below it, as `anthropic:<model>`, `dashscope:<model>` and `openrouter:<model>`, each with its own `*_API_KEY`. A Qwen model would come in through the `dashscope:` prefix, and the locally served 66.8% to 92.4% jump needs serving arrangements the page never spells out, which is the practical gap for anyone who wants the 92.4% figure rather than the abstract's wording. `--engine single` is named as the one-call baseline, which is the comparison that carries the claim, yet the documented pass uses only `--engine multiagent`, so the baseline has to be run separately to see the delta for yourself.

## `--no-project` discards the dependency file the repository ships

The root packaging file declares a project named `gvs5h`, version `0.1.0`, requiring Python 3.12 or newer, depending on matplotlib, numpy and scipy. The documented run is built the opposite way. `uv run --no-project` tells uv to ignore that file, and the environment is assembled from `--with 'datasets<4' --with numpy --with anthropic` instead.

```toml
[project]
name = "gvs5h"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "matplotlib>=3.11.2",
    "numpy>=2.5.3",
    "scipy>=1.18.1",
]
```

Two consequences follow. The cap on `datasets` exists only on the command line, so nothing in the declared dependency set records why the benchmark loader needs an older release. And matplotlib and scipy, which the root file names, are missing from the `--with` list, which fits the tree: `paper_plot_script/` stands beside `codebase/` as figure tooling rather than part of the escalation run. A `uv.lock` is committed at the root too, but `--no-project` means that lock does not govern the run being documented. Anything else pinned at the root, including `main.py` at the top level and the escalation package under `codebase/v2-current/`, is reached by path rather than by an installed entry point, so there is no importable package name to depend on even though the file declares one.

## Escalation budget and problem set arrive as environment variables

Four inputs to a benchmark run are environment variables rather than flags: `LCB_RELEASE=release_v6`, `ESCALATION_CLOUD_MAX_TOKENS=128000`, `ESCALATION_CLOUD_TIMEOUT=7200` and `MULTIAGENT_MODEL`. The timeout reads as two hours and the token ceiling is the budget the manager is given for an escalation, so the shape of a run is fixed before the command starts and cannot be tuned per problem through the documented interface.

The problem set is flags instead: `--lcb 100` with `--parallel 8`, while `--only lcb` narrows the harness to that one benchmark. `LCB_RELEASE=release_v6` points the loader at a named release of the forked LiveCodeBench rather than a moving branch, which is what keeps the 100 problems comparable between runs. What is absent is any documented way back in: no resume flag, no output directory override, no cleanup step for `runs/ws/`. An interrupted run leaves its workspaces in place with no stated way to tell them apart from a previous attempt.

## MIT in the metadata, three license families in the tree

The repository is listed as MIT and the code is MIT, but the evidence is not. The paper, the figures and the run data are under CC BY 4.0, so the numbers written to `runs/results.json` carry attribution obligations even though the script that wrote them is MIT. The LiveCodeBench fork, the benchmark problem statements and the LaTeX template files keep their own licenses, and `NOTICE.md` is the file that maps paths to licenses.

Both license files sit at the root, `LICENSE` and `LICENSE-CC-BY-4.0`, next to `NOTICE.md`. Vendoring the fork pulls in obligations that a package listing showing MIT does not describe. The split is stated rather than accidental, which is the right way to handle it, but it means the license attached to the repository and the license covering the run data behind the headline numbers are two different things.

## Version 0.1.0, a placeholder description, and no releases

The packaging metadata is unfinished. `pyproject.toml` names the project `gvs5h`, sets the version to `0.1.0`, and fills the description field with the literal placeholder text `Add your description here`. No GitHub releases exist, so nothing published pins a version that the code under `codebase/v2-current` corresponds to.

The rest of the tree explains the layout. `main.py` sits at the root, the runnable benchmark lives under `codebase/` in a version-suffixed directory, `paper/` holds `paper_latest.pdf`, `paper_plot_script/` holds the figure tooling, and `assets/` backs the Trendshift badge pointing at repository 225068. A `.claude/` directory and a `.python-version` file are committed at the top level as well. With 714 stars, 90 forks and no open issues, interest in the work is real; the versioning and packaging are the parts that have not caught up with it.

## Conclusion

Read GVS5H as a scaffold study rather than a leaderboard. The transferable claim is that decomposition plus persistent context on disk can lift a locally served 27B model from 66.8% to 92.4% pass@1, and the same abstract admits gains are not universal. Before citing a figure, open the paper for the per-model table and NOTICE.md for which license covers which path. Before running anything, note that the only documented invocation targets openai:gpt-5.6-terra and writes into fixed paths under runs/, with no release pinning the version you are reading.

## FAQ

### What does GVS5H actually do at inference time?

It spawns fresh instances of one model per problem and lets them coordinate through a shared filesystem holding a plan, notes and the current solution, with no training step. The flag `--engine multiagent` runs that manager, while `--engine single` is the one-call baseline.

### Can I reproduce the Qwen3.8 numbers using the command in the project?

Not directly. The only documented invocation sets `MULTIAGENT_MODEL=openai:gpt-5.6-terra` with `OPENAI_API_KEY` and runs from `codebase/v2-current`. Qwen routes are named as `dashscope:<model>` with their own `*_API_KEY`, and the page does not spell out the local serving arrangement behind the 66.8% to 92.4% rise.

### Which license covers the paper and the run data in GVS5H?

Code is under the MIT License, while the paper, figures and run data are under CC BY 4.0. The LiveCodeBench fork, the benchmark problem statements and the LaTeX template files keep their own licenses, and NOTICE.md records which license covers which path.

### How many models and problems were tested, and where are the per-model results?

The abstract covers eleven open and closed-weight models on the 100 latest hard LiveCodeBench problems, with gains of up to 25.6 percentage points on pinned backends and some models unchanged or worse. The per-model table is not on the project page; it is in paper/paper_latest.pdf and in the committed runs/ directory.

## Sources

- [Issues](https://github.com/slee-persis/GVS5H/issues)
- [License: MIT](https://github.com/slee-persis/GVS5H/blob/master/LICENSE)
- [README](https://github.com/slee-persis/GVS5H/blob/master/README.md)
- [slee-persis/GVS5H on GitHub](https://github.com/slee-persis/GVS5H)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/slee-persis-gvs5h