Grok API Pricing 2026: Token Costs, Tool Fees and How to Cut Them

Grok’s API pricing looks simple at first: pick a model, pay for the tokens you use. But the real cost depends on more than the headline rate. Long prompts can push requests into a higher pricing tier, agentic workflows can add separate tool-call fees, and model choice, caching, and context management can materially change what you pay.

This guide breaks down Grok API pricing in 2026, including token rates, tool charges, worked examples, and the biggest levers for reducing costs.

Grok API Pricing at a Glance (2026)

The Grok API is billed per token, not per seat. The current flagship, Grok 4.6, costs $2.00 per million input tokens, $0.50 per million cached input tokens, and $6.00 per million output tokens for prompts under 200,000 tokens. Cross that threshold and the entire request — not just the overage — is billed at double those rates: $4.00 / $1.00 / $12.00 per million. On top of tokens, xAI charges separately for the server-side tools that make Grok agentic: Web Search, X Search, and Code Execution each run $5.00 per 1,000 calls, with File Attachments search at $10.00 and Collections Search (RAG) at $2.50 per 1,000 calls. That second charge is the one most cost estimates leave out, and it's often the difference between a bill that matches expectations and one that doesn't.

How xAI Charges for Grok

Per-token input and output pricing by model

xAI prices four active model tiers:

• Grok 4.6 (flagship, released Aug 12, 2026) — $2.00/M input, $0.50/M cached input, $6.00/M output, 500K-token context. The default recommendation for both general use and coding.
• Grok 4.5 — same standard rates as 4.6, but a lower cached-input price of $0.30/M.
• Grok 4.3 & the Grok 4.20 family — the value tier: $1.25/M input, $2.50/M output, 1M-token context. The right default when a task doesn't need flagship-level reasoning.
• Grok Build 0.1 (coding-specific) — the cheapest tier: $1.00/M input, $2.00/M output, 256K-token context.

Legacy model names — Grok 4, Grok 4 Fast, Grok 4.1 Fast, Grok 3, Grok 3 Mini — now route to Grok 4.3, so older integrations still work but bill at current Grok 4.3 rates. A separate Priority Processing tier runs 2x standard token prices and only bills when a response confirms "service_tier": "priority".

The tier that matters most for cost isn't the cheapest one — it's whichever one a team defaults to without testing the alternative. Grok 4.6 is the model xAI names as the default recommendation, which means it's also the tier most workloads land on by default even when a task never needed flagship-level reasoning. At 60% more on input and 2.4x more on output than Grok 4.3, that default costs real money across a high-volume integration. The cheaper tiers are worth benchmarking against actual output quality before assuming the flagship is required, rather than treating model choice as a one-time decision made at launch and never revisited.

There's a second lever inside model choice that the headline per-token rate doesn't show: reasoning effort. Grok's reasoning models accept a configurable reasoning_effort parameter, and turning it up doesn't change the per-token rate — it changes how many tokens the model spends thinking before it answers. Those reasoning tokens are generated and billed the same as any other output token, so a request run at high reasoning effort can cost several times what the same prompt costs at low effort, even though the rate card never changes. A workload that defaults to maximum reasoning effort on every request is paying for depth it may not need on simple queries; effort should scale with how hard the task actually is, not sit fixed at one setting for everything that comes through.

Context window and how long contexts change effective cost

The detail most pricing pages gloss over: cross 200,000 tokens in a prompt and xAI doesn't bill just the overage at a higher rate — it bills the entire request, from the first token, at the doubled rate.

200,000 tokens is roughly 150,000 words, or about a 500-page book — more context than a single chat exchange or short document review will ever touch. It's a realistic ceiling for large-codebase analysis, long document sets fed in at once, or a chat session whose history gets resent in full on every turn rather than summarized. Teams doing any of those three should expect to brush against the threshold; teams doing typical single-document or short-conversation work won't come near it regardless of model choice.

Example: a 210,000-token prompt to Grok 4.6 isn't 200,000 tokens at $2.00/M plus 10,000 at $4.00/M. The whole 210,000 tokens bill at $4.00/M input, with cached input and output doubling along with it — a request just 5% over the line costs roughly double what a request just under it would.

For teams running large-document analysis, long chat histories, or big codebases through the API, staying just under that line — by trimming context, summarizing history, or splitting a request in two — is a bigger cost lever than switching models.

