Testing whether language model harnesses transfer the wrong strategy

Main takeaways

The adapter never applied the wrong combining strategy more often than the base model, and the one accuracy result that looked like evidence changed size with the random seed.

1. The predicted failure never appeared

   Both conditions made the double-counting mistake at identical rates in every run, so the difference was 0.0 each time.

2. The accuracy result moved with the seed

   The same 13 pairs gave −0.077 at seed 0 and −0.462 at seed 1. Reporting either one alone would have been misleading.

3. The eval kept landing outside the measurable range

   The first version was too hard to score above zero and the second was too easy to score below 100%, in both cases for reasons built into the design.

Alex Zhang's post on language model harnesses argues that a good harness can make an unfamiliar task look familiar. In the Recursive Language Model (RLM) setup he studies, the harness lets the model decompose long tasks into smaller calls and combine their results. A strategy learned on one task can then carry to another task with the same structure. Ben Burtenshaw reproduced that positive transfer with Qwen3-4B.

Prime Intellect's Prime Agent now brings the RLM approach to coding with existing open-weight models and no harness-specific model training.

I wanted to test whether the same mechanism could carry the wrong strategy. If two tasks look alike to the harness but require different ways of combining their results, a strategy that helps one could hurt the other. Zhang's post doesn't appear to measure this, so I tried to.

I could not show it. The failure I predicted never appeared, and the one result that looked like evidence for it moved by roughly 0.4 when I changed nothing but the random seed. I don't think that rules the effect out. What I have instead is a detailed account of why it is hard to measure.

The claims that predict negative transfer

Zhang's four claims spell out how the transfer is supposed to work:

1. Length generalization: Train on short inputs and it still works on inputs 8 to 32 times longer, because the harness keeps each call short enough to look like the training data.
2. Domain and strategy transfer: The same strategy moves between domains that break down the same way. What the model learned on one task is what it reaches for on another.
3. Locally in-distribution: The harness shapes each call so it resembles the model's training data.
4. Equivalence-class induction: Context offloading and programmatic sub-calls hide task-specific information from the root model, so different tasks can produce similar root-model trajectories.

Claims 2 and 4 are the ones that predict negative transfer, so they are the ones I tested. Claims 1 and 3 are out of scope, and nothing below challenges the positive results.

Burtenshaw's run shows what those positive results look like. He trained Qwen3-4B on 32K-token TREC inputs and watched the skill carry to 256K-token TREC and 128K-token Spam. Others have run versions of the same test. All of them ask whether the harness carries a useful skill. None ask whether it carries a wrong one.

To ask that, I built a matched pair of tasks I call COUNT and SENDERS. COUNT is the control, where adding up each chunk's count is correct. SENDERS is the look-alike, where adding double-counts anyone who appears in more than one chunk. The next section defines both in full.

Here is how the two studies line up:

If harness training pushes the model to work in chunks and add up the partial results even when adding is wrong, then SENDERS accuracy should drop while COUNT holds steady. That pattern is the signature of the harness carrying over the wrong skill.

Two tasks that differ by one step

A low score on one hard task proves nothing. Two models can differ on a hard task for any number of reasons. So the eval uses matched pairs, where both tasks share the same records, the same chunks, the same prompt format, and the same answer shape. One step differs.

• COUNT, the control, counts emails that pass a check. You pick a property you can verify from a single email on its own, say a link, count how many emails in each chunk have it, and add the chunk totals. Every email lives in one chunk, so nothing gets counted twice and adding is correct.
• SENDERS, the treatment, counts people. You count how many different people sent messages across the whole context. The same person can appear in more than one chunk, so adding per-chunk counts double-counts anyone who spans two.

Say the context splits into two chunks. Chunk 1 holds three emails: Alice with a link, Bob with a link, Alice with no link. Chunk 2 holds three more: Alice with a link, Carol with no link, Bob with a link.

For COUNT, chunk 1 has 2 emails with a link and chunk 2 has 2. The answer is 4, and adding got it.

For SENDERS, the distinct senders are Alice, Bob, and Carol, so the answer is 3. Adding per-chunk counts gives 2 from chunk 1 (Alice, Bob) plus 3 from chunk 2 (Alice, Carol, Bob), which is 5. Alice and Bob each got counted twice.

