A financial analytics application submits complex multi-step calculations to Claude. Occasionally, responses are cut off mid-calculation due to reaching max_tokens. The team sets max_tokens to 4,096 to prevent truncation, but this creates over-provisioning cost for short responses. What is the correct approach?

Dynamic max_tokens sizing with a truncation-detection retry is the correct engineering pattern. Pre-classifying requests by expected output length allows appropriate provisioning: short calculations can get 512 tokens, while complex multi-step calculations can get 4,096. Checking stop_reason == max_tokens after each response provides a reliable truncation signal that triggers a retry with a higher limit, while end_turn indicates normal completion. This approach optimizes cost by not over-provisioning short requests while ensuring long calculations complete. The absolute-maximum-ceiling approach is wrong because, while Anthropic bills for generated tokens rather than the max_tokens ceiling, a high ceiling can cause issues with certain response patterns, and the principle of appropriate resource provisioning applies even when costs are output-proportional; more importantly, it does not address the structural problem. The prompt-instruction approach is wrong because telling Claude to 'limit to 500 tokens' for complex multi-step calculations would produce incomplete results rather than concise ones; the content genuinely requires more tokens, and truncating it causes incorrect outputs. The streaming-cancel approach is wrong because detecting completion by parsing streaming output for a final result pattern is brittle for mathematical calculations, partial results can appear to be complete, and stream cancellation adds operational complexity without the reliability of the retry-on-truncation approach.