Thinking is a budget you set

A lesson from Working With AI. Play it above, or read it through below.

• The knob moved, and the old one is an error

  The common read: Temperature is the first thing to reach for when output varies, so pinning it to zero is the standard way to make a model behave.

  All three sampling parameters are gone on current models. 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 migration period in the request; the code that worked last quarter returns an error this quarter.

  What replaced it is effort, and it is a different kind of control. The docs describe it as trading response thoroughness against token efficiency with a single model, say the default is high, and say setting high explicitly is identical to omitting it. The important half is the scope: it affects all tokens in the response, text, tool calls and thinking, so lower effort means fewer tool calls, not merely shorter answers. It is an agentic-behaviour dial wearing a reasoning-dial name.

  That arrives as a total outage on a deploy that changed one string, filed against the deploy, by a team whose diff was a model id. Read the parameter list before you read the prompt. The output you were tuning with temperature is now tuned with effort, the boilerplate you have been copying since 2024 is now the thing breaking the request, and neither fact announces itself anywhere except in 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.

  Name whether thinking is on by default on the model you use most, then read on. Most people cannot, and the answer, read 2026-08-27, is a generation split rather than a fact about models.

  Thinking is already on with no configuration on Claude Opus 5, Sonnet 5, Fable 5, Mythos 5 and Mythos Preview; it is off until you set thinking: {type: "adaptive"} on Opus 4.8, 4.7, 4.6 and Sonnet 4.6; and on Fable 5, Mythos 5 and Mythos Preview it cannot be turned off at all.

  Claude Opus 5 carries a second no-disable rule scoped to effort rather than to a model: it accepts thinking: {type: "disabled"} at high or below, and combining it with xhigh or max returns a 400.

  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 says something sharper about the prompted kind: 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.

  There is a trap in the word itself. 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. That arrives as a latency regression on a prompt whose only change was a politeness edit. Set the mode, then write the prompt. The phrase you have been appending for two years is either redundant or a trigger, and on no current model is it the control.

• 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, Sonnet 5, Fable 5, Opus 4.8 and Opus 4.7, display defaults to "omitted", which returns the thinking block with an empty field and a signature. The documentation's own line is that omitting reduces latency, not cost.

  The second billing surprises people who already knew the first. On Opus 4.5 and later, Sonnet 4.6 and later, Fable 5 and Mythos 5, 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. Loop's bill did. Loop now knows more about billing than about reasoning, which is its own kind of thinking.

  That arrives as a cost line that grew without a traffic change, filed against a pricing change, on an agent whose only difference is a model upgrade and a session that runs long. Meter the thinking before you tune the prompt. output_tokens_details.thinking_tokens reports what was spent reasoning, usage.input_tokens counts only what follows the last cache breakpoint, and a dashboard reading the second one alone will report a fraction of 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 is a free correctness win, so it belongs at the end of every serious prompt.

  The same sentence is a win on one model and a 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, on the ground that it verifies its own work without being asked and that inherited verification instructions cause over-verification, adding tokens and latency. The instruction to migrate is delete, not rewrite.

  That pattern is the lesson rather than the particular line. Three documented instructions have now inverted across a generation boundary: emphasis that fixed undertriggering now overtriggers, the phrase that invoked reasoning is now redundant or a trigger token, and the verification line that bought correctness now buys latency. None of them was wrong when it was written and none of them announced its own expiry.

  The version of this that never gets filed is a prompt file where all three are still present, still believed, and never measured, because the thing they were fixing stopped happening years ago and nobody removes a line that is not visibly failing. Delete on migration, then measure. A prompt is a set of corrections to a specific model's behaviour, and every correction outlives the behaviour it corrected.

• A reasoning trace is an output, not a receipt

  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.

  Predict what a thinking block is evidence of, then read on. Its own generation. A trace is text the model produced, subject to the same process as the answer, and the research term for whether it corresponds to the computation that actually produced the answer is faithfulness. It is not assumed. Anthropic's own handling makes the gap concrete: when thinking is summarised, the summary is produced by a DIFFERENT model from the one you targeted, and the thinking model never sees the summary.

  Spending more does not close the gap either, and the documentation says so about its own top setting. The highest effort level is described as reserved for genuinely frontier problems, adding significant cost for relatively small quality gains on most workloads, and leading to overthinking on some structured-output tasks. A dial that goes to max and a doc that tells you not to use it is an unusual combination and it is the honest one.

  That arrives as a review where a human 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, never the narration. The trace is useful for debugging your prompt and for spotting where the model went looking; 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 does not need to think

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

  The documentation's own guidance is to spend nothing where nothing is needed: thinking adds latency and should only be used where it will meaningfully improve answer quality, typically for problems requiring multistep reasoning, and when in doubt, respond directly. Nightshift's classifier reads one filename and one size and returns one of four labels. There is no multistep reasoning in it, there is no second-order consequence to weigh, and the cost of a wrong label is that a file lands in the wrong section of a text file.

  The decision has a shape you can apply without measuring anything. Ask what happens when the answer is wrong. Where being wrong is cheap and recoverable, low effort is correct and thinking is a tax on latency you pay every night. Where being wrong is expensive or invisible, the same tokens are the cheapest insurance in the system. Nightshift has exactly one step of the second kind, and lesson 11 is where it gets the budget the classifier does not.

  What this actually prevents is the failure nobody files: a nightly job that runs for eleven minutes instead of forty seconds, on a machine that is asleep, for a decision that a regular expression could have made. Match the spend to the cost of being wrong. That sentence is the whole of this level's practical content, and every parameter in this lesson is a way of acting on it.