What Is Least-to-Most Prompting? Breaking Problems into Subproblems

// In plain English

Least-to-most prompting is a way of getting a language model to solve a hard problem by first breaking it into a ladder of smaller subproblems, then solving them one at a time — easiest first — feeding each answer into the next step. The name says it plainly: you go from the least complex piece to the most complex, building up the final answer instead of trying to leap straight to it.

Picture teaching a child long division. You don't hand them a five-digit problem and hope. You first ask, how many times does 7 go into 23? Then you use that answer to take the next bite, and the next. Each small win becomes a stepping stone for the harder step that follows. Least-to-most prompting does exactly this with an LLM: it makes the model lay out the stepping stones first, then walk across them in order.

This sits in the same family as chain-of-thought prompting, where the model "thinks step by step." The key difference: chain-of-thought reasons through everything in one pass and hopes the steps stay correct. Least-to-most splits the work into separate, explicit subproblems and solves each in its own turn, carrying the results forward — so a later step can lean on a verified earlier answer rather than a fuzzy mid-thought.

// Why it matters

Plain chain-of-thought reasoning works well when a problem is roughly as complex as the examples in the prompt. But it has a known weak spot: compositional generalization — solving a problem that requires more steps than anything the model has seen demonstrated. Asked to chain together five operations when the examples only showed two, a single reasoning pass tends to skip a step, lose track, or jump to a wrong conclusion.

Least-to-most attacks this directly. By forcing the model to name the subproblems first and solve them in order, it turns one overwhelming task into a series of small, manageable ones — each of which is in the model's comfort zone. The hard part (the overall structure) gets handled by decomposition; the easy parts (each individual step) get handled by ordinary reasoning.

Where a builder feels the difference

• Multi-step math and word problems. Problems where the answer to one part is needed before you can even state the next part.
• Multi-hop question answering. "Who directed the film that won Best Picture the year X was born?" — you must first find X's birth year, then the winning film, then its director. Each hop depends on the last.
• Structured generation. Building something in stages — outline, then sections, then polish — where a later stage relies on decisions made earlier.
• Symbolic / list manipulation. Tasks like last-letter concatenation or interpreting commands that get longer than the demonstrations, the exact setting where the original paper showed the largest gains.

The payoff is reliability on long-horizon problems and, often, generalization beyond the examples — the model handles a 6-step instance after seeing only 2-step demos. The cost, which we'll come back to, is more model calls and a bit more orchestration. For a quick factual lookup it's overkill; for genuinely compositional tasks it can be the difference between a right answer and a confidently wrong one.

// How it works

Least-to-most prompting runs in two phases. First you decompose: ask the model to break the problem into an ordered list of subproblems, simplest first. Then you solve sequentially: work through that list one subproblem at a time, and crucially, paste each solved answer into the prompt for the next subproblem. The accumulating context is what makes the chain hold together.

Phase 1 — decompose into a subproblem ladder

You give the model the problem and a few examples of how to break problems down, then ask it to list the subproblems it would need to solve, in order, easiest to hardest. The output isn't an answer yet — it's a plan. For a question like "How many times can Amy slide down a 200-foot slide in 2 hours if each slide takes 4 minutes including the climb back up?", the decomposition might be: (1) how many minutes are in 2 hours? (2) how many 4-minute slides fit in that many minutes?

Phase 2 — solve sequentially, accumulating answers

Now you solve the ladder bottom-up. Subproblem 1 is answered on its own. Then — and this is the heart of the method — you build the prompt for subproblem 2 so it includes subproblem 1 and its answer. The model never has to re-derive what it already worked out; it just uses it. Each step's context is the original question plus every (subproblem, answer) pair solved so far. The answer to the final subproblem is the answer to the whole thing.

Notice what's happening: the model is reading its own earlier outputs as trusted facts. That's the difference from chain-of-thought, where every step lives in a single generation and an early mistake silently poisons everything downstream. Here each answer is committed and reused, so the chain is built on solid ground rather than on a long, unbroken stretch of "hopefully correct" reasoning.

// A worked example

Let's run a small multi-hop question end to end: "What is the population of the country whose capital is the city where the 2016 Summer Olympics were held?" A single pass can stumble by conflating cities and countries. Least-to-most makes each hop explicit.

Phase 1: the decomposition prompt

To answer the question below, list the subproblems that must be
solved first, in order, simplest first. Do not answer them yet.

Question: What is the population of the country whose capital is
the city where the 2016 Summer Olympics were held?

Subproblems:
1. Which city hosted the 2016 Summer Olympics?
2. Which country has that city as its capital?
3. What is the population of that country?

Note a real subtlety the decomposition surfaces: the host city was Rio de Janeiro, which is not a capital. A naive single-pass answer might assume "host city = capital" and report Rio's population. Splitting the hops forces the model to check that link explicitly, and that's often where it catches its own error.

