What is a reasoning model?
In Chapter 9 you saw the collapsible reasoning block that can appear before an AI answer. This chapter explains why some models use extra computation before answering, how that affects usage and latency, and when it is worthwhile. You will learn when to use a reasoning model for a difficult comparison and when a general model is enough for a simple tool call. OpenRouter remains the first route; direct providers are optional later additions.
Why distinguish reasoning from direct answers?
Chapter 9 showed what a reasoning block looks like and how to expand it. The distinction matters for two practical reasons: usage and latency.
- Usage: Some providers bill reasoning as output or expose it as a separate usage category. Exact accounting depends on the model and route, so inspect live pricing and actual usage.
- Latency: A reasoning model may take longer before producing a final answer. There is no universal delay or service guarantee.
Reasoning can help with difficult tasks, but it does not guarantee a correct answer. The goal is to decide which problems justify additional cost and latency and which are better handled by a lower-cost model. You can apply that choice with the model selector in Chapter 13.
How reasoning models differ from other models
Think about the difference between recalling a fact and solving a multistep problem.
- General model: Produces a direct answer. It is often a good fit for a short lookup, simple rewrite, or one tool call.
- Reasoning model: Allocates additional computation to planning or checking before the final answer. It can help with a complex automation involving several rooms, devices, time periods, and constraints.
What Chapter 9 showed may be provider-exposed reasoning, a summary, or usage information. A visible block is not necessarily the model's private chain of thought, and a longer trace does not prove greater accuracy.
Which models reason?
Capabilities change frequently. Use this table as a category guide, then verify the exact current model ID and route before saving it. Model catalogs and prices change frequently. Do not infer a current model ID from an older family name such as deepseek-reasoner or assume that an Anthropic release still uses budget_tokens. Verify behavior and pricing in the current provider documentation:
| Model or category | Provider or route | Reasoning? | Visible information |
|---|---|---|---|
| A GLM reasoning model | Optional Z.ai direct route | When documented for that model | Use zai when the endpoint format requires it |
| A lower-cost GLM chat model | Optional Z.ai direct route | Check the exact model | May have no reasoning block |
| deepseek-reasoner | DeepSeek | Yes | Reasoning in reasoning_content |
| deepseek-chat | DeepSeek | No separate reasoning route in the repository baseline | No separate reasoning block expected |
| A current Claude reasoning model | Anthropic | Model-dependent when documented; do not infer controls from a family name such as type:"enabled" or budget_tokens |
Native Messages API blocks or summaries; do not assume display: "omitted" behavior. Verify whether the current route documents summarized |
| A current Claude general model | Anthropic | Configuration-dependent; verify whether budget_tokens is supported by the exact model |
Check current documentation instead of assuming summarized output |
| An older or differently configured Claude route | Anthropic | Model-dependent; do not infer support for type:"enabled" plus budget_tokens from a marketing family name |
Retention and summary behavior are model- and route-specific |
| A current OpenAI reasoning model | OpenAI direct or OpenRouter | Yes when documented | Supported usage or a reasoning summary, not private chain of thought |
| A current OpenAI general model | OpenAI direct or OpenRouter | Model-dependent | Check the exact API model page |
| A hosted instruction model | Groq or OpenRouter | Do not assume; consult the host for the Instruct variant and reasoning behavior | Use the host's current catalog and route notes |
| A hosted Llama-family model | Groq or OpenRouter | Model-dependent | No separate block unless the route documents one |
| A current MiniMax model | Optional MiniMax direct route | Model-dependent | The add-on baseline uses deepseek for M-series reasoning |
Likewise, do not repeat unsupported future Claude version or
display: "omitted" claims. Verify whether the current provider documentation supports summarized.What thinkingFormat means in Pi Agent
Chapter 6 configured the first OpenRouter route. The Add Model dialog includes a field called thinkingFormat. Examples in older or route-specific instructions may show zai or deepseek or native, or a blank value. The field tells Pi Agent how a compatible route represents reasoning data; it does not make a model reason. Use openrouter for an OpenRouter reasoning route only when documented. The Pi AI type contract does not accept native or none as field values.
The four configurations shown here mean:
| thinkingFormat value | Use it for | Representation | Typical route |
|---|---|---|---|
zai |
A compatible GLM direct route | The endpoint may use <think>…</think>, reasoning_content or another documented field. Pi Agent uses zai for route-specific parsing; verify the exact endpoint rather than guessing |
Optional later GLM provider |
deepseek |
DeepSeek-style OpenAI-compatible reasoning | The API can place reasoning in message.reasoning_content, separately from message.content |
deepseek-reasoner and repository-tested MiniMax M-series handling |
native |
A description of Anthropic Messages API blocks, not a legal field value | Reasoning may be represented as a content block such as type: "thinking", parallel to type: "text". Do not assume future-version display: "omitted" behavior without current documentation |
Anthropic direct uses anthropic-messages with this field left blank |
| Blank | Anthropic direct or a route without a parser requirement | Native Messages API blocks, or no separate reasoning data | Anthropic direct and documented non-reasoning routes |
Use the format documented for the exact route. A mismatch can prevent reasoning data from rendering correctly:
| Mistake | Likely effect |
|---|---|
| A documented GLM direct parser requirement is left blank | Reasoning may appear inline, including a raw <think> tag, instead of rendering as a separate block. |
| deepseek-reasoner set to zai | The route-specific reasoning field is not represented by a <think> tag and may not be parsed correctly. |
| Anthropic direct set to zai or deepseek | The configuration does not match native Messages API handling and may cause confusing parsing behavior. |
| A non-reasoning model given an unrelated format | The setting adds no capability and may produce confusing parsing behavior. |
api: "anthropic" rather than openai-compatible. In the current UI, choose anthropic-messages and leave thinkingFormat blank; “native” describes the Messages API blocks, not a value for this field. See Chapter 11.How much extra does reasoning cost?
deepseek-reasoner; do not infer billing from an old tutorial name.Compare models using the same representative home-automation prompt:
Write a Home Assistant automation that starts at 10:00 p.m. and gradually dims the living-room light to 20%.
By 10:30 p.m., transition it fully to the night-light color temperature. Keep both changes smooth, explain the assumptions, and respond in English.
This task requires time logic and transition behavior. Keep the input and output requirements identical for each route, then record the results:
| Model or category | Reasoning? | Reasoning usage | Answer usage | Cost source |
|---|---|---|---|---|
| Lower-cost general model through OpenRouter | No separate reasoning when documented | Record the provider result | Record actual output tokens | Live OpenRouter model page |
| Direct general model | Model-dependent | Record the provider result | Record actual output tokens | Live direct-provider pricing |
| OpenRouter reasoning model | Yes when enabled and supported | Record reported reasoning usage | Record actual output tokens | Exact OpenRouter model page |
| deepseek-reasoner | Yes | Inspect current usage fields | Record actual output tokens | DeepSeek pricing page |
| Anthropic reasoning model | Model and request dependent | Inspect current usage fields | Record actual output tokens | Anthropic pricing page |
| Premium reasoning route | Yes when documented | Inspect current usage fields | Record actual output tokens | Exact route's live pricing |
The useful result is not a universal multiplier. Compare measured cost, latency, and answer quality for the same task.
max_tokens limit and expose a field such as usage.output_tokens_details.thinking_tokens ; another OpenAI-compatible route may report usage.completion_tokens_details.reasoning_tokens. Field names differ by provider and version, so inspect the actual API response and dashboard.When reasoning is worth the added effort
Choose by task difficulty and consequence:
| Task | Use reasoning? | Model choice |
|---|---|---|
| Look up a living-room entity ID or a storage-room sensor | Usually no | A current lower-cost OpenRouter model |
| Discuss today's weather or dinner | Usually no; more detail is not necessarily better | A current general model |
| Call one approved tool to set a temperature | Usually no; reliable tool use matters more | A model that reliably uses the approved tool |
| Debug an automation that fails at night | Often useful | A current reasoning-capable model |
| Compare HVAC options under several constraints | Useful, with professional verification | A current reasoning model |
| Plan schedules across several rooms, devices, routines, and tariff periods | Useful, with professional verification | A capable reasoning route whose cost you accept |
| Write a complex Jinja template that calculates energy use from three sensors | Often useful | A coding-capable reasoning model, followed by tests |
| Perform a mechanical YAML format conversion | Usually no | A capable general model, followed by validation |
| Design SKILL.md frontmatter | Often useful | A current model with relevant coding performance |
A useful rule: Use a general model when the result is easy to verify and the downside is small. Use reasoning when several constraints must be balanced or an error could be costly. A reasoning model still needs authoritative sources and human review; do not treat its fee as insurance against errors.
Hiding reasoning is not the same as disabling it
Some pi-web versions collapse or hide reasoning blocks. That changes the display, not necessarily the model request.
Check the model configuration. The provider can still perform and bill reasoning when the UI does not show it.
| Assumption | Reality |
|---|---|
| A hidden block means no reasoning | Display state alone says nothing about provider computation or billing. |
| No visible OpenAI chain of thought means no reasoning | OpenAI may expose usage or summaries without private chain-of-thought text. |
| One model name always means one reasoning mode | Behavior can depend on route, request parameters, and model version. |
| A small reasoning budget is always good value | Controls and minimums are model-specific. Do not assume that a guessed budget_tokens setting is supported or useful. |
To reduce reasoning usage, select a documented non-reasoning model. Alternatively, use an officially supported reasoning control for the exact model and route. Do not use guessed parameters.
Use different models at different stages
A practical approach is to use different models at different stages of one Session. You can keep OpenRouter as the route; this applies the strategy from Chapter 10. A direct provider remains optional.
A practical sequence is:
-
Explore with a general model
Describe the problem, gather known facts, and confirm entity names with a current lower-cost OpenRouter model.
-
Switch when the task becomes complex
When you must plan across several devices, constraints, or failure modes, use the model selector described in Chapter 13 to choose a current reasoning-capable model.
-
Understand the context cost
Previous turns are not regenerated, but relevant history is sent to the newly selected model on the next request and may count as input usage.
-
Return to a general model for simple revisions
After reviewing the plan and its initial YAML, a small value change may not require premium reasoning. Verify that the newly selected model can interpret the existing context.
Common reasoning problems
-
An OpenRouter reasoning model shows no block
Return to Chapter 6 and open the Add Model dialog. Confirm whether the exact model exposes reasoning through its route and set
thinkingFormatonly as documented. For the first-provider route, use the documented OpenRouter format rather than copyingzai. A blank or mismatched setting can leave a raw<think>…</think>segment inline or prevent separate rendering. Do not usedeepseekornativefor OpenRouter. Usezaionly for an optional compatible GLM direct route, save, and test in a new Session. -
A reasoning model gives a poor answer
The task may not benefit from reasoning, the input may be incomplete, or the model may still be wrong. If the exact provider and model document
budget_tokensas a control, follow that documentation; do not infer support from older model names. A later version may reject an unsupported parameter rather than accepting it. Do not assume a universal minimum such as1,024. Check current controls, constraints, sources, and the final result. For a simple lookup, use a suitable general model instead. -
The general model seems less thorough after a switch
That can happen. If the task still requires multistep planning, switch back to a suitable reasoning model. Do not equate verbosity with quality; verify the answer.
-
deepseek-reasoner is rate-limited or times out
Inspect the actual response and current provider status. Wait, reduce request size, or manually select another configured reasoning model. Do not assume Pi Agent provides automatic fallback. Use the current documented model ID, such as
deepseek-reasoner, rather than relying on an unsupported future rename. -
The reasoning phase takes a long time
Check whether the request is still active and whether the provider reports an error. If latency is unacceptable, use a supported lower-effort control or choose another current model next time. Do not assume one provider is always faster.
-
An OpenAI reasoning model has no visible chain of thought
This can be expected. Use supported summaries or usage information if available, and evaluate the final answer. Do not ask Pi Agent to reveal reasoning that the provider does not return.
Reasoning FAQ
Should I expand the reasoning block?
Can I tell a reasoning model to answer without reasoning?
thinking: {type: "enabled", budget_tokens: N}, while another route may document type: "adaptive" with output_config: {effort: "low"} as an effort control. Do not infer that behavior for future versions. Some models expose only adaptive reasoning, and an unsupported type:"enabled" parameter may fail. The reliable alternative is selecting a documented non-reasoning model through OpenRouter or an optional direct route.Can I share reasoning content?
Will all models become reasoning models?
Can Pi Agent choose the model automatically?
Do reasoning blocks consume context?
reasoning_content may or may not be retained. Check current documentation and context usage. Start a new Session with a verified summary when old reasoning no longer helps (see Chapter 8 for Session workflows).