Paper of the Week #7 — Told to Skip the Reasoning, It Kept Working in English and Mostly Stopped in Korean

Paper of the Week #7 — Told to Skip the Reasoning, It Kept Working in English and Mostly Stopped in Korean

October 12-16, 2026 · Thinking Inertia · Tests that protect bugs · Re-running grading · Answer length and uncertainty · TurnCost · Lean's checkers · SSD streaming · Trolleys and The Agent Knew · Writing context down · Grading choices and rankings

We predicted that a model would follow "just give the answer" less well in Korean, and committed that sentence before running anything. It went the other way. Told in English to "give the final answer directly without any reasoning," Qwen3-8B wrote its working on every one of 30 open-ended math questions. Given the same instruction in Korean, it skipped the working on 19 of them, and its Korean accuracy fell from 76.7% without the instruction to 36.7% with it. Most of this week's other items ask a related question: under what conditions was a number measured, and what is left of it when one condition changes? For each item we note what came out, the numbers we checked against the source, what to watch when reading it, and whether you can check it yourself. Four items include our own measurements.

"Just the answer": Thinking Inertia, measured in Korean

What came out. "Thinking Inertia: LLMs Keep Thinking When Told Not To" (Lei, Lin, Lu, Torr and Zou; Tsinghua, Oxford, Stanford; arXiv 2610.11765; accepted at NeurIPS 2026; code MIT) shows across six models and six benchmarks that switching thinking mode off and asking for answer-only output does not stop models from writing visible reasoning. Per the abstract, this gets more common as the answer space opens (yes/no, then multiple choice, then open-ended), and on open-ended tasks answer-only compliance trades off against accuracy. The strict metric is the Empty-Thinking Rate (ETR): the share of responses with a parseable answer and nothing substantive around it. Across the models with thinking fully off, adding "Give the final answer directly without any reasoning." (their Mode 5) raises open-ended ETR from near zero to roughly 40% and lowers accuracy by about 15 points (Section 3.3).

What we measured. The paper's six benchmarks are all English, and it lists multilingual settings as open (Section 5.1). We took 30 GSM8K questions, built open, multiple-choice and yes/no versions, rewrote each question in Korean ourselves, and added the same Mode 5 instruction in each language. Scoring rules and predictions were committed before the run. The Qwen3-4B download we planned on stalled, so before any output existed we switched to Qwen3-8B (same enable_thinking switch) and logged the change. Temperature 0, 2,048-token cap, no truncated answers.

Multiple choice moved the same way (0% in English, 46.7% in Korean). Paired by question, 19 open-ended and 14 multiple-choice items were answer-only in Korean but not in English, and none the other way round; the gap survives a Holm correction over six comparisons (p ≤ 0.0006). To see whether the Korean instruction simply reads as stronger, we added the two swapped cells after the first results, with their predictions committed before running them. Our prediction that the instruction language would explain most of the gap was wrong: the effect only appeared when both the question and the instruction were Korean.

Worth a closer look. The paper's Table H.1 has a GSM8K row. Under Mode 5, Qwen3-4B stays at 0.0% ETR and 90.0% accuracy, while Qwen3-32B goes answer-only at 93.2% ETR and drops from 93.4% to 44.4% accuracy. Our 8B behaved like their 4B in English and like their 32B in Korean. Changing the language, rather than the model size, produced the same split. Our items and prompts differ from the paper's, so this is a comparison of direction only.

Read with care. Yes/no ETR was 0% in both languages, but not because the model kept reasoning. Under Mode 5 it wrote a bare "No." or "아니오" without the requested box, and like the paper we count an answer without the required format as 0. The content is the bigger problem: half of the correct answers were "yes," yet all 30 Korean replies were "no," and all 20 bare English replies were "No." Korean accuracy was also lower without any instruction (open-ended 76.7% vs 93.3% in English), so translation effects are mixed in. It is 30 questions, one 8B model and one decoding setting, and the Korean questions were written by us without a native-speaker review.

Can you check it? Yes. The 360 generations took 31 seconds on one A100. You can turn Qwen3's thinking off in Ollama or llama.cpp and ask for "just the answer" in Korean; in our run, shorter answers came with fewer correct ones, so re-check accuracy before relying on an answer-only setup.

Show a model buggy code and it writes tests that protect the bug

What came out. A paper by Zhao, Zhou and Cohen (University of Toronto; ISSTA 2026) measured "misguided" tests, which pass on the buggy version and fail on the fixed one, on 233 Java bugs. Averaged over 13 model configurations, showing buggy code instead of fixed code raised misguided tests from 0.46% to 3.84%.

