Mistral adopts OpenAI's Responses format and welcomes two new competing models

Mistral launches an API compatible with OpenAI's Responses format and hosts two economical models from DeepSeek and Z.ai for AI agents.

Build an agent with Mistral models while retaining the API format popularized by OpenAI, then access Chinese models from the same cloud infrastructure. Mistral AI is evolving its developer platform with three new features: the arrival of the Responses API in public preview, the hosting of DeepSeek V4.1 Flash, and the general availability of GLM 5.3 Flash.

The announcement goes beyond simply adding new models. It reflects an evolution in Mistral's positioning, as it seeks to become an execution platform for AI agents capable of hosting both its own technologies and those of competing labs. A Responses API Compatible with OpenAI's Format

Mistral introduces a new programming interface using the OpenAI Responses API format.

This format organizes a model's outputs into several distinct items. A response can notably contain text intended for the user, reasoning information, and function calls.

With the traditional Chat Completions API, developers primarily work from a sequence of messages. The Responses format allows for a more explicit representation of the intermediate operations required by an agent.

When a model wants to query a database or trigger a function, this call can appear as a dedicated item, complete with its name and arguments.

The application then executes the operation and passes its output back to the model so it can continue the conversation.

This separation makes it easier to process the different steps of a workflow, particularly when the agent needs to alternate between reasoning, content generation, and tool usage.

The API works with conversational models hosted by Mistral, subject to the features supported by each, including Mistral Large 4. Text, Images, Documents, and Functions in a Single Interface

The Responses API documentation describes several capabilities already available during this preview.

Developers can send text, attach images to vision-compatible models, transmit documents, and request structured responses in JSON format.

The interface supports JSON schemas, which are useful when the output must strictly follow a precise structure to be processed directly by an application.

It also allows responses to be received progressively via streaming. Events can describe the arrival of text, arguments for a function call, or different execution steps.

Reasoning management depends on the chosen model. Some accept a `reasoning.effort` parameter, allowing developers to select an effort level tailored to the task.

Reasoning can also appear as a separate output item when supported by the model. This does not mean that all models expose the same level of detail, nor that an application automatically receives the entirety of their internal calculations.

Finally, the interface offers an endpoint to count input tokens before running the generation. An Important Difference: The API Does Not Persist Conversations

Despite its format compatibility with OpenAI, Mistral's new API features a major operational difference.

It is stateless, meaning it does not preserve conversational state on the API side.

Developers must maintain the exchange history themselves and resend it in every new request.

This history must include previous messages, as well as items generated by the model—such as function calls—and the corresponding execution outputs.

At this stage, Mistral does not offer the ability to resume a conversation simply by passing the ID of a previous response. The `previousresponseid` and `conversation` parameters cannot be used to retrieve a saved state on the server.

This approach may suit applications that want complete control over how they preserve their context and exchanges. However, it implies greater responsibilities for developers.

Compatibility therefore applies to the format of requests and responses, not to the entire feature set of OpenAI's Responses platform.

Furthermore, background deferred execution mode is not available in this preview: responses are generated during the active request. DeepSeek V4.1 Flash Joins Mistral's Cloud

Alongside this new API, Mistral is starting to host DeepSeek V4.1 Flash 1017, offered in public preview.

The model is developed by DeepSeek and distributed with open weights. Mistral specifies that it is served without any modifications on its part.

It specifically targets coding on long contexts and agentic tasks involving multiple tools or execution steps.

Its context window reaches one million tokens, with an announced maximum output length of 128,000 tokens.

The model is accessible under the ID `deepseek-v4-1-flash-1017`.

Mistral's published public pricing is as follows:

Usage · Price per million tokens Input tokens · $0.30 Cached input · $0.007 Output tokens · $1.20

The difference between standard input pricing and cached input pricing is significant for agents that regularly reuse long contexts, such as code repositories or reference documents.

However, actual availability and billing conditions for caching depend on the service's settings and operation. GLM 5.3 Flash Available in Stable Version

The second model added to the offering is GLM 5.3 Flash, developed by Z.ai.

Unlike DeepSeek V4.1 Flash, it is offered in General Availability (GA), a status intended for production workloads.

It is a multimodal Mixture-of-Experts model featuring 320 billion total parameters, of which approximately 18 billion are activated.

Its context window also reaches one million tokens, with a maximum output capacity of 128,000 tokens.

Mistral positions it particularly for coding agents, interface creation, and systems that need to execute numerous tool calls.

GLM 5.3 Flash is offered under the ID `zai-glm-5-3-flash`.

Usage · Price per million tokens Input tokens · $0.15 Cached input · $0.03 Output tokens · $0.50

These rates are lower than those for DeepSeek V4.1 Flash for standard input and output. DeepSeek, on the other hand, shows a lower price for cached input.

This comparison alone is not enough to determine which of the two models is more cost-effective in a real-world application. The