Least-to-Most Prompting: 6 Recipes That Ship (2026)

Quick Answer

Least-to-most prompting (in LLMs, not the ABA-therapy technique with the same name) is a two-stage move: first make the model list the ordered subproblems, then make it solve them in sequence, feeding each answer into the next. It beats a single chain-of-thought pass on problems where step 3 depends on the answer to step 1. As of 2026 the rule that survives production is short: decompose first, solve second, and carry the state forward by hand so the model cannot skip a rung.

Six copy-paste recipes below, each with the receipt, why it works, and the failure mode. Tested on Claude and GPT-class models.

Tested on Claude and GPT models. Named after Zhou et al., 2022, the paper that showed easy-to-hard generalization from ordered subproblems.

Recipe 1: Decompose, then solve

Claim: Split the work into two prompts. First prompt lists subproblems. Second solves them in order.

PROMPT 1 (decompose):
Break this problem into the smallest ordered subproblems needed to
solve it. Number them. Do NOT solve anything yet.
Problem: {problem}

PROMPT 2 (solve):
Here are the subproblems: {numbered list from prompt 1}.
Solve #1. Then use its answer to solve #2. Continue in order.
Show each answer before moving to the next.

Why: Forcing the list before the work stops the model from committing to a plan mid-reasoning and then bending later steps to fit it. The order is the product.

Failure mode: The model solves during decomposition anyway. Add "Do NOT solve anything yet" in caps and reject any prompt-1 output that contains a final answer.

Recipe 2: Single-message least-to-most

Claim: For cheaper cases, run both stages in one prompt with a fixed scaffold.

Solve this in two passes.
PASS 1: list the ordered subproblems, numbered, no solutions.
PASS 2: solve each in order, carrying earlier answers forward.
End with the final answer on its own line prefixed FINAL:
Problem: {problem}

Why: One round-trip, half the tokens, most of the benefit on medium-hard problems. The FINAL: prefix gives you a clean parse target.

Failure mode: On genuinely hard chains the single message lets the model rush pass 2. If the answer is wrong, promote it back to the two-prompt version in Recipe 1.

Recipe 3: Carry the state forward by hand

Claim: Do not trust the model to remember subproblem 1's answer by subproblem 4. Paste it in.

Subproblem 2. Given that subproblem 1 returned: {answer_1}
solve: {subproblem_2}
Return only the answer, no restatement.

Why: Explicit state carry is the whole point of least-to-most over plain chain-of-thought. When each rung receives the prior answer as literal input, later steps generalize to inputs harder than anything in your examples.

Failure mode: State drift, where the model quietly re-derives answer_1 and gets a different number. Pin it: "Use exactly this value: {answer_1}. Do not recompute it."

Recipe 4: Least-to-most for data pipelines

Claim: Order the stages the way a pipeline runs: extract, then normalize, then aggregate.

Stage 1 (extract): pull every date and amount from the text below.
Stage 2 (normalize): using stage 1 output, convert all dates to
ISO 8601 and all amounts to cents.
Stage 3 (aggregate): using stage 2 output, sum amounts per month.
Run the stages in order. Show each stage output.
Text: {document}

Why: Each stage has one job and receives clean input from the last. You can eval each stage in isolation and swap one without rewriting the prompt.

Failure mode: Stage 3 references the raw text instead of stage 2 output and double-counts. Say "use ONLY the previous stage output" on every downstream stage.

Recipe 5: When to reach for least-to-most (and when not to)

Claim: Least-to-most earns its extra tokens only when later steps depend on earlier answers.

- One-step answer, format is nameable        -> zero-shot
- Linear reasoning, no dependency between steps -> chain of thought
- Step N needs the answer to step 1          -> least-to-most
- Independent calls with different prompts    -> prompt chaining

Why: Decomposition is overhead. On a problem with no cross-step dependency it just costs tokens and adds a place to go wrong.

Failure mode: Decomposing trivial tasks. If subproblem 1 already contains the final answer, you picked the wrong technique. This is the same discipline as choosing the reasoning depth in chain of thought prompting, and it pairs naturally with prompt chaining once each subproblem needs its own call.

Recipe 6: Cap the decomposition

Claim: Bound the subproblem count so the model cannot spawn a runaway list.

Break this into AT MOST 5 ordered subproblems. If it needs more
than 5, group the smallest ones. Fewer, larger rungs beat many
tiny ones.

Why: Unbounded decomposition produces 14 micro-steps, each a chance for state drift, and burns tokens for no accuracy gain past a point.

Failure mode: The cap is too tight and a real dependency gets merged away. Start at 5, raise only if a genuine step is being crushed.

One placement note

The decomposition rule is a standing instruction, not a per-task one, so it belongs in the system prompt, while the actual problem goes in the user prompt. If you are unsure which lane a rule lives in, the split is covered in system prompt vs user prompt. The same instinct that ships a product also applies here: solve the smallest subproblem first, then the next, which is how most of the founders in OperatorBook's build stories got anything out the door at all.

Cost to test: $0.04. Run one hard problem through Recipe 1 and the same problem through a single chain-of-thought pass, and compare the last step.