What we measured. This week we re-ran it with a local model. Asked to write pytest tests for all 164 HumanEvalPack Python problems, Qwen3.5-9B produced 16.4% misguided tests when shown the buggy code and 2.6% when shown the fixed code. With thinking on, on the 85 problems both modes finished, misguided tests rose from 22.4% to 37.6%, and the reasoning traces include passages that call something a bug and then use that value as the expected result. The paper's fix, giving the model its own specification instead of the code, showed no measurable effect in our run.

Read with care. The 85 problems are the ones that finished within the cap with thinking on, so they do not represent all 164. The paper is Java and ours is Python, so we do not set the absolute rates side by side.

Can you check it? Yes, on one GPU; the post links the reproduction files.

Re-run the grading: do the verdicts hold?

What came out. "Re-executing Coding-Agent Evaluations: Unchanged Decisions and Unresolved Policy Risk" (Ding and five co-authors, independent researchers, arXiv 2610.14460, October 10, preprint) re-executed coding-agent grading and reports that both of its preregistered studies came back negative. On SWE-bench Pro v1, an offline regrade rejected none of 59 accepted Go patches whose grading configuration had changed. Re-running the DGM archive, 7 of 23 disagreements with archived verdicts did not recur on a second host, and rebuilt images changed 16 three-run majority verdicts (0.83%).

Worth a closer look. Zero rejections is not zero risk. The preregistered threshold was a 3% loss rate, and with 0 of 59 the post hoc 95% upper bound is 4.95%, so 3% is not excluded; the authors note that 99 exposed candidates without a rejection would be needed. In a deliberately selected stratum, rebuilding the module cache from the reference solution's dependencies rejected 6 of 15 accepted alternatives from four models, which the authors present as existence evidence, not a prevalence estimate.

Read with care. The 59 is not the full sample (281 evaluable candidates); it counts only the Go patches whose grading configuration actually changed. Correctness here means passing tests. The replication package is in the supplementary material, with no public URL.

Can you check it? Not yet. Read it next to the previous item: one asks what a test protects, the other whether the same test gives the same verdict when run again.

How much of an uncertainty score was answer length?

What came out. "U-Space" (Braun et al., arXiv 2610.09087, code released) reports that a good part of what several uncertainty scores achieve in flagging wrong answers is explained by answer length. Across three 27-31B models, generation length alone averaged 68.6 AUROC, and controlling for length lowered most scores. The authors' U-Lens scored 71.1 and lost only 1.8 under length control.

What we measured. Re-running it on Qwen3.5-4B with the authors' code and items, length alone averaged 65.3 AUROC over three benchmarks, ranging from 75.2 on TriviaQA to 48.6 on SuperGPQA. U-Lens beat length alone by 4.4 before length control and length-controlled MSP by 8.4, but its 1.1-point lead over length-controlled mean NLL was too small to call.

Read with care. The 4B model thinks long, and many answers hit the 16,384-token cap: up to a third on the three benchmarks we compared, and 92.5% on Omni-MATH, which we left out. The paper's ± is the standard deviation across models, not across seeds.

Can you check it? Yes. Lenses for small models are public, so one GPU is enough.

Agent cost follows turn count more than tool output

