What Is Chain-of-Thought Prompting?
Chain-of-thought prompting asks for intermediate steps to be produced before a final answer, rather than the answer alone. The intermediate text becomes part of the context the answer is generated from, and that is the entire mechanism by which it has any effect.
How the steps are elicited, and what they are
Two forms are in general use: instructing that the working be shown, and supplying examples that themselves contain worked reasoning so the demonstrated answer shape includes the steps. Some deployments produce intermediate reasoning by default and do not return it, in which case the technique is a property of the deployment rather than of the prompt.
What the steps are is worth being exact about, because the phrasing invites a stronger reading than the mechanism supports. The steps are generated text. They are produced by the same process that produces the answer, and they condition it because they are in the context — not because they are a record of a separate procedure carried out elsewhere and then reported back.
Three neighbouring things travel under one name, and separating them removes most of the confusion around the term. Chain-of-thought as described here is a prompting technique: the request asks for the working, and the working comes back inside the response. Separately, some deployments are trained to produce extended reasoning before answering, budgeted and billed as its own class of tokens; what the caller receives back may be a shortened account of that process rather than the text the process consisted of, and a summary should not be read as a transcript. Sitting on top of either is a sampling procedure usually called self-consistency: the same question is answered several times independently, with sampling rather than greedy decoding, and the final answer appearing most often across the runs is the one kept. Its cost is the number of samples, paid in full each time.
| Situation | Why the steps matter |
|---|---|
| Multi-step arithmetic | Intermediate results are carried in the text rather than held implicitly. |
| Ordered procedures | The order is made explicit and can be checked against the requirement. |
| Extraction from long input | Candidate passages are identified before the answer is composed from them. |
| Tasks needing a citation trail | The route to the answer is visible for review afterwards. |
| A single-fact lookup | Little to gain; the cost in tokens and latency is paid regardless. |
The last row is the general rule rather than an exception to it. The technique costs tokens and time on every request, and it is worth that on tasks that have steps to get wrong.
The steps are not an explanation
A visible chain of steps reads as an account of how the answer was reached, and it is safer to treat it as text that accompanies the answer. Steps can be internally consistent and lead to a stated conclusion that does not follow from them, and a correct answer can appear beneath working that contains an error.
The practical consequence is that reasoning text is not an audit trail. Where a task genuinely requires verification, the check is applied to the answer — recomputing the arithmetic, resolving the citation, running the code — rather than to the plausibility of the narrative sitting above it.
Displaying the steps carries a second cost, and it is not the token bill. Reasoning text is generated alongside the answer and drawn from the same output allowance, so a long chain under a fixed output cap can crowd out the conclusion it was produced to support and truncate exactly where the result should have been. Shown to a reader, that same text presents as justification, which is a stronger thing than the mechanism warrants, and it carries whatever passed through it on the way: a discarded hypothesis, a quotation from a supplied document, an intermediate figure the final answer was written to omit. Where the working is wanted for review it is better logged than displayed — the same evidence, kept where it can be examined, without being served to a reader as an account of a decision that was not made that way.
How the Registry classifies a step-by-step reasoning task
Producing the intermediate steps of a multi-step arithmetic task before stating the final answer is filed as data processing in this registry's classification: quantities are derived from supplied inputs, and the derivation is what the task consists of.
The Registry's canonical brief for this entry is filed as:
Produce the intermediate reasoning steps for a multi-step arithmetic task before stating the final answer.
Submitted for assessment it is
classified as Data processing, and its wording is hashed once — to
b397b657625144d9…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/analysis.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about chain-of-thought prompting
How much the technique changes any particular result is a measurement, and this registry publishes none, having taken none. It computes a verdict from the wording of a submitted task; it does not run the task and compare.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about chain-of-thought prompting
- What is chain-of-thought prompting?
- Chain-of-thought prompting asks for intermediate reasoning steps to be produced before the final answer. The steps enter the context the answer is generated from, which is the mechanism by which they affect it.
- What is zero-shot chain of thought?
- Zero-shot chain of thought elicits the steps with an instruction alone — asking that the working be shown — rather than by supplying examples that contain worked reasoning. Few-shot chain of thought does the latter, demonstrating both the steps and the format they should take.
- Does chain of thought make answers more accurate?
- It is used on tasks that have intermediate steps to get wrong, and its effect on any specific task is a measurement rather than a property of the technique. This registry publishes no figure for it, having measured none.
- Are the reasoning steps a reliable explanation of the answer?
- No. The steps are generated text produced alongside the answer, not a transcript of a separate procedure. They can be internally consistent and still not support the conclusion beneath them, which is why verification is applied to the answer rather than to the working.
- What is self-consistency?
- Self-consistency answers the same question several times independently, with sampling rather than greedy decoding, and keeps the final answer that appears most often across those runs. It applies where the answer is short enough to be compared across runs, and its cost is simply the number of samples: the question is answered repeatedly before one result is retained.
Related entries
Order an assessment for data processing tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.