Thinklite: Deleting the Reasoning a Model Repeats

A reasoning model often keeps thinking after it already has the answer: it restates the question, redoes a step, checks a result it has checked twice, or explores an approach it then drops. Thinklite-27B is Qwen3.8-27B trained to skip that part. We built it only from the model's own correct answers, with the redundant reasoning deleted and nothing rewritten, and we release it in three versions that trade token savings against accuracy differently.

This continues our earlier work on Nanolite, where we shortened the reasoning of small models. Thinklite asks the same question of a 27B model, with a stricter rule: the model may only learn from its own reasoning, with parts removed.

At reasoning_effort=low, across six public benchmarks, Thinklite-27B High uses 28% fewer reasoning tokens than Qwen3.8-27B and returns complete answers 22% faster on average. Thinklite-27B Low keeps average accuracy within 0.6 points of the base model with 20% fewer reasoning tokens. Thinklite-27B Max cuts reasoning by 40% but loses accuracy on the hardest math and code. All three are open weights under Apache-2.0 at Sparset/thinklite-27B.

Why we did not ask for shorter answers

The obvious ways to shorten reasoning change more than its length. Training on another model's compact traces teaches that model's style and problem-solving habits. A length penalty during reinforcement learning rewards brevity directly, which can also reward skipping steps that were needed. We wanted a model that reaches the same answers it already reaches, by a shorter route.

So every training target in Thinklite is the base model's own reasoning with parts removed. If a trace is correct and a unit of it adds nothing to reaching the answer, deleting that unit leaves a shorter trace the model could plausibly have written. The model is not asked to learn new facts or a new voice, only to omit the repetition.

How the training data was made

Start from answers that are verifiably right

Qwen3.8-27B answered a broad prompt set: math, code, structured output (JSON, YAML, TOML and tool calls), instruction following, science, tool use, grounded question answering and multi-turn conversations. We kept only answers we could verify: exact checkers for math, executed unit tests for code, parsers and schema checks for structured output, rule checks for instructions, and an answer-only judge for open-ended questions, which saw the final answer but never the reasoning.

Cut after the answer, then delete what repeats

Each correct trace was split into numbered units. The first cut removes everything after the point where the model had committed to its final answer. The second step deletes whole units that fall into five categories: restating the prompt, repeating a step already done, re-checking something already checked, abandoned detours, and filler. Nothing is paraphrased, merged or added.

The deletions themselves were proposed by a stronger, separate model rather than by Qwen3.8-27B. We tried the base model first. On 60 calibration traces where we had reference deletions, it recovered 7% of them at low effort and deleted nothing at all in 53 of the 60 traces; at its highest reasoning effort it deleted nothing in any of them. It was a reasonable judge of where an answer was reached (80% agreement on the trimming decision), but it would not prune its own reasoning. We keep it for trimming and do not use it as an editor.

Check every edit mechanically, then check that the model can still finish

Every proposed deletion had to pass mechanical checks before it counted: the final answer must be unchanged, every value the answer uses must still be derived somewhere in the kept text, no kept unit may depend on a deleted one, and long traces have a deletion cap. On hard problems, one check of the key result must survive.

The stricter test is behavioural. In a continuation test, the model is given the shortened reasoning up to a cut point and must continue to a correct answer. It ran on every heavily edited trace and on a sample of the rest. When the shortened version solved the task less often than the original, the original trace was kept. In the final data round, 85% of tested traces passed; on hard rows, 82%.

Two groups of rows are deliberately left at full length. Hard rows where the continuation test showed the reasoning was needed teach the model when not to cut. High-effort traces are kept as full-reasoning anchors, so the xhigh setting still means thorough thinking. Across the rows we did shorten, tokens fell by 41.5%.

Training and the merge that defines High

Training used LoRA adapters (rank 32, alpha 64) on all attention, MLP and linear-attention projections. The objective combines DPO, with the shortened trace preferred over the original (beta 0.1), and a supervised term on the preferred trace; rows without a shorter variant are supervised directly. We used quantization-aware training: the frozen base weights ran fake-quantized to int4 (group size 32) during training, so that the learned changes are made against a 4-bit view of the model. We have not measured how much this helps the 4-bit GGUF release, which uses a different quantization format. The full dataset has 1,370 rows across ten task types (541 preference pairs, 829 supervised rows) and was trained for one epoch at a learning rate of 5×10⁻⁵. Thinklite-27B Low was trained on a smaller set of 474 rows for two epochs.

