Choosing a Grok model: all six ids compared

First split: text, image, video

Six ids carry the Grok name and they do not compete with each other. Three are text models on POST /v1/chat/completions: grok-4.6, grok-4.5 and grok-composer-2.5-fast. Two are image models on POST /v1/images/generations: grok-imagine-image and grok-imagine-image-quality. One is video, grok-imagine-video-1.5, on POST /openai/v1/videos.

The routes differ, so this is not a model-field swap. An image request does not go to the chat-completions endpoint, and the video id is asynchronous — you create a job and poll the returned id. Picking "a Grok model" means picking a route first.

Billing units differ too, even though the multiplier does not. The text ids are priced per million tokens. The image ids are priced per image: $0.01 official on grok-imagine-image and $0.04 on grok-imagine-image-quality, which at 0.2x is $0.002 and $0.008 per image. The video id is billed per video second, also at 0.2x.

Among the three text ids, two questions decide it

Question one: do you need thinking, or a window above 200,000 tokens? grok-composer-2.5-fast lists text and tools only, takes 200,000 tokens of context and emits up to 32,768. grok-4.6 and grok-4.5 both list thinking as well, take 500,000 tokens and emit up to 65,536. A yes to either part rules Composer out on capability, not on preference.

Question two, if Composer is still in: is its speed worth the price? Composer is $0.60 per million input and $3.00 output (0.2x on a $3/$15 official rate). grok-4.6 and grok-4.5 are $0.40 and $1.20 (0.2x on $2/$6). Composer costs more on both lines — 1.5 times on input, 2.5 times on output — so no input-to-output ratio makes it the cheaper id. Its case is the one its catalog description makes, a low-latency tier for interactive coding loops, and the catalog publishes no latency figure, so time a real turn on both before paying for it. Note that the 4.6/4.5 figures are the sub-200K tier — xAI doubles both at or above 200,000 tokens in a single prompt, to $0.80 and $2.40, which is also where Composer's window ends.

Between grok-4.6 and grok-4.5 there is nothing left to decide on paper. Same 500,000-token window, same 65,536-token ceiling, same capabilities, same $0.40/$1.20, same route. They differ by release date — 2026-06-03 and 2026-08-12 — and by cached-read rate: $0.30 per million official on 4.5 against $0.50 on 4.6, which at 0.2x is $0.06 against $0.10. On a workload with a heavily reused prefix, that is the only line in the table that moves.

# Text: grok-4.6, grok-4.5, grok-composer-2.5-fast
curl https://token-share.app/v1/chat/completions \
  -H "Authorization: Bearer $TOKEN_SHARE_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "grok-4.6",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Write a migration for this schema change."}]
  }'

# Image: different route, billed per image
curl https://token-share.app/v1/images/generations \
  -H "Authorization: Bearer $TOKEN_SHARE_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "grok-imagine-image",
    "prompt": "A wireframe diagram of a three-tier web application."
  }'

The two image ids differ by price, and the video id by resolution

grok-imagine-image and grok-imagine-image-quality are both 0.2x, like every Grok id, and both bill per generated image. The difference is $0.002 against $0.008 after the multiplier ($0.01 and $0.04 official), a factor of four. The catalog describes the second as the higher-fidelity variant and publishes no quality metric, so generate the same prompt on both and look at the results before committing a batch.

grok-imagine-video-1.5 is billed per video second at 0.2x, with official rates that vary by resolution: $0.08 per second at 480p, $0.14 at 720p and $0.25 at 1080p, which after the multiplier is $0.016, $0.028 and $0.05. Clips run 1 to 15 seconds, so resolution and duration together set the cost of a single generation, and choosing 480p over 1080p cuts it by roughly two thirds.

One operational note on video: the id is asynchronous. You POST to /openai/v1/videos, get a video id back, then poll /openai/v1/videos/{video_id} until it completes and fetch the result from /openai/v1/videos/{video_id}/content. Code written against a synchronous chat endpoint will not work here without that loop.

Common questions