Grok API Pricing Explained: What xAI Models Actually Cost to Run

Most teams meet Grok API pricing twice. The first meeting is a pricing page, scanned quickly, filed under "cheap enough". The second is an invoice three weeks after launch that does not match the spreadsheet. The gap between those two moments is almost never caused by the headline rate. It is caused by billing mechanics that sit one layer below the price table: long-context tiers, reasoning tokens, cached prefixes, and server-side tool calls.

This guide covers those mechanics in the order they hit your bill. Every rate quoted here is taken from xAI's published documentation on the date at the top of this page, and we relist rather than round, because rounding is how estimates drift. If you want to run the arithmetic on your own traffic while you read, keep the token calculator and the pricing database open in a second tab.

How xAI bills a Grok API request

Grok is metered per token, not per request, per seat, or per minute of use. A token is roughly three quarters of an English word, so a 1,000 word document is about 1,300 tokens. Every API call is priced across three meters that run at different rates:

• Input tokens are everything you send: system prompt, retrieved context, conversation history, tool schemas, and the user message.
• Cached input tokens are the part of your prompt prefix that xAI has already processed recently and can reuse. They are billed at a steep discount.
• Output tokens are everything the model generates, including internal reasoning tokens that never reach the end user.

That third point is the one worth reading twice. On reasoning-capable models, the chain of thought the model produces before answering is billed at the output rate. A response that shows 200 words on screen can carry several thousand billed output tokens behind it. This is standard practice across the industry rather than an xAI quirk, but it makes reasoning workloads behave very differently from classification or extraction workloads on the same price sheet.

Current Grok API pricing per million tokens

The table below reflects xAI's published text API rates. Prices are in USD per one million tokens. Models with two rows use tiered long-context pricing, explained in the next section.

Two structural details matter more than the absolute numbers. First, the output multiple: output costs three times input on Grok 4.5 and twice input on Grok 4.3. Any workload that generates long answers is an output-dominated workload, and its cost curve is set by that multiple. Second, the cached discount: cached input runs at roughly 15 to 16 percent of standard input. A stable system prompt is not a rounding error, it is a lever.

xAI also maintains a wide alias list, which is where a lot of confusion about "Grok 3 pricing" or "Grok 4 pricing" comes from. Older model names such as grok-3, grok-4, and the grok-4-fast variants now resolve to a current model rather than a separately priced legacy endpoint. If you are budgeting against a model string you set months ago, confirm what it resolves to today before you trust the forecast.

The long-context tier: the most expensive line in the fine print

xAI applies tiered pricing at a 200,000 token prompt threshold. The important part is not that the rate doubles. It is that the higher rate applies to every token in the request, not only to the tokens above the threshold. There is no blended rate and no partial application.

Consider a retrieval-augmented request on Grok 4.5 with a 199,000 token prompt and a 2,000 token answer. Input costs 0.199 million times $2.00, or about $0.40. Output costs 0.002 million times $6.00, or about $0.012. Total: roughly $0.41. Add 2,000 more tokens of retrieved context and the same request crosses the threshold. Input is now 0.201 million times $4.00, or about $0.80, and output is 0.002 million times $12.00, or about $0.024. Total: roughly $0.83. Two thousand extra tokens, a request that costs twice as much.

A retrieval pipeline that averages 190k tokens per prompt is not safely under the threshold. It is one verbose document away from doubling its unit cost.

The practical response is a hard budget in your retrieval layer rather than a soft target. Cap assembled context at a value with real headroom, measure the distribution of your prompt sizes instead of the average, and log the count of requests that cross the tier. If more than a small fraction crosses it, the fix is usually tighter chunk selection or a reranking step, not a bigger budget. Our context window calculator is built for exactly this sizing exercise.

Prompt caching: the cheapest optimisation available

Prompt caching lets xAI reuse the computation for a prompt prefix it has seen recently. Cached tokens appear in the response payload under prompt_tokens_details.cached_tokens on the Chat Completions API, and under input_tokens_details.cached_tokens on the Responses API. If that value stays at zero across a multi-turn conversation, caching is not working and you are paying full price for text the model has already processed.

Caching works on prefixes, so the order of your prompt determines whether it works at all. The pattern that pays:

1. 01Put everything stable at the very top: system instructions, policy text, tool and function schemas, few-shot examples, and any fixed reference material.
2. 02Put everything volatile at the bottom: retrieved chunks, the current user turn, timestamps, session identifiers, and personalisation.
3. 03Never edit earlier messages mid-conversation. A single character changed near the top invalidates the whole prefix and resets you to full price.
4. 04Keep a consistent cache key across turns of the same conversation so requests route to the same cached prefix.
5. 05Instrument cached_tokens as a first-class metric next to latency and error rate, and alert when the hit rate falls.

The arithmetic is worth stating plainly. A support assistant on Grok 4.5 with a 4,000 token system prompt and 40,000 requests a month spends 160 million input tokens on that prompt alone. At $2.00 per million that is $320. At the cached rate of $0.30 it is $48. Same product, same model, same answers, $272 a month recovered from prompt ordering. Scale that to an agent that replays a long tool schema on every step and the difference becomes the largest single line item in the account.

Server-side tools, agents, and why costs scale non-linearly

When a request uses xAI's server-side tools, billing has two components: the tokens consumed and the tool invocations themselves. Because the model decides autonomously how many tool calls a task needs, cost scales with query complexity rather than with query count. Two users asking questions of the same length can produce bills that differ by an order of magnitude.

Agentic loops amplify this in a specific way. Each step of a loop resends the accumulated conversation, so input grows roughly quadratically with step count while output grows linearly. A ten-step agent does not cost ten times a single call. In our modelling it typically lands between fifteen and thirty times, depending on how much of the prefix stays cacheable and how much reasoning the model does per step.