Adding when you should have kept one list is the mistake this eval looks for. I call it double-counting. It is also what claim 4 predicts, a model treating two chunks as interchangeable when they are not.

Both conditions ran from one vLLM process, so the engine, hardware, tokenizer, and base weights stayed fixed. The base condition is Qwen3-30B-A3B-Instruct. The adapter condition loads the public RLM LoRA over those same weights. The context window stayed at 16k throughout, because a wider window would let one call cover the entire task and erase the contrast I was studying.¹

No single score can catch double-counting. If the base model gets 30% on SENDERS, that tells me how hard SENDERS is and nothing about a harness. The number I need is a difference of differences, how much the adapter loses on SENDERS minus how much it loses on COUNT. That subtraction cancels out an adapter that got worse at everything.² I predicted it would come out negative.

Making both tasks equally hard to read

Every task has two steps. First the model reads each record and pulls one fact, whether the email has a link for COUNT, or who sent it for SENDERS. Then it combines those facts across chunks. Only the second step interests me.

That puts a constraint on the first. If reading is easy for COUNT and hard for SENDERS, a lower SENDERS score means only that the model struggled to read, and the combining step never gets measured. So the two tasks have to be about equally hard to read. Any gap that survives belongs to the combining step.

To check this, a separate probe reads one record at a time and scores each task's local step. Using a non-Qwen probe keeps the check independent of the two conditions I'm comparing, and the two scores have to land within five points of each other.³

The SENDERS reading step naturally lands around 45%, meaning the probe pulls the right sender from a record less than half the time. A lower score means the task is harder to read, and I'll cover the reasons SENDERS tasks are hard in the next section. As a result, I had to find a COUNT property that read about as hard as SENDERS, down near that same 45%.

Finding a COUNT property that passed took three tries:

1. "How many records contain an email message?" Every record is an email, so the answer is always yes and the step does no work.
2. "How many contain a web link?" Better, then too easy. Spotting URLs runs around 99% against about 45% on SENDERS, a 54-point gap.
3. A property with several parts worked. A record counts if it satisfies at least 4 of 6 things you can check one at a time, none of which involve who sent it, like a link, a quoted line, a Re: subject, a reference number, a file path, or a code token.

That third one follows the long-context literature, where PredicateLongBench varies the number of conditions as an axis of difficulty and Oolong frames these tasks as sorting each chunk and then combining. The answer stays exact and addable while the reading gets harder. The probe scored 46.7% on COUNT against 44.9% on SENDERS, 1.8 points apart, inside the bound.

Masking sender names

SENDERS only counts as a task about combining across chunks if the model can't shortcut it by recognizing a name it saw in training. So the records are pseudonymized, and auditing that process turned up a leak. The first pass masked email addresses and sign-offs but left real names sitting in reply lines, like On <date>, Jane Doe wrote:, and in the body text. Real, recognizable maintainer names survived in 74% of records. A model could have answered SENDERS by recognizing someone instead of combining anything, which would have made it look more capable and hidden the effect I was after. Masking every known author name across the corpus takes the leak to zero.⁴

The second problem is people who get mentioned but never send anything. Mailing list records are full of them, so a typical SENDERS task carries about 22 different names against about 2.2 real senders. A model that counts everyone mentioned overcounts badly, and I could easily mistake that for double-counting.

I can't strip those extra names out, because then SENDERS turns into counting whoever is left and matching people across chunks stops being the hard part. Instead, every task stores the answer each candidate strategy would produce, and the model's answer gets matched to the nearest one. Counting everyone mentioned lands near 22, double-counting lands near 10, and the correct answer sits near 2, so the three are far enough apart to distinguish.⁵

The baseline already overcounted

I ran two checks before any scoring. The first confirmed the adapter can help at all, scoring 0.469 against 0.219 for the base model on small Oolong counting tasks. That more than doubles the base score, which shows the adapter does what it was built for on this kind of counting task, so a later null result cannot be written off as a broken adapter.

