Grok's Reasoning Mode: How the “Think” Output Differs From the Final Answer

A Grok reasoning response can contain three distinct things: an internal trace, a summary of that trace, and the answer. They are different fields, they are billed differently, and only one of them is safe to show a user.

Three different outputs, not two

The mental model most people bring is a two-part response — thinking, then answer. xAI’s reasoning documentation describes a third thing in between, and the distinction is load-bearing.

• The raw reasoning trace. Tokens the model generates while working, before it commits to an answer. xAI documents an include: [“reasoning.encrypted_content”] option for returning reasoning in encrypted form — encrypted content is content you can carry between turns without being able to read it, which tells you plainly that the raw trace is not simply handed over as plain text on demand.
• A summary of the reasoning. xAI documents summarised reasoning exposed alongside the final answer in streaming responses. This is a rendering of the trace, produced for display — useful for a “thinking…” panel, and not a faithful transcript.
• The answer. The output text. This is the only part your parser, your evaluation and your user should be reading.

Treat the first two as diagnostics. A trace is a record of a search that included branches the model abandoned, so a claim inside it may be one the final answer deliberately rejected. Extracting a value from the trace because it appeared there is a reliable way to ship a bug that only reproduces on hard inputs.

reasoning_effort and its values

The dial is reasoning_effort. xAI’s API reference documents the values as none, low, medium and high, with low as the default, and scopes that description to grok-4.3. Its reasoning guide describes the parameter for grok-4.5 with low, medium and high, and documents high as the default there — low being characterised as using some reasoning tokens while staying fast, and high as spending more tokens on deeper thinking.

Set side by side, the two pages do not agree:

source                     model      documented values              default
API reference              grok-4.3   none, low, medium, high        low
reasoning guide            grok-4.5   low, medium, high              high

The difference is not cosmetic, and it is not obviously reconcilable by scoping. Both pages describe the same parameter name. One offers an off position and the other does not list one. One defaults to the cheapest setting and the other to the most expensive — which, on a model billing reasoning tokens as output, is a difference in cost per request of whatever ratio deep thinking bears to shallow thinking on your traffic. A developer who reads only the reasoning guide and calls grok-4.3 has a different mental model of their own bill than one who read only the API reference.

It is possible the values genuinely differ per model and each page is correct within its scope; it is equally possible one page lags the other. Nothing observable from the documentation settles it, and this page is not going to pretend otherwise — asserting a single answer here would be inventing a fact to make a page tidier.

What follows is the same either way, and it is the useful part. Never rely on the default: send reasoning_effort explicitly on every request, for the specific model you are calling. Then confirm what happened from the response rather than from the docs — usage.reasoning_tokens is the ground truth, and comparing it across two effort settings on a handful of your own prompts tells you in minutes what the parameter is doing on that model. If a value is rejected, you have learned the supported set for that model authoritatively.

{
  "model": "grok-4.3",
  "messages": [ { "role": "user", "content": "..." } ],
  "reasoning_effort": "none",
  "max_completion_tokens": 512
}

Two further documented behaviours belong here. On models that reason, reasoning cannot be disabled — none is a documented effort level on grok-4.3 rather than a universal off switch, and where a model has no such level the trace is part of how it answers. And on the multi-agent model, xAI documents the effort setting as controlling the number of agents rather than a depth of thought, under a nested reasoning.effort field — the same word meaning something different.

Reasoning tokens are billed

Usage exposes reasoning_tokens, and xAI’s rate-limit page lists reasoning tokens among the categories that count toward your tokens-per-minute limit alongside prompt tokens, completion tokens and cached prompt tokens.

So the trace is not free, not hidden from the meter, and not exempt from throughput limits. It is output you are charged for and mostly do not read. That reframes reasoning_effort as a cost control rather than a quality knob: raising it raises the bill and the latency on every request in the workload, including the easy ones, and the easy ones are usually most of the traffic.

The other consequence is on your token budget. Reasoning tokens occupy the same window as everything else, so a long trace eats into what is available for the answer — see how the output ceiling is actually determined. Give a reasoning request more headroom than the answer length suggests, and lower the effort rather than clamping the token cap when you want it shorter.

Where the trace appears in a stream

Not in choices[].delta.content. xAI documents typed streaming events on the Responses endpoint — response.reasoning_text.delta and response.reasoning_summary_text.delta — separate from the output text events. The OpenAI-compatible chat.completion.chunk shape has no field for a trace at all.

Practically that means a client reading only content deltas sees nothing for the whole thinking phase, and then the answer. Two things follow. A progress indicator driven by content deltas will look stalled during entirely normal operation. And an idle timeout measured against content activity can fire mid-generation, which is why xAI’s reasoning documentation advises manually extending client timeouts for reasoning models. Feed every received frame to your idle detector, not only the ones with visible text. The full event shape is in the streaming format page.

There is also a parameter interaction worth remembering here, because it turns up as a 400 rather than as a behaviour change: stop, presence_penalty and frequency_penalty are documented as unsupported on reasoning models. That is covered in the stop sequences page.

What to do with the trace

• Show the summary, never the raw trace. The summary exists for display. A raw trace contains discarded reasoning and reads as though the model believes things it decided not to say.
• Parse only the answer. If you are extracting JSON, extract it from the output text. Anything that scans the whole response for a code fence will eventually find one in the trace.
• Log reasoning_tokens separately. It is the single most useful number for deciding whether an effort level is earning its cost on your traffic, and it is invisible in a total token count.
• Carry encrypted reasoning rather than reconstructing it. Where a multi-turn flow benefits from the model retaining its earlier thinking, the documented mechanism is the encrypted content option — not pasting a trace back into the prompt as text.
• Compare effort levels on your own task. Higher effort helps on some problems and only adds cost on others. That is a property of your workload, measurable with the evaluation set you already need for model pinning.