The versions differ in how the trained update is applied. Thinklite-27B Max adds the whole LoRA update to the base weights. Thinklite-27B High uses an update-selective merge, following DLER: in each weight matrix, only the largest 25% (by magnitude) of the fine-tuning changes are kept, and those are applied at 0.7×. Thinklite-27B Low is merged the same way as High. The intuition is that the largest changes carry most of the behaviour we trained for, while the long tail of small changes and the full strength of the update are where unwanted drift accumulates. Whether that is the mechanism is a hypothesis; what we measured is the effect.

What the benchmarks show

We evaluated on one frozen suite with identical prompts, chat template, sampling, token caps and scoring for every model: GSM8K (1,319 problems), AIME 2025 (30 problems, two samples each), a 1,000-question stratified subset of MMLU-Pro, IFEval (541 prompts, prompt-level strict), LiveCodeBench v6 (131 problems, pass@1) and BFCL non-live function calling (1,240 cases). All comparisons are at reasoning_effort=low, the setting we trained for, and use the base model's answers from the same suite.

Low: savings without a measurable accuracy cost

Thinklite-27B Low cut reasoning on every benchmark, from 11% on GSM8K to 31% on AIME 2025, and none of its six accuracy differences from the base model is distinguishable from zero: every 95% paired-bootstrap interval includes zero. Its largest point change is on IFEval, −1.9 points (−4.4 to +0.9). Low was evaluated in a separate session; its intervals are against the base model's scoring in that session, which differs from the table's base column by up to 0.7 points (see the appendix).

High: the base model's accuracy on most tasks, not on the hardest

Thinklite-27B High matched the base model on GSM8K (97.3 vs 97.4), MMLU-Pro (84.7 vs 84.4) and BFCL (90.4 vs 90.8) while cutting reasoning by 20 to 32% on those benchmarks. It was weaker on the hardest tasks. AIME 2025 fell from 90.0 to 78.3 (−11.7 points, 95% interval −23.3 to −1.7) and LiveCodeBench from 71.8 to 67.2 (−4.6, interval −13.0 to +3.8). AIME has only 60 graded attempts here, so the size of that drop is uncertain, but its direction is not.

Max, and what the merge buys back

Thinklite-27B Max shows what the full update does. It cut reasoning by 27 to 51% per benchmark and total output by a third, but AIME 2025 fell 25.0 points (−40.0 to −11.7), LiveCodeBench 9.9 points (−18.3 to −2.3) and MMLU-Pro 1.8 points (−3.6 to −0.1). Because High and Max share the same training, their difference isolates the merge: keeping the top quarter of the changes at 0.7× recovered 13.3 points on AIME 2025 and 5.4 on LiveCodeBench, while keeping roughly 70% of Max's reasoning reduction (28% vs 40%).

The gap between Low and the full-dataset versions is harder to attribute. The two datasets differ in size, composition, the depth of the math edits, and the number of epochs, so we cannot say which of these caused High's larger losses on hard problems. Our working hypothesis is the math edits: in the full dataset, edited math traces lost about half their tokens, and AIME is where the regression concentrates. We have not tested that hypothesis in isolation.

Shorter thinking is faster answers

Thinklite does not change the architecture, so it decodes at exactly the base model's speed: about 28 tokens per second for a single user on our GPU. Every second saved comes from writing fewer tokens. We report time to full answer, the wait for a complete response, because that is what a user experiences. At the median, Thinklite-27B High answered 23% faster on AIME 2025, 33% on IFEval and 45% on LiveCodeBench; Max answered LiveCodeBench problems 91% faster. Savings are small where the base model already thinks little: on BFCL, where it averages 96 reasoning tokens, every version is about 4% faster. Full per-benchmark times are in the appendix.

What the shorter reasoning looks like

Averages say how much shorter the reasoning is, not what was removed. One problem answered by all four models shows it directly. This GSM8K problem asks how many Pokémon Stan caught, given that three friends caught 339 together, Alex caught 5 more than Stan, and Stan caught 13 fewer than 4 times as many as Adelwolfe (answer: 147). All four runs used the same prompt, seed and reasoning_effort=low, and all four were correct.

Below is each model's complete reasoning for this problem, exactly as generated and unedited. In every response the reasoning is followed by a short written answer, and all four answers end in 147. The setup and algebra barely change from one version to the next; what changes is how much checking surrounds them.

