xAI describes Grok 4.7 as its frontier model for coding, agentic tasks, and knowledge work, with a 500K-token context window. According to xAI’s current pricing page, direct API rates below 200,000 prompt tokens are $2.00 per million input tokens, $0.50 per million cached tokens, and $6.00 per million output tokens. When a prompt reaches 200,000 tokens or more, xAI lists $4.00, $1.00, and $12.00 respectively. These are xAI direct rates, not a universal price across third-party platforms.
Actual spend depends on more than the headline input rate. Fresh input, cached input, output, retries, tool calls, and the number of model calls in an agent workflow can all change the bill. The 200K prompt threshold is especially important because both xAI and CometAPI publish higher long-context rates once that boundary is reached.
This guide first establishes the xAI pricing baseline, then compares the current CometAPI Grok 4.7 listing. As of September 28, 2026, CometAPI lists $1.60 / $0.40 / $4.80 per million fresh-input, cached-input, and output tokens in the standard tier, and $3.20 / $0.80 / $9.60 in the long-context tier—20% below the corresponding xAI direct rates. The sections that follow explain how to calculate workload cost, reduce waste, and access the model through CometAPI. All prices are dated snapshots and should be rechecked before production use.
xAI Direct vs. CometAPI Grok 4.7 Pricing
xAI direct rates (USD per 1M tokens)
| Token category | Below 200K prompt tokens | Long context (≥200K) |
|---|---|---|
| Fresh input | $2.00 | $4.00 |
| Cached input | $0.50 | $1.00 |
| Output | $6.00 | $12.00 |
CometAPI rates (USD per 1M tokens)
| Token category | CometAPI: below 200K prompt tokens | CometAPI: long-context tier |
|---|---|---|
| Fresh input | $1.60 / 1M tokens | $3.20 / 1M tokens |
| Cached input | $0.40 / 1M tokens | $0.80 / 1M tokens |
| Output | $4.80 / 1M tokens | $9.60 / 1M tokens |
The 200K prompt boundary matters because both platforms currently list long-context rates at twice their standard-tier rates for Grok 4.7. This is a pricing rule set by each API platform, not a change in the model’s capability. A request becomes more expensive when an application repeatedly sends large prompts or lets agent history grow without control—not simply because Grok 4.7 supports a 500K context window.
For budgeting, treat any request projected to reach the boundary as long-context until the active billing behavior is verified. Model availability and prices can change, so production calculators should recheck both xAI direct pricing and the current CometAPI model page instead of hard-coding permanent values.
The Formula for Estimating Grok 4.7 Cost
Estimate one request by pricing each token category separately:
request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000
Then convert the request estimate into a workload estimate:
monthly cost = request cost × requests per user × active users × days in billing period
Use a realistic percentile rather than one average. A p50 estimate describes a normal request, but p95 input and output lengths expose the expensive tail that often drives the bill. For agent workflows, multiply by the expected number of model calls per completed task. A five-step workflow is five billable calls, not one.
Worked Example 1: A Support Copilot
Assume one support request sends 6,000 fresh input tokens and generates 800 output tokens. It stays below the 200K threshold and does not receive a cache discount.
- Input: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
- Output: 800 × $4.80 ÷ 1,000,000 = $0.00384
- Total: $0.01344 per request
At 100,000 requests per month, the estimated token cost is $1,344. If evaluation shows that a 400-token answer performs as well as an 800-token answer, the estimate falls to $0.01152 per request, or $1,152 per month. That single output cap saves about $192 per month, or 14.3%, without changing the model.
This is why output control deserves attention. At the listed CometAPI rate, output tokens cost three times as much as fresh input tokens in the same tier.
Worked Example 2: Reusing a Stable 20K-Token Prefix
Suppose each request contains a 20,000-token product manual, 2,000 tokens of new conversation context, and a 600-token response.
Without a cache hit, the estimate is:
- 22,000 fresh input tokens: $0.03520
- 600 output tokens: $0.00288
- Total: $0.03808 per request
If the 20,000-token stable prefix is billed as cached input while only 2,000 tokens remain fresh, the estimate becomes:
- 20,000 cached input tokens: $0.00800
- 2,000 fresh input tokens: $0.00320
- 600 output tokens: $0.00288
- Total: $0.01408 per request
At 100,000 requests, that is $1,408 instead of $3,808—an estimated saving of $2,400, or 63.0%. The saving is not automatic: the first request, a changed prefix, or a route that does not produce a cache hit can still be billed at the fresh-input rate. Confirm the cached-token count in actual usage data before treating the estimate as achieved savings.
Worked Example 3: The Cost of Crossing 200K
Consider a long-running agent request with 210,000 prompt tokens and 2,000 output tokens. Using the listed long-context rates:
- 210,000 fresh input tokens: $0.67200
- 2,000 output tokens: $0.01920
- Total: $0.69120 per run
If context compaction, retrieval filtering, and summary checkpoints reduce the prompt to 180,000 tokens while preserving the same 2,000-token output, the standard-tier estimate is:
- 180,000 fresh input tokens: $0.28800
- 2,000 output tokens: $0.00960
- Total: $0.29760 per run
The difference is $0.39360 per run, or about 56.9%. Across 10,000 runs, the estimated saving is $3,936. The lesson is not to delete useful context. It is to keep only the context that changes the answer and to summarize or retrieve the rest before the request crosses a price boundary.
A Python Calculator for Pre-Call Estimates
The following function uses CometAPI's currently listed Grok 4.7 rates. It applies the long-context tier conservatively when the total prompt reaches 200,000 tokens.
from dataclasses import dataclass
@dataclass(frozen=True)
class Rates:
input_per_million: float
cached_input_per_million: float
output_per_million: float
SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)
def estimate_grok_47_cost(
fresh_input_tokens: int,
cached_input_tokens: int,
max_output_tokens: int,
) -> float:
prompt_tokens = fresh_input_tokens + cached_input_tokens
rates = LONG if prompt_tokens >= 200_000 else SHORT
return (
fresh_input_tokens * rates.input_per_million
+ cached_input_tokens * rates.cached_input_per_million
+ max_output_tokens * rates.output_per_million
) / 1_000_000
estimate = estimate_grok_47_cost(
fresh_input_tokens=2_000,
cached_input_tokens=20_000,
max_output_tokens=600,
)
print(f"Estimated upper bound: ${estimate:.5f}")
This is a planning guard, not an invoice. The final cost depends on actual input, cached input, output, retries, tool calls, and the active price at execution time. After every response, store the returned token usage, model ID, request status, and task outcome. Reconcile those values with the provider's billing records.
Five Grok 4.7 Cost Controls, Ranked by Likely Impact
1. Keep Repeated Context Stable Enough to Cache
Place static instructions, product documentation, schemas, and reusable examples before request-specific content. Avoid changing timestamps, IDs, whitespace, or ordering inside a large shared prefix unless the change is required. xAI's Grok 4.7 guidance recommends stable cache-routing identifiers for conversations; when using an intermediary route, verify which cache controls and usage fields are supported before relying on them.
Measure cache-hit tokens and cache-hit rate by workload. A theoretical cache discount has no value if the application constantly mutates the prefix.
2. Treat 200K as an Engineering Budget, Not a Target
Reserve headroom below the threshold for system instructions, retrieved passages, tool results, and the next user turn. For an agent, compact old turns into a validated summary and retain the raw transcript outside the model context. For retrieval, rank and deduplicate passages before insertion instead of sending every match.
Track prompt-length distributions and alert before p95 approaches the threshold. Under xAI’s official schedule, once a prompt reaches 200K tokens, long-context rates apply to all tokens in that request. CometAPI likewise lists a separate, higher long-context tier for Grok 4.7. These are platform pricing terms, not model capabilities.
3. Cap Output and Tune Reasoning Effort Against an Evaluation Set
Set an application-level output cap that matches the product. A classification result may need tens of tokens; a support answer may need a few hundred; a research report may need more. This cap is a budget and user-experience control, not a hard limit of the Grok 4.7 model. xAI’s September 21 release notes state that Grok 4.7 has no text output limit; that does not prevent an application or a specific API route from enforcing its own request cap. Confirm any endpoint- or SDK-enforced request limit with the route you actually use.
Grok 4.7 supports multiple reasoning-effort levels. Use the lowest level that passes a representative evaluation set, and reserve higher effort for tasks where it produces a measurable improvement. Reducing reasoning or output without quality checks can create retries and erase the saving.
4. Reject or Reshape Expensive Requests Before the API Call
Estimate an upper bound from input size and the configured output cap. If the request exceeds the product budget, the application can ask the user to narrow the task, summarize uploaded material, reduce retrieved context, or move the job to an approved asynchronous workflow. This is more predictable than discovering the cost after generation.
A rough character-to-token approximation can be useful as an early guard, but it should not replace a tokenizer or actual usage data. Languages, code, JSON, and formatting can produce very different token densities.
5. Optimize Cost per Successful Task, Not Cost per Call
A cheaper call that fails validation twice can cost more than one successful call. Track:
- cost per accepted answer;
- cost per completed agent task;
- retry and fallback cost;
- cache-hit rate and cached-token share;
- p50 and p95 prompt and output tokens;
- quality score, latency, and human escalation rate.
If routine traffic does not require Grok 4.7's quality or context capacity, CometAPI's unified model catalog can make an application-managed model switch easier. Keep the routing rule explicit, evaluate each model on the same task set, and send only the requests that benefit from Grok 4.7 to this route.
A Practical Monthly Cost Review
Once a week, group traffic by feature and compare estimated cost with actual usage. Start with the features responsible for the most output tokens, the largest prompts, and the lowest cache-hit rate. Then review expensive outliers rather than optimizing the median request blindly.
| Signal | Likely problem | First action |
|---|---|---|
| Low cached-token share | Shared prefix changes too often | Stabilize and version reusable context |
| Prompts cluster near 200K | History or retrieval is unbounded | Compact, rank, and reserve headroom |
| Output dominates spend | Responses are longer than the product needs | Lower the cap and test answer quality |
| High retry cost | Validation, timeouts, or prompts are unstable | Fix the first-call failure mode |
| Low cost but poor task completion | The optimization reduced useful quality | Measure cost per accepted result |
Where CometAPI Fits in the Grok 4.7 Cost Model
CometAPI’s role in this workflow is at the API-platform level: it provides access to Grok 4.7, publishes its own token rates, and documents an OpenAI-compatible entry point. It does not change Grok 4.7’s underlying model capabilities. Teams already using an OpenAI-style client may be able to keep the same client pattern while changing the API key, base URL, and model ID, subject to endpoint compatibility.
As of September 28, 2026, CometAPI’s listed Grok 4.7 rates are 20% below the corresponding xAI direct rates in both the standard and long-context tiers. This is a platform-price comparison, not a model-quality claim. Before production rollout, teams should also verify the active model ID, endpoint parameters, cache behavior, rate limits, reliability, support, and billing terms.
To test the model, review the current pricing and access details on the CometAPI Grok 4.7 model page. Keep the price table in configuration, record actual usage after every call, and re-run workload estimates whenever the model or product behavior changes.
FAQ
What is the Grok 4.7 price per token on CometAPI?
For prompts below 200K tokens, CometAPI currently lists $1.60 per million fresh input tokens, $0.40 per million cached input tokens, and $4.80 per million output tokens. The listed long-context rates are $3.20, $0.80, and $9.60 per million tokens respectively.
How much does one Grok 4.7 API request cost?
It depends on fresh input, cached input, output, and the active context tier. Multiply each token count by its per-million rate, add the results, and divide by one million. Also include retries and every model call in a multi-step workflow.
What is the easiest way to reduce Grok 4.7 API cost?
Start with the largest measured cost driver. Repeated long instructions usually benefit from caching; growing agent histories benefit from compaction; verbose answers benefit from a lower output cap. Confirm that quality remains acceptable after each change.
Does a 500K context window mean I should send 500K tokens?
No. The context window is a capacity limit, not a recommendation. Both xAI direct pricing and CometAPI’s current listing use higher long-context rates at the 200K prompt threshold, so applications should send only the context needed for the task.
Can I estimate cost before calling Grok 4.7?
Yes. Estimate input tokens, choose the correct context tier, add a realistic output cap, and calculate the upper bound. After the call, replace the estimate with actual usage data for reporting and optimization.