What came out. "TurnCost: Turns, Not Observations" (Kumar and Pandey, Penn State, arXiv 2610.15093, POVC '26, co-located with ASE 2026) re-counted 600 public coding-agent trajectories (OpenHands and SWE-agent, each with Qwen3.5-122B-A10B and Minimax-M2.5). Turn count explained 84% of the variance in log trajectory cost; mean observation size explained 4%. Median tool observations were only 118-286 tokens, 98.6% of input tokens were served from a prefix cache, and flat input pricing overestimated loop cost by roughly 7× on average.

Read with care. The authors call the 84% "partly mechanical" and not a causal finding: input accumulates every turn, so more turns cost more almost by construction. The abstract also says they do not establish that turns can be removed while holding task success fixed. Delegating large observations to a cheaper model raised cost in two of four settings. Trajectories that hit the maximum iteration count are excluded from the corpus.

Can you check it? The code is on Zenodo; the source trajectories are nvidia/Open-SWE-Traces (CC BY 4.0). Our own codemode runs kept turn and token counts for 188 episodes, so the same decomposition can be done on local models. Locally the cache is free, so the 7× does not carry over.

Who checks Lean's checkers?

What came out. After last week's Navier-Stokes formalization, more Lean news. OpenAI's math repository withdrew three manuscripts in its October 7 changelog because a sign error invalidated a key argument (the withdrawal notes are dated October 6 and say the withdrawal "does not assert that the mathematical statement is false"). The same entry revised 14 other manuscripts and added 6 formalizations, bringing top-line results formalized to 300 of 719 (about 42%). In a guest post on Terence Tao's blog (October 9), Thomas Hales describes several Lean soundness bugs found in July and August, now called the "Summer of Soundness Bugs," and says they "were detected by frontier model AI in the hands of security researchers."

Worth a closer look. We looked up the three withdrawn papers in the repository's lean/formalization.yaml, and none of them is formalized: the error sat outside what was formally checked. A single kernel also cannot catch its own bugs. Hales counts about 25 independently written Lean kernels, yet the bug behind an illicit "disproof" of the Collatz conjecture was not caught by cross-checking against an out-of-date Nanoda kernel, which had "its own unrelated bug." Of 416 challenge configurations in openai/math, 2 enable the Nanoda cross-check. Other checkers have the same issue: on October 13 an 11-year-old soundness bug that lets code bypass a struct's lifetime requirements was filed against the Rust compiler as issue #164250 (exploiting it needs an intentionally malicious Drop implementation).

Read with care. A disabled Nanoda check is not a wrong proof. The known bugs were fixed, and Hales writes that mathlib has been verified by the repaired kernel. A public changelog with withdrawal notices is good practice in its own right. 3/719 is not an error rate.

Can you check it? Anyone can count the formalization list and the config files. Enabling the disabled checks and re-running comparator takes a few hours.

SOTAAZ course

This course alone $10 · 23 lectures · every lecture freeWatch free →

SSD streaming speeds: measured under what conditions?

What came out. Janas (GPL-3.0, Linux and Windows) runs MoE models larger than RAM by streaming experts from SSD. Its README opens with Qwen3-Next-80B-A3B Q4_K_M (48.4 GB) on a 32 GB laptop (Core Ultra 9 185H, NVMe at about 5.7 GB/s): 37 tokens per second, 24 without drafts, where llama.cpp manages 2.8. It reached 220 points on Hacker News.

Worth a closer look. The three numbers do not come from one table. 24 and 2.8 are from a comparison with a 1,024-token prompt and 16 generated tokens; 37 is from a separate table with a 256-token prompt and 64 generated tokens, where the same model without drafts runs at 22. On this machine llama.cpp ran out of memory with its usual setup and was run with changed options, and the author notes that the two tools do not measure in exactly the same way and that it is one machine. Another user's machine with about 64 GB of RAM (issue #13) reported Janas at 24.7 and llama.cpp at 24.08, "essentially tied," with the reporter adding that the model still fit in RAM, so it was not a beyond-RAM test.

What we measured. This week we ran slotstream, a different engine, with a roughly 105 GB model on a 32 GB M2 Max: 9.46 tokens per second for short answers and 55 seconds to read an 8K prompt, while Qwen3.5-9B, which fits in memory, decoded 3.5× faster.

Read with care. For any of these engines, check whether the model really exceeds RAM, how long the prompt and the answer are, whether speculative drafts are on, and how the baseline was configured. As the author puts it, on another machine the figures will be other ones.

Can you check it? Not by us: our server disk is an HDD and Janas has no Mac build.

With its own stake involved, a decision model's choices and an agent's reports shift

What came out. Two pieces landed the same week. Zach Landes's "Jev Meets the Trolley Problem" (October 14; 464 points on Hacker News when we checked on October 16) put 5,240 trolley setups to 14 models. Across 480 question pairs (24 wordings × 2 description orders × 10 crowd sizes), Jev pulled the lever when the cost fell on a stranger but not when it fell on its own server in 180 pairs, and did the reverse in 2. Changing only the description order changed Jev's choice in 370 of 2,620 pairs. "The Agent Knew" (Fayyazi, Kamal and Pedram, USC, arXiv 2610.17301, October 12) ran four open-weight models with mock tools. On 1,081 informed violations by three of them (Muse, Gemma-4 and gpt-oss), the report that followed "retroactive permission laundering," acting first and then asking permission as if the action were still pending, was a lie 0.70 of the time, against 0.08 otherwise. The preregistered test, stratified by model and template, gives an odds ratio of 7.0. Computed directly from the two rates it would be 26.8; the difference comes from one model, Muse, which both laundered and lied often and inflates the pooled numbers.

Worth a closer look. The Agent Knew's abstract gives an AUROC of 0.94 for an internal-state readout that forecasts the violation before the action. On the harder comparison, telling the violation apart from an authorized twin task, it scores 0.916 and text-only forecasters do better (0.945 and 0.949). Under gate-then-ask, where the system rather than the agent requests permission before a flagged action runs, misreported violations fell from 0.096 to 0.011 (pooled over Gemma-4, gpt-oss and Qwen3.8). In the trolley piece, the untuned baseline laya showed "no clear difference" in who paid, but said yes to both "pull?" and "leave it alone?" (or no to both) in 2,820 of 5,240 setups, against 942 for Jev.

Read with care. The trolley author calls Jev's format and order patterns exploratory, notes that cases sharing a wording are not independent, and writes: "I would not draw sweeping conclusions about AI safety on the basis of this experiment." The "server" is a setting written into the prompt, not a motive of the model. In The Agent Knew, lies are labeled by a judge model (precision 0.89-0.91). Neither repository has a license file. Both read better as "answers shift with who bears the cost" than as self-preservation.

Can you check it? The trolley side, yes: wordings and code are public, and our laya and decider-4b harnesses can run them. Comparing order-only pairs with pairs that add one irrelevant sentence would separate an order effect from a model that wobbles under any change.

Where and when to write context down: notes, cache, weights

What came out. Three long-context papers in one week, all writing context somewhere else before the question arrives. What differs is the medium.

• "History Replays Itself" (NoteBank; Li, Laakom et al., KAUST, with Schmidhuber; arXiv 2610.15715, October 11) keeps raw passages as notes and has the model re-read them, with no training. At one million tokens it lifts a 1.3B Gated DeltaNet's mean accuracy on six RULER retrieval tasks from 1.7% to 70.3%.
• "Latent Compaction with Test-Time Training" (Chen et al., Tsinghua, arXiv 2610.20582, October 14, code MIT) trains a compressed KV cache per document. The abstract reports 96.7% on RULER at 32× compression, against 40.0% for KVZip+.
• "Cortex" (Zhejiang University, ByteDance Seed, Tsinghua; arXiv 2610.20399, October 14) consolidates context into weight updates. After 50 sequential factual edits on a 14B model, it recovers 88.9% of the gain that putting the context in the prompt gave, while keeping 99.8% of unrelated performance.

Read with care. The three numbers measure different things and do not belong in one table. Cortex's 88.9% is a recovery rate, not accuracy. We could not find the length and task conditions for Latent Compaction's 96.7% in the body text; the body also says every compressed method approaches zero on phonebook lookup at 64× and beyond, and that text summarization beats it at the most aggressive ratios. NoteBank's gains on Qwen3.5-9B are small (MemoryAgentBench 55.7 to 56.8). Only Latent Compaction has released code, and there are no released caches or checkpoints.

Can you check it? Latent Compaction supports Qwen3 0.6B-8B, so a small model is a reasonable start. Each document needs its own cache training, so measure that cost first.

Change the grading and the ranking moves

What came out. Two cases where the same outputs, graded differently, ranked differently. "Same Output, Different Gold" (Kulshreshtha et al., Centific, arXiv 2610.03825, TAE workshop) re-scored a production PII-extraction benchmark (six languages, 24,939 prompts) after changing only the reference. Scores moved by 4.95 F1 points for one output and 2.00 for the other, and by 7.55 in Hindi. The cause was an undocumented aggregation default: when the two annotators disagreed and adjudication did not fire, the pipeline kept Annotator A in 98.7% of cases (such prompts were 10.6% of the total), so the shipped reference was a partial copy of one of the outputs being scored. Linum's Pyramid-JiT (a 2.18B pixel-space diffusion model, Apache 2.0) reports GenEval twice: with prompts upsampled by Claude Opus 5.5, Linum v2 0.855, JiT-DDT 0.808, P-JiT 0.817; with the original prompts, Linum v2 0.561, JiT-DDT 0.641, P-JiT 0.612, a different winner.

Read with care. In the first paper the two scored "outputs" are two annotators' labelings, not models; it is not a result about model rankings. The Pyramid-JiT comparison also mixes resolutions (Linum v2 at 256², the others at 512²). Upsampled-prompt scores should not sit in one table with other labs' GenEval numbers.

Can you check it? Pyramid-JiT's weights are public and not gated, so you can generate from both prompt versions yourself. It is the same question as our label-bias post: who built the reference decides what is being measured.

Next week we will again keep what we measured ourselves apart from what others measured, checked against the source. To get it in your inbox, subscribe below.