# Mistral Small 4 reasoning_effort: none vs high

Use Mistral Small 4 reasoning_effort none and high as separate operating conditions, checking final answers, sampling settings and completion.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/mistral-small4-reasoning-none-high/
Language: en

Mistral Small 4 combines instruction and reasoning behavior in one release. Its documented reasoning_effort values none and high let an application evaluate whether a task needs additional reasoning without switching to another named checkpoint.

## Read the two documented modes

The [model card](https://huggingface.co/mistralai/Mistral-Small-4-119B-2603/raw/main/README.md) describes none as a non-reasoning condition and high as the reasoning condition. It recommends a temperature of 0.7 for high and a task-dependent value from 0.0 to 0.7 for none.

The [release article](https://mistral.ai/news/mistral-small-4/) explains the unified model design. These descriptions do not establish support for every intermediate effort spelling from another API. Use the values documented for the selected implementation and preserve the actual settings in a comparison.

## Separate a simple instruction from a constraint problem

For the first task, rewrite a fictional maintenance notice while preserving its fixed facts. For the second, select a maintenance window that satisfies all declared exclusions and ordering rules.

A concise accurate rewrite can pass without a long explanation. A planning answer must satisfy every constraint regardless of how much reasoning it contains. The same acceptance rule should apply to both effort conditions for a given task.

## Preserve input and output distinctions

| Element | What to keep explicit |
| --- | --- |
| User requirement | Same text and fixed facts |
| Effort | none or high as actually forwarded |
| Sampling | Document the chosen value and its rationale |
| Overall allowance | Enough space for the required final result |
| Acceptance | Correct final answer and required format |

The [Mistral preprocessing library](https://github.com/mistralai/mistral-common) is the first-party reference for model input preparation. A request option that never reaches valid model-specific preprocessing cannot explain a meaningful effort comparison.

## Diagnose unexpected responses

If both conditions return identical short results on a trivial task, that does not prove the control is ineffective. The task may not require extra reasoning. If high produces reasoning but no final answer, inspect output exhaustion before judging its completed-answer correctness.

If none gives an invalid interval, record the violated condition. If high provides a valid one only under a larger allowance, keep that different operating point visible. Avoid presenting additional generation work as an improvement without its associated completion conditions.

## Choose effort by verified task need

Keep the exact checkpoint revision, rendered input, effective controls, raw output and reference checks. Report completed accepted answers, incomplete responses and formatting failures separately.

Use the condition that meets the actual requirement under the allowed response process. The result can justify none for one class of tasks and high for another, or show no meaningful difference on a bounded set. It does not establish universal latency savings, a permanent quality ranking or the need to activate reasoning for every user message.

## Related reading

- [Output limits and reasoning tokens: the length-termination contract](/journal/provider-output-limit-reasoning-contract/)
- [Why generation_config.json changes vLLM generation defaults](/journal/vllm-generation-config-precedence/)