Thinking is a setting now

Visual Studio 18.9 went out on 11 August with a small control tucked into the model picker. You choose how hard the model thinks: Low, Medium, High, and on some models Extra High and Max. The idea is that you keep a model on Low for the dozens of small asks that fill a normal session, then bump it to High for the one hard problem (Microsoft, 2026). Higher levels burn more credits. Not every model exposes the control at all.

It looks like a preference toggle. It is not. It is the first time most working developers will meet reasoning depth as a metered, per-request decision, and it quietly changes how you are supposed to specify an AI feature.

The axis nobody was budgeting for

Until now the choice was one-dimensional. You picked a model, and the model was the cost and the capability, bundled. Cheap and quick, or expensive and clever. Everything downstream of that decision inherited it.

Effort levels split the bundle in two. The same model can now be a cheap tool or an expensive one depending on a flag you set at call time. That is a second axis, and it is the one that actually maps to the work: most tasks in a real system are not hard, and a handful are very hard indeed.

"

The interesting question stopped being which model. It is now how much thinking this particular task is worth.

Where this bites in a client system

We build AI into operational software: a system that reads a receipt, classifies a maintenance report, drafts a reply, checks a form against a rule set. In almost all of those, the request volume is lopsided. Thousands of trivial calls, a few dozen genuinely difficult ones a week.

If every one of those calls runs at the same reasoning depth, one of two things is true. Either you set it low and the hard cases fail quietly, which is worse than failing loudly. Or you set it high and you pay premium rates on the ninety-odd percent of traffic that needed nothing of the sort. We have watched a pilot look fine in a demo and then not survive contact with its own unit economics, and this is usually why.

• 01Classify your task types before you pick a level. Extraction, routing, and summarising rarely need deep reasoning. Anything involving a judgement call, a conflict between rules, or an ambiguous document usually does.
• 02Set the default low and escalate deliberately. Escalation should be a code path with a condition, not a person changing a dropdown.
• 03Make the escalation trigger observable. Low confidence, a validation failure, a disputed field, a retry. If you cannot name the trigger, you have not designed the feature yet.
• 04Log the level with every call. When the bill or the quality moves, you want to know which of the two axes moved with it.
• 05Test at the level you will ship at. A feature validated on Max and deployed on Low is untested, and the failure will not look like a crash.

The honest caveat

Effort is not a quality knob you turn up until the output is right. More reasoning on a badly specified task produces a longer, more confident version of the same wrong answer. If the prompt does not say what good looks like, no amount of thinking will infer it. Depth helps where the problem is genuinely hard, and it wastes money everywhere else.

The other caveat is portability. The control is not uniform across models, and the names of the levels are not a standard. Anything you build around it should treat the level as a configuration value with a sane fallback, not as an assumption baked into the call site. That is ordinary defensive work, and it is the sort of thing that gets skipped in a rush and then costs a fortnight later.

What we would do about it now

Nothing dramatic. If you have an AI feature live or in build, add one column to whatever document defines it: the reasoning level per task type, and the condition that escalates it. It takes an afternoon. It turns a running cost that nobody can explain into a line you can defend, and it forces the conversation about which parts of the system are actually difficult, which is a conversation worth having regardless.

The pattern underneath is familiar. Every mature piece of infrastructure eventually grows a dial that lets you trade cost against certainty, and every one of them is misused for a while first. Timeouts, cache lifetimes, replication factors, retry budgets. Reasoning effort has just joined the list. Treat it the same way: set it on purpose, write down why, and measure what happens.