What is a thinking-budget policy, and why does it matter for CCA-F (D4)?

For a while the only knob was which model you picked. Now reasoning effort is configurable too: the model can run a fast, shallow pass or spend a larger, slower thinking budget before it answers (first-hand: Claude exposes configurable reasoning effort, including an extended-thinking mode for harder tasks).

That turns "pick a model" into "pick a model and a thinking budget." And the moment effort is a dial, leaving it on one setting becomes a decision with a cost:

• Default too low and hard, multi-step tasks get confident, shallow answers.
• Default too high and trivial tasks pay flagship-level time and tokens for nothing.

The fix is not a better default. It is a policy: decide, per class of task, how much reasoning is worth it.

A policy is two decisions, made per class of task.

• Budget (how much to think). Match the task's accuracy bar to the smallest reasoning budget that clears it. Do not reach for the deepest mode by default.
• Escalation (when to think harder). Let the low budget handle the common case and raise the budget only for the hard or high-stakes items.

Worked example - "ship a feature with an AI coding agent."

1. Scaffolding and boilerplate on a low budget: file moves, imports, routine CRUD do not need deep reasoning.
2. The hard core on a deep budget: the concurrency logic, the migration, the security-sensitive path get extended thinking.
3. Review and tests back on a low budget: running and formatting is mechanical once the design is settled.
4. Spend depth where a mistake is expensive, not uniformly across the whole job.

That is a thinking-budget policy: cheap thinking by default, deep thinking on the step that can break.

The Thinking-Budget Policy - a written rule that maps task classes to reasoning depth, so simple work runs fast and cheap while accuracy-critical work gets the deep budget. You set it once, evaluate it, and revise it; you do not re-decide effort ad hoc on every prompt, and you do not leave one default running everywhere.

This sits in D4 - Prompt Engineering and Structured Output, which is 20% of the exam, and it leans on D1 - Agentic Architecture and Orchestration for the multi-step case.

The proprietary read: D4 questions reward right-sizing reasoning under cost and latency limits, the same discipline as model-tier routing, applied to the effort knob instead of the model.

• Old instinct: if it is wrong, think harder everywhere.
• D4 instinct: think harder on the step that is wrong, and keep the rest cheap.

The distractor pattern to memorize. On D4 scenarios about a slow or expensive workflow, the trap answer is "switch to the deepest reasoning mode for the whole task." The architecturally correct move is one of:

1. Match budget to task class (low for routine, deep for accuracy-critical), or
2. Escalate effort selectively (cheap pass first, deep budget only on the hard step), or
3. Reserve deep reasoning for the failure-prone step and evaluate that the cheaper budget holds elsewhere.

1. Write the policy down. List your task classes and the default budget each gets.
2. Start cheap. Begin every task at the smallest budget that could plausibly meet the bar.
3. Escalate on stakes, not on vibes. Raise the budget for steps where one error is expensive.
4. Separate the knobs. Decide model tier and thinking budget independently; pair them per task.
5. Evaluate downgrades. Prove a lower budget meets the bar on the real task before adopting it.
6. Review the bill. If every task runs deep, that uniform cost is the signal your policy is missing.

The meta-skill, and the D4 exam skill, is the same: accuracy per dollar comes from spending reasoning where it changes the answer, not from thinking harder everywhere.