This threshold is easier to cross than it looks in a multi-turn conversation, because the API itself is stateless: unless a request uses xAI's own conversation-persistence features, each new turn resends the full prior history as input tokens, not just the new message. A support chatbot or coding agent that's exchanged 40 or 50 messages can be resending a six-figure token count on every single turn from that point forward — which means once a long-running conversation crosses 200,000 tokens, every subsequent turn in that same conversation bills at the doubled rate, not just the one that crossed the line. Summarizing or truncating history as a conversation grows isn't just a nice-to-have here; it's what keeps a long-running session from silently doubling its per-turn cost partway through.

Prompt caching and where it applies

Cached input runs well below standard input pricing:

• Grok 4.6: $0.50/M — a 75% discount off the $2.00 standard rate
• Grok 4.5: $0.30/M
• Grok 4.3 & the 4.20 family: $0.20/M
• Grok Build 0.1: $0.20/M standard cached rate; cache-read pricing is the cheapest in the lineup at roughly $0.02/M on some published rate cards

Caching pays off most on workloads that resend the same content repeatedly in a short window — a system prompt reused across many requests, a codebase an agent references turn after turn, a long support-ticket history a chatbot keeps re-reading. The discount only applies to tokens that actually hit the cache, so real savings depend on how much of a given prompt is genuinely repeated rather than newly generated each call.

Caching and model selection are often framed as competing levers, but they solve different problems and the choice between them depends on what's driving the bill. A workload with a large, static, reused prefix — a long system prompt, a knowledge base injected on every call — gets more out of caching than out of downgrading models, since the discount applies regardless of which tier is running. A workload where the prompt changes substantially on every call gets nothing from caching no matter how aggressively it's configured, and model selection or context trimming are the only levers left. Checking which situation actually describes a given workload, rather than defaulting to whichever optimization is easiest to implement, is what determines whether the effort pays off.

One practical wrinkle: xAI publishes a single reduced rate for cached tokens rather than the separate write-and-read pricing some rivals use, where a first pass into cache costs more than a normal token before later reads get cheap. That structure suggests the discount applies whenever a request has a prefix matching a prior one, without a separate paid step to populate the cache first — worth confirming against current docs before assuming it, since cache mechanics are exactly the kind of detail providers revise without much notice.

Consumer subscriptions (SuperGrok and Business tiers) vs. API access — who each is for

It's easy to conflate Grok's consumer plans with API pricing, but they're different products aimed at different buyers. Individual consumer access runs across six tiers on two purchase paths:

• grok.com: Free, SuperGrok Lite (~$10/month), SuperGrok (~$30/month), SuperGrok Plus (~$100/month), SuperGrok Heavy (~$300/month)
• X: X Premium (~$8/month), X Premium+ (~$40/month)

The free tier runs on Grok 4.3 through a shared weekly usage pool, with web and X search and basic voice — it doesn't include the flagship model, DeepSearch, Big Brain mode, or image generation. SuperGrok ($30/month) is the tier most individual professionals land on: it adds the newest models, higher limits, DeepSearch, Big Brain mode, and a larger context window. SuperGrok Heavy ($300/month) adds Grok 4 Heavy, xAI's multi-agent tier aimed at intensive research and financial-modeling use cases rather than everyday chat. As of June 2026, the old per-two-hour prompt caps are gone; paid plans draw from one shared weekly usage pool spendable across Chat, Imagine, Voice, and Build.

Above the individual tiers, xAI sells two organizational plans separate from both SuperGrok and the API:

• Grok Business (~$30/seat/month): self-serve, aimed at teams that need shared access and admin controls — SOC 2 Type II, role-based access control, consolidated billing, and a default guarantee that customer data isn't used to train xAI's models.
• Grok Enterprise (custom pricing, sales-led): layers on custom single sign-on, SCIM directory sync, and Enterprise Vault, a dedicated data plane with customer-managed encryption keys for teams with stricter data-isolation requirements.

None of that is how the API works. The API has no seat, no subscription, and no usage pool to budget against — it's pay-per-token plus per-call tool fees, metered per request rather than per user. That's what makes it the only option for embedding Grok into a product rather than giving a team a chat interface. A company might reasonably run more than one of these at once: Business seats for staff who chat with Grok directly, and the API for whatever product actually calls Grok programmatically.

The Server-Side Tool Charges Most Teams Miss

