Mistral Large 4: what the preview offers and what to evaluate before using it

Mistral Large 4 has been in public preview API since October 6, 2026; the release of weights is announced by the end of the month. This distinction comes before any comparison: on October 8 you can evaluate the preview, while you don't have to plan a standalone installation as if the files were already available. The state is indicated in the Mistral official announcement.

For an Italian SME, the novelty can open an evaluation on documents, integrations and data control. Here we separate what is available from the project choices. The scenarios are hypothetical; we have not run independent benchmarks or Large 4 installations. The AI review of 2–8 October 2026 links this announcement to the other news of the week.

What can you prove today and what remains announced?

The first choice is to define the goal of the test. Do you want to know if the model reads a certain document? If you return fields in the management software format? If he can motivate an answer using a source? Each question requires a more delimited experiment than "let's see how powerful it is."

The first two lines are derived from Mistral Large 4 announcement; the others are design consequences to be verified, not further availability promised by the manufacturer. If you are meeting the supplier for the first time, the guide to Mistral AI clarifies the general context without replacing the updated status of this release.

A preview test should also produce an orderly output. Preserve prompts, authorized documents, and criteria in a reusable form. If the model changes, becomes unavailable or does not meet the need, you can repeat the comparison without reconstructing the work from scratch. It prevents all knowledge of experimentation from remaining in one person's conversations.

How to read prices and context without building a fragile quote?

The Large 4 data sheet indicates a context of one million tokens. The Official API Price list, verified on October 8, 2026, shows these promotional rates in dollars per million tokens. No end date has been verified: check the page before making any economic commitments.

For a purely arithmetic example, one million token inputs and one million outputs, with no other entries, would give $2.77 with the promotion indicated. It is not the cost of an archive or a practice: real consumption depends on the texts sent, the response requested, the attempts and the tools used. The Calculation of AI API costs helps to turn the price list into a measurable hypothesis.

A large context window is not an invitation to send the entire archive for every question. We suggest distinguishing necessary documents, documents relevant only in certain cases, and material the system must not see. This selection makes the test easier to interpret: when an answer is wrong, you can reconstruct which evidence was available.

The response length also deserves a functional limit. If the purchasing department requires five fields and a source, a long report is not automatically a better result. Requesting a precise format makes comparison with the current work easier and reduces review of content that was not requested.

European AI, regional inference and GDPR: what to check separately?

Mistral declares training and preview service on its own European infrastructure. It's manufacturer information, useful for starting an evaluation, but it doesn't describe the entire data processing of your project on its own. The statement is in the infrastructure section of the Large 4 announcement.

The documentation on regional inference describes a separate service, with a 10% surcharge, variable model availability and limits for functions such as Agents, Batch and Files. It also points out that not all metadata and control elements are regionalised; the geographical table includes EU and EFTA countries. We have not verified Large 4 in the catalog of a specific regional endpoint.

European supplier does not mean automatic compliance. To evaluate the project, we propose to follow the path of the data: from the original document to the application, from the application to the inference service, up to logs, results and recipient systems. A region chosen for the model does not alone answer questions about the other steps.

Prepare with those who follow privacy and contract a concrete list: what data enters, for what purpose, who accesses, where the result is kept, when it is deleted and how errors are handled. They are questions about the specific project, not a certification that this guide can issue. The route on AI and corporate privacy helps to organize the collection of information.

What evidence to ask before approving the data stream?

Ask for a map of the actual steps, the identification of the service and the endpoint used, the applicable contractual conditions, access permissions and retention rules. Add an example log with non-sensitive data and an explanation of what happens when a request fails. A generic answer "it's all in Europe" does not describe these elements.

How to rate Large 4 on a technical file?

Hypothetical scenario: a small manufacturing company must prepare an internal summary starting from data sheets, drawings and revisions of a component. The test does not ask the model to approve the component. It asks to locate the requested information and report what is not verifiable.

Before using AI, the technical manager defines which document takes precedence and how a revision is recognised. Then they choose an authorised package without information that must not leave the agreed boundary. The expected result includes field, value, document, page and verification status.

A prompt to adapt:

Prepare a summary of these documents for internal review. For each required field, report value, file, page, and evidence. If two revisions disagree, keep both and report the conflict. Do not convert units without declaring it. Do not approve conformity or suitability of the component. If a visual detail is not readable, write DA_VERIFICATION.

