A finance service handles two request classes through one code path: simple balance lookups, which make up most of the traffic, and multi-step contract reconciliations. Extended thinking is switched on for every request. A review of live traffic shows the lookups meet the agreed quality bar with extended thinking switched off, while the reconciliations fall below it without it. Spend per request is above the team's stated ceiling. Which change fits the stated constraints?
- AEnable extended thinking only for the reconciliation class, which the measurement shows needs it, and run the balance lookups without it. Correct
- BSwitch extended thinking off for the whole service and accept the lower reconciliation quality, since the stated cost ceiling applies to every request the service handles.
- CKeep extended thinking on everywhere and reduce the value of max_tokens so that each reply is shorter, bringing the measured spend per request under the stated ceiling.
- DKeep extended thinking on everywhere and negotiate a higher cost ceiling with finance, on the basis that reasoning depth is a fixed property of the service rather than a per-request choice.
Why A is correct: Correct: extended thinking buys reasoning depth at an extra cost per request, so it belongs on the class measured to need it and off the class measured to clear the bar without it.
Why B is wrong: Tempting because it certainly meets the ceiling, but it knowingly drops the reconciliations below an agreed quality bar when the measurement shows only that class needs the extra reasoning.
Why C is wrong: Tempting because it looks like a direct cost lever, but it caps the reply rather than the reasoning effort, so the lookups keep paying for thinking they do not need and long answers are cut short.
Why D is wrong: Tempting because it protects quality, but the stated ceiling is the constraint to design against, and the measurement already shows the depth is not needed on the majority class.