Among the major model providers, xAI is unusual in billing its built-in tools as a separate line item from tokens. When a Grok request uses Web Search, X Search, Code Execution, File Attachments search, or Collections Search, that invocation carries its own per-call charge on top of whatever tokens the request consumes — and the content those tools retrieve then flows back into the model as billed input tokens as well. The model, not the developer, decides how many tool calls a given query needs.

What each tool costs per call

• Web Search: $5.00 per 1,000 calls
• X Search: $5.00 per 1,000 calls today — repricing Sept 21, 2026 (see below)
• Code Execution: $5.00 per 1,000 calls
• File Attachments search: $10.00 per 1,000 calls
• Collections Search (RAG): $2.50 per 1,000 calls — the cheapest of the built-in tools

Storage for files and collections is billed separately: $0.025/GiB/day for file storage, $0.10/GiB/day for collection (vector) storage, and $0.20/GiB for downloads.

File Attachments search and Collections Search sound similar but serve different jobs. File Attachments search queries documents uploaded directly to a specific request or thread — the ad hoc case of "here's a file, answer questions about it." Collections Search queries a persistent, pre-indexed collection stored on xAI's platform ahead of time — the RAG case of a standing knowledge base a request draws from without re-uploading anything. That's also why they're priced differently: Collections Search assumes content that's already been indexed once and queried many times, so the marginal per-call cost is lower; File Attachments search assumes content specific to that request, with less reuse to amortize the cost across.

X Search pricing is changing: effective September 21, 2026, xAI moves from a flat $5-per-1,000-calls rate to $5 per 1,000 posts fetched plus $10 per 1,000 user profiles fetched. Every post returned by a search or thread fetch — including parent and quoted posts — counts toward the total, as does every profile returned by a user search. Workloads that pull long threads or do heavy profile lookups should expect this to move their X Search costs more than the headline rate suggests.

How agentic loops multiply tool invocations

xAI's agentic tool calling runs the reasoning-and-tool-execution loop entirely on its own servers. Given a query and a set of enabled tools, Grok decides at runtime how many searches to run, whether to execute code, and when it has enough information to answer — that decision isn't fixed per request, and by default the server applies its own cap on how many rounds it will run before returning an answer.

Developers aren't stuck with that default, though. The API's max_turns parameter caps the number of assistant/tool-call rounds a single agentic request can run — set it to 3, and Grok stops calling tools and returns a final answer based on whatever it's gathered by then, even if it would otherwise have kept searching. xAI doesn't publish the exact value of the default cap that applies when max_turns is left unset, which is itself a reason to set it explicitly rather than trust an undocumented ceiling: an unknown default is an unknown cost ceiling per request. max_turns is a direct lever for limiting how long an agentic request can keep searching, although it does not set a hard ceiling on individual tool calls because Grok can invoke multiple tools within a single turn.

Why tool spend can exceed token spend on agent workloads

The mechanism is compounding, not substitution: a tool call is billed once as an invocation, and its results are billed again once they land in the prompt as input tokens on the next model call. Neither charge is discounted or bundled — retrieved content is billed at the same standard input rate as anything else in the request, and the invocation fee applies whether the call turns out to be useful or not.

What pushes a workload from tool fees being a rounding error to tool fees being the majority of the bill is the ratio of tool calls to actual output, not the total volume of either alone. A single-search Q&A bot rarely notices tool costs, because one $0.005 search sits underneath a few hundred tokens of response. A multi-hop research agent that runs three or four searches, reads through each result, and only then writes a short final answer inverts that ratio: the tool calls and the content they retrieve dominate the request, and the final answer — the only part that reads as useful output — is comparatively small next to everything spent getting there. Code-heavy agentic loops behave the same way: a debug-run-read-error-adjust-rerun cycle can rack up several Code Execution charges before it produces one corrected file.

Research-heavy, multi-hop queries and debug-and-rerun coding loops are the two patterns most likely to invert the normal ratio and push tool fees above token fees, for exactly the reason above: many calls, comparatively little final output per call. The worked examples below show that shift directly, moving from negligible tool spend on a single-lookup workload to tool spend that outweighs tokens on a heavier agentic one.

Controlling and capping tool usage

A few practical levers keep tool spend predictable:

• Scope tools per request — only enable the specific tools a given request actually needs. A request that doesn't need X Search shouldn't have it available to call at all; every enabled tool is a call the model might decide to make.
• Reach for the cheaper tool when it fits — Collections Search (RAG) costs $2.50 per 1,000 calls versus $5.00 for Web Search. For queries answerable from content you've already stored in an xAI collection, routing there instead of out to the open web cuts the per-call cost in half.
• Cap turns with max_turns — the API's max_turns parameter caps how many assistant/tool-call rounds an agentic request can run before it must return a final answer. Set it explicitly rather than relying on the server's default ceiling, and size it to the task — a simple lookup rarely needs more than one or two turns.
• Tag tool calls for attribution — logging which feature, team, or customer triggered a given tool invocation makes it possible to trace a spend spike back to its source instead of discovering it only at the monthly bill.
• Monitor tool calls separately from tokens — a spike in tool invocations with flat token volume is a distinct anomaly signal from a spike in tokens, one that a token-only dashboard won't surface.

Grok vs GPT vs Claude on Price

Comparing across providers means picking roughly comparable tiers rather than matching model names, since each provider names its tiers differently. Grouped by capability level, current per-million-token rates (standard, short-context) are:

Rates shown are input/output per million tokens. OpenAI's newest model, GPT-6 Astra, has since launched above the GPT-5.6 family at $10.00/$50.00 per million; GPT-5.6 Sol remains available and is the closer capability match to Grok 4.6 and Claude Opus 5 here. All three providers' prices change frequently — confirm current rates at docs.x.ai, platform.openai.com, and platform.claude.com before publishing.

Raw per-token price is a starting point, not the full picture. Output verbosity (how many tokens a model uses to answer), tool-call charges, and how often a model needs a retry to get a usable answer all move effective cost — a cheaper-per-token model that needs more tokens or more tool calls to reach the same result can cost more in practice than the sticker price suggests.

Where Grok is genuinely cheaper

On the table above, Grok 4.6 undercuts both GPT-5.6 Sol and Claude Opus 5 on input, and beats both on output ($6.00 vs. $20.00 and $25.00 respectively). Grok's output-to-input ratio — 3x on the flagship tier — is also lower than the 5x ratio of the rival flagships, which matters most for workloads that generate long responses: reports, long-form drafts, detailed code output.

At volume, that gap is real money rather than a rate-card curiosity: a workload generating 10 million output tokens a month costs about $60 on Grok 4.6, versus about $200 on GPT-5.6 Sol and about $250 on Claude Opus 5 — a roughly 3–4x difference that compounds every month it runs.The advantage is largest specifically for output-heavy workloads; a workload dominated by input tokens (large documents, long retrieved context) sees a smaller gap, since Grok's input rate ($2.00) sits closer to Opus 5's ($5.00) than its output rate does.

Where the tool charges erase the advantage

It's tempting to assume Grok's per-call tool fees are the hidden cost that closes this gap, but on a direct comparison they don't — xAI's tool pricing is competitive with the other two providers, not worse. OpenAI charges $10 per 1,000 calls for its Web Search tool (with search-content tokens billed at the model's standard rate on top), and Claude's Web Search tool is also $10 per 1,000 searches plus token costs. Grok's Web Search, at $5 per 1,000 calls, is half the price of both.

Code execution is where the billing models genuinely diverge rather than just the price. OpenAI and Claude both meter code execution by container time — OpenAI's containers run $0.03 to $1.92 per session depending on size, billed by the minute with a 5-minute minimum; Grok instead charges a flat $5 per 1,000 calls regardless of how long the code runs. That favors Grok for many short, quick executions and favors the container model for one long-running session — which one wins depends on the workload's shape, not on either provider's price being categorically higher.

The place the token-price advantage can genuinely erode is efficiency, not sticker price: if Grok's agent needs more tool calls or more retrieved content to reach the same answer quality that a GPT or Claude agent reaches in fewer, the accumulated fees can close the gap regardless of any single tool's unit price. That's a question about how each model behaves on a given task, and it's worth testing on a representative workload rather than assuming from the rate card alone.

Worked Cost Examples

Three workloads, costed end to end at current rates, to show where tool charges actually land.

• Chat feature (tokens only, Grok 4.3): 30,000 requests/month, ~500 input and 300 output tokens per request. Input: 15M tokens × $1.25/M = $18.75. Output: 9M tokens × $2.50/M = $22.50. Total: ~$41/month — no tool calls, so token price alone is the full story here.
• RAG application (Grok 4.6 + Collections Search): 10,000 queries/month, each with one Collections Search call and ~500 input / 200 output tokens (prompt plus retrieved content). Tokens: (5M × $2.00/M) + (2M × $6.00/M) = $10 + $12 = $22. Tool calls: 10,000 ÷ 1,000 × $2.50 = $25. Total: ~$47/month — the tool fee is over half the bill.
• Agentic pipeline (Grok 4.6, heavy tool use): 5,000 complex queries/month, averaging 4 tool calls each (3 Web Search + 1 Code Execution) and ~3,000 input / 800 output tokens (larger due to retrieved content). Tool calls: 20,000 ÷ 1,000 × $5.00 = $100. Tokens: (15M × $2.00/M) + (4M × $6.00/M) = $30 + $24 = $54. Total: ~$154/month — tool spend ($100) outweighs token spend ($54) on this workload.

The pattern across all three: as tool usage rises relative to token volume, tool fees go from negligible to the majority of the bill. Modeling a Grok workload on token price alone systematically understates cost once tools are involved.

The assumptions above are illustrative — the way to get real numbers for a specific workload is to pull them from what's already running rather than guess. Request and response logs (or xAI's own usage dashboard) give actual average input and output token counts per request; the same logs, filtered to agentic requests, give the actual average number of tool calls per query and their type breakdown. Running the same arithmetic used above against those real averages, instead of the assumed ones, turns this from a general illustration into an actual budget line — and it's worth rerunning periodically, since both token volume and tool-call patterns shift as a product's usage changes.