Qwen3.8-27B: 416 reasoning tokens, then a final answer of 147.

Let me define variables:
- Let A = number of Pokemon Alex caught
- Let S = number of Pokemon Stan caught
- Let D = number of Pokemon Adelwolfe caught

From the problem:
1. A + S + D = 339
2. A = S + 5 (Alex has caught 5 more than Stan)
3. S = 4D - 13 (Stan has caught 13 less than 4 times as many as Adelwolfe)

From equation 3: S = 4D - 13, so D = (S + 13) / 4

From equation 2: A = S + 5

Substituting into equation 1:
(S + 5) + S + (S + 13)/4 = 339

Multiply everything by 4:
4(S + 5) + 4S + (S + 13) = 1356
4S + 20 + 4S + S + 13 = 1356
9S + 33 = 1356
9S = 1323
S = 147

Let me verify:
- S = 147
- A = 147 + 5 = 152
- D = (147 + 13) / 4 = 160 / 4 = 40

Check: 152 + 147 + 40 = 339 ✓
Check: A = S + 5 → 152 = 147 + 5 ✓
Check: S = 4D - 13 → 147 = 4(40) - 13 = 160 - 13 = 147 ✓

The answer is 147.

Thinklite-27B Low: 352 reasoning tokens, then a final answer of 147.

Let me define variables:
- Let A = number of Pokemon Alex caught
- Let S = number of Pokemon Stan caught
- Let D = number of Pokemon Adelwolfe caught

From the problem:
1. A + S + D = 339
2. A = S + 5 (Alex has caught 5 more than Stan)
3. S = 4D - 13 (Stan has caught 13 less than 4 times as many as Adelwolfe)

From equation 3: S = 4D - 13, so D = (S + 13) / 4

From equation 2: A = S + 5

Substituting into equation 1:
(S + 5) + S + (S + 13)/4 = 339

Multiply everything by 4:
4(S + 5) + 4S + (S + 13) = 1356
4S + 20 + 4S + S + 13 = 1356
9S + 33 = 1356
9S = 1323
S = 147

Let me verify:
- S = 147
- A = 147 + 5 = 152
- D = (147 + 13) / 4 = 160 / 4 = 40
- Total: 152 + 147 + 40 = 339 ✓

Stan has caught 147 Pokemon.

Thinklite-27B High: 280 reasoning tokens, then a final answer of 147.

Let me define variables:
- A = number of Pokemon Alex caught
- S = number of Pokemon Stan caught
- D = number of Pokemon Adelwolfe caught

From the problem:
1. A + S + D = 339
2. A = S + 5
3. S = 4D - 13

From equation 2: A = S + 5
From equation 3: S = 4D - 13, so D = (S + 13)/4

Substituting into equation 1:
(S + 5) + S + (S + 13)/4 = 339

Multiply everything by 4:
4S + 20 + 4S + S + 13 = 1356
9S + 33 = 1356
9S = 1323
S = 147

Let me verify:
- S = 147
- A = 147 + 5 = 152
- D = (147 + 13)/4 = 160/4 = 40
- Total: 152 + 147 + 40 = 339 ✓

Thinklite-27B Max: 212 reasoning tokens, then a final answer of 147.

Let:
- A = number of Pokemon Alex caught
- S = number of Pokemon Stan caught
- D = number of Pokemon Adelwolfe caught

Equations:
1. A + S + D = 339
2. A = S + 5
3. S = 4D - 13

From equation 3: D = (S + 13) / 4

Substituting into equation 1:
(S + 5) + S + (S + 13)/4 = 339

Multiply through by 4:
4(S + 5) + 4S + S + 13 = 1356
4S + 20 + 4S + S + 13 = 1356
9S + 33 = 1356
9S = 1323
S = 147

So Stan has caught 147 Pokemon.

On a problem this easy, the extra checks only confirm what the algebra already established, which is the kind of reasoning Thinklite was trained to drop. On hard problems, dropping a check can cost an answer. On AIME 2025 problem 7, a probability question about pairing twelve letters, the base model split the count into two cases, then re-checked each case before answering 821, using 4,839 reasoning tokens. Thinklite-27B High set up the same two cases in 1,836 tokens but counted six possible partners for one letter in the second case, where only one works, did not re-check it, and answered 41. That is consistent with where High lost accuracy, though a single problem does not establish the cause.

