Cerebras docs quote two Gemma 4 31B prices in 2026: $0.99 and $2.15 per million input tokens

Summary. As of 24 August 2026, the Cerebras Gemma 4 31B model page states two different prices for the same model on the same page: a plain-text block reading "$2.15 per million input tokens, $2.70 per million output tokens", and a rendered spec card reading $0.99 input and $1.49 output. That is a 2.17x gap on input and a 1.81x gap on output. The same page gives two speeds, ~1500 and ~1850 tokens per second. The GPT-OSS-120B page forks the same way on free-tier limits: 30 requests per minute and 60k input tokens per minute in the text, 5 and 30k in the card, with the Rate Limits page siding with 5 and 30k. Only 2 models are on the public catalogue. Prompt caching costs nothing extra, and the pricing page does not contain the word "cache" anywhere.

What the two Cerebras sources actually say

Every Cerebras model page is built the same way. There is a plain-text specification paragraph that machine readers and agents pick up, and a <ModelInfo> spec card that a human sees in the browser. On two of the two published public models, those halves disagree.

Five forks, two models. The tie-breaks point one way. The public cerebras.ai/pricing page carries the figures $0.35, $0.75, $0.99 and $1.49 and no others, which matches the spec cards and the GPT-OSS-120B rate of $0.35 input and $0.75 output. The Model Catalog lists Gemma 4 31B at ~1850 tokens per second, which matches the card. The Rate Limits page lists 5 RPM and 30K TPM on the Free Trial tier for both models, which matches the cards.

So the spec cards are almost certainly right and the plain-text paragraphs are stale. That is the worse failure of the two, because the plain-text paragraph is the part a retrieval pipeline, a procurement spreadsheet or a coding agent reads. A team that priced Gemma 4 31B off the text block budgeted 2.17x too much for input and would have written off the model on cost.

The free-tier limits fork cuts the other way

On GPT-OSS-120B the stale number is generous rather than expensive. The text says 30 requests per minute and 60k input tokens per minute on the free tier. The card and the Rate Limits page both say 5 and 30k. A prototype sized against 30 RPM starts returning 429s at request six.

Cerebras is explicit about what a 429 tells you: the error message names which of the two token buckets you exceeded. That matters because the platform enforces two independent limits, not one.

Caching buys throughput here, not a discount

Most hosted inference providers price a cache hit below a fresh input token and charge a premium to write the cache. Cerebras does neither. Its Prompt Caching page answers the question directly: "There is no additional fee for using prompt caching. Input tokens, whether served from the cache or processed fresh, are billed at the standard input token rate for the respective model."

Compare that with OpenAI's published rates for the same week.

Both models of caching are defensible. The point is that they are not interchangeable in a spend model. If you carry an OpenAI-shaped cost sheet across to Cerebras, every cache-hit line in it is wrong, and the benefit you were counting on shows up in a different column entirely. We have written before about the hosted DeepSeek V4 Pro cache-write price gap and about the OpenAI prompt caching dashboard and its cache-write cost; Cerebras is the third distinct billing shape in a month.

What Cerebras gives you instead is a second rate-limit bucket. Every organisation has an uncached tokens-per-minute limit and a total tokens-per-minute limit, and the total is 3x the uncached figure. Cached tokens count against the total bucket only. So a better cache hit rate does not lower your bill by a rupee; it raises the ceiling on how much traffic you can push through the same account.

Where the 3x ceiling stops paying

That 3x multiplier is a hard cap, and the arithmetic decides when caching stops helping. On the Developer (pay as you go) tier, GPT-OSS-120B has a 1M uncached TPM limit, so the total limit is 3M TPM. At a cache hit rate of h, your uncached spend is total x (1 - h), which must stay under 1M, while the total itself must stay under 3M.

The two constraints meet at a 66.7% hit rate. Below it, the uncached bucket binds and every point of cache hit rate is worth real throughput. Above it, the total bucket binds and further caching work buys nothing on this axis.

Cerebras's own worked example sits right on that line and mislabels it. The Rate Limits page reads: "With a 1M uncached TPM limit, your total limit is 3M TPM. At a 70% cache hit rate, you can effectively process up to 3M total tokens per minute, 1M uncached plus up to 2M cached." One million uncached against three million total is a 66.7% hit rate, not 70%. The illustration is the break-even point described as if it were headroom. If your roadmap assumed that pushing cache hits from 70% to 85% would grow capacity, it will not, and no error message will tell you why.

The routing key that fixes cache misses is behind a sales gate

The Prompt Caching page opens by saying caching "works automatically on all supported API requests. No code changes are required." Two sections later it documents a failure mode that is not automatic at all: "Under load, turn 1 of a session can be routed to one prompt cache and turn 2 to another, causing a cache miss even though the prefixes match."

The documented remedy is the optional prompt_cache_key parameter, a routing hint that keeps one conversation on one cache. It carries this note: "prompt_cache_key must be enabled on your account before you can use it. Contact us or reach out to your account representative to request access." So the fix for the documented under-load miss is a sales conversation, not a code change. Values are capped at 1024 characters and longer ones are rejected with a 400. Cerebras also warns against using the key for a system prompt or RAG context shared across many users, because funnelling those requests to one backend creates a throughput bottleneck.