How to Reduce Grok API Costs

These five levers aren't equally sized, and treating them as a checklist to apply evenly is itself a way to waste effort. For most teams, the biggest number by far is whichever one addresses how the bill actually got large in the first place — and that's usually model selection or context length, not caching or batching. A team defaulting every request to Grok 4.6 with an uncapped chat history is leaving more on the table than a team on the right model that hasn't yet enabled caching. Diagnose which lever matches the actual shape of the spend before investing engineering time in the others.

Model selection: route simple tasks to cheaper models

Not every request needs Grok 4.6. Route coding-specific tasks to Grok Build 0.1 ($1.00/$2.00), and general tasks that don't need flagship-level reasoning to Grok 4.3 or the 4.20 family ($1.25/$2.50) — reserve the flagship for requests that actually need its reasoning quality, since it costs 60% more on input and 2.4x more on output than the value tier. This is usually the highest-leverage change available, precisely because it requires no architecture change — just routing logic and a benchmark showing the cheaper tier holds up on the task.

The practical way to make that call isn't a one-time architectural decision, it's an ongoing benchmark: take a representative sample of real production requests, run them through both the current tier and a cheaper candidate, and compare output quality on the actual downstream task — a model's general reasoning score doesn't tell you whether it's good enough for this specific classification, extraction, or formatting job. Tasks that tend to tolerate a cheaper tier well: classification, extraction, formatting, short factual lookups, anything with a narrow and checkable output. Tasks that tend to need the flagship: open-ended reasoning, multi-step planning, and anything where a wrong answer is expensive enough that quality matters more than the token-price gap. Where the cheaper tier holds up on the sample, route production traffic there and keep the flagship as a fallback for requests the cheaper model flags as low-confidence or fails outright — capturing most of the savings without betting the whole workload on a single model choice.

Prompt and context optimization

Stay under the 200,000-token context threshold wherever possible. Trimming unnecessary context, summarizing long chat history instead of resending it in full, and splitting an oversized request into two smaller ones can each keep a request off the doubled-rate tier — a bigger lever than model choice for context-heavy workloads specifically, since crossing the line doubles the bill regardless of which model is running.

A few concrete techniques get a workload there. Summarize conversation history into a running digest instead of resending every prior turn verbatim — keep the last few turns in full and compress everything older, rather than letting a session grow unbounded until it silently crosses the threshold mid-conversation. Retrieve only the relevant slice of a large document or codebase for a given question rather than sending the whole thing on every call — the same access pattern Collections Search is built for, and one that applies just as well to context assembled client-side. For codebases specifically, sending only the files relevant to the current task rather than the whole repository does the same job a human reviewer does naturally: reading the two files that matter instead of every file that exists.

Caching strategies

Structure requests so repeated content — system prompts, reference documents, a codebase an agent reuses across turns — sits in the portion of the prompt that gets cached, since cached input runs 75–85% below standard rates depending on model. This is the highest-leverage lever specifically for workloads with a large, static, reused prefix; it does nothing for workloads where the prompt is different every call, so confirm the workload actually has repeated content before investing in cache structuring.

