Strong-model scaffolding lifts a weak model from 0.49 to 0.91 without retraining

When a strong model sets up the weak one's workspace

Transferring capability from a large model to a small one usually looks like this: take the strong model, use it to generate data, then fine-tune the weak one. This paper proposes a different move. What if you never touch the weak model at all? No weight updates. No fine-tuning. No long training run. Instead, ask the strong model to build the weak one a good inference-time pipeline.

The idea is simple. The effect is not: averaged over four benchmarks on reasoning about other people's intentions and beliefs, the weak model went from 0.49 to 0.91 in the best run. Close to double.

This matters if you work with cheap models, agents and multi-step pipelines. Often the problem is not that the model is too dumb. The problem is that the task arrived in an awkward shape. Too many steps. An answer format that drifts. Subtasks tangled together. Brittle spots where the model loses the thread. If a strong model can take the task apart once and pack the result into code, rules, routing and checks, the weak model starts performing noticeably better.

What the researchers tested

The authors call the approach strong-to-weak transfer through scaffolding. The setup:

🟠 a strong builder model that designs the pipeline

🟠 a weak target model whose weights are off limits

🟠 the builder sees only a small validation set — 5% of the data

🟠 on those 5% it iterates on the scaffold: prompts, routing, rules, code, checks, output format

🟠 the finished scaffold is then tested on the held-out full set

The experimental setup: the strong model iterates on the scaffold against a small validation set, then the scaffold is scored on a held-out test.

The key point is that the strong model never hands over answers to specific examples. It builds a reusable procedure. If that procedure then holds up on the held-out test, what transferred is the structure of the solution, not memorization.

The test bed is theory-of-mind tasks: benchmarks where the model has to track who saw what, who believes what, who is trying to deceive whom, what each participant wants and how they reason about what others want. This is a hard class of problems for small LLMs. It is also a good place to see how much of the reasoning can be pushed outside the model — into code, into intermediate state, into hard rules.

The headline numbers

The weakest target in the main experiment is GPT-5.4-mini. Unscaffolded, it averaged 0.488. With scaffolding, the average across all runs rose to 0.763. The best run reached 0.912.

Mean accuracy for each builder model × platform pair: nearly every combination sits well above a bare call to the weak model.

The numbers in short:

🟣 bare GPT-5.4-mini, no scaffold: 0.488

🟣 average across all scaffolds: 0.763

🟣 best result: 0.912

🟣 best-case gain: +0.423

🟣 every configuration beat the baseline

Sometimes it is cheaper and more useful to wrap the model you already have in the right pipeline than to move up a tier. The paper makes a stronger observation too: a well-built scaffold around GPT-5.4-mini beats stronger models running bare in places.

There is a limit, though. A human-designed scaffold, put together by hand, is still better: it scored 0.939. Automatic assembly already works well, but on the harder subtasks it does not always reach what a human engineer produces.

Where the gain comes from

The most interesting part of the paper is the mechanism. The authors are fairly candid about it: the gain does not come from making the weak model reason more, and not from giving it more attempts. It comes from three things.

First, the unstable part of the reasoning moves into deterministic code. If a question reduces to rules, it is better to hard-code the procedure once than to ask the model to improvise it every time.

Second, routing by task type works. One subtype goes to one handler, another goes elsewhere. That cuts the noise.

Third, strict control of the output format pays off a lot. It is a plumbing detail, but weak models lose points on trivialities all the time: wrong format, extra text, the wrong option selected. A scaffold cuts those off.

Different strong scaffolds fix different errors in the baseline model: together they cover almost every failure type.

The authors went through the techniques the builder models actually used, by hand. The most common:

🟠 output format control

🟠 deterministic decoding with no sampling

🟠 routing by benchmark and task subtype

🟠 forced step-by-step reasoning where it helps

🟠 rules for negation, polarity and logical inversion

🟠 hybrid schemes: rule first, model as fallback

Rare but frequently useful techniques:

🟠 deterministic solvers

🟠 extracting structured task state

🟠 verification in a separate pass

🟠 voting across several answers

Compressed to one line: the best scaffolds do not coax the weak model into thinking a bit harder, they take load off it.

How the experiment was run

The sweep is large: 72 runs, varying several factors at once.

🟣 builder model: GPT-5.5, Opus-4.7, Sonnet-4.6, Gemini-3.1-Pro, Gemini-3.5-flash and others

