Research-backed calculator guide

Mistral Cached Input vs Batch: Choose the Cheaper Path for Repeated Documents

Compare Mistral cached input and Batch pricing for repeated documents with a worked token-cost example, cache-hit formula, deadline test, and implementation checklist.

What the two Mistral cost levers actually do

Cached input is a hit-dependent input-price reduction

Prompt caching reuses previously computed prompt tokens when requests share the same prefix. Mistral specifically describes repeated system prompts, multi-turn history, and similar context as use cases. The stable content must be at the beginning of the request; a changing document or question placed before the reusable material can prevent the prefix from matching. A prompt_cache_key increases the chance of a hit but does not guarantee one. ^[2]

The accounting is important. prompt_tokens includes the whole prompt. cached_tokens identifies the portion served from cache. Billable uncached input is prompt_tokens - cached_tokens. The cached portion is billed at 10% of the standard input price. Mistral also documents 64-token cache blocks and notes that prompts shorter than 64 tokens do not receive cache hits. ^[2]

This means “90% cheaper input” is not the same as “90% cheaper request.” If a request has 10,000 cached input tokens but 90,000 uncached input tokens and a large completion, most of the bill remains outside the discount. The correct process is to record actual cached_tokens by model and workload, then calculate the weighted input charge.

Batch is an asynchronous serving choice

Batching lets you submit many API requests for asynchronous processing. Mistral’s Batch Processing documentation describes file-based jobs, inline batches for smaller jobs, a single model per batch, supported endpoints, and retrieval of job status and results. It supports up to 1 million requests in a batch according to the documentation, while the page also describes inline batching for fewer than 10,000 requests. ^[3]

The product announcement frames Batch for use cases such as document summarization, translation, sentiment analysis, embeddings, and data labeling where volume matters more than synchronous responses. It states that Batch costs 50% less than a synchronous API call. ^[4] That is a vendor statement about the Batch path, not a guarantee that every end-to-end workflow will cost exactly half after retries, storage, orchestration, human review, or a second model call.

Batch is therefore a strong fit for overnight or scheduled document backfills. It is a poor fit for an interactive user waiting on a result, a strict low-latency SLA, or a workflow that must stop and ask a human after each document. The discount cannot compensate for a missed deadline or an operational workaround that re-runs the same work synchronously.

A cost formula for Mistral cached input vs Batch

Start with a standard request estimate:

standard_cost = (input_tokens × standard_input_rate / 1,000,000) + (output_tokens × output_rate / 1,000,000)

For a request with caching:

cached_cost = ((input_tokens - cached_tokens) × standard_input_rate / 1,000,000) + (cached_tokens × cached_input_rate / 1,000,000) + (output_tokens × output_rate / 1,000,000)

For Batch, use the vendor’s 50% reduction as an estimate against the comparable standard request total:

batch_estimate = standard_cost × 0.50

That last equation is deliberately labeled an estimate. Confirm the applicable rate card and any model- or endpoint-specific behavior before committing spend. This article does not assume that cached-input pricing and the Batch discount stack. If you test both modes together, compare the actual usage and invoice records with a baseline Batch run.

The comparison should include more than token price. Add queue wait, polling or retrieval work, object storage, failed-request retries, output validation, and human review when they are material. A 50% token discount is not a 50% total-cost discount if Batch causes a second validation pass or forces a late synchronous fallback.

Worked cost example

The following is an estimate, not a vendor quote. It uses the official Mistral Small 4 token rates visible on 2026-11-02 and assumes the 50% Batch discount applies to the comparable standard token bill. It excludes taxes, subscription credits, network charges, storage, orchestration, retries, and review labor. The workload has one cold request followed by 99 requests that hit the full 80,000-token prefix.

The cached-input estimate is 66% below the standard baseline in this particular mix. Batch is 50% below that baseline. Cache is about 32% below the Batch estimate because the stable prefix is most of the input and the output is relatively small. The first request is not discounted by caching in this simplified scenario; it creates the baseline against which later hits are measured.

The table also shows why a model-rate lookup alone is insufficient. If the stable prefix falls from 80,000 tokens to 20,000, the cache path loses much of its advantage. If output rises from 2,000 to 20,000 tokens, neither input lever changes the output price, and the two choices move closer together. If only 10 of 100 requests hit, use the observed hit count rather than multiplying a theoretical discount across every call.

