About this video
A reasoning model was asked what day July 14 is, if July 3 is a Wednesday. It worked out Sunday, checked it again and again, and then wrote almost a thousand more tokens that changed nothing. That's overthinking, and you pay for every token. A new paper from Xi'an Jiaotong University and Tencent's WeChat AI teaches a model when to stop: math answers 42-45% shorter with about the same or better accuracy, and shorter code answers too, without ever training on code.
Would you trust a model that thinks half as long?
We read "Think Less, Locally" (LoCo) page by page: why reasoning models overthink (a preference, not an ability problem) and why whole-answer comparisons can't say where the waste was; idea 1, finding the moment overthinking starts (step confidence from the model's own top-token probabilities, volatility between steps, the bottom 25% / top 25% rule, and a Qwen3-30B judge that labels the next step OVERTHINK, NORMAL or FINAL); idea 2, freezing that moment and letting the same model write 8 new endings (correct only, shortest, at least 300 tokens saved, at most 3 pairs per question), with the paper's July example (212 tokens vs 986); idea 3, DPO on same-start pairs with a LoRA adapter on DeepSeek-R1-Distill-Qwen-7B; the math results (MATH-500 4,015 to 2,243 tokens; AIME 24 13,493 to 7,364 with accuracy up; best AUC on all five benchmarks; TokenSqueeze and DAST compared); the code results after math-only training (MBPP -36.3%, LiveCodeBench -24.7%, CodeContests -23.4%); the ablations (whole-answer pairs cut only 5-16%, GPT-5.4-written endings compressed less, random or evenly spaced cut points lost accuracy in 5 of 6 tests); what the paper does not show; and four things to do if you build with reasoning models.
Chapters
0:00 It found the answer, then kept going
1:04 Why reasoning models overthink
2:30 Idea 1: Find the moment it starts to overthink
4:04 Idea 2: Freeze it, and write a shorter ending
5:19 Idea 3: Learn to prefer stopping
6:32 Proof 1: Almost half the thinking on math
8:06 Proof 2: It never saw code, and still got shorter
9:14 Proof 3: Where you cut matters most
11:02 What this paper does not show
11:52 What to do about it
13:08 Recap
Paper: Think Less, Locally: Local Preference Learning for Reasoning Compression. Muyao Yuan, Liyan Xu, Weizhan Zhang, Muyan Jiao (Xi'an Jiaotong University), Jiangnan Li, Jinchao Zhang, Jie Zhou (WeChat AI, Tencent). arXiv:2611.04814, November 2026 (preprint, not yet peer reviewed). https://arxiv.org/abs/2611.04814
Code (promised by the authors): https://github.com/MuyaoYuan/LoCo
The paper has no open licence: its tables and Figure 2 are redrawn as our own animations from the published numbers, and the paper appears only as short credited excerpts (title block, a judge label definition, two lines from the appendix example) for commentary.
Music: Voice Over Under by Kevin MacLeod, CC BY 3.0, via Wikimedia Commons (https://commons.wikimedia.org/wiki/File:Voice_Over_Under_(ISRC_USUAN1600001).mp3)
Pranav Innovates: AI research, explained. Subscribe to stay up to date.
YouTube: https://www.youtube.com/@PranavInnovates
Instagram: https://www.instagram.com/pranavinnovates
What the video says
An AI was asked a simple question. If July third is a Wednesday, what day is July fourteenth? It worked out Sunday. Then it checked, by listing every day. Then again, with modular arithmetic. Twenty eight steps in, it still wasn't done. It wrote almost a thousand more tokens, and changed nothing. That's overthinking, and you pay for every token of it, in money and in waiting. A new paper from Xi'an Jiaotong University and Tencent's WeChat AI teaches a model when to stop. Its math answers got forty two to forty five percent shorter, with about the same or better accuracy. And it never trained on code, yet its code answers got shorter too. Stay to the end, where one experiment shows that how much you cut matters less than where you cut. The paper is called Think Less, Locally. Let's read it, page by page. First, how a reasoning model works. Before it answers, it writes out its thinking, often thousands of tokens of it. The paper splits that thinking into steps, one per paragraph. Overthinking is when the model keeps going after its steps already hold the answer. Earlier studies, cited here, suggest that on problems the model can solve, this is about preference, not ability. It could stop. It just prefers to keep thinking. Back in episode seven, we turned the thinking dial from the outside. This paper changes the model's own habit. The usual way is to compare whole answers: show the model a short correct solution and a long one, and reward the short one. But two whole answers can take completely different paths. A whole-answer comparison says, be shorter. It never says where the waste was. So here's a question. If you wanted to teach a model exactly when to stop, what would you show it? Think about it. Show it the same moment, twice. One version keeps thinking. The other wraps up. Everything before that moment is identical. That's the whole idea of this paper, and it takes three steps. Step one: find the moments where overthinking begins. The model reads its own finished thinking back, and at every token, it notes how sure it was of its top pick. Average that over a step, and you get the step's confidence. Then a second signal, volatility. How much did confidence jump from the previous step to this one? Either signal alone means little. Low confidence can just mean a hard part of the problem. A big jump can be a normal change of plan. But a step that is both unsure and unsteady, in the bottom quarter for confidence and the top quarter for volatility, is a candidate. Those cut-offs come from the model's own behaviour, measured on its own traces. And the check only uses steps the model has already written, never the part that might be cut. Confidence can't tell waste from real difficulty, so a bigger model, Qwen three thirty B, double checks each candidate. It reads the thinking so far and labels the next step. Overthink, if it re-checks something already settled. Normal, if it makes progress. Or final, if it wraps up and restates the answer. That third label matters. Models usually end by restating the answer in a box. It looks repetitive, but cut it, and you lose the answer itself. Only confirmed overthink steps survive. Step two. Take one of those moments and freeze everything up to it. Then let the same model write eight new endings from that exact point. Keep only the endings that reach the correct answer. Pick the shortest. And keep the pair only if that new ending saves at least three hundred tokens over the original. At most three pairs per question, so no single problem takes over. Here's the July example from the paper's appendix. The frozen part is the first twenty eight steps, with Sunday worked out and checked again and again. The new ending is two hundred twelve tokens. It says, multiple methods confirm it's Sunday, and stops. The original ending ran nine hundred eighty six tokens, and it opens like this. Wait, another way. Maybe using the concept of reference dates. Wait, no, I don't know that off the top of my head. Then it redid the count with modular arithmetic, a day of the week formula, and finally the calendar by hand. Same answer, seven hundred seventy four tokens later. Step three. Each pair now shares the same frozen start, with two endings: the short one is chosen, the long original is rejected. They train on these pairs with DPO, direct preference optimization. In plain words, the model is nudged to make the chosen ending more likely, and the rejected one less likely, compared with where it started. No reward model, no reinforcement learning loop. Because both endings follow the same start, the lesson is precise. Not, be shorter in general. Instead: from this kind of state, conclude. And at states the detector never flagged, nothing pushes the model to stop. The aim is a model that still keeps working when the problem needs it. The model is DeepSeek R1 Distill Qwen seven B, an open reasoning model. They trained a small add-on, called a LoRA adapter, for two epochs on four GPUs. The questions came from a pool of fourteen thousand math problems, and every training example was written by the model itself. Now the proof. Five math benchmarks, from school level to olympiad, with eight attempts per problem. Two rivals: DAST, and TokenSqueeze, a strong recent method. On MATH five hundred, the average answer dropped from about four thousand tokens to about two thousand two hundred. Forty four percent shorter, at the same accuracy. On the hardest sets, the two AIME competitions, answers got about forty five percent shorter. On AIME twenty twenty four, from about thirteen and a half thousand tokens to seventy four hundred, and accuracy went up, not down. Across all five benchmarks, LoCo cut between forty two and forty five percent of the tokens, and never lost more than a tenth of a point. The rivals show the trade-off. TokenSqueeze also cut a lot, twenty two to thirty nine percent, but lost accuracy on all five, about two points on each AIME. DAST barely compressed, and on the three hardest sets its answers actually got longer. The paper also caps the thinking at many lengths, from very short to very long, and plots accuracy against each cap. The area under that curve is the AUC. LoCo had the best on every math benchmark. For builders: shorter answers here didn't mean dumber ones. Now the twist. Every training example was math. Not one line of code. So what happens on coding benchmarks? On MBPP, basic Python tasks, answers got thirty six percent shorter at exactly the same accuracy. On LiveCodeBench, about a quarter shorter, and slightly more accurate. On CodeContests, competition problems, about twenty three percent shorter, and accuracy rose from eighteen and a half to twenty point six percent. Against both rivals, LoCo had the best accuracy and the best AUC on all three code benchmarks. DAST, by contrast, made code answers fifteen to twenty percent longer, and less accurate. The authors read this as evidence that LoCo didn't teach new knowledge. It changed a habit, when to stop, and the habit carried over. For builders: a stopping habit trained on cheap, checkable math may pay off on your other tasks too. Remember the promise: where you cut matters more than how much. Here's the experiment. The team kept everything the same, and changed one piece at a time. First, whole answers instead of moments. Pair the shortest and longest correct full answers, the usual approach, with the same questions and training. On the three benchmarks they tested, answers got only five to sixteen percent shorter. LoCo's moments got forty two to forty five. Same model, same questions. Only the shape of the lesson changed. Second, a stronger writer. Instead of the model writing its own short endings, GPT five point four wrote them, from the same frozen moments. It compressed less, thirty two to thirty six percent, with a lower AUC on all three. The authors' explanation: the model learns best from endings in its own style. Third, the big one. Keep the same number of cut points, but place them at random, or evenly spaced. They still cut almost as much, about forty to forty three percent. So, do they keep the accuracy too? Take a guess. No. They lost accuracy in five of six tests, by up to two and a half points on AIME twenty twenty four. LoCo gained on all three. Why? The detector's moments sit late in the thinking, about half of them in the final forty percent of steps, once the answer has settled. Random cuts land earlier, while the model still needs to think. Cut there, and you teach it to quit too soon. For builders: a stop signal is only as good as its timing. Now the catches. One. A single seven B model was trained. We don't know yet if this works the same on much larger reasoning models. Two. It needs problems with checkable answers, because each new ending must reach the correct one. That's why the training data is math. Three. The test sets are small. AIME has thirty problems a year, and the accuracy gains there are within the error bars. The safe reading is shorter at the same accuracy, not smarter. Four. Savings are reported in tokens, not seconds or dollars, against two rivals. It's a preprint, not yet peer reviewed, and the code is promised but not yet released. So what do you do if you build with reasoning models? Four things, then my take. One. Measure the tail. On a sample of your own tasks, find where the answer first appears in the thinking, and count the tokens after it. That's your overthinking bill. That one's my suggestion, not the paper's. Two. If you fine-tune for shorter thinking, build your pairs at moments, not on whole answers. Same start, two endings. In this paper, that gave three to eight times the compression of the whole-answer version. Three. Let your model write its own short endings. Here, its own endings beat ones from GPT five point four. Four. Never cut early. Random cut points lost accuracy on hard problems. If you build a stop signal, test it on your hardest tasks first. And my take. In episode seven, we picked the thinking level from the outside. This paper suggests a better future, where the model knows when it's done. The best thinkers aren't the ones who think longest. They're the ones who know when to stop. Quick recap. Reasoning models keep thinking after they have the answer. LoCo finds the moment overthinking begins, freezes it, writes a shorter correct ending with the same model, and trains it to prefer stopping there. The result: math answers forty two to forty five percent shorter at the same accuracy, shorter code answers without ever training on code, and evidence that where you cut matters most. So, remember that July question? The new model would say Sunday, and stop. Here's my question for you. Would you trust a model that thinks half as long? Tell me in the comments. The paper is linked below.