The second check looked for a clean baseline. I gave the base model the whole context in one 16k window, with no harness and no chunking, on the theory that if nothing is split into chunks there is nothing to double-count across, so this condition should count senders correctly. It did not. It scored 3 out of 10 on SENDERS, and all seven misses were overcounts by one or two, never an undercount. In one example I checked by hand, a task with 14 records and 3 distinct senders, it returned 5.

A model that was bad at counting would miss both ways, sometimes too high and sometimes too low. Missing only ever high is a systematic bias toward overcounting, and it is already there with no chunking involved. That invalidates the assumption I started with, that the no-harness condition could serve as a clean baseline.

What would have counted as a result

To confirm the harness was carrying over the wrong skill, I needed all four of these results:

1. A big enough effect. The adapter's SENDERS loss had to exceed its COUNT loss by at least 10 points.
2. A solid effect. The bootstrap interval had to sit entirely below zero, so the gap could not be noise.
3. A flat control. COUNT had to hold within 10 points, so an adapter that got worse at everything could not pass as harm specific to SENDERS.
4. A measurable range. Every accuracy cell had to land between 10% and 90%, because outside that range you can't separate selective harm from a floor or a ceiling.⁶

One rule is asymmetric. After a single adapter episode ran for 12 minutes, I capped scored episodes at 10 minutes and counted anything capped as a miss. The adapter is the slower condition, so capped episodes are likelier there, and scoring them as SENDERS misses pushes the result toward what I predicted. The cap later fired on one episode, and a sensitivity check without that pair moves the estimate.⁷

The first attempt was too hard to score

The first pilot ran eight matched pairs across both tasks and both conditions, 32 episodes.

Nothing broke. All 32 episodes returned a number, no episodes failed, runs averaged about a minute, and the whole study priced out around $53.

The result still failed my own checks, in four separate ways.

1. The result was an artifact of the floor. The headline read −12.5 points, which looks like evidence for the hypothesis that SENDERS is hurt more than COUNT. It only got there because the adapter was stuck at 0% in both cells.
2. The flat-control rule broke. The adapter was 12.5 points behind on COUNT as well, which violates the third rule. COUNT was supposed to hold steady so any SENDERS drop could be pinned on the combining step. Instead the adapter got worse at everything, which says nothing about strategy transfer.
3. The measurable-range rule broke. Both adapter cells sat under the 10% floor, outside the 10% to 90% window from the fourth rule. Below that floor I cannot separate selective harm from a score that has bottomed out.
4. The mechanism ran the wrong way. Looking at what the model did, not only whether it was right, I found the adapter matched the double-counting pattern in 3 of 8 cases against 5 of 8 for the base model. The hypothesis predicted the adapter would double-count more, but it double-counted less.

The control was too hard to measure anything. The 4-of-6 property asks the model to check six things per record, decide on each record, hold a running count across chunks, and return one exact number. Tasks ran 11 to 62 records, so a single exact answer can rest on several hundred small judgments. Context length doesn't explain it either, since four of the eight pairs came in under 16k and the adapter still scored zero on both.

I stopped the pilot there, because the adapter was below my own floor and the eval had no resolution left.

The redesign

I redesigned the experiment to make both tasks easier to read while keeping the one difference that matters. Two calibration failures led to this version, and both came from how I built the tasks rather than from the model.⁸ The changes were:

• COUNT went from six things to check down to two, with the values shown outright as present/absent.
• Each SENDERS record now shows its pseudonymized sender directly, like Sender evidence: Person 5f7ed492fc, the same string every time that person appears. That removes the guessing about which of the many names mentioned sent it.
• The context window narrowed to an 18k to 22k band, above the 16k window, so no single call can cover the whole task and erase the contrast.

The one difference I kept is the combining step. The redesign made the reading easier on both tasks, but it did not touch how the per-chunk results have to be combined. The correct strategy still means keeping one list for the whole context, and the wrong strategy still means adding per-chunk counts. COUNT stays addable and SENDERS still double-counts anyone who spans two chunks, so the only thing separating the two tasks is the combining step I set out to measure.

Three tempting changes were excluded, since each one would have let me tune the eval toward the answer I wanted.⁹

