Grok's Modes Explained (And How They Change Output)

TL;DR: Grok modes are four things at once. grok.com serves a four-item mode picker, Auto, Fast, Expert and Heavy, with Fast as the default. Personality presets change tone on a separate axis. Grok Imagine and Voice carry their own mode lists. In the API the equivalent control is reasoning effort, and it means something different depending on the model.

What are Grok's modes, and where do they live?

Most articles about grok modes are describing a menu that no longer exists. They list Fun Mode, Think and DeepSearch. Not one of those three names appears in the mode list Grok serves today.

Here is the current answer, taken from the app itself rather than from memory. grok.com embeds its mode list as a JSON block in the page HTML, under a script tag with the id server-client-data-modes. Fetched signed-out on August 27, 2026, these were its four entries, with the icon and tag plumbing trimmed and nothing else changed:

{"modes":[
  {"id":"auto",  "title":"Auto",  "description":"Chooses Fast or Expert"},
  {"id":"fast",  "title":"Fast",  "description":"Quick responses · Grok 4.5"},
  {"id":"expert","title":"Expert","description":"Thinks hard · Grok 4.5"},
  {"id":"heavy", "title":"Heavy", "description":"Team of Experts · Grok 4.5"}
],"defaultModeId":"fast"}

Four modes. Fast is the default. Auto, Expert and Heavy each carried a requiresUpgrade availability flag for a signed-out visitor; Fast carried available.

Two honest caveats before anyone builds a workflow on that. First, what you see signed in, on a paid tier, or on mobile can differ; the same payload is full of rollout flags. Second, the same payload's legacy model block still describes Grok 3 as "Our Newest Model", so treat these strings as the client's configuration rather than as a spec sheet. The mode names are reliable. The model names attached to them are decoration, and they already lag the API, where the current flagship is grok-4.6.

That is one surface. There are four more, and conflating them is why the topic reads as confusing:

Note the pattern. Everything a paying consumer touches is undocumented, and everything a developer touches is documented in detail. xAI's own FAQ says the quiet part out loud: the documentation "is mainly meant for our API users", while that page "collects the most common questions about our consumer-facing Grok website and apps".

What actually changes when you switch chat modes?

Three things, in descending order of how much they matter to your prompt.

Compute spent before the first token. Expert is labelled "Thinks hard" where Fast is "Quick responses". In API terms this is reasoning effort, and xAI is precise about it there: on grok-4.6 and grok-4.5, reasoning_effort takes low, medium, high or xhigh, and "If not specified, reasoning_effort defaults to "high". Reasoning cannot be disabled."

How many agents run. Heavy is a "Team of Experts". The documented API analogue is the multi-agent model, where xAI writes: "You can configure how many agents collaborate on a request. The two available setups are 4 agents and 16 agents." And the cost is stated plainly: "More agents means deeper, more thorough research at the cost of higher token usage and latency."

Who picks. Auto "Chooses Fast or Expert" for you. xAI publishes no rule for how that choice is made, which means in Auto you are writing a prompt for a router as well as for a model.

What does not change, as far as anything xAI publishes: refusal behaviour. There is no mode-by-mode safety table anywhere in the documentation. The company's position on Imagine is that "Enabling NSFW does not turn off moderation", that protections apply at all times, and that it deliberately does not publish specific moderation rules. Anyone telling you Expert mode refuses less than Fast is reporting a vibe, not a documented behaviour.

How should one prompt change across Auto, Fast, Expert and Heavy?

Same task, four modes. The task: you need a decision on whether to migrate an internal service to a new queueing system.

Fast. Ask for one thing, bounded, with the shape stated. Do not ask for analysis you are not paying thinking tokens for.

In under 120 words: three concrete reasons a team would move an internal job
queue from Redis to Postgres, and three reasons not to. Bullet points only.
No preamble, no summary paragraph, no recommendation.

Auto. The router decides for you, so say which way you want it to lean. Depth language in the prompt is the only lever you have over a routing decision xAI does not document.

Treat this as a considered question, not a quick lookup. I need a reasoned
comparison, not a list. If the answer depends on facts you are unsure of,
say which facts, then answer conditionally on each.

