> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inquantum.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Prompt reasoning models

> Write effective tasks for reasoning models and control thinking effort through Planck request parameters.

Reasoning models are most useful when a task benefits from planning, comparison, constraint satisfaction, or several dependent decisions. Prompt them with a clear problem and evaluation criteria; control the amount of reasoning with request parameters rather than repeatedly asking the model to “think harder.”

## Separate the task from the effort

The prompt describes the work:

```text theme={null}
Compare the two migration plans.

Evaluate them on downtime risk, rollback complexity, engineering effort, and cost.
Identify any missing assumptions, recommend one plan, and explain the decisive tradeoff.
```

The request controls reasoning behavior:

```json theme={null}
{
  "reasoning_effort": "high",
  "include_reasoning": true
}
```

For Anthropic-compatible requests, the equivalent fields are:

```json theme={null}
{
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "high" }
}
```

See [Reasoning and thinking](/gateway/reasoning) for complete requests and model-specific values.

## Choose an appropriate effort

| Task                                                          | Starting point                                                                           |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Rewrite, extraction, or simple classification                 | No reasoning or the provider default                                                     |
| Comparison with several constraints                           | `low` or `medium`                                                                        |
| Ambiguous planning, difficult coding, or multi-stage analysis | `medium` or `high`                                                                       |
| High-impact decision                                          | Higher effort plus independent validation; effort alone does not make the answer correct |

Accepted values depend on the selected model and provider endpoint. Inspect the model's Request Lab or `parameterContract` instead of hard-coding one global list.

## Prompt patterns that help

### Give decision criteria

Weak:

```text theme={null}
Which database should we use?
```

Better:

```text theme={null}
Recommend PostgreSQL or DynamoDB for this workload.
Compare transaction requirements, query patterns, expected write volume,
operational complexity, and a two-year cost horizon. State assumptions first.
```

### Define the deliverable

Ask for the artifact you need: a recommendation, patch, test plan, risk register, or concise explanation. If the answer feeds software, use Structured Outputs rather than relying only on formatting instructions.

### Provide complete source material

Reasoning cannot recover facts that are missing from the request. Include the relevant code, constraints, data, and definitions, and tell the model how to handle unknown information.

### Ask for verification, not hidden chain of thought

Ask for checkable evidence such as assumptions, calculations, citations, test cases, or a concise rationale. Do not make your application depend on receiving private internal reasoning; models and providers can return different reasoning representations.

## What to avoid

* Long process scripts that prescribe every thought before the model sees the problem.
* Conflicting instructions such as “be exhaustive” and “answer in ten words.”
* Assuming few-shot examples always help or always hurt reasoning models; test them on your task.
* Using maximum effort for every request, which can add latency and cost without helping simple work.
* Treating reasoning output as proof. Validate code, calculations, and high-impact recommendations independently.

## Qwen3.8 27B example

The Groq endpoint for Qwen3.8 27B supports `none`, `default`, `low`, `medium`, and `high`:

```bash theme={null}
curl https://api.inquantum.ai/v1/chat/completions \
  -H "Authorization: Bearer $PLANCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "groq/qwen/qwen3.8-27b",
    "reasoning_effort": "high",
    "include_reasoning": true,
    "messages": [{
      "role": "user",
      "content": "Review this rollout plan for failure modes. Rank the risks by impact and propose mitigations."
    }]
  }'
```

Start with the lowest effort that meets your quality target, then evaluate harder examples before increasing it globally.