Both examples were chosen by rule. The first is, among the problems all four models solved, the one whose reductions are closest to each version's average and follow the same order; the second is the first problem the base model solved and High did not. Samples were drawn at temperature 1.0, so individual problems vary, and on some a Thinklite version writes more than the base. That is why the benchmark averages above, not single traces, are the evidence, and they have limits of their own.

What these results do and do not establish

The comparisons are paired and controlled, but their scope is narrow. All measurements are at reasoning_effort=low; Thinklite supports medium and xhigh, and we have not yet measured whether the savings and the accuracy pattern carry over to those settings. Six benchmarks cover math, knowledge, instruction following, code and function calling, but not long-context retrieval, multi-turn agent tasks or vision; the vision encoder is unchanged from the base model and was not evaluated. The suite was checked for overlap with our earlier training prompts and none of its items reached 50% 8-gram overlap, but we did not repeat that check for every new prompt. Time to full answer is computed from each answer's length, its prefill time and the measured single-user decode speed rather than timed request by request. The GGUF file was smoke-tested for loading and correct answers, not benchmarked.

The practical guidance is therefore by workload. Thinklite-27B Low is the conservative choice when accuracy must match the base model. Thinklite-27B High suits workloads dominated by knowledge questions, structured output, function calling and everyday math, where it kept the base model's accuracy; test it carefully before using it on competition-level math or difficult code. Thinklite-27B Max is for latency-bound settings that can tolerate lower accuracy on hard problems.

Get the weights

All three versions are complete models, drop-in replacements for Qwen3.8-27B with the same chat template, in one repository: Sparset/thinklite-27B. Each version lives on its own branch: main is Thinklite-27B High, low is Low and max is Max. A Q4_K_M GGUF of High, with its vision projector, is on main for llama.cpp, and the LoRA adapters are on the adapters branch. The weights are released under Apache-2.0, the licence of the base model.

vllm serve Sparset/thinklite-27B                   # Thinklite-27B High
vllm serve Sparset/thinklite-27B --revision low    # Thinklite-27B Low
vllm serve Sparset/thinklite-27B --revision max    # Thinklite-27B Max

Pass reasoning_effort through the chat template as you would for Qwen3.8-27B. The model card lists the full results and usage for Transformers and llama.cpp.

Build a model around your workflow

Thinklite shows the kind of adaptation Sparset Forge is built for: start from a strong open model, train it on its own verified behaviour for a concrete target such as shorter reasoning, and measure what it gains and loses before anyone relies on it. The same approach applies to a model tuned for your tasks, your latency budget and your hardware; results on public benchmarks do not guarantee the same outcome on a different workflow.

If you want a custom model, or a model running on your own infrastructure, book a meeting.

Technical appendix

Time to full answer by benchmark

All values are at reasoning_effort=low for a single user. Thinklite-27B Low was timed in a separate session on the same GPU type; its times are scaled to the base model timing shown here, which leaves its speed-up unchanged. Speed-ups in the text and in Figure 1 are the base model's median time divided by the version's, minus one: 45% faster on LiveCodeBench means 129.4 s against 89.4 s, about 31% less waiting.

Evaluation setup

Every model was served with vLLM 0.30.0 in bf16 with an FP8 KV cache and 64 concurrent requests, on one NVIDIA RTX PRO 6000 Blackwell (96 GB). Sampling followed the base model's thinking-mode recommendation (temperature 1.0, top-p 0.95, top-k 20), with a fixed seed per item and sample so every model received the same seed for the same question. Per-benchmark output caps were set from the base model's measured lengths before the runs and applied to all models; answers that reached a cap were rerun once with a 131,072-token cap. Truncated and unparseable answers count as incorrect, and no item was dropped. Accuracy differences use 95% paired-bootstrap intervals (10,000 resamples). Scoring used math-verify for GSM8K and AIME, the official LiveCodeBench evaluator on public and private tests, the lm-eval IFEval checker on the final answer only, and the official BFCL AST checker on 1,240 items from the v3 non-live categories. The base model's answers were generated once and re-scored in each session. Re-scoring moved its IFEval score by up to 0.4 points (its language check is not deterministic) and its LiveCodeBench score by 0.7 points (executed tests); the tables use the latest scoring.

Release details

For the base model see the Qwen3.8-27B model card; for the merge method see DLER (arXiv 2510.15110).