How to Use Least-to-Most Prompting

Least-to-most prompting is a two-stage strategy. In stage one (decomposition), you prompt the model to break the original question into an ordered list of subproblems, starting with the simplest. In stage two (sequential solving), you solve each subproblem one at a time, and critically, each solved subproblem's answer is appended to the context so the next subproblem can build on it.

The name captures the ordering: you go from the 'least' (easiest, most foundational) subproblem to the 'most' (the full original problem) by accumulating partial results. By the time the model reaches the hard final step, the groundwork is already solved and in context, so the remaining leap is small.

The key result from Zhou et al. 2022 is generalization: because the model composes a solution from simpler solved pieces, it can handle problems more complex than the worked examples in the prompt — the regime where standard few-shot chain-of-thought tends to break down.

Chain-of-thought produces the reasoning and the answer in **one pass** — the model thinks aloud and lands on a result in a single generation. Least-to-most is **explicitly two-stage and sequential**: first decompose, then solve the subproblems in order across multiple steps, carrying answers forward. The decomposition is a first-class, separate output.

That structural difference is why least-to-most generalizes to harder-than-example problems where one-pass CoT stumbles. Each subproblem is small enough that the model is reliable on it, and chaining reliable small steps beats attempting one big, error-prone leap. Per Zhou et al. 2022, this matters most on compositional tasks — symbolic manipulation, multi-stage math, and last-letter-style problems where length itself is the difficulty.

The cost is structure and steps: you run more turns and carry more context. On easy problems that one CoT pass already nails, that overhead is wasted — least-to-most is for the hard, compositional tail.

Use least-to-most when: the problem is compositional and harder than the examples you can show — multi-stage math, symbolic reasoning, tasks that get harder with length — and a single chain-of-thought pass keeps failing on the later steps. Decompose first, then solve subproblems in order.
Skip least-to-most when: a single chain-of-thought pass already solves it, the problem doesn't decompose into ordered subproblems, or the task is open-ended with no clear chain of dependencies. The extra stages and context are wasted overhead on easy problems.

Take a compositional word problem. The 'before' is a single chain-of-thought pass:

``` Amy has 3 boxes. Each box has 4 bags. Each bag has 6 marbles, but every third bag is empty. She gives away half her marbles, then buys 2 more full bags. How many marbles does she have? Reason step by step, then answer. ```

On a fast model this stacks too many dependent operations into one pass and often slips on the 'every third bag' or the 'half' step. The least-to-most 'after' splits it. Stage one — decompose:

``` Break this problem into an ordered list of the smallest subproblems needed to solve it, from simplest to the full question. Do NOT solve them yet — just list them in order. [paste the problem] ```

The model returns something like: (1) total bags, (2) how many bags are empty, (3) marbles before giving any away, (4) marbles after giving half away, (5) marbles in 2 more full bags, (6) final total. Stage two — solve each in order, carrying answers forward:

``` Solve these subproblems one at a time, in order. After each, restate the running result so the next step can use it. Subproblems: 1. How many bags total? ... 2. How many bags are empty? ... 3. Marbles before giving any away? (use 1 and 2) 4. Marbles after giving half away? (use 3) 5. Marbles in 2 more full bags? ... 6. Final total? (use 4 and 5) End with: ANSWER: <number>. ```

Each step is now trivial on its own, and step 6 only has to add two already-computed numbers. The decomposition is what removed the difficulty.

---

In production you'd run stage one to get the subproblem list, then loop stage two as separate calls (or a single guided call), appending each result to the context. For code tasks, the same pattern — decompose, then implement piece by piece — works well with the Code Prompt Builder.

Frontier reasoning models — GPT-5.5 in thinking mode, Claude Opus 4.8 and Sonnet 4.6 with extended thinking — already decompose problems internally during their hidden reasoning, so an explicit least-to-most scaffold often duplicates work they'd do anyway. On these models, lead with a clear problem statement and only add explicit decomposition when the output still skips or fumbles a stage.

Where the explicit version still pays off in 2026: on faster, cheaper non-reasoning tiers (the lower-cost models in cost per token, all major models); when you need the decomposition **visible** for auditing or for a human to check each step; and when subproblems map to real tool calls or database lookups, which pushes you toward an agentic tool-use pattern. For model selection, see how to choose an AI model.

Least-to-most is part of the chain-of-thought family but emphasizes explicit, ordered decomposition over single-pass reasoning. It overlaps with Tree of Thoughts (arXiv:2305.10601), which also breaks problems into steps but explores and prunes a branching search rather than following one linear chain of dependent subproblems.

It composes well with other patterns: add self-consistency on the hardest subproblem to vote out errors, or wrap the whole thing in a role so an expert persona drives the decomposition. For the broader map of variants, see the chain-of-thought variants comparison and the DAIR.ai Prompt Engineering Guide.