Mistral opens Responses API preview in OpenAI's format for AI agents
Unicorn News Desk ·
Key facts
- Released
- October 28, 2026, public preview
- Format
- OpenAI Responses format
- State
- Stateless: the app sends conversation history each time
- Output
- Answer, reasoning and tool calls as separate items
- Models
- All Mistral-hosted chat models, including Large 4
Mistral AI has opened a Responses API in public preview, a new interface for building agents on its models, the company said on Wednesday, October 28. The key fact for developers: it uses the OpenAI Responses request format, so applications written against that format can be pointed at Mistral models.
Each response returns the model’s answer, its reasoning and its tool calls as separate items, which Mistral says lets applications handle each step more easily than with its existing Chat Completions interface. The API works with all chat models hosted by Mistral, including Large 4.
What Mistral’s Responses API changes over Chat Completions
Until now, Mistral’s main text interface has been Chat Completions, which the company describes as following the same request structure as OpenAI’s Chat Completions API. That design made migration simple: for most applications, switching meant changing the client import, the initialization call and the model name.
The Responses API is a different shape of interface. Instead of returning a single chat message, each response carries an output array that can contain the model’s messages, its reasoning and any function calls, according to Mistral’s documentation. A “function call” here means the model asking the application to run a piece of code the developer defined, such as a database lookup, and return the result.
Separating those pieces matters for agents, which are programs where a model plans, calls tools and acts across several steps. Mistral’s pitch, as reported by Crypto Briefing, is that splitting answers, reasoning and tool calls into distinct items lets an application process each step more easily than the Chat Completions format allows. That is Mistral’s claim; the sources contain no independent comparison of the two interfaces.
Mistral’s documentation says the API works well both for new applications and for bringing an existing Responses integration to Mistral. The company’s migration guide now directs developers whose code calls client.responses.create() to the new Responses API guide rather than the Chat Completions path.
What the public preview supports
Mistral lists the features available in this preview. They cover the core building blocks of a typical agent loop:
| Feature | What the preview supports |
|---|---|
| Text | Input and output as strings and message arrays |
| Images | Image URLs and base64 data URLs in user messages and function results, with a vision-capable model |
| Files | HTTPS URLs, base64 data URLs and uploaded file IDs in user messages and function results |
| Structured output | JSON mode and JSON Schema via text.format |
| Streaming | Responses events for text and function arguments |
| Function calling | Client-executed functions, including namespaces |
| Reasoning | reasoning.effort and plaintext reasoning, depending on the model |
| Token counting | POST /v1/responses/input_tokens |
Source for table rows: Mistral documentation.
A few details stand out. Images and files can be passed not only in user messages but also in function results, which means a tool can hand a document or picture back to the model mid-task. For file input, developers set exactly one of file_url, file_data or file_id as the file source. Structured output covers both JSON mode and JSON Schema, the latter being a way to force the model’s reply to match a defined data structure.
The input token counting endpoint lets an application check how many tokens a request will use before sending it, which helps with budgeting long agent conversations.
Function calling in the preview is described as “client-executed”: the model requests a call, and the developer’s own code runs it and returns the result.

A stateless design: the app keeps the history
The most important architectural detail for builders is that Mistral’s Responses API is stateless. In Mistral’s words, the application keeps the conversation history and sends it in input with each request, including the output items from earlier responses.
In practice, a multi-step agent has to store every turn itself, including the reasoning items and function calls the model produced, and replay them on the next call. The migration guide repeats the point and advises developers to check the supported features before migrating. Teams porting an existing Responses integration should confirm whether their code relies on any behavior outside Mistral’s supported list.
The upside of stateless design is that the application keeps full control of what is sent and stored. The cost is that request sizes grow with conversation length, which is where the token counting endpoint becomes useful.
How to start, and which models work
Mistral’s documentation shows getting started with its own SDK, installed with pip install -U mistralai or npm install @mistralai/mistralai@latest, and an API key set in the MISTRAL_API_KEY environment variable. The prompt goes in the input field. The examples use mistral-large-4 with high reasoning effort and a 4,096-token output budget.
Model choice affects what works. Mistral notes that if developers switch to another model, they need to pick a reasoning effort that model supports, and image understanding requires a vision-capable model. Crypto Briefing reports Mistral as saying the API works with all chat models it hosts, including Large 4.
Large 4 is itself still new. A Medium analysis of Mistral’s October 6 announcement describes Large 4’s API as being in public preview, with downloadable weights expected at the end of the month. That author states the piece does not include independent performance testing.
Access
- Status: public preview; Mistral asks users to contact its support with issues or feedback.
- Interface: OpenAI Responses format, through Mistral’s own SDKs in Python and TypeScript, with cURL examples also shown.
- Base URL: Mistral’s API lives at
https://api.mistral.ai/v1.