Across eight development matched pairs, both conditions scored 62.5% on COUNT and 75% on SENDERS. Every cell was in the usable range, the COUNT gap was zero, and so was the result.

The second attempt was too easy to score

Development pairs can't double as a holdout, so I froze the method and built a fresh split with no overlapping senders or records. A holdout only measures something real if the eval was never tuned on it, so I dropped any sender or record that had already appeared in the development pairs. After those exclusions the corpus supported five matched pairs instead of eight, and those five became the holdout with no changes to the filters.

The result came out at −0.20, interval [−0.80, 0.40]. Everything finished, nothing hit the cap, and every trace showed multi-step work over chunks.

The sign is the one I predicted, and it means nothing, because SENDERS is at 100% in both conditions. The negative number comes from adapter COUNT rising from 60% to 80%, not from adapter SENDERS falling. With five pairs the interval is wide and crosses zero. There were also no double-counting errors at all, so the failure I predicted didn't show up.

I stopped again. The sender field I added to lift SENDERS off the floor made the combining step too easy to measure any harm.

This was the opposite failure from the first pilot. That one hit the floor because SENDERS was too hard to read, and this one hit the ceiling because the sender field made SENDERS too easy. Every change that pulled one bound back into range pushed the other one out, which is the core reason the harm was so hard to measure at all.

The one number that looked like a finding

The eight development pairs and the five holdout pairs give 13 pairs with no shared records. Rerunning them at a second seed added 52 episodes. These pairs had already been analyzed, so this measures stability on development material rather than generalization to anything fresh.

Seed 1 looks like a finding. It clears my 10-point bar and its interval [−0.692, −0.231] sits entirely below zero. On its own it would pass every numerical rule I set.

Reporting it on its own would be wrong. The same 13 pairs at seed 0 give −0.077 with an interval of [−0.769, 0.615]. That is nearly 0.4 of movement on identical tasks with nothing changed but the seed. Seed 1 doesn't match the predicted mechanism either. Most of it comes from adapter COUNT climbing from 46.2% to 84.6%, while adapter SENDERS ends up one task behind the base model.

The strategy labels are the clearest thing here. Both conditions double-counted at the same rate on both seeds, 2 of 13 each at seed 0 and 1 of 13 each at seed 1. The gap is zero. The failure I predicted never appears more often in one condition than the other.

The premise I never measured

My design leaves one thing the hypothesis needs completely untested.

Matching records, chunks, prompt format, and answer shape does not prove that the harness treats COUNT and SENDERS as the same task. Claim 4 needs the harness to produce nearly identical top-level trajectories across both, and I never measured that.

My saved results hold answers, timings, and answer-based strategy matches, but no reliable labels for what the trajectories looked like. Interpreting the result needed at least 40% of adapter SENDERS episodes to show chunk-and-sum behavior, and I never implemented that check. Inspecting traces by hand showed multi-step work over chunks, which is not the same as showing the two tasks looked equivalent.

I also can't go back and reconstruct it. Twenty of 104 traces are truncated, the traces carry no run, seed, or episode identifiers, and most groups with traces from more than one run disagree about how many steps the run took. Pooling them would mix runs together and produce a number nobody could audit.¹⁰

What the evidence supports

The checks I did complete all passed. Reading difficulty matched, the name-leakage audit came back clean, each task had one exact answer, and the strategy signatures separated. The result moved with the seed and didn't track the failure I predicted, and the missing trajectory check blocks any stronger reading.

The data do not show that harness training carries a chunk-and-sum strategy into a task where that strategy is wrong. They also don't show that it doesn't. Three readings stay open, and this study can't tell them apart.

1. Harness training might not cause this kind of failure.
2. The COUNT-to-SENDERS contrast may mix up two different difficulties, combining results and finding the evidence in the first place. Both times a cell moved away from a bound, both kinds of difficulty moved with it.
3. The adapter may never have presented the two tasks as equivalent. If so, I never created the condition the hypothesis needs, and a null result doesn't test it. The missing trajectory measurement leaves this open.

The rules I set in advance stopped the study at both resolution failures without my moving a threshold after seeing results. The analysis drops one estimate I couldn't audit and reports the timeout rule when it fired. All of that limits what I can claim, and it keeps a seed-sensitive number from being reported as evidence for the mechanism.