Three further miss causes are documented and worth designing around. Caching works in 128-token blocks, so a prefix shorter than 128 tokens may not be cached at all. Requests can be routed to a different data centre where your cache does not exist. And the time-to-live is guaranteed for 5 minutes only, though caches may survive up to an hour depending on load.

The model support list contradicts the model pages

The Prompt Caching FAQ answers "Which models support prompt caching?" with a single entry: gpt-oss-120b. Both public model pages list Prompt Caching in their capabilities, including Gemma 4 31B. One of those two statements is wrong, and Cerebras does not say which. If your workload is the multimodal one, and Gemma 4 31B is the only public Cerebras model that takes images, you cannot tell from the documentation whether you get a cache at all, and therefore whether you get the 3x total-TPM bucket.

Verify it empirically rather than from the docs. Every response carries usage.prompt_tokens_details.cached_tokens; send the same prefix twice inside five minutes and read the field. The console also has a Cached-Usage tab under Analytics that breaks input tokens into hits and fresh processing.

What the pricing page leaves out

Search cerebras.ai/pricing for the word "cache" and you get zero occurrences. The page that sets your unit economics never mentions the mechanism that sets your throughput ceiling. Nothing there is untrue, but a buyer who reads only the pricing page will model Cerebras as a flat per-token service and will miss both the dual-bucket limit and the 3x cap.

Two other omissions belong in the same bucket. The public catalogue is two models. The families that appear in the model selection guide, Kimi K2.6, GLM 5.1, MiniMax M2.5 and Qwen3 32B, are marked as available only through Dedicated Endpoints, whose pricing is quoted per organisation. And there is no permanently free tier: new accounts get $5 in credits that expire 30 days after they are granted, and API access stays inactive until a verified payment method is added.

How to tell if this affects you, and what to do

You are exposed if any of the following is true. Your cost model for Gemma 4 31B came from anything other than the spec card or the pricing page, in which case re-check it against $0.99 and $1.49. Your load test was sized against 30 requests per minute on the free tier, in which case re-size against 5. Your capacity plan assumes cache hit rate improvements above roughly 67% will keep buying throughput on a 1M uncached TPM account, in which case they will not. Or you planned on Gemma 4 31B caching, in which case measure cached_tokens before you commit.

The practical fix is a one-hour verification pass: pull the current rates from the pricing page rather than the doc text, send a duplicate-prefix probe on each model you intend to use, read cached_tokens, and record the 429 body when you exceed a limit so you know which bucket bound. Then hold that evidence alongside your provider comparison. A hybrid routing framework for API spend only works when the per-provider numbers underneath it are the live ones, and this month they moved on three providers.

India-specific considerations

For Indian teams the arithmetic is unforgiving in both directions. At $0.35 input and $0.75 output for GPT-OSS-120B, a workload that would cost roughly $4.00 input on a frontier model is a large saving. But a team that budgeted from the stale $2.15 figure for Gemma 4 31B and converted at about ₹87 to the dollar would have carried roughly ₹100 per million input tokens more than the real ₹86 in its board deck, and may have rejected the multimodal option on price. Data protection also deserves a check: Cerebras states that prompt caches are ephemeral, ZDR-compliant, never persisted and never shared between organisations, but it does not publish a residency guarantee for the data centre a given request lands in, and the caching page confirms that requests may be routed to a different data centre. Teams with DPDP-driven residency commitments should get that in writing before production traffic moves.

What is still unknown

Cerebras has not said which side of each fork is the intended figure, and the doc pages carry no last-updated stamp to date them against each other. There is no published enterprise-tier uncached TPM number, so the 3x rule is only verifiable at the tiers that publish limits. Whether Gemma 4 31B caches is unresolved in the documentation. And Cerebras does not publish an SLA figure for the guaranteed 5-minute cache TTL, so the one-hour upper bound remains best-effort. For a broader read on where these providers land against each other, see our comparison of Gemini 3.5 Pro, GPT-5.6 and Claude Fable 5.

FAQ

How eCorpIT can help

Provider documentation forks like this one are cheap to catch and expensive to miss, and they are showing up on three hosted inference providers a month. Our engineering team runs verification passes on inference cost models: pulling live rates, probing cache behaviour with duplicate-prefix requests, and recording which rate-limit bucket actually binds under your traffic shape. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and the same review covers residency questions where DPDP commitments apply. Book an inference cost review and we will start from your current provider mix.

References

1. Cerebras Prompt Caching documentation

1. Cerebras Rate Limits documentation

1. Cerebras Model Catalog

1. Cerebras Gemma 4 31B model page

1. Cerebras OpenAI GPT OSS model page

1. Cerebras public pricing page

1. Cerebras usage monitoring and Cached-Usage tab

1. Cerebras Dedicated Endpoints overview

1. Cerebras model selection guide

1. Cerebras documentation index

1. Cerebras Quickstart

1. Cerebras error reference

1. OpenAI API pricing documentation

Last updated: 24 August 2026.