Phase 2: solving the ladder, carrying answers forward

Step 1
Q: Which city hosted the 2016 Summer Olympics?
A: Rio de Janeiro, in Brazil.

Step 2  (context now includes Step 1's answer)
Known: The 2016 Olympics were held in Rio de Janeiro, Brazil.
Q: Which country has that city as its capital?
A: Rio de Janeiro is not a capital. It is in Brazil, whose
   capital is Brasilia. The intended country is Brazil.

Step 3  (context now includes Steps 1-2)
Known: The country is Brazil.
Q: What is the population of that country?
A: Brazil's population is roughly 210 million.

Here's the same idea wired up as a tiny orchestration loop, the structure you'd actually build for the multi-call version:

from anthropic import Anthropic

client = Anthropic()

def ask(prompt):
    msg = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=400,
        messages=[{"role": "user", "content": prompt}],
    )
    return msg.content[0].text.strip()

def least_to_most(question, subproblems):
    # subproblems: ordered list from the decompose phase, simplest first.
    solved = []  # accumulates (subproblem, answer) pairs
    for sub in subproblems:
        context = "\n".join(f"Known: {s} -> {a}" for s, a in solved)
        prompt = (
            f"Original question: {question}\n"
            f"{context}\n"
            f"Now answer ONLY this subproblem: {sub}"
        )
        answer = ask(prompt)
        solved.append((sub, answer))
    return solved[-1][1]  # the last answer IS the final answer

// Least-to-most vs chain-of-thought vs tree-of-thought

These three reasoning techniques are easy to mix up because all of them make the model "show its work." The real difference is the shape of the reasoning: one line, one ladder, or one tree.

A clean way to remember it: least-to-most fits when you know the order of the steps but each depends on the last; tree-of-thought fits when you don't know the right path and must search. They also compose — you can decompose with least-to-most and use self-consistency (sample each step several times, take the majority) to harden any individual step.

// Common pitfalls and practical tips

Least-to-most is powerful but it has failure modes that mostly trace back to the decomposition step. If the ladder is wrong, solving it perfectly still gives a wrong answer.

• A bad decomposition dooms everything. If the model lists the wrong subproblems or the wrong order, the rest of the pipeline faithfully produces nonsense. The plan is the highest-leverage part — review it, or have the model double-check it, before solving.
• Error propagation still exists. Committing answers helps, but a wrong early answer is now trusted by every later step. The chain can be more confidently wrong, not just wrong. For critical steps, verify or use self-consistency.
• Over-decomposition. Splitting a 2-step problem into 8 trivial subproblems wastes calls and adds places to slip. Decompose only as finely as the problem actually needs.
• Context bloat. Because you accumulate every (subproblem, answer) pair, long ladders grow the prompt fast. On very long chains, summarize or keep only the answers each later step truly needs — this overlaps with context engineering.
• Using it when you don't need it. For a one-hop factual question, plain chain-of-thought or even a direct answer is cheaper and just as good.

Tips that make it work

• Give the model a few decomposition examples, not just answer examples — show it how to break problems down.
• Keep each subproblem self-contained: phrase it so it can be answered with the original question plus the answers carried so far.
• Label carried-forward answers clearly in the prompt (e.g. a Known: block) so the model treats them as established facts, not new questions.
• Fence inputs and prior answers with simple structure — see structuring prompts with XML or markdown — so the model never confuses the question with the context.

// Going deeper

Once the basic two-phase loop clicks, a few directions are worth knowing.

Relationship to modern reasoning models. Today's reasoning models do a lot of decomposition internally, spending hidden "thinking" tokens to plan before answering. That doesn't make least-to-most obsolete — it changes who drives it. When you control the decomposition explicitly (separate calls, an editable plan, verification between steps), you get auditability and the ability to inject tools or checks at each rung that a single opaque thinking pass can't offer.

Dynamic vs. fixed decomposition. The original method decomposes once, up front. A more flexible variant decomposes as it goes: solve a step, look at the result, then decide the next subproblem. That blurs the line toward tree-of-thought search and toward agent loops, where a model interleaves planning, acting, and observing rather than committing to a full plan in advance.

Decomposition as a building block for tools and agents. The subproblem ladder maps neatly onto tool use: a subproblem like "what is the population of Brazil?" can be routed to a search tool or database instead of the model's memory. This is how least-to-most thinking shows up inside agentic systems — decompose the user's goal, then solve each piece with the right capability, accumulating results. It pairs naturally with retrieval and external data sources.

Evaluation. Because the method has discrete steps, you can measure it at two levels: decomposition quality (did it list the right subproblems in the right order?) and step accuracy (was each subproblem solved correctly?). Tracking both tells you whether failures come from a bad plan or a bad execution — a far more useful signal than a single right/wrong on the final answer. To go further from here, read about self-consistency for hardening individual steps and the broader craft of prompt engineering.