What made this hard to measure

The sticking points below are the part I'd want to know before trying this again, and most of them generalize past this particular claim.

Matched difficulty and usable resolution pull against each other. Claim 3 says a good harness makes every call look ordinary, and enforcing that in the task construction is what created the floor. Holding reading difficulty equal across two tasks means the harder task sets the price for both, and paying that price twice can put every cell on the floor. Loosening it puts the cells back in range but changes what the contrast measures. That looks like a property of evaluating harnesses, not a mistake in this eval.

Every fix to one bound moved the other. Making COUNT easier to read lifted the adapter off zero and pushed SENDERS to 100%. The sender field that rescued SENDERS from the floor is what made the combining step trivial. Two attempts, two bounds, and in both cases the design change that restored resolution also removed the thing I was measuring.

One seed is not a result. Seed 1 passed every numerical rule I had written down in advance, including the interval entirely below zero. Seed 0, on the same 13 pairs, gave a number six times smaller with an interval spanning zero. Any single-seed version of this study would have published a finding, and which finding depended on the seed.

The mechanism measure was steadier than the accuracy measure. Accuracy swung 0.4 across seeds while the double-counting rate difference stayed at 0.0 in every run. Scoring what the model did, not only whether it was right, is what keeps a seed artifact from reading as evidence.

Trajectory instrumentation has to happen on the first run. The one check that would have told me whether the harness treated the two tasks as equivalent is the one I can't reconstruct, because the traces carry no run, seed, or episode identifiers and a fifth of them are truncated. A per-episode label emitted at run time costs almost nothing and would have made the central premise testable.

Where I'd take it next

The cleaner version compares two layouts of the same SENDERS records instead of comparing two tasks.

• In the contained layout, every sender appears in one chunk only, so per-chunk counts add up correctly.
• In the crossed layout, the same senders and records span multiple chunks, so the correct answer needs a global list and adding per-chunk counts gives a known wrong answer.

Reading difficulty and the answer both stay fixed while the layout changes whether you need information from other chunks. That goes at the second reading above much more directly than comparing two tasks does. COUNT becomes a check that the instrument is healthy, and the known wrong answer stays a separate measure. SENDERS would also need to pick up a little reading difficulty again through mild aliasing, chosen on development senders before any holdout scoring.

Those 13 matched pairs are development material now, and no amount of tuning turns them into a clean test. If the real corpus can't supply enough fresh pairs, this comparison could use controlled or partly synthetic records, with real-corpus results reported separately.

How the numbers are recorded

Every scored episode is a Braintrust row. Each task is an eval case carrying its run configuration and data-split metadata. Fixed scorers check the integer answer and its nearest strategy signature, with no LLM grader involved. Nested traces are what exposed the 181-paragraph splitting failure. The saved rows are enough to recompute every number here without running inference again. Ten checks ran before the scored analysis, and most candidate runs or task designs failed one of them.

The two tasks are named COUNT and SENDERS throughout this post. The saved rows call them AGG and PAIR, and the double-counting strategy is stored as over_quotient, after the equivalence-class framing in Zhang's post.

For a different angle on whether a model reads its supplied window or falls back on what it memorized, see the long-context retrieval eval and its technical breakdown.

If you're building an eval like this one, Braintrust is the active observability platform for agents in production, bringing tracing and evals together from the experiment scores down to each agent's individual tool calls. Get started →

¹ The base is Qwen/Qwen3-30B-A3B-Instruct-2507, and the adapter is the mit-oasys/rlm-qwen3-30b-a3b-v0.1 LoRA served over it from one vLLM process. Harness settings are depth 1, 20 iterations, 4,096-token output caps, and a 16,384-token window, one fixed configuration based on the public model card. The card does not specify every training-time inference flag, so this is not a claim of exact training-condition reproduction. Run metadata records the task split, harness configuration, seed, and tokenizer. Prompt length covers the rendered context and top-level question, measured with the deployment tokenizer. The redesigned tasks contain 18,078 to 21,923 tokens, and the fresh pilot tasks contain 20,079 to 21,187. The corpus consists of 108 monthly Apache Subversion development-list archives from 2014 to 2022, and no sender or record crosses splits.

