Introduction
OpenAI-compatible chat for Grok 4.5, the coding model in xAI's Grok line. One turn carries text and image_url parts, reasoning effort runs up to xhigh, and a single reply can reach 450,000 tokens.
xAI publishes Grok 4.5 for agentic software, engineering and workflow tasks, trained with additional science, engineering and mathematics data, and also serves it under the aliases grok-4.5-latest and grok-build-latest. Here it is one endpoint at /v1/chat/completions that reads up to 500,000 tokens across at most 256 ordered messages and hands back up to 450,000 in one reply. Input, cached input and output are metered apart from one another, which is the part an agent loop replaying a long prefix is really paying for.
Key features & highlights
The prefix you resend has its own meter
An agent loop sends the same system prompt, the same tool schemas and the same file map on every step, and only the tail of the conversation is ever new. Input served from cache comes back counted separately in the usage block and is metered on its own, cheaper rate. Nothing has to be switched on. Keeping the leading messages identical between steps is the whole technique, and the reply tells you how much of the prefix actually landed in cache instead of leaving you to assume it did.
Text and images in, text out
Message content may be a plain string or an array of parts, and this model declares two of them: {"type": "text", "text": "..."} and {"type": "image_url", "image_url": {"url": "...", "detail": "auto|low|high"}}. A screenshot and the question about it travel in the same turn, and image content is counted inside the 500,000-token window rather than on top of it. There is no file or PDF part on this endpoint, so a spec, a log or a diff has to arrive as pasted text. Reasoning effort takes low, medium, high or xhigh and starts on high; the effort is spent in output tokens, so it counts against the response cap as well as against the bill.
Request parameters
| Parameter | Required | Description |
|---|---|---|
messages | Yes | At most 256 turns. Content can mix text and |
reasoning_effort | No | low, medium, high or xhigh. High is the default; effort is spent in output tokens, so xhigh raises the bill even when the answer is short. |
max_tokens | No | Caps the visible reply at 450,000; the default of 4,096 truncates a long answer silently. |
temperature | No | 0 to 2, default 0.7. Use 0 when comparing two patches or two runs of the same task. |
top_p | No | 0.01 to 1. Move this or temperature, not both together. |
tools | No | Up to 128 function definitions per request. Keeping their order stable between steps helps the prefix stay cacheable. at most 128 items |
parallel_tool_calls | No | true or false, default true: the model may request several tool calls in one turn. Default: |
tool_choice | No | auto, none, required, or an object naming the function to call. |
response_format | No | Request a JSON object when the reply is parsed by the next step of an agent rather than read by a person. |
Pricing
Input $2 / Output $6 per 1 million tokens; Prompts of 200K tokens or more: Input $4 / Output $12
Total input includes cached tokens. At 200,000 input tokens or more, long-context rates apply to all input, cached input and output for the request; smaller inputs use standard rates. Cached input is metered apart from fresh input and priced below it. Output includes reasoning tokens, so a higher effort level costs more even when the visible answer is the same length. Check the request budget before submitting. The initial hold assumes no cache savings, and settlement refunds the difference against measured usage.
Use cases
Keep the whole loop in context
A coding agent resends its instructions, its tool schemas and its file map on every step and adds a few hundred new tokens each time. All of it fits inside the 500,000-token window, the repeated part is metered as cached input, and the request only crosses into the long-context rate at 200,000 combined input and cached input tokens - which the pre-submit estimate tells you before you pay for it.
Refactor with the module, its tests and the failure in one turn
Paste the module, the test file and the failing output together and ask for the patch plus the reasoning behind it. Raise reasoning_effort to xhigh when the change has to be thought through before it is written: it spends more output tokens before the first line of code appears, which is the right trade on a change you will review line by line.
Read a screenshot and a stack trace together
Attach a failing dashboard as an image_url part at detail high and paste the stack trace as text in the same message, then ask for causes in order of likelihood. The picture and the log arrive in one turn, so the model reads the panel itself rather than your description of it.
Take a migration write-up back in one response
450,000 output tokens is enough for a full migration plan, a rewritten module or a translated manual in a single reply instead of a chapter loop. Raise max_tokens explicitly: the default of 4,096 truncates a long generation without raising an error, and truncation is the failure mode that looks most like a finished answer.
Prompt guide & pro tips
Choose the effort level per task, not per project
reasoning_effort starts on high, so an omitted field already buys careful work and the output tokens that come with it. Decide per call: xhigh for a migration or a proof, high for ordinary review, low for a mechanical turn such as classifying a log line. Because effort is paid in output tokens, a short answer at xhigh can still cost more than a long answer at low.
Ask for the artefact, with a body you can paste
Pin the output shape in the system message and let the user turn carry the evidence - the file, the log, the screenshot - so the model is not guessing at the format while it works through the problem.
curl https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "xai/grok-4.5",
"messages": [
{"role": "system", "content": "Return the patched file in full. No diffs, no commentary, no omitted regions."},
{"role": "user", "content": [
{"type": "text", "text": "Both panels are the same service before and after the deploy. Which one regressed, and what in the diff explains it?"},
{"type": "image_url", "image_url": {"url": "https://cdn.spicyapi.ai/models/examples/inputs/c681580c3c6a0b63.jpeg", "detail": "high"}}
]}
],
"reasoning_effort": "high",
"max_tokens": 32000
}'
Read the usage block before you tune anything
The reply reports input, cached input and output tokens separately, and that is the only honest answer to "did my prefix cache". Tune from it rather than from the shape of the conversation: if the cached share stays at zero across steps, something in the leading messages is changing between calls - a timestamp in the system prompt, a reordered tool list - and moving that content to the end of the request is usually the whole fix. Stream long replies with stream: true, which returns chat.completion.chunk events until data: [DONE].
API quick start
curl --fail-with-body -sN https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"model": "xai/grok-4.5/chat",
"messages": [
{
"role": "user",
"content": "Summarise the following release notes into three bullet points."
}
],
"stream": true
}' \
| jq --unbuffered -Rrj 'select(startswith("data: ")) | .[6:] | select(. != "[DONE]") | fromjson | if .error then "\n[error] \(.error.message)\n" else (.choices[0].delta.content? // empty) end'
See the API reference for authentication, the complete schema, polling, and error handling.
