Mistral Large 4 Open Weights: Evaluate the Coding Workflow Before Self-Hosting

Mistral’s October 29 announcement releases the weights of an updated Mistral Large 4, also called Le Chonk. The company says additional reinforcement learning since its earlier public preview improved coding and reasoning efficiency. This is a subsequent release of improved weights, rather than the model’s initial introduction.

The distinction matters when comparing results. Mistral’s model documentation still displays October 6, 2026 and a Public Preview label. The announcement supplies the date for this news event. Anyone evaluating the update should record the exact checkpoint or endpoint model identifier so that results remain attributable to the version actually used.

Our recommendation is to separate model suitability from deployment suitability. First establish whether the updated model completes useful work in your agent workflow. Then decide whether maintaining your own deployment serves a concrete need.

Mistral’s published model card describes a mixture-of-experts model with roughly one trillion total parameters and about 52 billion active parameters per token when embeddings and output layers are included. It documents text and image inputs, text output, a one-million-token context window, function calling, and structured output support.

For a developer, a useful proposed task is fixing a layout defect from a screenshot and the relevant source files. That exercises visual interpretation and code editing together. Another is reading a chart and producing a structured explanation that names the visible evidence behind each conclusion.

These examples are evaluation proposals, not demonstrated outcomes. Check whether the model identifies the relevant visual detail, connects it to the right file, and produces a change that passes review. A documented context limit also does not establish reliable use of every detail in a large repository.

The release supports low, medium, and high reasoning effort, with high as the default. Mistral recommends low for simple tasks, medium for everyday work, and high for the hardest cases. The announcement also says low replaces the previous None reasoning mode, a detail worth checking in existing integrations.

We propose running the same small task set under all three modes. Include a localized bug fix, a change spanning several files, and one screenshot-based task. Keep the starting repository, instructions, available tools, and acceptance checks consistent. Record completion quality, elapsed time, tool calls, and human corrections.

The model card notes that max_completion_tokens includes reasoning tokens as well as visible output. A short answer therefore does not reveal the full generation budget. Track truncation separately from incorrect solutions, and inspect the request actually sent by your agent instead of assuming its interface preserves the selected reasoning effort.

Mistral reports that the updated model reached 41% on Terminal-Bench 4.0, compared with 28% for its preview, while reducing output tokens by 30%. Those figures come from the vendor’s announcement. We have not independently reproduced them or evaluated their transfer to a small team’s repository.

The practical implication is a reason to schedule an evaluation, not a prediction of your task success rate. Your agent’s prompts, tools, stopping rules, and repository context can differ from the reported benchmark setup. Token reductions on that setup also do not establish shorter completion times on your hardware.

Use our coding-assistant evaluation guide to define acceptance criteria before inspecting results. Preserve failing examples as carefully as successful ones. A model that finishes an impressive demonstration may still require too many corrections on the repetitive maintenance tasks that dominate your week.

The model card provides serving examples for vLLM and SGLang. Both illustrate tensor parallelism across eight GPUs; the SGLang notes explicitly describe that as an example topology to adjust. This is useful deployment guidance, but it is not a universal hardware minimum or proof that any eight-GPU machine can serve your intended workload.

Mistral also documents a separate NVFP4 checkpoint targeting Blackwell GPUs. Check the selected checkpoint, numerical format, serving framework, and hardware together. The active parameter count alone does not describe the resources needed to store and serve the full model.

Before committing infrastructure, propose a feasibility check with your expected context length and simultaneous requests. The vLLM instructions advise reducing maximum context length or concurrency when GPU memory is insufficient. Establish acceptable limits for both, then measure whether the deployment meets them. We have not verified memory consumption, throughput, or deployment reliability.

Start with a fixed repository revision and a handful of tasks whose correct outcomes you can verify. Save the model identifier, reasoning mode, prompt, generated diff, and actual test output for each run. Repeat enough tasks to expose inconsistent behavior rather than selecting the most attractive answer.

Apply the same review standard you use for other generated code. Our regression-testing guide explains how to turn a reported defect into a check that can catch its return. Passing those checks supports a specific change; it does not validate every claim in the model’s explanation.

Advance to deployment planning when the model repeatedly handles a useful task and you can support the required serving setup. Defer expansion when corrections remain frequent or infrastructure requirements remain unclear. Open weights make local operation an available path; a successful, maintainable workflow must still be established through your own evidence.