Should a 12-person team running 40k background jobs a day move from Redis
to Postgres-backed queues?

Expert. Give the reasoning something to chew on: constraints, a decision rule, and an explicit instruction to argue against itself.

Decision: migrate our job queue from Redis to Postgres, or stay.
Constraints: 40k jobs/day, p95 latency budget 2s, one part-time SRE,
already running Postgres 16 with read replicas, 18-month horizon.

Work in this order:
1. State the decision rule you will use before you evaluate anything.
2. Argue the strongest case FOR migrating. Then the strongest case AGAINST.
3. Name the single fact that would flip your answer, and how to test it
   in under a day.
4. Give a recommendation and a confidence level, with the reason for
   that confidence.

Heavy. Heavy is a team, so ask for the disagreement rather than the consensus. A synthesised answer from several agents will smooth over exactly the conflict you needed to see, unless you ask for it.

Analyse this migration from four distinct positions: the SRE who owns the
pager, the backend engineer who ships features, the finance lead who signs
the infra bill, and a sceptic who thinks the migration is resume-driven.

For each position: the strongest argument, the assumption it rests on, and
what evidence would change it.
Then: list every point where the four positions genuinely conflict. Do not
resolve them. End with the two conflicts that most affect the decision.

The pattern generalises. In cheap modes you constrain the output; in expensive modes you constrain the process. Writing a Heavy-shaped prompt in Fast mode wastes your words, and writing a Fast-shaped prompt in Heavy mode wastes your money.

What are Grok's personality settings, and how do they change output?

This is the second axis, and it is more mechanical than the name suggests. grok.com ships four personality presets in the same page payload, each with an id, a name, a user-facing description, and a prompt string that is what the app actually sends.

The Concise preset's instruction, verbatim from the payload: "Respond briefly and directly, using as few words as possible. Focus on the core point without elaboration or follow-up questions."

Formal opens with "Use a formal tone, providing clear, well-structured sentences and precise language." Tutor opens with "Respond as a Socratic teacher, guiding the user through questions and reasoning to foster deep understanding." Comprehensive opens with "Provide thorough, detailed responses that explore topics from multiple angles."

So a personality preset is a prompt. That has one immediate consequence: your instructions do not override it, they compete with it. If Tutor is on and you ask for a direct answer, you have asked for the opposite of a standing instruction the model also received. Sometimes you win. Sometimes you get a question back.

Four prompts, one per preset, written to work with the preset rather than against it:

[Concise is on]
Answer in one sentence, then stop. If a caveat is genuinely load-bearing,
add it as a second sentence beginning "Except:". Nothing else.

[Formal is on]
Write this as an internal memo to a director who has 90 seconds. Lead with
the recommendation. Then three supporting points, each one sentence. Then
one line naming the main risk. No greeting, no sign-off.

[Tutor is on]
I already understand the fundamentals here, so skip the discovery questions.
Instead: give me the answer first, then the one question I should be asking
that I have not asked yet. One question, not three.

[Comprehensive is on]
Full depth is fine, but structure it so I can stop reading early. Lead with
a 40-word answer. Then the reasoning. Then edge cases. Then anything that
only matters at scale. Label each section so I can skip.

And if you would rather set your own, the honest move is to write the standing instruction the way xAI writes theirs: short, imperative, about behaviour rather than identity.

Default behaviour for all my chats:
- Answer first, explain second. Never open with a restatement of my question.
- If a claim depends on something after your training data, say so and
  say what would confirm it.
- When you are unsure, give a number: high, medium or low confidence,
  and the reason.
- Never end with an offer to help further.

That last block is the one worth saving somewhere reusable, because you will paste it into every mode, every surface and every model you use. It is the part of your setup that outlives the vendor's menu.

Does Grok still have a Fun Mode?

Not under that name, and this is where most of the search traffic for grok modes is going.

Checked on August 27, 2026: the strings "Fun Mode", "DeepSearch", "DeeperSearch" and "Big Brain" appear zero times in xAI's complete published documentation corpus, and "Fun" appears zero times in the mode payload grok.com serves. Two internal flag names containing deepsearch survive in the client config, which tells you the plumbing is still referenced in the client config, not that the button is there.

What the current surfaces actually contain:

