Configuring a run
Reasoning effort
How long the model is allowed to think before it commits to an answer.
Next to the model picker on the composer sits a control labelled Reasoning. It sets how much thinking the model is allowed to do before it commits to an answer. The model stays the same; what changes is how long it is given to work the problem out.
The three levels
| Level | What it is for |
|---|---|
| Low | Fastest and cheapest. Good for a small module you could almost write yourself, a rename, or a change you have already described precisely. |
| Medium | The default, and the right answer most of the time. Enough thinking for a real module without paying for deliberation the problem does not need. |
| High | Most thorough. Worth it for a design with a lot of interacting conditions, an unfamiliar protocol, or anything where the first plausible answer is likely to be subtly wrong. |
What it actually changes
Higher effort means more internal reasoning before the model acts, and more willingness to check its own work as it goes. In practice you will notice three things: the run takes longer, it costs more, and on a hard problem it is more likely to be right the first time.
- It is not a quality dial for easy work. On a straightforward counter, High produces the same module as Low and charges you more for it.
- It does not replace a good spec. More thinking about an ambiguous request produces a more confident version of the wrong module; see Writing a good spec.
- It stacks with the tools rather than replacing them. Reasoning cannot tell you whether your design simulates; only Auto-Verify can do that.
When the control is greyed out
Not every model supports this. When you pick one that does not, the control is shown disabled with a note saying so, rather than silently accepting a setting nothing will honour. Switching back to a model that supports it makes the control live again with your previous choice intact.
Note
Reasoning is separate from the effort setting on an optimization run. That one controls how many transformations the run may explore and how much it may spend, which is a different question from how hard the model thinks about each step. They are named differently on purpose.
Picking one
| You are... | Try |
|---|---|
| Sketching an interface or a small block | Low |
| Writing something you intend to keep | Medium |
| Implementing a protocol from a standard | High |
| Iterating on a module that is nearly right | Low or Medium |
| Working through a design nobody on the team fully understands | High |
Tip
The pragmatic order is: get the spec right, then turn on Auto-Verify, and only then reach for High. Effort is the smallest of those three levers and the easiest one to reach for first.
Where it is set
The control sits on the composer next to the model, so it is a per-run choice; the value you pick applies to the run you are about to start. It is stored with the run, which is what lets a retry reproduce the same conditions rather than quietly changing them.