Making an AI think longer can mean one deep chain or dozens of quick guesses — and these aren't interchangeable.

This explores the difference between spending inference budget on *depth* (one long chain of reasoning that builds on itself) versus *breadth* (many independent attempts you aggregate). The corpus treats this as the central recurring trade-off of test-time compute: parallel methods buy you coverage — more shots at a lucky correct answer — while sequential methods buy you depth, letting a model carry an intermediate result forward into the next step How should we balance parallel versus sequential compute at test time?. The tempting read is that these are interchangeable knobs. They aren't. The right one depends on the *shape* of the problem.

The sharpest result is that on genuinely compositional problems — where the answer can only be reached by accumulating intermediate steps, like tracing connectivity through a graph — sequential chain-of-thought beats parallel voting by an *exponential* margin When does sequential reasoning beat parallel voting?. The reason is structural: short parallel chains can't manufacture a multi-step derivation by majority vote, because no single short chain ever holds the whole computation. Parallelism wins the opposite case — many independent, short, self-contained problems where a wider net catches more correct answers. So the primitives aren't ranked; they're matched to whether a task's solution is decomposable-and-independent or genuinely chained.

Here's the part a curious reader might not expect: our models are lopsided. One line of work (SPIRAL) names *three* primitives — sequential, parallel, and aggregative (combining separate traces into one better answer) — and points out that post-training only ever optimizes the first Why does post-training ignore parallel and aggregative reasoning?. Models are trained to think in one long line, so at inference they waste parallel budget: they never learned to produce traces that are *jointly* informative or to aggregate them well. The compute is available; the trained skill to use it isn't.

There's also a humbling counterweight to the whole 'just add compute' framing. When you control for total compute spent, different search frameworks — best-of-N sampling versus tree search — converge to roughly the same accuracy Does the choice of reasoning framework actually matter for test-time performance?. What actually moves the needle is total budget and the quality of the reward/value function judging the attempts, not the cleverness of the search shape. And none of it manufactures capability the base model lacks: test-time compute can substitute for model size on hard prompts Can inference compute replace scaling up model size?, but it can't push past limits set by training Can non-reasoning models catch up with more compute?. A non-reasoning model given unlimited inference still loses to a reasoning model, because training instilled a protocol that makes each extra token productive in the first place.

The cleanest way to hold all this: parallel and sequential are two ends of one budget-allocation problem, and both sit inside the larger split between *external* scaling (search and verify over a fixed model) and *internal* scaling (training the model to reason autonomously) How do internal and external test-time scaling compare?. Parallel-vs-sequential is the external, inference-time face of that decision — but it's rate-limited by whether training ever taught the model to spend depth *and* breadth well, and by whether you're spending on the kind of problem each primitive is built for How should we spend compute at inference time?.