• Unhinged exists today as one of thirteen voice personalities, not as a chat mode. The full list in the Voice Mode config is assistant, therapist, storyteller, kids-stories, kids-trivia, meditation, doctor, unhinged, sexy, motivation, conspiracy, romantic and argumentative.
• Grok Studio is gone and xAI says so directly: "Grok Studio is no longer supported. Use Grok Build instead." The same FAQ entry adds a security note worth reading if a third-party app is still showing you a Studio view.
• Companions are not a web feature at all. xAI's FAQ: "Companions are available on the iOS app only, and there are no plans to bring them to the web or Android."
• Deep research exists as a Grok Build CLI command, /deep-research, rather than a chat toggle.

If you are following a 2025 tutorial, this is the paragraph that saves you twenty minutes of hunting for a button.

What modes does Grok Imagine have?

Grok Imagine carries its own mode list, and it is the one place where the mode genuinely decides whether prompt craft matters at all. The video prompt modes grok.com served on August 27, 2026 were three: Custom, Normal and Spicy.

The interesting part is the flags rather than the names. Custom is marked as a custom mode, meaning the prompt is yours. Spicy is marked mature and, more importantly, model-generated-only, with the internal mode name extremely-spicy-or-crazy. In a model-generated mode the prompt is written by the model, so there is nothing for you to write. Every "best Spicy mode prompts" article is selling you a lever that is not connected to anything.

[Imagine, Custom mode — text-to-video]
Static locked-off shot. A ceramic mug on a windowsill, morning light from
camera left. Steam rises and drifts right. The light slowly warms over the
clip as if the sun is clearing a building. Nothing else moves. No camera
movement, no cuts, no people.

[Imagine, Custom mode — image-to-video from a still]
Animate only the water. The rest of the frame stays locked. Water falls at
natural speed with visible spray at the base. Camera pulls back slowly and
evenly across the whole clip, no easing at the end.

Two constraints from xAI's own FAQ that shape those prompts more than any wording does: generated media carries a Grok watermark with no setting to remove it, and "720p videos automatically fall back to 480p once you hit the 720p cap for your tier." If your output looks softer than yesterday's, that is a quota behaviour, not a prompt failure. For how the video-prompt grammar itself works, post 183 covers Grok Imagine Video 1.5.

How does Voice Mode change what you should say?

Voice is the mode where written-prompt habits actively hurt. The config grok.com serves lists 27 voices and 13 personalities, plus toggles for search, vision, an NSFW switch and a kids switch. Some voices carry a disablePersonalities flag, so the two lists are not freely combinable.

Two things break in voice that never break in text: structure markers and length. Nobody hears a bullet point, and a 400-word answer is 3 minutes of talking.

[Voice]
Answer out loud in under 20 seconds. No lists, no headings, no "firstly".
One idea per sentence. If it needs more than 20 seconds, give me the
headline and ask whether I want the detail.

[Voice, hands busy]
I am driving, so keep everything spoken and short. When you give me steps,
give me one step, then wait for me to say "next". Do not read ahead.

What is the API equivalent of a mode?

There is no mode parameter in the xAI API. There are three controls that do the work the consumer picker does, and one of them is a trap.

Reasoning effort. On grok-4.6 and grok-4.5 this is depth. Four levels, default high, and it "cannot be disabled". xAI also notes that ""xhigh" is available on grok-4.6 and later. On models that do not support it, such as grok-4.5, requests with "xhigh" are treated as "high"."

{
  "model": "grok-4.6",
  "reasoning": {"effort": "low"},
  "input": "Classify this ticket as bug, feature or question. One word."
}

{
  "model": "grok-4.6",
  "reasoning": {"effort": "xhigh"},
  "input": "Prove or disprove: every planar graph is 4-colourable. Show every step."
}

Agent count, wearing the same parameter's clothes. This is the trap. On the multi-agent model the identical field means something else: "For grok-4.20-multi-agent, the reasoning.effort parameter controls how many agents collaborate on a request rather than reasoning depth." xAI's mapping table sends low and medium to 4 agents, high and xhigh to 16. So on one model medium is a real intermediate setting, and on another it is a synonym for low.