🟣 the platform the builder wrote code in: Cursor, Claude Code, GPT Codex

🟣 target model: GPT-5.4-mini or Gemini-3.5-flash

🟣 number of repeats, to check stability

Every builder worked only against the small validation set, roughly five passes over it on average. That produces another finding: more validation passes barely help. Final scaffold quality correlates weakly with the number of those iterations. It correlates very strongly with the quality of the builder model itself.

In other words, the win is not in grinding through variants. It is in the strong model forming the right hypothesis about the structure of the task.

A stronger builder makes a better scaffold

One of the cleanest parts of the paper compares reasoning-effort levels within a single builder, Opus-4.7. It was given different internal reasoning budgets while writing the scaffold: low, medium, high and very high.

The result is close to monotonic: more effort, better scaffold.

Statistical significance of the best scaffold against the baseline: far more errors fixed than new ones introduced.

This is interesting for two reasons.

First: compute spent at build time pays for itself. Thinking during the answer is useful, but so is thinking while designing the pipeline.

Second: the improvement is not a matter of the model simply writing more code. Code volume on its own correlates weakly with quality. What matters is how well the code takes load off the weak model.

The short version:

🟠 more builder effort → a better final scaffold

🟠 more validation passes → almost no effect

🟠 the platform matters less than the quality of the builder model itself

If you want to improve the system, give the strong model more time to build the pipeline rather than cycling the weak model over the same examples.

The platform was not the main factor

There is a lot of argument right now about whether the environment a coding agent runs in matters: Cursor, Codex, Claude Code and the rest. In this paper the effect turned out to be secondary.

Platforms do differ, but the gap is small and inconsistent. The dominant factor is the builder model. A platform only starts to help visibly once the builder already has enough reasoning budget to use what the platform offers.

That is worth holding onto. A good harness helps. It does not work miracles. If the builder is weak, the platform will not save it.

Who gains most from scaffolding

The biggest gains go to weak models with real headroom left. When the target model is already strong, a scaffold helps less. Sometimes it gets in the way.

The authors compared GPT-5.4-mini and Gemini-3.5-flash as targets. For the weaker GPT the gain was enormous. For Gemini, far smaller. And on tasks where Gemini was already near its ceiling, the extra engineering sometimes made the result worse.

The logic is simple: a scaffold mostly gives the model back abilities it appears to have already but applies unreliably. If the model handles the task anyway, extra rules and routes just add noise.

What that means in practice:

🟣 scaffolds pay off most on weak, cheap models

🟣 on strong models, apply them selectively, subtask by subtask

🟣 measure first where the model still has headroom

Where the limit runs

Not everything compiles into rules and code. The residual errors mark the boundary of the method clearly.

Automatic scaffolds did best on tasks with explicit structure: who saw what, who did not, what follows from that. There, deterministic rules work almost perfectly.

They did worst where the task requires:

🟠 tracking deeply nested beliefs about beliefs

🟠 accounting for deception and shifts in perspective

🟠 Bayesian inference about goals from ambiguous actions

So a scaffold is excellent at removing the routine share of the cognitive load, but it does not substitute for the capacity to reason where the problem stays genuinely open-ended.

Why this matters

The paper shifts the question. Usually we ask how well a model solves a task on its own. Here the question is different: how well can a strong model construct the conditions under which a weak model solves the task better?

For industry that is a very practical turn. Almost nobody runs a bare model in production. There is normally already a pipeline around it: tools, memory, routing, checks, code, format constraints. And what becomes visible now is that this outer layer is its own channel for transferring capability.

Put plainly, the strong model here acts as an engineer. It spends a lot of reasoning once to pack the solution into a procedure. The weak model then executes that procedure cheaply, many times over.

The takeaway

If you want to squeeze more out of inexpensive models, changing weights is not the only path. Part of the capability can be moved into the pipeline layer.

The paper's main conclusions:

🟠 a strong model can substantially improve a weak one with no fine-tuning, purely through inference-time scaffolding

🟠 the gain comes mainly from moving brittle reasoning into code, rules, routing and format control

🟠 builder quality matters more than the number of validation iterations, and more than the platform

🟠 weak models gain the most; strong models gain little, and in places lose

🟠 the method runs out where the task resists being reduced to explicit structure

In product terms this means something simple: between buying a more expensive model and leaving things as they are sits a large intermediate layer of engineering. And that layer can now be partly automated by LLMs themselves.