Grok 4.1 Fast Token Counter

Estimated token count and cost for Grok 4.1 Fast, worked out in your browser.

0 characters0 words
Tokens~95% estimate
0
Estimated cost
Input
$0.00
$0.2/1M tokens
Output
$0.00
$0.5/1M tokens
Context window0 / 2,000,000
0.00% used

Two million tokens for twenty cents

Grok 4.1 Fast is $0.20 per million input and $0.50 per million output, with a 2,000,000-token context window. That combination is unusual: a very large window is normally attached to a mid-tier or frontier price.

Filling the entire window costs 40 cents. That number is what makes certain designs reasonable which would be indefensible elsewhere, like sending a whole repository or a full day of transcripts on every request instead of maintaining a retrieval layer.

The ratio is nearly flat

Output is only 2.5 times input, against the 5 or 6 to 1 that most models charge. Combined with the low absolute price, that means verbosity is close to free here.

It inverts the usual advice. On a frontier model the discipline is to cap output. Here you can let the model write at length without the bill noticing, and the cost lives in how much context you send rather than how much comes back.

More detail

What you are trading away

Speed and price come from a smaller, faster model. On multi-step reasoning, subtle code, and anything where a wrong answer is expensive, it will not match a frontier model, and the retries plus the errors that slip through can easily exceed what you saved.

The test that matters is accuracy on your own task, not the price list. Run a real sample through this and through a frontier model and compare the outputs before committing to the cheap option at volume.

Count accuracy

Estimated with o200k_base, since xAI publishes no local tokeniser. At a two-million-token window a few percent of drift is a lot of tokens in absolute terms, so leave real headroom rather than aiming to land just under the limit.

Questions

What does it cost to fill the two-million-token window?

About 40 cents in input at $0.20 per million. That is low enough that sending large fixed context on every request can be cheaper than building and maintaining a retrieval pipeline.

Should I still cap the output length?

Less urgently than elsewhere. Output is only 2.5 times input here and the absolute rate is low, so long answers are not the dominant cost. Your bill will be shaped by how much context you send.

What is the catch?

Capability. It is a fast, small model, so hard reasoning and subtle code are where it falls short. Test accuracy on your own workload; retries and undetected errors can cost more than the token savings.

How reliable is the count at this scale?

It is an estimate using o200k_base. A few percent of drift is negligible on a short prompt and significant across two million tokens, so do not plan to land exactly at the limit.

Related tools