Thinking is a budget you set

A lesson from Working With AI: Context, Tools, Agents and Evals. Play it above, or read it through below.

• Sampling parameters now return a 400, and effort is a different control

  The common read: Temperature is the first setting to change when output varies, so setting it to zero is the standard way to make a model behave.

  Current models no longer support the three sampling parameters. The reference marks temperature, top_p and top_k deprecated and states the failure mode for each: temperature takes 1.0 for backwards compatibility and rejects everything else with a 400, top_k rejects any value at all, top_p accepts 0.99 and above. There is no warning step: the same request that works on an older model id returns an error as soon as you change the id.

  No parameter replaces them: the migration guides say to remove them and use prompting instead. The request-level control current models do add is effort, and it sets how much work the model does, not how random the output is. The default is high on most models and medium on Claude Opus 5.5, and setting a model's default explicitly is identical to omitting it. effort affects all tokens in the response, including text, tool calls and thinking, so lower effort means fewer tool calls, not only shorter answers.

  A common failure: a deploy that changes only the model id causes a total outage, and the team blames the deploy instead of the parameters the new model rejects. Read the parameter list before you read the prompt. Temperature has no successor setting, and even temperature: 0 never guaranteed identical outputs. The boilerplate you have copied since 2024 now breaks the request, and in production the first sign is usually a 400.

• Thinking is a mode, not a phrase

  The common read: Adding think step by step is how you get reasoning out of a model, so it belongs at the end of every hard prompt.

  Before reading on, say whether thinking is on by default on the model you use most. As of 2026-09-24, thinking is on by default on Opus 5.5, Opus 5, Sonnet 5 and every Fable and Mythos model; it is off until you set thinking: {type: "adaptive"} on Opus 4.8, 4.7, 4.6 and Sonnet 4.6; and it cannot be turned off on Opus 5.5 or any Fable or Mythos model. Opus 5 accepts thinking: {type: "disabled"} at high or below, and returns a 400 at xhigh or max.

  Manual chain of thought is now the fallback rather than the technique. The reference keeps it for the case where thinking is off, recommends structured tags to separate reasoning from the answer, and then gives a stronger instruction about prompted reasoning: prefer general instructions over prescriptive steps, because "think thoroughly" often produces better reasoning than a hand-written step-by-step plan and the model's reasoning frequently exceeds what a human would prescribe.

  On every current model, the phrase you have appended for two years does not switch thinking on or off. The model's default and the thinking parameter decide that. Where thinking is adaptive, prompt text still changes how often and how deeply the model thinks, and the documentation's examples use general wording such as "Think carefully before responding", not a step-by-step plan.

  The word "think" can itself cause a problem. With thinking disabled, Opus 4.5 is documented as particularly sensitive to "think" and its variants, and the suggested workaround is to say consider, evaluate or reason through instead. A common failure on Opus 4.5 with thinking disabled: an edit that only rewords the prompt adds the word "think", and the model's behaviour changes. Set the thinking parameter first, then write the prompt.

  Asking for the reasoning in the reply now carries a risk. On Claude Opus 5.5, Fable 5.1 and Fable 5, a prompt that pushes the model to write its reasoning into the response text can be declined, with stop_reason: "refusal" and the category reasoning_extraction. The documented route is to remove that instruction and read the summarized thinking block (display: "summarized") instead.

• You are billed for what you cannot read

  The common read: Thinking tokens are internal, so they are a per-request implementation detail and not a line on my bill.

  Thinking is output, and on current models it is output you cannot see. The tokens the model spends reasoning are billed as output tokens even when the thinking text is not returned, and they count toward max_tokens alongside the response. On Opus 5.5, Opus 5, Sonnet 5, Opus 4.8, Opus 4.7 and every Fable and Mythos model, display defaults to "omitted", which returns the thinking block with an empty field and a signature. The documentation states that omitting the thinking text reduces latency, not cost.

  Thinking is also billed a second time, as input. On Opus 4.5 and later, Sonnet 4.6 and later, and every Fable and Mythos model, prior turns' thinking blocks are KEPT in context rather than stripped, so they join the next request's input and are billed as input like the rest of the history. Earlier Opus and Sonnet models and every Haiku through 4.5 keep only the last turn's thinking blocks.

  A common failure: an agent's cost grows with no change in traffic, after a model upgrade and in long sessions, and the team blames a pricing change. Measure thinking tokens before you tune the prompt. output_tokens_details.thinking_tokens reports what was spent reasoning. When prompt caching is on (lesson 4), usage.input_tokens counts only the uncached part of the input, so a dashboard that reads usage.input_tokens alone under-reports what you sent.

