Chain-of-Thought Prompting for Business Tasks

Chain-of-thought (CoT) prompting is the technique of asking a model to reason step by step before giving its answer. The classic version — appending "think step by step" or asking for analysis inside a <thinking> tag before a <answer> tag — still works. But on the current Claude generation, deliberate reasoning is a first-class API feature called thinking, and understanding how the two interact is what makes CoT useful in a business system rather than a demo trick.

Why reasoning-first output matters for business tasks

For a vendor-contract comparison, a pricing anomaly investigation, or a "should we escalate this claim?" call, the answer alone is unauditable. Reasoning that precedes the answer does three practical things: it surfaces assumptions ("assuming the Q3 figures are in USD…") that a reviewer can veto; it catches errors early, because working through intermediate steps gives wrong turns a chance to self-correct before the conclusion; and it creates a review artifact — a paragraph a human approver can skim to decide whether to trust the output. If nobody will ever read the reasoning and the task is simple, CoT just adds latency and output tokens; reserve it for decisions with consequences.

Built-in thinking: what the current models do

Current Claude models support adaptive thinking, enabled with thinking: {"type": "adaptive"} in the Messages API — available on all four third-party platforms. In adaptive mode, Claude itself decides whether and how much to deliberate per request. Depth is steered by the effort parameter (output_config: {"effort": ...}, levels from low to max, default high): at the default it almost always thinks; at lower effort it may skip thinking for simple queries. Older models instead use manual extended thinking with an explicit token budget ({"type": "enabled", "budget_tokens": N}) — check the documentation for your specific model, since newer models reject the manual form.

Two operational facts matter for planning:

Thinking is billed output. Thinking tokens count toward max_tokens, and usage.output_tokens_details.thinking_tokens reports what you paid for. If responses cut off with stop_reason: "max_tokens", raise the limit or lower effort.
You may not see what you pay for. The thinking.display option accepts "summarized" or "omitted"; on the newest models the default is "omitted" — thinking happens and is billed, but isn't returned. Omitting reduces latency, not cost.

Rule of thumb: use built-in thinking for quality — it makes the answer better. Use prompted, visible reasoning in the response text for auditability — structured analysis your reviewers actually read. Many production systems use both: adaptive thinking on, plus an instruction to present key assumptions and evidence before the recommendation.

Prompting the reasoning you want

The official docs confirm that thinking is promptable: phrases like "Please think hard before responding" encourage deliberation, and "Answer directly without deliberating" suppresses it, per-message or in the system prompt. For the visible layer, be specific about the shape of reasoning rather than just requesting "steps":

from anthropic import AnthropicFoundry

client = AnthropicFoundry(api_key="...", resource="my-resource")
resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    thinking={"type": "adaptive"},
    system=("Before any recommendation: (1) list the assumptions "
            "you are making, (2) cite the specific figures you used, "
            "(3) name the strongest argument against your conclusion. "
            "Then give the recommendation in <answer> tags."),
    messages=[{"role": "user", "content": analysis_request}],
)

One boundary to respect: the visible reasoning Claude writes is a presentation of its analysis, not a transcript of the internal thinking blocks — on the newest models, raw chain of thought is never returned, and attempts to extract it can be refused. Design your audit trail around the structured, visible layer you asked for.

Costs and alternatives

Reasoning tokens are output tokens — the most expensive kind. Two mitigations: set effort to match the stakes rather than defaulting everything to maximum, and route high-volume, non-urgent reasoning work through batch processing at 50% of standard prices. And remember the overview docs' caveat: not every quality problem is a prompting problem. If a task needs heavy reasoning scaffolding on a small model, a more capable model at low effort may be cheaper and better.

Where to go next

See thinking budgets for the API mechanics, self-critique patterns for a complementary review technique, and the feature matrix for platform support.

Sources

← All articles