How to decide for repeated documents

Use caching first when prefix stability is high. Put invariant instructions, schemas, and reusable reference material before the variable document-specific question. Keep a stable application-level prompt_cache_key, but do not treat that key as proof of a hit. Log model, request ID, prompt_tokens, cached_tokens, output tokens, latency, and outcome. After a representative sample, calculate the weighted cached share rather than relying on a hoped-for hit rate.

Use Batch first when deadline slack is high. Define the latest acceptable completion time, not just the desired average. A nightly enrichment job with a six-hour window can tolerate a queue; a support reply cannot. Batch’s documented workflow involves creating a job, waiting for processing, retrieving results, and handling failures. ^[3] Those steps are part of the operating design even if they do not appear on the provider’s token line.

Prefer Batch when the repeated documents are not actually repeated prompts. A folder of unrelated documents may share a task instruction but have little reusable prefix. In that case, cache savings may be small while Batch can still reduce the total model charge for eligible asynchronous work. Conversely, a long policy or handbook sent to many synchronous questions can be an excellent cache candidate even when each question must return immediately.

Do not compare discounts without comparing correctness. A cached prefix must remain semantically valid. If document versions change, invalidate or version the prefix. A Batch backfill must preserve request identifiers and map outputs back to source documents. Mistral’s batch format uses a unique custom_id for each request, which is useful for reconciliation. ^[3] Include malformed outputs, retries, and rejected documents in the effective cost per accepted result.

Validate combinations separately. The brief question “Mistral cached input vs batch cost” often leads to an assumption that a 90% input reduction and 50% Batch reduction can be multiplied. That would imply an attractive but unverified combined price. Unless the current rate card, usage response, and invoice clearly establish the interaction, model the two paths separately and run a small controlled test. This is safer than publishing a stacked discount as if it were a quote.

For a broader model-rate comparison, use the model pricing comparison. For a monthly request-and-token budget, use the LLM cost calculator. If you need to inspect how prompt, cached, and output tokens contribute to a bill, see the AI token cost calculator. The Mistral and Groq API cost calculator is the assigned calculator for a provider-specific starting estimate, but you should still replace assumptions with observed usage.

FAQ

Is Mistral cached input always cheaper than Batch?

No. Cached input is cheaper only for the input tokens that actually hit the cache. Batch applies a separate asynchronous discount to the comparable workload. A mostly unique prompt, low hit rate, large output, or a failed cache match can make Batch cheaper. A stable long prefix and synchronous requirement can make caching cheaper. Compare measured cached_tokens with a Batch baseline instead of applying a headline percentage to the whole request.

How much do cached tokens cost on Mistral?

Mistral’s prompt-caching documentation states that cached tokens are billed at 10% of the standard input token price. The official pricing table is the source for the model-specific standard and cached-input rates. For example, the table read on 2026-11-02 lists Mistral Small 4 at $0.15 per million standard input tokens and $0.015 per million cached input tokens. ^{[1] [2]} Rates can change, so treat those figures as a dated snapshot rather than a perpetual quote.

Does prompt_cache_key guarantee a cache hit?

No. Mistral explicitly says the key increases the chance of a hit but does not guarantee one. The request must share a compatible prefix, and the response’s prompt_tokens_details.cached_tokens tells you what was actually served from cache. ^[2] Use that field in your cost ledger. A configured key without a measured cached-token count is an intention, not billing evidence.

Is Mistral Batch synchronous?

No. Batch is designed for asynchronous processing. You submit a list of requests or a batch file, create a job, wait for processing, and retrieve status and results. ^[3] It suits high-volume work with deadline slack, such as document backfills and scheduled classification. It does not provide the same interaction pattern as a synchronous completion request.

Can cached input and Batch discounts be combined?

Do not assume that they can be stacked. The official pages describe cached-input billing and Batch pricing as separate mechanisms, but the decision model should remain conservative until a current rate card, usage response, or invoice confirms the combined treatment for your model and endpoint. Run a small test with the same document mix and compare effective input, output, and total charges.

What should I record before choosing a path?

Record model and endpoint, total prompt tokens, cached tokens, output tokens, request count, retry count, queue and completion time, and accepted-result count. Also record document version and prefix layout. These fields let you separate price effects from workload changes. For Batch, retain custom_id and job identifiers so output reconciliation and reprocessing do not create hidden duplicate costs.