• A prompt line is tuned to a model, not to a task

  The common read: Asking the model to verify its answer before finishing improves correctness at no cost, so it belongs at the end of every serious prompt.

  The same prompt sentence can improve results on one model and add cost on the next. The reference recommends appending a verification instruction and says it catches errors reliably for coding and maths, then names Opus 5 as the exception, because it verifies its own work without being asked and because inherited verification instructions cause over-verification, adding tokens and latency. The migration instruction is to delete the line, not rewrite it.

  The pattern matters more than this one line. Three documented instructions have now inverted across a generation boundary: emphasis that fixed undertriggering now overtriggers, the phrase that invoked reasoning no longer switches it on and can be a trigger token, and the verification line that improved correctness now adds latency. None of them was wrong when it was written, and none of them produced an error when it stopped helping.

  A common failure that nobody reports: a prompt file still contains all three lines, nobody has measured them, and the model behaviour each line corrected has changed. Nobody removes a line that is not visibly failing. On every migration, check each line against the new model's prompting guide, apply the fix the guide names, then measure. A prompt is a set of corrections to one model's behaviour, and each correction stays in the file after the model stops needing it.

• A reasoning trace is an output, not a proof

  The common read: The reasoning trace shows me how the model reached the answer, so a trace I agree with is evidence the answer is right.

  Before reading on, decide what a thinking block is evidence of. On current models, the text in a thinking block is never the raw reasoning. It is a summary, written by a different model from the one you targeted, and the thinking model never sees that summary. The research term for whether a model's reasoning matches the computation that produced the answer is faithfulness, and faithfulness is not guaranteed even for the raw reasoning. A thinking block shows what a summary says, not how the answer was computed.

  Higher effort does not make the trace faithful either, and the documentation is cautious about its top settings. For Opus 4.7 it reserves max for frontier problems, with significant cost for relatively small quality gains on most workloads and overthinking on some structured-output tasks; for Opus 5.5 it says to reserve xhigh and max for work with a measured quality gain. The API offers max, and for these two models the documentation reserves it rather than recommending it.

  A common failure: a reviewer reads a plausible trace, agrees with each step, and ships an answer that is wrong at a step the trace never mentioned. Judge the output, not the trace. The trace is useful for debugging your prompt and for seeing which approaches the model tried; it is not a proof, it was not produced by an auditable process, and on a summarised display it was not even written by the model you asked.

• Nightshift's classifier does not need thinking

  The common read: Reasoning makes every task better, so the default for anything I care about is to raise it.

  When adaptive thinking triggers more often than you want, the documentation suggests this system-prompt line: "Thinking adds latency and should only be used when it will meaningfully improve answer quality, typically for problems that require multistep reasoning. When in doubt, respond directly." Nightshift's classifier fails that test: it reads one filename and one size and returns one of four labels, with no multistep reasoning, and a wrong label only lists a file in the wrong section of a text file.

  You can make this decision without measuring anything: ask what a wrong answer costs. If a wrong answer is cheap to fix, use low effort, because thinking only adds latency to every nightly run. If a wrong answer is expensive or hard to detect, spend the reasoning tokens. Nightshift has exactly one step of the second kind, and lesson 11 gives that step the reasoning budget the classifier does not get.

  This rule prevents a failure nobody reports: a nightly job that runs for eleven minutes instead of forty seconds, on a machine nobody is watching, for a decision that a regular expression could have made. Match the reasoning spend to the cost of a wrong answer. Every parameter in this lesson is a way to set that spend.