Why OpenAI compatibility matters for builders
Mistral has leaned on OpenAI compatibility before. Its migration guide says applications using OpenAI-compatible clients, such as LangChain or LlamaIndex, can point at the Mistral API by changing only the base URL and model name, with no library swap required.
Third-party tooling already builds on that compatibility. Kong’s AI Gateway documentation, for example, calls Mistral’s API OpenAI-compatible and shows a setup where client code talks to Kong with the stock OpenAI SDK and never imports a Mistral library. That recipe routes chat and embeddings, not the new Responses endpoint. Similarly, the AI SDK’s Mistral provider documents models that call the Mistral chat API. None of these third-party sources mention support for the new Responses API, so builders who depend on such layers should not assume it is wired through yet.
Kong’s documentation also flags a risk that applies to any easy integration: a Mistral API key is a single bearer token with account-wide scope, and usage reporting is per key rather than per caller. For agent workloads that make many calls across services, that is a reason to think about key management early.
Limits and open questions
- Preview status. The API is labelled public preview. The sources give no date for general availability.
- Feature coverage. Mistral lists the features available “in this public preview”, and the migration guide tells developers to review them before switching. Anything outside that list should be treated as unsupported until Mistral says otherwise.
- Model-dependent behavior. Reasoning options and plaintext reasoning depend on the model, so an agent tuned on Large 4 may need adjustments on a smaller model.
- No independent evidence yet. The claim that separate output items make agents easier to build comes from Mistral. The sources contain no hands-on reports or benchmarks of the preview.
Mistral’s announcement is also narrower than it might first appear: it is a new interface to existing models, not a new model. For developers, the main question is whether the format change and stateless design fit how their agents already manage history and tools.
What to watch next
Three things will show how far this goes. First, whether Mistral expands the supported feature list and moves the API out of preview. Second, whether gateways and SDKs that already wrap Mistral’s OpenAI-compatible chat API, such as Kong’s AI Gateway and the AI SDK, add the Responses endpoint. Third, the Large 4 open-weight release that commentators expected at the end of October, which would determine whether the model shown in Mistral’s Responses examples can also run on builders’ own infrastructure.
Frequently asked questions
What is Mistral's Responses API?
It is a new Mistral interface, in public preview since October 28, 2026, for building agents on Mistral models. It uses the OpenAI Responses format and returns the model's answer, reasoning and tool calls as separate items.
Is Mistral's Responses API compatible with OpenAI's?
Mistral's documentation says it lets developers build with Mistral models using the OpenAI Responses format, and that it suits bringing an existing Responses integration to Mistral. Only the features on Mistral's supported list are covered in the preview.
Which models work with the Responses API?
According to Mistral, as reported by Crypto Briefing, it works with all chat models hosted by Mistral, including Large 4. Image input needs a vision-capable model, and reasoning options depend on the model.
Does Mistral's Responses API store conversations?
No. Mistral describes the preview as stateless: the application keeps the conversation history and sends it in the input of each request, including output items from earlier responses.
Is it ready for production?
It is labelled a public preview, and Mistral asks users to contact support with issues or feedback. The sources include no independent testing, so builders should validate behavior on their own workloads.