{
  "model": "grok-4.20-multi-agent",
  "reasoning": {"effort": "high"},
  "input": "Compare three approaches to distributed consensus. Cover safety, performance and implementation cost, and flag where the sources disagree."
}

One documented consequence for how you prompt it: "Only the leader agent's output is returned, including its tool calls and response content." The sub-agents' reasoning is encrypted and withheld unless you explicitly ask for it. If you want the disagreement, the leader has to be told to surface it, or it will hand you a clean synthesis with the interesting parts filed off.

Service tier, which is a latency mode and nothing else. Priority Processing "gives your xAI API requests higher scheduling priority, which typically results in lower time-to-first-token (TTFT) and faster inter-token latency (ITL), especially during periods of high demand", at a premium token price. It changes nothing about the output.

{
  "model": "grok-4.6",
  "input": "Draft the release note.",
  "service_tier": "priority"
}

Note the honest bit in xAI's own wording: "The response always includes a service_tier field indicating whether priority was granted; check it to confirm." Asking is not getting.

And none of these turn on live data. That is a separate switch, and it is the subject of how to prompt Grok when real-time data is involved. If you want the job-shaped versions, post 188 has 28 real-time templates.

Where do xAI's own docs disagree about modes?

In two places, and both are worth knowing before you quote a number at a colleague.

Reasoning effort has three published definitions. The capability guide at /developers/model-capabilities/text/reasoning says grok-4.6 and grok-4.5 support it, that it defaults to high and cannot be disabled. The REST reference's machine-readable twin for the chat endpoint still says it is "Only supported by grok-4.3", that the values are none, low, medium and high, that "none (disables reasoning completely)" and that low "is the default if not specified". The batch endpoint's twin gives a third account: two values, low and high. Those reference pages render client-side, so the text exists only in the markdown twin, which is a reason to treat the guide as authoritative and the twins as stale rather than to average them.

Grok 4.6 has two knowledge cutoffs. The models page states: "The knowledge cut-off date of Grok 4.6 is February 1, 2026." The Grok 4.6 page's at-a-glance table lists it as January 2026. Neither page references the other. Both were live on August 27, 2026.

What are Grok Build's three session modes?

The CLI is the one surface where xAI documents its modes properly, and the three of them are permission gates rather than intelligence dials. Shift+Tab cycles them.

• Plan. "Plan mode is planning first: only the session plan file can be edited until you approve." The file-edit gate is independent of the permission mode.
• Auto. "Auto uses a classifier to auto-approve safe tools; dangerous ones may still prompt."
• Always-approve. "Always-approve skips permission prompts for tool calls", with deny rules and hooks still applying.

Prompting shifts accordingly. In Plan mode you are writing a spec, so the output you want is a document. In Always-approve you are writing an instruction that will execute, so the output you want is a boundary.

[Grok Build, Plan mode]
Plan only. Do not write code. Produce: the files you would change, the
order, the one test that proves each change, and the rollback. Flag any
step you are less than 80% sure about and say what would resolve it.

[Grok Build, Always-approve]
Scope: src/queue/ only. Do not touch migrations, CI config or anything
under infra/. Run the test suite after each file you change and stop on
the first failure. If a change requires editing outside that scope, stop
and tell me instead of doing it.

Worth noting where the trend points. Grok Bot, xAI's newest surface, does not offer the choice at all: "Grok Bot has no model picker, for members or admins." Mode selection is a phase, not a permanent feature of these products, which is a decent argument for putting your effort into prompts that survive a menu change.

The short version

Grok modes are three separate dials that people talk about as one. Compute, through the Fast, Expert and Heavy picker and its API twin, reasoning effort. Tone, through the four personality presets. Capability, through whichever product you are inside, since Imagine, Voice and Build each carry their own mode list.

The move that pays is not memorising the menu. It is writing prompts that state their own requirements, so the same text produces something useful whether the router sent it to Fast or to Expert. Constrain the output in cheap modes, constrain the process in expensive ones, and keep your standing instructions somewhere you can paste them into whatever the menu looks like next quarter. If you want that discipline in a more structured form, JSON prompting makes the requirements explicit enough that mode changes stop mattering, and the same logic drives how to get shorter, sharper answers out of any model with a verbosity setting.