---
title: 'In the News: October 31, 2026 (Extra 3)'
description: 'A rerun of the five-Qwen GVS5H loop scored 9.8 of 10 against 8.0 for Fable 5 alone, and published all 50 runs, including two ways the manager failed.'
canonical_url: 'https://darkfactory.dev/news/2026-10-31-extra-3'
markdown_url: 'https://darkfactory.dev/news/2026-10-31-extra-3.md'
collection: news
date_published: '2026-10-31T23:20:00-04:00'
date_modified: '2026-10-31T23:20:00-04:00'
---

# In the News: October 31, 2026 (Extra 3)


A third-party rebuild of the five-model Qwen coding loop we covered on October 25 reproduces its result on ten problems, and its authors published every run, including the two where the loop's manager made things worse.

## 1. A rebuild of the GVS5H team-solve loop scores 9.8 of 10 and publishes all 50 runs

**[team-solve, a Memdoor workflow](https://github.com/guregodevo/memdoor/tree/main/examples/workflows/team-solve)** · guregodevo · GitHub, README dated October 31, 2026

The repository rebuilds the harness from GVS5H (Lee, 2026) as a Memdoor workflow: a planner, two ideators, a solver, a manager and a repair worker, each starting from a fresh context and passing work through files on disk. The README states the design rule plainly: "A shell script that runs the samples decides success, not a model." On the first ten LiveCodeBench Hard problems, five passes each, with Qwen3.8-27B and the original authors' prompts, the rebuild averaged 9.8 solved problems out of 10. The README puts the authors' own harness at 9.6 and Fable 5 alone at 8.0, both taken from the authors' published result files. Forty-nine of the 50 runs solved their problem. The 50 runs cost $35.79 for 15.3 million output tokens, with a median of 40 minutes and $0.39 per run.

The README lists its own limits. It covers ten problems, not the authors' 100. The contests date from March and April 2025, so training contamination cannot be ruled out. Fable 5 was not run in this harness; its column is a single call per problem from the authors' files. The runs went through OpenRouter, not the authors' own FP8 vLLM server, and some were moved between hosts mid-run. All figures here are the repository author's. We read the README and did not rerun the workflow or open the run files.

The two manager failure modes are the most useful part. In one pass, a manager invented a counterexample with a wrong expected answer, the team rewrote a correct program to fit it, and the new version passed the samples but passed only 32 of 44 hidden tests. In another, a program that passed every hidden test was overwritten by a later round because the manager did not declare it done; the team recovered a correct program before the run ended. The README says both are fixable without changing the method: check a manager's counterexample against a brute-force solver on small inputs, and keep the last program that passed the samples.

**Why it matters:** If your loop lets a reviewer model order rewrites, a confident wrong critique can destroy working code, so check its counterexamples against ground truth and keep the last version that passed. The result also says the October 25 parity claim holds on a small sample from an independent rebuild, with the contamination caveat unchanged.