Home/Blog/How to Use the Claude Extended Thinking Prompt to Pick Budgets That Fit Your Latency and Cost Limits
Blog

How to Use the Claude Extended Thinking Prompt to Pick Budgets That Fit Your Latency and Cost Limits

P
promptstudio

Plan how to turn on extended thinking in the Claude API for a real feature: choose a budget_tokens and max_tokens pair per task, keep thinking blocks intact across tool calls, know which parameters stop working, decide when to stream, and test cost and quality before rollout.

How to Use the Claude Extended Thinking Prompt to Pick Budgets That Fit Your Latency and Cost Limits

Extended thinking can make Claude noticeably better at hard, multi step tasks, but turning it on changes more than one setting. Budgets have to fit inside max_tokens, some request parameters stop working, tool loops need thinking blocks passed back intact, and billing counts tokens you may never see. The Claude Extended Thinking Budget Planner: budget_tokens vs max_tokens, Tool Use with Thinking Blocks Passed Back, Streaming Thresholds, Caching Effects, and a Cost Test Plan prompt plans the change for your actual feature before you ship it.

What the prompt produces

  1. A task by task decision on where thinking is worth enabling.
  2. A budget table with budget_tokens and max_tokens for each task and the reasoning.
  3. Parameter conflicts in your current request, such as temperature, forced tool choice, and prefill, with fixes.
  4. A tool loop plan for passing thinking blocks back unchanged.
  5. A streaming rule for large outputs and how the interface should show progress.
  6. A caching note on how budget changes interact with cached prefixes.
  7. A billing note on how thinking tokens are counted.
  8. A cost and quality test plan with metrics to log.

How to fill the inputs

FeatureAndTasks should list the distinct task types inside your feature. Most products have a mix of quick answers and hard reasoning tasks, and thinking is rarely worth it for all of them.

CurrentRequest describes your request shape today: system prompt size, input sizes, max_tokens, temperature, tools, and tool_choice. Several of these interact with thinking, so details matter.

ToolLoop explains whether the model calls tools in a loop and how you store conversation history. This is where many integrations break, because storage code often keeps only text blocks.

Limits sets your latency and cost targets, which the test plan uses to choose budgets.

CachingSetup tells the prompt where your cache breakpoints sit, so it can explain what a thinking budget change does to cache reuse.

Reading the example output

The example plans thinking for a property management assistant with three task types.

  • Short FAQ answers stay without thinking, since latency matters more than depth.
  • Lease clause review gets thinking with a larger budget and a higher max_tokens so the answer still fits.
  • Rent roll questions that call a SQL tool several times get thinking between tool calls.
  • The conflicts section catches a custom temperature and a forced tool_choice setting, and explains how to change each one.
  • The tool loop section finds a real bug: the app's storage drops non text blocks, which would break the loop once thinking is on.
  • The test plan compares three budgets per task on a fixed eval set and picks the smallest one that meets the quality and latency targets.

Version specific details, like minimum budgets and streaming thresholds, are marked for you to confirm in Anthropic's documentation, since they can change between model releases.

Tips for better results

  • Start with thinking off for simple tasks and turn it on only where tests show a gain.
  • Read usage.output_tokens from each response instead of counting visible text. Billing may include thinking you do not see in full.
  • Keep one fixed budget per task rather than tuning it on every request, so caching stays predictable.
  • Save the full content array of each assistant turn in tool loops, including thinking blocks and their signatures.

Mistakes to avoid

  • Do not edit, trim, or reorder thinking blocks during a tool loop.
  • Do not set budget_tokens higher than max_tokens unless you are using a mode that documents it.
  • Do not ship a thinking change without running the same eval set before and after.

Who it is for

Developers and platform engineers building on the Claude API, AI product teams tuning cost and quality, and anyone moving a feature from a plain model call to one that reasons first.

A practical rollout order

Pick one task that clearly needs deeper reasoning. Fix storage so thinking blocks survive tool loops, then remove conflicting parameters. Run the test plan with two or three budgets, choose the smallest one that meets your targets, and roll it out behind a flag. Watch output tokens and latency for a week before expanding thinking to other tasks.

Related PromptDig links

Open the Claude Extended Thinking Budget Planner: budget_tokens vs max_tokens, Tool Use with Thinking Blocks Passed Back, Streaming Thresholds, Caching Effects, and a Cost Test Plan prompt with your request details. For more AI tools prompts, Browse more prompts. If you have a tested setup for reasoning models, Share a prompt.

Share this article