Mistral adds an OpenAI-format API for building with its AI models

Developers can now use Mistral models through the OpenAI Responses format, with Mistral’s Responses API available in public preview. The interface handles text, images, documents and function calls. But the familiar format comes with a clear division of work: the model produces responses and requests actions; the application maintains the conversation and runs those actions.

One format for messages, files and structured answers

Mistral positions the interface for both new applications and existing integrations built around the Responses format. Requests supply material through input, while each response returns an output array. That array can contain messages, reasoning and function calls as separate items—not just a single answer string.

Text can arrive as a string or an array of messages. Images can be supplied through image URLs or base64 data URLs, which carry the image data inside the request. Image questions require a vision-capable model. Documents have three routes: an HTTPS URL, base64 data or an uploaded file ID. Developers must choose exactly one file source for each file item.

On the output side, the preview offers JSON mode and JSON Schema through text.format, giving developers a way to request structured answers. Reasoning controls are model-dependent: the interface includes reasoning.effort and plaintext reasoning, but developers need to select settings supported by their chosen model. A shared request format does not make every model’s available settings identical.

The model asks; the application acts

The API is stateless: applications must keep conversation history and send it with each request. Mistral’s instructions call for adding all output items from the previous response to that history, followed by the next user message. Keeping only the visible answer text would not follow that documented conversation pattern.

Function calling follows the same application-managed approach. Developers describe available functions in tools. The model can then return a function name and arguments, but application code executes the function. Mistral’s example uses an order-status lookup and instructs developers to validate arguments before running a function in a real application.

The matching call_id connects a function’s result to its request. Developers send that result back as a function_call_output item alongside the accumulated history. The distinction is important: support for function calling gives the model a way to request an action, not responsibility for executing the application’s business logic.

Streaming answers still need completion checks

Streaming lets an application show text as it arrives rather than wait for the full answer. The stream also carries reasoning, function-call and response-lifecycle events. Mistral identifies response.completed as the completion signal and tells developers to handle response.failed, response.incomplete and error events too. Receiving some text is therefore not the same as receiving a completed response.

For a first Python request, Mistral’s guide starts with the SDK installation below and a MISTRAL_API_KEY environment variable. Its examples call client.responses.create using mistral-large-4, high reasoning effort and a 4,096-token output budget. Those are the guide’s example settings, not universal requirements for every supported model.

pip install -U mistralai

Before generating an answer, developers can count input tokens—the units used to measure the request’s size—through POST /v1/responses/input_tokens. Mistral instructs them to send the same model, input, instructions and tools planned for generation. The endpoint returns an input_tokens count, making request measurement a separate step from producing the response.