Concise reasoning in large language models (LLMs) seeks to generate only essential steps needed to arrive at a final answer, thereby alleviating issues of “overthinking”. Most proposed approaches reduce conciseness to a hand-tuned coefficient or threshold that must be re-tuned across domains and model scales. We address this brittleness by treating concise reasoning as a constrained problem that minimizes length subject to an accuracy floor, and develop Performance-Aware Length Update (PALU), an algorithm guided by a Lagrangian view of this problem. PALU maintains a per-prompt length budget and updates it using two data-driven signals: the prompt's pass rate, which determines whether to compress, and the dispersion of its correct responses, which determines how much. On DeepSeek-R1-Distill-Qwen-1.5B, PALU reduces generation length by 64% while improving accuracy from 44.2% to 51.6% across six benchmarks, matching GRPO accuracy under a 2.5× tighter length budget. The same hyperparameters transfer across math, logic and STEM, and across 1.5B to 14B models, suggesting that constrained optimization remains a productive design scaffold for training reasoning LLMs even where its classical guarantees no longer apply.


L: the length budget of prompt q, i.e. the max-token limit (max_tokens in vLLM or SGLang) used when sampling its rollouts. R: the expected reward, here accuracy, of rollouts under that budget. C: the accuracy floor. λ: the Lagrange multiplier, which grows while the floor is violated.
At inference time only a fixed maximum length applies; the shorter reasoning lives in the trained weights.
| Method | Pass@1 (%) | Length (tokens) | AE score ↑ |
|---|---|---|---|
| R1-Distill-Qwen-1.5B | 44.2 | 11,297 | 0.000 |
| GRPO | 51.4 | 10,438 | 0.563 |
| ThinkPrune-4k | 46.4 | 5,390 | 0.659 |
| AutoThink-Stage3 | 50.6 | 5,563 | 1.077 |
| ALP | 48.9 | 4,742 | 0.958 |
| L1-Max | 44.6 | 3,311 | 0.551 |
| ShorterBetter | 37.7 | 2,585 | 0.030 |
| PALU | 51.6 | 4,093 | 1.185 |
DeepSeek-R1-Distill-Qwen-1.5B trained on DeepScaleR, macro average over MATH-500, AIME 2024, AIME 2025, AMC 2023, OlympiadBench and Minerva-Math. AE score: accuracy-efficiency score (Luo et al., 2025). Bold is best, underlined second best. Per-task numbers and more baselines are in the paper.
PALU reaches GRPO's accuracy with 2.5× fewer tokens. Starting from DeepSeek-R1-Distill-Qwen-1.5B, PALU shortens responses from 11.3k to 4.1k tokens while raising accuracy from 44.2% to 51.6%, the best accuracy-efficiency score in the comparison. Prior methods land on one side of the trade-off: ShorterBetter and L1-Max compress harder but give up accuracy, while ThinkPrune and AutoThink keep accuracy but compress less.
What does a concise answer look like? Below are three questions answered by the base model and by PALU. Text in grey italics is the model's thinking.
Which one is greater, 8.11 or 8.9?
First, I need to compare the whole number parts of both numbers. Both 8.11 and 8.9 have the same whole number part, which is 8. Since the whole numbers are equal, I'll move on to comparing the decimal parts. Looking at 8.11, the decimal part is 0.11, while the decimal part of 8.9 is 0.9. To make the …
1. Compare the Whole Numbers: both numbers have the same whole number part: 8. 2. Compare the Decimal Parts: convert 8.9 to have two decimal places: 8.90. Now, compare 0.11 (from 8.11) and 0.90 (from 8.90). 3. Determine Which Decimal is Larger: 0.90 is greater than 0.11. 4. Conclusion: since 0.90 > 0.11, 8.90 is greater than 8.11. Therefore, 8.9 is larger than 8.11. 8.9
To determine which number is larger between 8.11 and 8.9, I'll compare their decimal places. Both numbers have the same whole number part, which is 8. Next, I'll look at the tenths place. In 8.11, the tenths digit is 1, while in 8.9, it's 9. Since 9 is greater than 1, 8.9 is larger than 8.11.
1. Compare the Whole Number Part: both numbers have the same whole number part, which is 8. 2. Compare the Tenths Place: 8.11 has a tenths digit of 1; 8.9 has a tenths digit of 9. Since 9 is greater than 1, 8.9 is larger than 8.11. 8.9
“Same answer, one step fewer: PALU compares the tenths digits directly instead of padding 8.9 to 8.90.”
What is the first prime number after two hundred?
To determine the first prime number after 200, I'll start by checking each number sequentially to see if it's prime. I'll begin with 201 and check if it's divisible by any prime numbers less than its square root. The square root of 201 is approximately 14.17 … 209: checking divisibility by 11, since 209 divided by 11 is 19, it's not prime. Finally, 210 is even, so it's divisible by 2. 211: checking divisibility by primes up to 14, it doesn't divide evenly by 2, 3, 5, 7, 11, or 13. Therefore, 211 is the next prime number after 200.
1. Understand What a Prime Number Is … 2. Start Checking Numbers After 200 … 3. Check Divisibility: 201 / 3 = 67, not prime. 202: even, not prime. 203 / 7 = 29, not prime. … 209 / 11 = 19, not prime. 210: even, not prime. 211 is not divisible by 2, 3, 5, 7, 11, or 13; 211 is a prime number. 4. Final Answer: the first prime number after 200 is 211
To determine the first prime number after two hundred, I'll start checking each number sequentially from 201 onwards. 201 is divisible by 3, so it's not prime. 202 is even, thus not prime. 203 is divisible by 7, so it's not prime. 204 is even, not prime. 205 ends with a 5, so it's divisible by 5, not prime. 206 is even, not prime. 207 is divisible by 3, not prime. 208 is even, not prime. 209 is divisible by 11, so it's not prime. 210 is even, not prime. 211 is a prime number because it isn't divisible by any number other than 1 and itself. Therefore, the first prime number after two hundred is 211.
The first prime number after 200 is 211
“Both check 201 to 211 in order. The base model then repeats every check in its answer; PALU states the result once.”
Find the sum of all integer bases b > 9 for which 17b is a divisor of 97b.
Okay, so I have this problem where I need to find the sum of all integer bases b > 9 for which 17b is a divisor of 97b. Hmm, let me think about how to approach this. … b + 7 is a divisor of 9b + 7. … Let me denote this fraction as k … b = 7(k − 1)/(9 − k) … Let me denote m = k − 1 … b = 7m/(8 − m) … Let me denote d = 8 − m … So d is a positive integer divisor of 56 … Therefore, m can be 0, 1, 2, 3, 4, 5, 6, or 7. So, let's find corresponding d for each …
No answer: the response exceeds the 32k-token limit.
Okay, so I need to find the sum of all integer bases b > 9 where 17 base b divides 97 base b. … So the condition is (b + 7) divides (9b + 7). … Using polynomial division: 9b divided by b is 9. Multiply (b + 7) by 9: 9b + 63. Subtract: 7 − 63 = −56. … So (b + 7) divides 56. Given that b > 9, b + 7 > 16. The divisors of 56 greater than 16 are 28 and 56. So b = 21 or 49. Sum is 21 + 49 = 70.
We need b + 7 to divide 9b + 7. The remainder of 9b + 7 divided by b + 7 is −56, so b + 7 must divide 56. With b > 9, b + 7 is 28 or 56, giving b = 21 or b = 49. The sum of all such bases is 70
“The base model sets up a chain of substitutions and runs out of tokens; PALU divides once, reads off the remainder, and answers 70.”
Concise reasoning is a useful feature in its own right. Shorter reasoning traces make it easier for people to work alongside a model, and, I hope, lower the energy cost of deployment.
There is another angle. After nearly thirty years of using natural language, I find that when two texts carry the same information, the shorter one usually comes from the clearer thinker. This makes me wonder whether concise reasoning, beyond improving the human experience and saving energy, can also raise a model's performance ceiling. If this question interests you, feel free to reach out to me, Chengqian Gao. I welcome collaboration.
@article{gao2025concise,
title={Concise reasoning in the lens of lagrangian optimization},
author={Gao, Chengqian and Li, Haonan and Killian, Taylor W and She, Jianshu and Wang, Renxi and Ma, Liqun and Cheng, Zhoujun and Hao, Shibo and Xu, Zhiqiang},
journal={arXiv preprint arXiv:2510.10168},
year={2025}
}