grok-4.5 as a Sume model id runs GPT-6 Sol, not Grok: the alias list

If you send grok-4.5 as a model id to Sume, you do not get a Grok. Four old ids, grok-4.5, composer-2.5, composer-2.5-fast and sume-1.0-fast, are mapped to GPT-6 Sol on every new request, and Sume's own source says the grok-4.5 spelling stays that alias even though xAI ships a live Grok 4.5. Grok 4.7 is the live Grok id (grok-4.7), behind a Grok catalog gate.

Why does grok-4.5 not mean Grok 4.5?

The id predates the current catalog. Sume's changelog for v0.2.55 records Grok 4.5 as the default agent model on 2026-07-31, and the catalog has changed since. Saved automations, browser picks and in-flight clients kept sending the old strings.

Rather than 400 those callers, the registry keeps a small set of Cursor-era ids and resolves each to GPT-6 Sol. A comment in the code states the intent: old clients, stored threads and saved automations keep working, and the grok-4.5 spelling is not reclaimed for the real Grok 4.5. The practical rule is that a model id that looks like a Grok may be an alias, so the receipt, not your payload, tells you what ran.

Which ids are aliases and which are real?

This table is built from the registry. The right-hand column is what a new request resolves to:

What is Grok 4.7 on Sume and what does xAI say?

xAI's model page lists grok-4.7 with text and image input, text output, a 500,000-token context window, reasoning effort low, medium, high and xhigh with high as default, and function calling and structured output. Its price is $2.00 per million input tokens and $6.00 per million output tokens under 200,000 tokens, and $4.00 and $12.00 above that.

In Sume the Grok 4.7 row exists only where the Grok gate is open. The registry ties it to the Grok Build harness plus a catalog flag in the environment, and says that with the flag off a request gets a 400 instead of being moved onto a GPT row. Retired grok-4.6 moves to 4.7 behind that same gate. So whether you can pick Grok 4.7 is a property of your workspace, not of the model name.

The Grok 4.7 remote MCP post covers the other direction: calling Sume tools from xAI's own API.

Why not refuse grok-4.5 outright?

Because a refusal breaks callers who did nothing wrong. A scheduled automation saved in July with grok-4.5 would start failing in October with no change on their side. Sume's rule is the opposite of both a silent downgrade and a hard break: known old ids move to a named successor, and ids that were never in the catalog are refused.

The cost of that choice falls on you if you rely on the name. A dashboard that counts "Grok runs" by the string in your request will be wrong for every alias hit. Count by the model on the receipt instead.

How do I make sure a run really used Grok?

Do not infer it from the string you sent. After the run, read the receipt: for a Format run, model is the catalog id the orchestrator ran on, as Runs and results documents. If it says gpt-6-sol, the alias fired or the Grok gate was not what you thought.

If your code still sends grok-4.5 or a composer- id, replace it with the id you actually want, whether that is grok-4.7, gpt-6.1-sol or another catalog id. Keeping the alias works, but it hides the model from your own logs, and the alias list is Sume's to change.