Reasoning effort

Which models#

These controls apply to the hosted models in the catalog, the ones marked hosted on the Models page, today zhipu/glm-5.3-derisked. Partner-served models keep whatever reasoning behaviour their vendor defines; the fields below are passed through to them unchanged and take effect only where the vendor supports them.

The ladder#

Send reasoning_effort at the top level of a chat-completions request. The last column is what one hard prompt actually spent on thinking at each level.

curl https://api.ahurasense.com/v1/chat/completions \
  -H "Authorization: Bearer $AHURA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zhipu/glm-5.3-derisked",
    "reasoning_effort": "medium",
    "messages": [{"role": "user", "content": "Plan a three-day trip to Kyoto on a budget."}]
  }'

This is the field OpenCode, Hermes and most SDKs already send when you set a reasoning level in them, so in those tools there is nothing extra to configure. The template spelling, "chat_template_kwargs": {"reasoning_effort": "high"}, is refused by zhipu/glm-5.3-derisked with a 400, so use reasoning_effort. Sending any level is always safe; a model without a matching level uses its nearest.

On zhipu/glm-5.3-derisked the ladder is coarser than the table: none, minimal and low all answer without thinking, medium and high think briefly, max thinks most, and sending nothing sits between the two. Every level finishes on its own.

An exact budget#

To cap thinking at a number of tokens rather than a level, send custom_params.thinking_budget. A budget overrides the ladder when both are present. On zhipu/glm-5.3-derisked the budget is ignored; use the ladder there.

{
  "model": "zhipu/glm-5.3-derisked",
  "custom_params": { "thinking_budget": 300 },
  "messages": [{ "role": "user", "content": "Summarise this changelog in three bullets: …" }]
}

No thinking at all#

reasoning_effort: "none" puts the model in no-think mode: it answers directly, in well under a second on the hosted models, and nothing from the reasoning stage appears in the reply. Use it for classification, extraction and short answers, where thinking adds latency and cost without changing the result.

From the Anthropic-compatible route#

Code written against the Anthropic SDK expresses the same intent with Anthropic’s fields, and POST /v1/messages translates them for hosted models:

message = client.messages.create(
    model="zhipu/glm-5.3-derisked",
    max_tokens=1024,
    thinking={"type": "enabled", "budget_tokens": 300},
    messages=[{"role": "user", "content": "Summarise this changelog in three bullets: …"}],
)

Claude Code and other Anthropic-protocol clients that set an effort level or a thinking budget therefore work as expected against hosted models. A budget wins over an effort level when both are present.

Cost and limits#

• Thinking tokens are output tokens: billed at the model's output rate and reported in usage as reasoning_tokens. Pricing & usage.
• They count against max_tokens. With unbounded thinking and a small max_tokens, the model can spend the whole allowance thinking and return an empty reply with finish_reason: length. Either raise max_tokens or set an effort level. See reasoning tokens.
• Reasoning settings are part of the request, not the key, so one key can run a no-think classifier and an unbounded planner side by side.

Choosing a level

Start at medium for anything interactive: it keeps the first token under a second or two on the hosted models and handles most tasks. Reserve unbounded thinking for batch work and hard problems where waiting is fine. Use none wherever the prompt already contains the answer and the model only has to reshape it.