Reasoning

How to ask#

Both dialects reach the same control. What you send is an intent; xKiro translates it into whatever the model that ends up serving your request actually understands.

{ "reasoning_effort": "high" }

{ "thinking": { "type": "adaptive" } }                          // model decides the depth
{ "thinking": { "type": "enabled", "budget_tokens": 16000 } }  // a token budget
{ "thinking": { "type": "disabled" } }                         // off

Budgets become levels

When a request carrying budget_tokens is served by a model that expresses reasoning as a level rather than a budget, the budget is converted:

Support is per model#

Every model declares which control it has and which values it accepts. The shapes currently in the catalog:

Two meanings of minimal

Two models in the catalog accept minimal, and they do not mean the same thing. On GLM-5.2 it is a step on a graded scale that also has a separate none for switching reasoning off. On Gemini 3.6 Flash there is no none: minimal is the off position, and it is also what you get when you send no reasoning parameter at all.

The practical consequence is only on Gemini 3.6 Flash: asking for something below low lands on minimal rather than being refused, and a request that says nothing is served at the cheapest step rather than a middle one. If you want more than that on this model, ask for it explicitly.

Finding out for your model

Read it from the API instead of this page: GET /v1/models returns a reasoning_efforts object per model — the exact levels it accepts and its default, straight from the live catalog (see List models). The catalog in the dashboard shows the same data. Treat those as the source of truth: the table above is a snapshot, and models are added and revised without a documentation deploy.

curl -s https://api.xkiro.com/v1/models \
  | jq '.data[] | select(.id == "z-ai/glm-5.3") | .reasoning_efforts'
# { "levels": ["low", "high", "max"], "default": "high" }

Four intents, and why they differ#

This is the part that trips people up most, so it is worth stating precisely.

Levels a model does not have#

Nothing is rejected for this reason, and nothing is ever quietly upgraded. The rules, in order:

• Above the model's range → step down to the nearest level it has. Asking for max on GPT-5.4, which stops at xhigh, gives xhigh — not the model default, which would be lower than you asked for.
• Below the model's lowest level → nothing is sent. Rounding up would cost more than you asked for. On most models that means the model runs on its own default. ⚠️ On openai/gpt-5.6-*, gpt-5.5 and gpt-5.4* it does not mean "off": none lands on the model's lowest level and still bills reasoning tokens. There is currently no way to fully disable reasoning on those models.
• Two-position models get the obvious answer. Any positive level turns the switch on; noneturns it off. There is no way to ask for "a bit" of thinking on those models.
• Unrecognised values are never forwarded upstream. A typo does not silently disable reasoning — some providers return 400 for an unknown level, so xKiro drops it. On most models the model default then applies; on the models named above the lowest level applies instead.
• Models with no control ignore the field. No error, no cost, no effect.

Reading the reasoning#

Where a model exposes its thinking, it arrives alongside the answer: thinking content blocks on Messages, and reasoning_content on the delta in Chat Completions. Not every model returns it, and some return only a summary.

for await (const chunk of stream) {
  const delta = chunk.choices[0]?.delta as
    | { content?: string; reasoning_content?: string }
    | undefined;

  if (delta?.reasoning_content) showThinking(delta.reasoning_content);
  if (delta?.content) showAnswer(delta.content);
}

Cost and latency#

• Reasoning tokens are billed as output tokens. On the same prompt, a high level can cost several times what a low one does.
• Time to first visible token grows with depth, because the model reasons before it writes. Use streaming so the wait is visible rather than blank.
• Sampling parameters are dropped while reasoning is active — reasoning models reject temperature and top_p, so xKiro removes them rather than letting the provider fail the request.
• If a model defaults to reasoning and you do not need it, turning it off explicitly is one of the largest single savings available.