Least-to-Most Prompting

What Is Least-to-Most Prompting? Least-to-most prompting is a technique that solves a complex problem in two stages:

Decomposition: the model breaks the problem into a sequence of simpler subproblems, ordered from the easiest ("least") to the one that answers the original question ("most"). Sequential solving: the model solves the subproblems one at a time, and each answer is added to the context for the next subproblem. In simple terms: first make a list of smaller questions, then answer them in order, using each answer to help with the next.

Example Original problem:

A student must finish 48 lessons. She completes 3 lessons on each weekday, 5 lessons on Saturday, and rests on Sunday. She starts on a Monday. On which day does she finish the last lesson? Stage 1 — Decomposition:

1. How many lessons does she complete in one full week?
2. How many lessons has she completed after two full weeks?
3. How many lessons remain after two full weeks?
4. On which day of the third week does she complete the remaining lessons? Stage 2 — Sequential solving:

Q1: How many lessons does she complete in one full week? A1: 5 weekdays × 3 = 15, plus 5 on Saturday = 20 lessons per week.

Q2: How many lessons has she completed after two full weeks? A2: 2 × 20 = 40 lessons.

Q3: How many lessons remain after two full weeks? A3: 48 − 40 = 8 lessons.

Q4: On which day of the third week does she complete the remaining lessons? A4: Monday: 3 (5 left), Tuesday: 3 (2 left), Wednesday: 3 (done). She finishes on Wednesday of the third week. Example Explanation Each subquestion is easy on its own. The key feature is that later subquestions use earlier answers: Q3 needs A2, and Q4 needs A3. The final subquestion answers the original problem.

Where It Comes From Least-to-most prompting was introduced in the 2022 paper "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models" by Zhou et al.

The authors focused on a specific weakness of chain-of-thought prompting: easy-to-hard generalization. When the problems at test time were harder than the examples in the prompt, for instance requiring more steps, chain of thought often failed. Least-to-most prompting performed much better on such problems, including on SCAN, a benchmark that tests whether a model can interpret longer and more complex commands than it has seen in examples.

The idea: if a model can reliably solve simple problems, and a hard problem can be reduced to a sequence of simple ones, then the model can solve the hard problem step by step.

Why It Works Smaller Problems Are More Reliable Each subproblem is simpler than the original and is more likely to be solved correctly. This is similar to the benefit of chain of thought (Lesson 39), but with a stronger structure.

Explicit Planning Before Solving In chain of thought, the model decides what to do next while reasoning. In least-to-most, it first plans the full sequence of subproblems. Separating planning from solving makes it less likely that important steps are skipped (compare Plan-and-Solve, Lesson 40).

Answers Build on Verified Context Each subproblem is solved with the previous questions and answers in its context. The model does not have to remember or recompute earlier results; they are written explicitly.

It Scales to Harder Problems A problem with more steps simply produces a longer list of subproblems. The difficulty of each step stays manageable, even when the overall problem is harder than anything in the examples.

Least-to-Most Compared With Related Techniques Aspect Chain-of-Thought Least-to-Most Task Decomposition (Lesson 15) Who plans the steps? The model, during reasoning The model, in a separate first stage Usually the developer Steps are explicit questions? No, free-form reasoning Yes Yes, as separate prompts Each step's answer feeds the next? Implicitly, in one response Explicitly, by including previous Q&A Yes, through code Number of requests 1 1 (decomposition) + one per subproblem, or combined One per step Best for Problems of moderate complexity Problems harder than the examples, with clear dependencies Production workflows with fixed structure The Key Difference From Lesson 15 In Lesson 15, you design the steps of a workflow, such as "extract, then group, then report". In least-to-most prompting, the model decides how to break down each problem, which makes it suitable when every problem may need a different decomposition.

Stage 1: The Decomposition Prompt The decomposition prompt asks for subproblems only, without solving them.

Break the problem in into a short sequence of simpler questions.

Rules:

• Order the questions so that each can be answered using only the problem and the answers to the earlier questions.
• The last question must be the one that answers the original problem.
• Do not answer the questions.
• Use at most 5 questions.