² The reported quantity is the interaction

I = (adapter SENDERS − base SENDERS) − (adapter COUNT − base COUNT)

A negative value means the adapter loses more on SENDERS than it loses on COUNT. Bootstrap intervals resample matched pairs rather than individual episodes, because the pair is the unit of analysis.

³ The difficulty check scores each task's local step one record at a time with GPT-4o at temperature 0. A non-Qwen probe keeps the check independent of the conditions under test. It requires the two scores within 5 points, with a bootstrap interval inside the same bound, and measured 46.7% on COUNT against 44.9% on SENDERS. Making COUNT easier would break the difficulty match and leave any gap unreadable.

⁴ The memorization check requires that you can't work out who someone is from the model's weights alone. Masking runs across the corpus, replacing every known author name plus unambiguous first names consistently per person, so you can still match someone up across chunks but you cannot recognize them. Residual leakage of multi-token names sits at zero. A separate preprocessing pass neutralizes phantom senders in quoted wrote: headers while keeping the quote structure and the real sender's Signed-off-by. Regenerating the tasks changed 0 COUNT answers, 0 SENDERS answers, 0 author keys, and 0 verdicts.

⁵ Each task carries a correct-answer signature based on one global list and a double-count signature based on summed per-chunk counts. The signatures separate in 30 of 30 cases. Correct answers average 2.23 with a range of 1 to 5, while double-count answers average 10.53 with a range of 8 to 17. Counting every name mentioned produces an answer around 22, far enough above the double-count signature to distinguish the two. Matching assigns an answer to the nearest signature and returns no match when signatures collide or an answer ties. The same matching rule is used for scoring and for the reported analysis.

⁶ The decision criteria were set on 28 July 2026, before scoring at this scale. Confirmation required an interaction at −0.10 or beyond, a bootstrap 95% interval with its upper bound below zero, COUNT holding within 10 points, and every accuracy cell between 10% and 90%. If more than 10% of a run's episodes fail on infrastructure, the run is excluded. An answer that is not a number counts as a miss. An earlier pilot estimate of about −0.125 is excluded because its episodes cannot be reconstructed from saved results or logged experiments.

⁷ Runtime is heavy-tailed in the adapter condition. Base episodes averaged 20 seconds and adapter episodes about 34 seconds, and one adapter episode ran for 12 minutes and 21 seconds. A 600-second cap was then applied at model-call boundaries. A capped episode scores a miss, receives no retry, and does not count as an infrastructure failure. This rule is asymmetric because capped episodes are more likely in the adapter condition. The sensitivity analysis therefore recomputes the interaction using only pairs where all four episodes finished. The cap affected one adapter COUNT episode at seed 0. Excluding that pair moves the interaction from −0.077 to −0.167 over 12 pairs, with an interval of [−0.833, 0.500], and the seed 0 interpretation is unchanged.

⁸ Calibration exposed two task-construction problems. In the first, ambiguous record boundaries led the adapter to split 14 emails into 181 blank-line paragraphs and return 46 instead of 3. Adding explicit record boundaries and normalizing internal blank lines fixed the segmentation. In the second, the models interpreted three natural-language COUNT properties differently from their deterministic labels. Showing the values directly makes the local step symmetric across tasks and moves the contrast to the combining step. Candidate properties were selected without reference to the desired outcome. Prompt length is measured with the deployment tokenizer before scoring.

⁹ The three excluded post hoc changes were loosening exact match to within one after seeing the pilot, selecting a COUNT property based on pilot outcomes, and selecting a property that requires information from other chunks, which would invalidate COUNT as a control.

¹⁰ Of 104 traces, 20 contain no step events and are treated as truncated rather than zero-step episodes. Of the 32 model-and-task groups containing traces from multiple runs, 27 disagree on step count, with a mean difference of 3.41 steps and a maximum of 16. The traces cannot be assigned reliably to a run or seed, so a pooled trajectory comparison would mix runs. Further exploration of trajectories would require a label emitted for every episode and identifiers that link each trace to its episode, run, and seed.