The structuring matters as much as the decision to cache. Put the static, reused material first in the prompt and the request-specific, always-different material last, since a cache hit generally depends on the leading portion of a prompt matching a prior request exactly — a single word changed early in the prompt can invalidate the match for everything after it, even when the rest is identical. That means a system prompt with today's date baked into it, or a reference document reformatted slightly between calls, quietly breaks caching without any error being raised anywhere. Keeping the cached prefix genuinely static — same wording, same order, same formatting, call after call — is what turns the discount from theoretical into real.

Capping and budgeting tool invocations

The techniques for controlling which tools fire and how often are covered above under Controlling and capping tool usage. What's still missing for most teams isn't another technique, it's an actual number to enforce those techniques against — a dollar or call-count ceiling per day, per feature, or per customer, checked against real usage rather than assumed. Without a number to check against, having scoped the tools and set max_turns are directional improvements with no way to know whether they're enough. A workable version doesn't need to be sophisticated: a daily count of tool invocations by type, compared against the volume the worked-example math above implies is reasonable for the traffic level, catches a runaway pattern — a feature suddenly averaging six tool calls a request instead of two — well before it turns into a surprise on the monthly bill.

Batching and request consolidation

Consolidating multiple small requests into fewer, larger ones reduces the fixed overhead (system prompts, repeated context) paid on every call. xAI offers a 20% Batch API discount for Grok 4.3 and the 4.20 family. Batch support varies by model; Grok 4.6, for example, does not currently support the Batch API. Request consolidation is still worth doing on its own merits, though it’s typically the smallest of the five levers unless per-request overhead is unusually large relative to the useful content in each call.

In practice, this usually means restructuring a loop that sends one request per item — one call per support ticket, one call per spreadsheet row — into a single request that processes a batch of items together. Each individual call pays the same fixed prompt overhead regardless of how much or how little useful work it does, so a job processing 500 short items one at a time pays that overhead 500 times; grouped into batches of 20, it pays it 25 times instead, with the per-item token cost essentially unchanged.

For general cost-optimization techniques that apply across providers, see LLM cost optimization tips.

Tracking Grok Spend Alongside Your Other AI Costs

Everything above is enough to model and control what a single Grok integration costs on its own. Most organizations running Grok in production aren't running it alone, though — it sits next to at least one other model provider, and the two-part billing structure covered above (tokens plus per-call tools) is specific enough to Grok that a generic multi-provider cost view can miss it entirely if it isn't built to account for tool invocations as their own line item.

Why single-provider dashboards break once you are multi-model

xAI's console shows Grok usage; it doesn't show what the same team is spending on GPT, Claude, or Gemini elsewhere in the stack. Most teams running Grok in production are running it alongside at least one other provider, and a per-provider dashboard can't answer the question that actually matters: what is AI costing us in total, and where.

The practical failure shows up in exactly the situations where it matters most. A team deciding whether to move a workload from GPT to Grok has no single view showing what that workload costs today, next to what it would cost on Grok including tool fees — so the decision gets made on a rate-card comparison instead of real, comparable usage data. And a spend increase that's actually a Grok tool-fee spike looks, from the finance side, identical to a token-price increase on any other provider, unless the underlying view is granular enough to separate them — which a console built around a single provider's own billing model was never designed to do.

Attributing Grok spend to teams, apps and environments

Grok's billing is metered per request, not per team or app, so attribution depends on tagging calls at the point of use — by feature, environment, or customer — and rolling that up into a cost-allocation view. Without that tagging, a spend increase is visible in the aggregate bill long before anyone can say which product or team drove it.

That tagging has to happen in the calling application, not on xAI's end: passing a consistent identifier — a feature name, customer ID, or environment label — alongside each request, logging it against the tokens and tool calls that request generated, and rolling those logs up into a per-tag total. It's straightforward to build once, but it has to be built deliberately; nothing about Grok's own billing does this automatically, so a team that skips it at launch finds out which feature drove a spend spike by process of elimination instead of by looking it up.

Anomaly alerts on token and tool usage