The assessment also concerns silent errors. A correct number associated with the previous drawing may be more insidious than an empty field. In the test sample then enter similar revisions, different units, and tables with notes that change the meaning of the value. The goal is to see if the process makes these conditions visible.

Multimodality is a declared feature of the model, not a guarantee on reading your drawings. To deepen the concept find the guide to Multimodal AI. The final decision on a technical requirement remains in the verification process defined by the company, with people and tools appropriate to the case.

How to compare offers without losing conditions and attachments?

According to hypothetical scenario: a distributor compares offers from Italian and foreign suppliers. The price is only part of the decision; they also count minimum quantity, yield, declared availability, exclusions and validity of the offer. The model prepares a comparative view, while the purchasing office checks the conditions before choosing.

The test should be constructed so that the system does not fill the voids with assumptions. If an offer does not indicate transport, the correct box is "not indicated", not "included". If a condition appears only in an annex, the result must cite it. If two offers use different quantities, the comparison must report it before proposing an order of convenience.

Proposed work prompt:

Compare the quotes only on the fields listed. Keep the original currency, units and quantities. State the source for every value. Do not convert amounts or infer missing costs. If the quotes are not comparable, explain which information to ask the supplier for. Prepare an internal draft; do not make commercial commitments.

A useful test compares the produced table with the interpretation of the person currently doing the work and records the reason for every correction. Do not stop at asking whether the text “looks right”. Check whether another person could reconstruct the answer from the sources without guessing which document the model used.

What criteria to use instead of a general ranking?

The manufacturer presents benchmark results on the launch page. They should be read as information attributed to Mistral, not as independent proof of performance on an Italian company. To choose we propose a card that separates quality of the result, quality of evidence and compatibility of the service.

On the result evaluates correct fields, omissions and conflict management. On the evidence it controls existing references, correspondence to review and distinction between quotation and interpretation. On the service it verifies the format required by the application, the errors handled and the tools actually available in the chosen configuration.

Maintain an error category for each rejected outcome. "The wrong model" does not help to decide; "he used the previous revision because they both had the same name" suggests an intervention on the archive. The test must also be able to lead to this conclusion: the biggest advantage may come from making better documents and rules, before changing the model.

In comparison with Claude Haiku 5.5, avoid an absolute winner. Haiku and Large 4 can enter tests with different perimeters; the choice must be made on the task, costs, availability and control required. To build a common grid there is the guide to how to choose an AI model.

Which documents should be included in the initial sample?

It prepares a group of normal documents and a group of cases that test the rules: missing attachment, scan poorly readable, two almost identical versions, table with different units, information present only in a note. For each write first the expected answer or why the system should stop. If you can't describe that outcome, clarify the task with the manager before evaluating the model.

It then separates the material used to improve the prompt from that used to judge the result. Keep a card with case ID, documents allowed, version of the request, product outcome and correction required. You don't need a huge collection to start with; you need to be able to explain why a result has been accepted. Add new cases when a different type of error emerges, without rewriting the history of previous tests.

Finally, ask a colleague who has not prepared the prompt to use the summary. If he does not find the source or understand which data remains uncertain, the proof is not over. This step evaluates the product of the work: a summary must be useful to the recipient, not only convincing to the one who generated it.

When does it make sense to wait for weights before designing hosting?

Waiting may be the reasonable choice if the main goal is to run the model on company-controlled infrastructure. Before the actual release it is not advisable to promise a configuration, estimate local performance or assume a particular license. Instead, write down the requirements that future service will have to meet.

The list may include documents allowed, expected load, required continuity, people responsible for updates, and criteria to replace the model. When weights and conditions become available, these requirements will become the basis for a technical comparison. The Guide to Local AI Models clarifies the responsibilities to be considered; that to the Open Source AI Models helps to distinguish weight availability and licensing.

The mistakes to avoid are concrete: sell the preview as a ready-made installation; extend to all tools an endpoint property; treat a promotional price as permanent; evaluate only easy documents. Also choosing the model before determining who approves the result leaves open the most important problem of the flow.

A useful first step is to draw the path of a single document and define which result is really needed. The Lab you can explore interactive examples to turn a generic need into observable steps. If you want to link the proof to the data and permissions of your management software, we design custom software starting from the document flow to make verifiable, before choosing where to run the model.