Return only a JSON array of strings. Why Each Rule Matters Order by dependency: ensures each subproblem can actually be solved when it is reached. Last question answers the original: guarantees the sequence ends with the required result. Do not answer: keeps planning separate from solving, so the solving stage can focus on one question at a time. At most 5 questions: prevents over-decomposition into trivial steps, which adds cost without benefit. Few-Shot Decomposition The original research used examples of decomposition to show the model how to break down problems of that type. For a specific domain, a few examples of good decompositions can improve consistency:

Problem: A course costs ₹6,000 with 15% off, then 18% GST is added. What is the final price? Questions:

1. What is the discount amount?
2. What is the price after the discount?
3. What is the GST on the discounted price?
4. What is the final price? Stage 2: The Sequential Solving Prompt Each subproblem is solved with the original problem and all previous questions and answers in the context.

[original problem]

Previous questions and answers: Q1: [question 1] A1: [answer 1] Q2: [question 2] A2: [answer 2]

Answer the next question briefly, using the problem and the previous answers. Q3: [question 3] A3: Why Include Previous Answers Each request is independent (Lesson 2). Without the previous Q&A pairs, the model would have to recompute everything, which defeats the purpose of the decomposition.

Implementing Least-to-Most in Python Requirements: pip install openai and an OPENAI_API_KEY environment variable.

import json

from openai import OpenAI

client = OpenAI() MODEL = "gpt-5.4" # Replace with a model available in your account

DECOMPOSE = """Break the problem in into a short sequence of simpler questions. Order the questions so that each can be answered using only the problem and the answers to earlier questions. The last question must answer the original problem. Do not answer the questions. Use at most 5 questions. Return only a JSON array of strings."""

SOLVE = """Answer the next question briefly, using the problem and the previous answers. Show any calculation in one line."""

def call(instructions: str, input_text: str) -> str: response = client.responses.create(model=MODEL, instructions=instructions, input=input_text) return response.output_text.strip()

def least_to_most(problem: str) -> list[tuple[str, str]]: problem_block = f"\n{problem}\n"

# Stage 1: decomposition questions = json.loads(call(DECOMPOSE, problem_block)) if not isinstance(questions, list) or not questions: raise ValueError("Decomposition did not return a list of questions")

# Stage 2: sequential solving solved: list[tuple[str, str]] = [] for number, question in enumerate(questions, start=1): history = "\n".join( f"Q{i}: {q}\nA{i}: {a}" for i, (q, a) in enumerate(solved, start=1) ) prompt = ( f"{problem_block}\n\n" f"Previous questions and answers:\n{history or '(none)'}\n\n" f"Q{number}: {question}\nA{number}:" ) solved.append((question, call(SOLVE, prompt))) return solved

problem = ( "A student must finish 48 lessons. She completes 3 lessons on each weekday, " "5 lessons on Saturday, and rests on Sunday. She starts on a Monday. " "On which day does she finish the last lesson?" )

for i, (question, answer) in enumerate(least_to_most(problem), start=1): print(f"Q{i}: {question}\nA{i}: {answer}\n") Code Explanation DECOMPOSE The Stage 1 instructions: ordered subquestions, the last one answering the original problem, no answers, and at most five questions, returned as a JSON array.

Validation of the decomposition The code checks that the result is a non-empty list. A failed decomposition stops the process early with a clear error, rather than producing confusing results later.

history Builds the text of all previously solved questions and answers. For the first question, there is no history, so (none) is shown instead of an empty section.

The solving prompt Contains the delimited original problem, the history, and the next question with an open answer label (A3:) as the output cue (Lesson 8).

solved A list of (question, answer) pairs. The last pair contains the answer to the original problem; the full list documents how it was reached, which is useful for checking and debugging.

Verifying the Result The example problem is exact, so it can be checked with a simple simulation:

DAYS = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"] LESSONS_PER_DAY = {"Saturday": 5, "Sunday": 0}

def finishing_day(total: int, weekday_rate: int = 3) -> tuple[str, int]: done, day = 0, 0 while True: name = DAYS[day % 7] done += LESSONS_PER_DAY.get(name, weekday_rate) if done >= total: return name, day // 7 + 1 day += 1

print(finishing_day(48)) Output:

('Wednesday', 3) The simulation adds each day's lessons until the total is reached and returns the day name and week number. It confirms the least-to-most answer: Wednesday of the third week. As in earlier lessons, use code for exact computation whenever the problem allows it.

Combining Stages in a Single Prompt For simpler problems, both stages can be performed in one request:

Solve the problem in using these steps:

1. First, list the simpler questions that must be answered, in order.
2. Then answer each question in order, using the previous answers.
3. Finally, give the answer to the original problem on a line starting with "Answer:". Trade-Off Approach Advantages Disadvantages Separate requests Each subproblem receives full attention; easy to inspect and validate each step More requests, higher latency and cost Single prompt One request; simpler Less control; errors in one step are harder to catch before the next Use separate requests for difficult or important problems, and the single-prompt version for moderate ones.

Least-to-Most Beyond Math The technique works for any problem that can be reduced to dependent questions.

Answering Questions From Documents Problem: Using the course policy, can a student who joined the September batch still switch to the November batch?

Subquestions:

1. What does the policy say about batch switching?
2. What is the deadline for switching, relative to the batch start date?
3. When did the September batch start?
4. Has the switching deadline passed for the September batch? Debugging Problem: Why does the student dashboard load slowly for users with many courses?

Subquestions:

1. Which database queries run when the dashboard loads?
2. How does the number of queries change with the number of courses?
3. Which query or pattern grows with the number of courses?
4. What change would make the number of queries constant? This decomposition leads naturally toward identifying an "N+1 query" problem, where one query is executed per course instead of a single query for all courses.

Planning Problem: How should we migrate our Django project from SQLite to PostgreSQL without losing data?

Subquestions:

1. What data and schema need to be moved?
2. How can the data be exported from SQLite?
3. How should PostgreSQL be configured for the project?
4. How can the data be imported and verified?
5. How can the switch be done with minimal downtime? Common Mistakes Mistake 1: Subquestions That Are Not Ordered by Dependency What it is: A subquestion requires information that is only answered later.

Why it happens: The decomposition prompt does not require dependency order.

What it causes: The model guesses the missing information, and errors propagate.

How to fix it: Require that each question can be answered from the problem and earlier answers only.

Mistake 2: Over-Decomposition What it is: Breaking a simple problem into many trivial questions.

Why it happens: No limit on the number of subquestions.

What it causes: More requests and longer outputs without improvement.

How to fix it: Set a maximum number of questions and use least-to-most only for genuinely multi-step problems.

Mistake 3: Not Passing Previous Answers What it is: Solving each subquestion in a separate request without including earlier answers.

Why it happens: Each request is built only from its own subquestion.

What it causes: The model recomputes or guesses earlier results, losing the core benefit of the technique.

How to fix it: Include the original problem and all previous Q&A pairs in every solving request.

Mistake 4: Last Subquestion Does Not Answer the Original Problem What it is: The decomposition ends with an intermediate question.

Why it happens: The prompt does not require the final question to answer the original problem.

What it causes: The process ends without a final answer.

How to fix it: Require it explicitly, and check the last question before solving.

Mistake 5: Trusting Each Step Without Checking What it is: Assuming that simpler subproblems are always solved correctly.

Why it happens: Each step looks easy.

What it causes: An error in one step propagates through all following answers (Lesson 44).

How to fix it: Validate intermediate answers where possible, and compute exact values in code.

Best Practices Separate planning from solving. Decompose first, then solve.

Order subquestions by dependency. Each must be answerable from the problem and earlier answers.

End with the original question. The last subquestion must answer the problem.

Pass all previous answers forward. That is what makes later steps reliable.

Limit the number of subquestions. Enough to make each step simple, no more.

Use few-shot decomposition examples for a domain. They make decompositions more consistent.

Verify steps and use code for exact work. Simpler steps are more reliable, not infallible.

Try It Yourself Exercise 1: Decompose by Hand Write a least-to-most decomposition for this problem, then solve each subquestion in order:

A course has 4 modules of 6 lessons each. A student completes 2 lessons per day on weekdays and 4 lessons per day on weekends. Starting on a Saturday, on which day does the student complete the course? Check your answer with a modified version of finishing_day().

Exercise 2: Compare With Chain of Thought Create five multi-step problems that are harder than typical examples, with more steps or more conditions. Solve each with a chain-of-thought prompt and with the least_to_most() function. Compare accuracy and inspect where each approach made errors.

Exercise 3: Non-Math Decomposition Use the decomposition prompt on a debugging or planning question from your own project. Evaluate whether the generated subquestions are in a sensible dependency order, whether any important question is missing, and whether the last question answers the original problem.