# Mistral Responses API: OpenAI Compatibility and the Limits of the Preview

Mistral adds the Responses format, but developers still own conversation history and tool execution.

By Paras Madan | 2026-10-29


Mistral has opened its Responses API in public preview, giving developers another way to call Mistral models using the OpenAI Responses format. The useful change is a more familiar interface for applications built around typed model outputs, streaming and tool calls. It does not make every Responses feature portable.

## What the Mistral Responses API supports

The [official guide](https://docs.mistral.ai/studio/conversations/responses) documents text, image inputs for compatible models, file inputs, structured outputs and function calling. Streaming returns typed events rather than requiring an application to treat everything as a growing text string.

Developers can use the latest Mistral SDK with a Mistral API key. Reasoning controls depend on the selected model. Choosing the new interface does not itself give a model additional modalities or reasoning capabilities.

For a developer already handling messages, reasoning items and function calls separately, this can reduce the amount of provider-specific translation around the model. That is an integration benefit, rather than evidence that two models will follow instructions identically.

## Conversation history stays in your application

**The preview is stateless.** To continue a conversation, the application must send the previous output items back as part of the next request's input. Function calls also remain client-executed: your code runs the requested function and returns its result in a later request.

Consider an agent that reads a document, asks a database for missing information and then writes a response. Moving that workflow involves preserving the model's output items and tool results across turns. Sending the latest user message alone is not an equivalent migration.

This makes multi-turn tests more useful than a successful first prompt. Check that tool-call identifiers, arguments and returned results survive the entire loop before changing a production route.

## OpenAI format does not mean full feature parity

The [API reference](https://docs.mistral.ai/api/endpoint/responses) makes several boundaries explicit:

| Field or feature | Current preview behavior |
| --- | --- |
| `previous_response_id` | Must be omitted or null |
| `conversation` | Must be omitted or null |
| `background` | Must be false |
| `store` | Must be omitted, false or null |
| `truncation` | Must be disabled |
| `max_tool_calls` | Accepted for compatibility, but ignored |

Applications therefore need their own history management, context budgeting and tool-loop limits. A request schema that accepts a field should not be mistaken for an implementation that enforces it.

The reference also defines `max_output_tokens` as including reasoning and answer tokens. That matters when a response budget appears generous but reasoning consumes part of it.

## Who should try the preview

Mistral's [API overview](https://docs.mistral.ai/studio) presents Responses alongside Chat Completions. Existing integrations do not need to switch simply because another endpoint exists.

The strongest reason to evaluate it is an application whose internal model interface already resembles Responses. Test one representative workflow, including its failure paths, before attempting a broad migration. Keep model quality, latency and cost evaluation separate from request-format compatibility.

A common interface becomes valuable when it makes switching providers less disruptive. The remaining engineering work is making sure that a familiar request still produces a workflow your application can safely control.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn API launches and engineering updates into clear stories developers read and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).