Mistral's Responses API opens in public preview

What Mistral shipped

Mistral has moved its Responses API into public preview, according to the company's documentation. The API lets developers build with Mistral models using the OpenAI Responses format, which means the request and response shapes follow a specification many teams already use with OpenAI's models.

The documentation says the API is intended for both new applications and existing Responses integrations being brought to Mistral. The supported work is ordinary model work: generating text, asking questions about images and documents, calling developer-defined functions, and streaming answers as they are generated.

What the preview supports

The feature list, as published, is broad. Text input and output can be plain strings or message arrays. Image input accepts image URLs and base64 data URLs in user messages and function results, with a vision-capable model. File input accepts HTTPS URLs, base64 data URLs and uploaded file IDs, again in user messages and function results.

Structured output is available through JSON mode and JSON Schema via text.format. Streaming produces Responses events for text and function arguments. Function calling is client-executed, including namespaces, and the documentation shows the standard loop: the model returns a function name and arguments, the application runs the function, and the result goes back with a matching call_id.

Reasoning is configurable through reasoning.effort with plaintext reasoning, depending on the model. There is also an input token counting endpoint, POST /v1/responses/input_tokens, which takes the same model, input, instructions and tools a request would use and returns the input token count.

The structured-output options are not the same thing: JSON mode constrains the response to valid JSON, while a JSON Schema also constrains its shape, which matters when downstream code parses specific fields.

Stateless by design, and what that costs

The API is stateless. The documentation is explicit: the application keeps the conversation history and sends it in input with each request, including the output items from earlier responses. To continue a conversation, you append the model's output to your history and add the next user message.

That design puts the burden of context management on the application, and it has a cost model attached. Every turn resends the prior conversation, so longer conversations consume more input tokens per request. Teams that want stored conversation objects, automatic history handling or server-side state will not find it here; teams that want control over what the model sees will.

The documentation's token counting endpoint is relevant for exactly this reason: with history resent each time, estimating request size before sending becomes a routine cost-control step. It is a small feature that follows directly from the stateless architecture.

Streaming adds client work as well. The documentation says applications should handle response.failed, response.incomplete and error events, not only the completed event that marks a finished response.

Adopting a rival's format is the strategic choice

The interesting decision is not any single feature. It is that Mistral built the API around the OpenAI Responses format. That lowers the cost of switching or running both providers: the same SDK calls, the same event names, the same function-calling loop, and the same structured-output mechanism can point at a different base URL and model.

For developers this is a portability benefit. It also means the differences that matter become provider-specific: which models support vision, which support reasoning effort and at what levels, how the input file IDs work, and where the two implementations drift as the format evolves. Compatibility is a starting point, not a guarantee that behaviour is identical.

The documentation's examples use mistral-large-4 with high reasoning effort and a 4,096-token output budget, and it advises choosing a reasoning effort the selected model supports. That sentence is the practical warning: the format is shared, but capabilities are not.

If the two formats diverge, the portability benefit shrinks, and nothing in the documentation commits Mistral to tracking future versions of the OpenAI specification.

What the documentation does not settle

The documentation reviewed here does not publish pricing, rate limits, a service-level commitment, or a timeline for general availability. It labels the API a public preview and asks users to contact Mistral support with issues or feedback, which is standard for a preview but also means the interface can change.

It also does not describe data retention in detail. Stateless here refers to conversation state being held by the application, not necessarily to how request data is logged or retained on Mistral's side. Teams with compliance requirements should read the privacy and data-handling terms rather than infer them from the word stateless.

Finally, there is no independent performance data. The documentation is a product specification, not a benchmark, and nothing in it establishes latency, throughput or quality relative to other providers offering the same format.

The documentation also does not list which models support vision, reasoning or structured output; it points readers to separate Vision and Reasoning pages for those details.

How to read the release

The concrete facts are that the Responses API is in public preview, it follows the OpenAI Responses format, it is stateless, and it supports text, image and file input, structured output, streaming, client-executed function calling, configurable reasoning effort and input token counting. SDKs are available for Python and JavaScript, and the examples use mistral-large-4.

The reasonable reading is that Mistral is competing for workloads that are already written against a rival's interface. That is a pragmatic play: it meets developers where their code is. It does not, by itself, show the models are better, cheaper or faster, and the documentation does not claim so.

For a developer deciding whether to use it, the test is narrow. Port an existing Responses integration to Mistral, run the same prompts, and check three things: whether the model's output quality is acceptable, whether the reasoning and tool-calling behaviour matches what the application expects, and whether the per-request cost with resent history stays inside budget. Until that is measured, the release is a door opening, not a result.

The setup is ordinary: install the SDK with pip install -U mistralai or npm install @mistralai/mistralai@latest, and set MISTRAL_API_KEY. The preview label is not decoration: until Mistral says otherwise, teams should treat the interface as movable. The documentation lists the preview's supported features but does not give a date for general availability. Related coverage includes Mistral Large 4 open weights, Notion 3.8 agent context, and Products. Agent tooling on the OpenAI side is covered in the site's report on OpenAI Dots.