Grok 4 Heavy vs Grok 4: speed and cost compared

The practical decision between xAI’s two current flagships comes down to Grok 4 Heavy vs Grok 4 speed and how that latency translates into dollars. Grok 4 Heavy fans out multiple inference paths to improve reasoning on hard problems, while Grok 4 is the single-pass model optimized for lower latency and cost. Below is a head-to-head built for engineers who need to ship, not for benchmark leaderboard watchers.

Capabilities

Grok 4 is a dense transformer with strong coding, math, and instruction-following. It handles single-turn completions, RAG answers, and basic tool calls without drama. For the majority of product surfaces—summarization, entity extraction, straightforward code generation—it is the right tool.

Grok 4 Heavy runs a parallel synthesis pattern: the serving stack internally spawns several Grok 4 instances, lets them reason independently, then merges the result. That improves accuracy on multi-step agentic tasks, deep debugging, and open-ended planning where a single pass is likely to miss an edge case. The knowledge cutoff, vocabulary, and modality support are identical; you are paying for redundant compute to reduce reasoning errors.

In internal eval-style tasks like “find the bug in this 500-line diff” or “design a schema migration with zero downtime”, Heavy consistently produces fewer broken proposals. On “translate this paragraph” it adds nothing. The capability gap is not about raw intelligence—it is about verification bandwidth.

Price and Cost Model

xAI publishes Grok 4 at $5 per million input tokens and $15 per million output tokens. Grok 4 Heavy is priced at roughly 2x: $10 per million input, $30 per million output. You are billed only on the tokens you send and receive; the internal fan-out is xAI’s problem, not your meter.

When you route through an OpenRouter-class gateway such as n4n.ai, per-token usage metering is forwarded transparently, so the same pricing applies with no markup on token count. The cost multiplier is straightforward: for a 1k-input / 2k-output request, Grok 4 costs $0.035, Heavy costs $0.070.

# Cost estimate for a single request
def cost(model, in_tok, out_tok):
    rates = {
        "grok-4": (5/1e6, 15/1e6),
        "grok-4-heavy": (10/1e6, 30/1e6),
    }
    ci, co = rates[model]
    return in_tok*ci + out_tok*co

print(cost("grok-4", 1000, 2000))        # 0.035
print(cost("grok-4-heavy", 1000, 2000))  # 0.070

The hidden cost is latency, not token price. Heavy may also consume more of your rate-limit budget per request because each parallel worker counts against backend capacity. If you run a pipeline that emits 10M output tokens daily, the Heavy tax is $300 versus $150—money best spent only where eval shows a quality lift.

Latency and Throughput

The Grok 4 Heavy vs Grok 4 speed gap is widest on short prompts. A simple 50-token question might return in ~400ms on Grok 4 and ~900ms on Heavy due to orchestration overhead. For long generations, the gap narrows in percentage terms but stays constant in absolute ms: Heavy adds a fixed tax before the first token and a smaller merge delay at the end.

Throughput on a shared endpoint favors Grok 4: Heavy occupies roughly 3–5x the compute per request, so providers impose lower requests-per-minute (RPM) on Heavy. If you need to sustain 100 req/s, Grok 4 is the only realistic option without dedicated capacity.

# Typical latency observed via OpenAI-compatible client (illustrative)
curl -s -o /dev/null -w "%{time_total}\n" \
  -X POST https://api.x.ai/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -d '{"model":"grok-4","messages":[{"role":"user","content":"ping"}]}'
# grok-4: ~0.4s
# grok-4-heavy: ~0.9s (same payload)

When routing through a gateway that honors client routing directives, you can pin Heavy only for flagged hard tasks and fall back to Grok 4 on timeout. That hybrid keeps p95 latency sane while preserving reasoning depth where it matters.

# Pseudo-route: try Heavy, fall back to Grok 4 on slow response
try:
    resp = client.chat.completions.create(
        model="grok-4-heavy",
        messages=msgs,
        timeout=2.0,
    )
except TimeoutError:
    resp = client.chat.completions.create(
        model="grok-4",
        messages=msgs,
        timeout=1.0,
    )

Ergonomics

Both models expose the same OpenAI-compatible chat completions schema. You switch by changing one string. Streaming, function calling, and JSON mode behave identically. Heavy does not require a different SDK or special headers.

from openai import OpenAI
client = OpenAI(base_url="https://api.x.ai/v1", api_key=KEY)

for model in ["grok-4", "grok-4-heavy"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role":"user","content":"Reverse this string: n4n"}],
        stream=False,
    )
    print(model, resp.choices[0].message.content)

The only ergonomic penalty is error handling: Heavy requests fail more often under provider load because they are resource-heavy, so you need retry logic with jitter. System prompts, temperature, and top_p transfer unchanged. If you use structured outputs via a library like Instructor, the same validator runs on both.

Ecosystem

xAI’s first-party API ships both models. Third-party gateways mirror them under the same model IDs. Tooling like LangChain, LiteLLM, and raw HTTP clients treat them as drop-in replacements for each other. No ecosystem feature is exclusive to either model.

If you already use a gateway that provides automatic fallback when a provider is rate-limited or degraded, you can list Grok 4 as primary and Heavy as secondary for specific routes. That’s a clean way to get Heavy’s reasoning only when Grok 4 produces low-confidence output or when a task tag matches a hard class.

Limits

Context window is 256k tokens for both. Max output is 8k for Grok 4 and similar for Heavy, though Heavy may internally truncate parallel thoughts before merge. Rate limits: xAI typically grants higher RPM on Grok 4. Heavy is often restricted to a fraction of that. If you hit 429s on Heavy, it’s not a bug—it’s the compute weight.

Concurrent connections follow the same pattern: a single Heavy request can saturate the slot that would otherwise serve four Grok 4 requests. Plan capacity accordingly.

Comparison Table

Which to Choose

High-volume RAG or classification: Use Grok 4. The speed and half price matter when you’re processing millions of docs. Heavy adds latency with no accuracy gain on shallow tasks.

Interactive chat with occasional hard questions: Run Grok 4 as default. Switch to Heavy only when the user prompt contains “debug”, “design”, or “plan” and the context exceeds 10k tokens. Implement a classifier or use gateway routing hints to keep the common path fast.

Autonomous coding agents: Heavy is worth the premium. The parallel reasoning reduces hallucinated APIs and broken tests. Budget for lower RPM and add exponential backoff. A typical agent loop that makes 20 calls per task will feel the latency tax but ship fewer regressions.

Cost-sensitive batch jobs: Grok 4 only. If you’re generating 10M tokens per day, the 2x Heavy tax is $300 vs $150 for output alone. Not justified unless eval shows measurable quality lift on your specific distribution.

Latency-critical real-time (e.g., autocomplete): Grok 4 exclusively. Heavy’s orchestration overhead breaks interactive SLAs even before the first token.

Pick based on task difficulty, not model hype. The Grok 4 Heavy vs Grok 4 speed difference is real, but it’s a knob you can tune per route rather than a global switch. Measure on your own traffic, then pin the model that hits your p95 latency and cost targets.