Mistral Large 4 opens a hosted preview for software investigations

Mistral opened a public preview of Mistral Large 4 on October 6. The launch made the preview available through Mistral Studio's API. Publicly downloadable weights are promised by the end of the month. The company emphasizes cybersecurity and tool-using workflows.

The hosted preview gives an investigation team something it can try now. A team that needs local inference has a different starting point: it must wait for the promised weights before evaluating that deployment. Keeping those two paths separate makes the launch easier to act on without mistaking a future option for an available one.

From a request to an investigation

The model page lists function calling and structured outputs for mistral-large-4. Function calling lets an application offer operations such as reading a source file or retrieving an approved log excerpt. For a custom function, the model chooses the operation and supplies its arguments; the application executes it and returns the result. Mistral's function-calling guide explains that exchange.

Consider a hypothetical orders API that starts returning internal-server errors for malformed JSON after a dependency update. Its expected behavior is to reject an invalid request with HTTP 400 while continuing to accept valid orders. The investigator supplies a synthetic failing request, the dependency diff and a sanitized stack trace, then asks the assistant to locate the error-handling change.

Let a read-only function follow the exception into the handler. The assistant can compare the changed dependency call with the code expected to catch its error, then point to a candidate mismatch. The useful finding includes the file location and supporting trace so an engineer can walk the same path and decide what to test.

Checking the affected request

A separate check can answer that question on a disposable copy of the service. It would run the malformed request against the candidate change and check for the expected rejection, then send a valid order to check that the ordinary path still works. The assistant's statement that it has fixed the problem cannot establish either result. This is the distinction developed in our incident-agent evaluation guide: service behavior must be checked independently of the agent's completion claim.

The distinction is between two finish lines. For a read-only investigation, a supported finding and a useful next test can complete the assignment. For a repair, the malformed request must now receive the expected rejection and the valid order must still work. The explanation helps someone choose the change; observations from the service establish whether the change did its job. This example does not extend that result to production recovery.

Tracing what the preview actually did

Mistral's current observability documentation recommends recording model configuration, inputs, outputs, tool calls, errors and retries. It describes tracing individual model calls and tool steps through an agent workflow. Those records make an investigation's result easier to explain.

In the orders example, a refusal to analyze the supplied material, a failed file-read function and a completed finding followed by a failing service check are different outcomes. The first leaves the requested analysis undone. The second points to a problem in the tool path. The third preserves potentially useful reasoning while showing that the proposed correction did not satisfy the check. Reporting only whether the model returned a final answer would lose those distinctions.

For the orders example, a worthwhile preview result is a finding the engineer can verify and a clear account of where an unsuccessful attempt stopped. A later local deployment adds serving questions of its own, but the affected-request check can stay the same. The meaningful finish is still the malformed order rejected correctly while valid orders continue to work.