Extended Thinking and Prompt Caching

Extended Thinking

Turning on a thinking budget lets Claude produce internal reasoning before its final answer, improving performance on hard, multi-step tasks. The catch: thinking tokens are billed as output tokens. Extended Thinking is a capability-vs-cost lever, not a free quality upgrade -- apply it to steps whose reasoning depth genuinely pays for the added tokens and latency, not uniformly across a pipeline.

The Signature Carry-Back Rule

Extended Thinking imposes one non-negotiable structural requirement on multi-turn, tool-using conversations: every thinking block the API returns must be passed back on the next request byte-for-byte unchanged. Each thinking block carries an opaque signature field that the API uses to confirm the reasoning it's receiving back is exactly what it produced -- not edited, not summarized, not reconstructed from a paraphrase. Modify the block in any way and the signature no longer matches; the API rejects the request rather than silently accepting tampered reasoning.

This applies identically to redacted (encrypted) thinking blocks. Their contents are ciphertext -- unreadable, not meant to be inspected by your code or a human -- but that does not exempt them from the rule. They still have to be returned in the same position, completely untouched, on the next turn. There is no version of "it's just encrypted noise, so trimming it is harmless" -- the signature check runs regardless of whether the payload is legible.

The most common way this rule gets violated in practice: a developer worried about context-window growth strips thinking blocks out of history before resending it, intending to save tokens. That optimization breaks the very next request. If context budget from accumulated reasoning is the actual concern, the fix is the context-engineering toolkit (pruning, compaction, subagent handoffs) applied to the conversation as a whole -- not ad hoc surgery on an individual thinking block, which is a hard failure rather than a savings.

Prompt Caching

Mark a stable prefix -- a system prompt, long reference documents, tool definitions -- with cache_control so it is cached server-side. Subsequent requests that reuse that identical prefix:

• Pay a large discount on the cached tokens
• Start faster, since the cached portion doesn't need to be reprocessed from scratch

Cache writes cost a bit more than normal input tokens (a one-time premium the first time a prefix is cached); cache reads are much cheaper. The economics favor caching precisely when many requests share a long, unchanging prefix -- the repeated cheap reads outweigh the one-time write premium.

Common exam traps

• Treating Extended Thinking as strictly beneficial -- it costs billed output tokens and latency, so it should be reserved for genuinely hard reasoning steps.
• Stripping or summarizing a thinking block to save context before the next tool-use turn -- this breaks the signature and the very next request fails.
• Assuming a redacted/encrypted thinking block is exempt from the carry-back rule because its content can't be read -- it still must be replayed unchanged.
• Assuming caching helps when every request is different -- caching only pays off with a long, unchanging, *shared* prefix across many requests.
• Truncating a needed document to save tokens instead of caching it, trading away correctness for a savings that caching would have delivered without any information loss.