Grok's split billing model means token volume and tool-call volume can move independently — a spike in one with the other flat is a distinct signal worth alerting on separately, not just a total-spend threshold. A total-spend alert set at some percentage above baseline fires the same way whether the cause is a token-volume increase (more requests, longer prompts) or a tool-call increase (the model deciding to search more per query) — but the fix for each is different, so an alert that can't distinguish them tells you something changed without telling you what to do about it.

Splitting the two into separate thresholds — one on tokens, one on tool-call count — turns a generic spend-is-up alert into a diagnosis: a token spike with flat tool calls points at request volume or prompt length; a tool-call spike with flat tokens points at the model's own behavior shifting, or at max_turns being left unset somewhere it should be capped.

Related reading: GenAI cost attribution, FinOps tools for AI, and AI cost anomaly detection.

Understand & optimize your AI costs with nOps

Getting Grok API costs under control isn't really about any single optimization — it's about having accurate, ongoing visibility into what tokens, tool calls, and model choices are actually costing you across every workload.

nOps helps teams understand and optimize cloud and AI infrastructure costs across AWS, GCP, and Azure — so they can see what’s driving spend, allocate costs to the teams and workloads responsible, and identify opportunities to reduce waste.

• Unified visibility: Understand cloud and AI infrastructure spend across teams, applications, customers, and business units with granular cost allocation.
• Commitment Management: Automatically maximize discounts and minimize commitment risk across eligible cloud infrastructure supporting your AI workloads. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.

nOps manages $5B+ in cloud spend and was recently rated #1 in G2's Cloud Cost Management category. Get a free savings analysis to see where your cloud and AI infrastructure costs can be optimized.

FAQ Section

How much does the Grok API cost?

It depends on the model: Grok 4.6 (flagship) runs $2.00/M input and $6.00/M output; Grok 4.3 and the 4.20 family run $1.25/M and $2.50/M; Grok Build 0.1 (coding) runs $1.00/M and $2.00/M. All three double once a prompt crosses 200,000 tokens. On top of tokens, any Web Search, X Search, or Code Execution calls add $5.00 per 1,000 invocations.

How is Grok API pricing calculated?

Each request bills for its input tokens and output tokens separately, at the active model's per-million rate, plus a per-call fee for any server-side tool it invokes. A request that stays under 200,000 tokens and uses no tools is priced on tokens alone; anything that crosses that threshold or calls a tool adds the corresponding surcharge or fee on top.

What are Grok's server-side tool charges?

Web Search, X Search, and Code Execution are each $5.00 per 1,000 calls; File Attachments search is $10.00 per 1,000 calls; Collections Search (RAG) is $2.50 per 1,000 calls. These are billed per invocation, separately from whatever tokens the request also consumes — including the tokens the tool's own results add to the prompt.

Is Grok cheaper than GPT or Claude?

On raw per-token price, Grok 4.6 undercuts comparable flagship tiers from both OpenAI and Anthropic, especially on output tokens. That advantage can narrow or disappear on tool-heavy agentic workloads, where accumulated per-call tool fees matter more than the underlying token rate — and where the model's own efficiency at resolving a query in fewer calls matters more than any single tool's list price.

What is the difference between SuperGrok and the Grok API?

SuperGrok is a consumer subscription for chatting with Grok directly, priced per seat per month with a shared usage pool. The API is a separate, pay-per-token product with no seat and no subscription, built for embedding Grok into an application. Teams need the API regardless of which consumer or Business plan, if any, their staff also use.

Does Grok offer prompt caching discounts?

Yes — cached input runs 75–85% below standard input pricing depending on the model (e.g., $0.50/M on Grok 4.6 versus its $2.00/M standard rate). The discount only applies to tokens that actually hit the cache, so it benefits requests with a large, repeated prefix — a reused system prompt or knowledge block — far more than requests where the prompt changes every call.

How do I reduce Grok API costs?

The two highest-impact levers are usually routing requests to the cheapest model tier that still meets quality requirements, and keeping prompts under the 200,000-token threshold that doubles the entire request's rate. Caching helps specifically when a prompt has a large reused prefix; limiting agent turns with max_turns and preferring cheaper tools helps specifically on agentic workloads; request consolidation is a smaller, secondary lever on top of those.

How do I track Grok spend alongside my other AI costs?

xAI's own console only shows Grok usage, so teams running more than one model provider need a cost view built to sit above all of them — one that tags Grok spend by team, app, or environment, and that treats Grok's tool-invocation volume as its own metric worth alerting on separately from token volume, since the two can spike independently.