n4nAI

Grok 4 performance benchmark: cost per million tokens

A practitioner's analysis of Grok 4 cost per million tokens: how pricing structure, caching, and output ratio drive real LLM inference economics.

n4n Team6 min read1,225 words

Audio narration

Coming soon — every post will get a voice note here.

Grok 4 cost per million tokens is the headline number most teams latch onto when evaluating xAI’s flagship model, but that figure hides the operational reality of inference spend. The published input and output rates are only the start; effective price depends on cache reuse, batching, and the shape of your traffic. This analysis breaks down where the money actually goes and how to engineer around it.

Pricing anatomy of Grok 4

xAI bills LLM usage by token counts, split into three buckets: fresh input tokens, cached input tokens, and generated output tokens. The cached bucket is cheaper because the provider avoids recomputing the prefix attention state. Output tokens cost multiples of input tokens, a pattern consistent across frontier models from OpenAI, Anthropic, and Google.

The exact ratio shifts as xAI adjusts its rate card, but the structural truth holds: you pay a premium for every token the model emits. Grok 4 cost per million tokens therefore cannot be summarized by a single scalar posted on a pricing page.

Input versus cached input

A fresh input token is billed at the standard rate. If the same prefix appears in a later request and the provider still has it in cache, those tokens fall into the cached tier at a discount. The discount is not trivial; typical cached pricing lands at 25% of fresh input cost for ephemeral caches.

Output pricing

Output tokens are the most expensive. Frontier models price generation at 3–5x the fresh input rate. Grok 4 follows this convention. The model’s tendency to reason at length makes output the dominant cost driver for interactive apps.

Calculating effective Grok 4 cost per million tokens

Treat cost as a weighted sum. If you know your traffic mix, you can compute a blended rate:

def blended_cost_per_million(input_fresh, input_cached, output,
                             p_fresh, p_cached, p_output):
    total = input_fresh + input_cached + output
    cost = (input_fresh/1e6)*p_fresh + (input_cached/1e6)*p_cached + (output/1e6)*p_output
    return cost / (total/1e6) if total else 0.0

Plug in xAI’s current numbers for p_fresh, p_cached, p_output. The result is your real Grok 4 cost per million tokens for that workload.

A typical chat app with a 1k-token system prompt, 200-token user turn, and 500-token reply looks like this per call:

  • Fresh input: 1,200 tokens (first call only if uncached)
  • Cached input: 1,000 tokens on subsequent calls
  • Output: 500 tokens

If cached input is priced at 1/4 of fresh input, the per-call cost drops sharply after the first request in a session. The blended rate across a 10-call session might be 40% lower than the naive fresh-only calculation.

Output tokens dominate spend

Generation is where budgets blow up. Grok 4 is a strong reasoner; left unchecked it will produce long chains of thought or verbose answers. At a 1:3 input:output price ratio, a 2k-token response costs as much as 6k fresh input tokens.

Engineers often optimize the wrong thing. Trimming the system prompt from 2k to 1k tokens saves little if the model still emits 3k tokens. Constrain output with max_tokens, strict schemas, or post-generation summarization to keep the output side lean.

Reasoning traces

Grok 4’s strength in multi-step tasks comes from internal deliberation that may surface as longer outputs. If you do not need the trace, instruct the model to return only the final answer. A support bot that returns a 50-token resolution costs an order of magnitude less than one that returns a 600-token explanation with citations.

Cache reuse is the real lever

xAI supports prompt caching on repeated prefixes. If your system prompt or retrieved context is stable across requests, mark it cacheable. The gateway you route through should forward those hints.

from openai import OpenAI
client = OpenAI(base_url="https://api.n4n.ai/v1", api_key="KEY")
# n4n.ai forwards provider cache-control hints to xAI
resp = client.chat.completions.create(
    model="grok-4",
    messages=[{"role":"system","content": SYSTEM_PROMPT}],
    extra_body={"cache": {"type": "ephemeral"}}
)