• Cap the loop. Set a maximum step count and a maximum token budget per task, and fail loudly rather than silently spending.
• Summarise instead of accumulating. Replace the raw transcript with a compact state object once a conversation passes a threshold.
• Route by difficulty. Send classification, routing, and extraction to a cheaper tier and reserve the flagship for the steps that actually need it.
• Trim tool schemas. Every tool definition is billed input on every step. Ten unused tools in the schema are a permanent tax.

Three worked cost examples

Abstract rates are hard to reason about, so here are three workloads modelled end to end on Grok 4.5 list pricing. Each assumes a 30-day month and no volume discount.

Customer support assistant, 40,000 conversations a month

Assume a 4,000 token system prompt, 1,500 tokens of retrieved help-centre context, a 200 token question, and a 350 token answer. Without caching, input is 5,700 tokens per conversation, or 228 million a month, at $2.00 per million: $456. Output is 14 million tokens at $6.00: $84. Monthly total: roughly $540. With the system prompt cached, 160 million of those input tokens shift to $0.30 per million, taking input to about $184 and the monthly total to roughly $268. The caching change alone cuts the bill by half.

Document analysis, 5,000 long documents a month

Assume 120,000 tokens of document per request and a 3,000 token structured summary. Input is 600 million tokens at $2.00: $1,200. Output is 15 million at $6.00: $90. Monthly total: roughly $1,290. Now assume the ingestion pipeline gets sloppier and average prompt size rises to 210,000 tokens. Input becomes 1,050 million tokens at the long-context rate of $4.00: $4,200, and output moves to $12.00 per million: $180. The bill goes from about $1,290 to about $4,380 for a 75 percent increase in document length. This is the single most important non-linearity in xAI's pricing model.

Internal research agent, 2,000 tasks a month

Assume eight steps per task, a 6,000 token tool schema, an average 3,000 tokens of accumulated context per step, and 800 output tokens per step including reasoning. Input per task is roughly 72,000 tokens, or 144 million a month, at $2.00: $288. Output is 12.8 million tokens at $6.00: $77. Monthly total: roughly $365, of which the tool schema alone accounts for 96 million input tokens. Cache the schema and that component drops from $192 to about $29. The agent is cheap, but only because the expensive part was made cacheable.

How Grok compares with other providers

Comparing providers on headline rate alone produces bad decisions, because the meters differ. A model with a lower input rate and a higher output multiple can be more expensive for a summarisation workload and cheaper for a classification workload. The only comparison that survives contact with an invoice is a per-request unit cost computed on your actual input and output mix.

Three variables decide the outcome for most teams. Your input-to-output ratio, which determines how much the output multiple matters. Your cache hit rate, which determines what fraction of input you pay full price for. And your prompt size distribution, which determines whether you trip a long-context tier. Fix those three numbers for your workload, then compare. The model comparison tool runs that calculation across providers, and the API cost calculator does the same for a single workload if you want to see the arithmetic step by step.

One further caution on cross-provider maths: tokenisers differ. The same document does not produce the same token count across vendors, and differences of five to fifteen percent are normal. When you migrate, remeasure on a sample of your real traffic instead of assuming your existing counts transfer.

A practical checklist for reducing Grok API spend

In order of typical return, from largest to smallest:

1. 01Restructure prompts so the stable prefix sits first, then verify a rising cached_tokens value in the response. This is usually the largest single saving and requires no model change.
2. 02Cap output length deliberately. Output is the expensive meter, and most applications ask for more words than the interface can display.
3. 03Set a hard context budget below the long-context threshold, with headroom, and monitor the tail of your prompt size distribution rather than the mean.
4. 04Route by task difficulty so that only the steps needing frontier reasoning reach the frontier tier.
5. 05Prune tool schemas and few-shot examples that no longer earn their token cost.
6. 06Deduplicate retrieval results. Overlapping chunks are a common and invisible source of input inflation.
7. 07Batch anything latency-tolerant, and check whether your provider offers a discounted asynchronous path for it.
8. 08Track cost per successful outcome, not cost per call. A cheaper model that fails a third of the time and triggers a retry is not cheaper.

That last point deserves emphasis because it is where most cost programmes go wrong. Teams optimise the unit price of a call and then quietly pay for the retries, the escalations, and the human review that a weaker model creates. If you are building the business case rather than the infrastructure, model it end to end with the ROI calculator.

What to monitor after launch

Cost control is an operational discipline rather than a launch-day decision. Four metrics catch nearly every regression we have seen in production systems:

• Cost per request, tracked as a distribution. The mean hides the expensive tail, and the tail is what breaks budgets.
• Cache hit rate. A silent drop after a deployment usually means someone added a timestamp or a session ID near the top of the prompt.
• Share of requests crossing the long-context tier. This should be close to zero and should be alerted on.
• Reasoning token share of output. A model or parameter change that increases thinking length raises cost without changing a single visible word.

Log token counts from the usage object on every response and store them alongside your application metrics. Provider dashboards tell you what you spent. Your own logs tell you which feature, which customer, and which prompt version spent it, and only the second view lets you act.

What the numbers mean for your budget

Grok sits in a competitive position on list price, particularly on the mid tier where a one million token context is available at $1.25 input and $2.50 output. But list price is not the variable that decides your invoice. Prompt structure, context discipline, and output length routinely move real-world spend by two to five times on identical traffic and identical models. Teams that treat those three as engineering constraints run cheaply on almost any provider. Teams that treat pricing as a procurement decision get surprised on almost any provider.

Rates change, sometimes without announcement. Verify against xAI's own documentation before you commit a budget, and re-check the models you depend on when aliases shift. Every figure on this page is dated, sourced, and updated when the underlying documentation changes.