When the cache hits, those prefix tokens move from the fresh input price tier to the cached tier. For high-QPS services with static instructions, this can cut Grok 4 cost per million tokens by 30–60% on the input side.

Cache lifetime tradeoffs

Ephemeral caches expire quickly; longer-lived caches may require explicit management. If your system prompt changes daily, you lose the discount on the first call after the change. Design prompts to be versioned and stable for at least hours to amortize the cache warm-up cost.

Batching and request shape

Grok 4 throughput improves with continuous batching on the provider side, but client-side batching of independent tasks still matters. If you send ten 100-token classification calls separately, you pay ten times the fixed per-request overhead in scheduling. Concatenate them into one structured request with a clear delimiter and parse the response.

{
  "model": "grok-4",
  "messages": [{"role":"user","content":"Classify each line:\nA: ...\nB: ..."}],
  "response_format": {"type": "json_object"}
}

This reduces output token overhead from repetitive boilerplate and shrinks the total request count. For offline jobs, batch 50–100 items per request bounded by the model context window.

Routing and fallback to control cost

Not every call needs frontier quality. A pragmatic architecture sends Grok 4 only for hard queries and falls back to a smaller model on rate limits or explicit low-priority tasks. An inference gateway like n4n.ai exposes one OpenAI-compatible endpoint across 240+ models and meters per-token usage, so you can switch models without client changes while preserving cache directives.

Automatic fallback also protects you when xAI is degraded. If Grok 4 returns 429s, the gateway can route to a comparable model and still report token usage for accurate billing. This keeps tail latency and spend predictable.

Tradeoffs: when Grok 4 justifies the rate

Grok 4 earns its cost when tasks need deep reasoning, tool use, or broad knowledge. For templated summarization or simple extraction, a 10x cheaper model delivers similar accuracy at a fraction of the price. Measure on your own eval set; do not trust vendor benchmarks alone.

The risk with Grok 4 cost per million tokens is treating it as fixed. If you ignore caching and output limits, your effective rate climbs well above the sticker. If you implement prefix caching and tight output schemas, you approach the lower bound of the published rate.

Comparing to peers

Without citing exact numbers, Grok 4 sits in the same price band as other frontier models. Its differentiator is reasoning quality, not price. If your workload is latency-sensitive and accuracy-tolerant, a smaller model may halve total cost of ownership even after counting extra retries.

Hidden costs beyond token price

Latency is a cost. Grok 4’s larger compute per token means higher time-to-first-token. If you run synchronous user-facing flows, slower responses increase infrastructure idle time and hurt conversion. Sometimes a cheaper, faster model reduces total cost of ownership even when token price is higher.

Logging and observability also consume engineering hours. Per-token metering helps, but you still need to attribute spend to features. Tag requests with user_id or trace_id via metadata headers if your gateway supports it.

Error rates

A model that requires three retries to produce valid JSON effectively triples its output cost. Grok 4’s instruction following is strong, but always validate responses and cache the validated prefix to avoid regenerating the same context.

A decisive takeaway

Grok 4 cost per million tokens is competitive only when you treat caching and output control as first-class concerns. Build your client to mark stable prefixes cacheable, cap max_tokens aggressively, and route non-critical traffic elsewhere. Do that, and the effective rate drops close to the cached input floor; ignore it, and you pay a premium for tokens you never needed to generate.

If you are shipping a product today, start with Grok 4 behind a gateway that supports fallback and per-token metering, instrument your mix, then dial down to cheaper models where the eval permits. That is how you keep Grok 4 cost per million tokens from becoming an excuse for a failed budget review.

Tagsgrok-4cost-per-tokenprice-performance

Written by

n4n Team

The team building n4n — a single OpenAI-compatible API in front of 240+ models, with automatic fallback, load balancing and pay-per-token metering.

More from n4n Team →

All grok performance benchmarks posts →