Mistral Responses API vs OpenAI Responses API

According to Mistral's documentation, its Responses API uses the OpenAI Responses format for text, image and file input, function calls and streaming. It is a public preview, it is stateless, background must be false, and its documented tools are function and namespace tools only.

At Layer3Labs, we build custom agents and enterprise integrations for small and mid-sized businesses.

OpenAI stores responses by default and lets you chain context with previous_response_id. Because the request format is shared, a stateless text-and-function agent may need only small changes, while code that relies on stored state, background runs or OpenAI's built-in tools must change.

Mistral Responses API vs. OpenAI Responses API: Side-by-Side

Are you one of these vendors? Update your listing

What Carries Over and What Breaks in the Schema

Mistral's POST /v1/responses reference documents the OpenAI Responses request and response shape for core generation tasks. In our side-by-side reading of Mistral's and OpenAI's documentation, we listed the shared attributes alongside the parameters Mistral's reference says must be omitted, null or fixed. Check any row against the Mistral Responses guide, the Mistral reference linked above, the OpenAI Responses create reference and the OpenAI migrate-to-Responses guide.

Mistral's reference requires model and input. Optional fields include instructions, reasoning, text.format, tools, tool_choice, parallel_tool_calls, temperature, top_p, max_output_tokens, metadata, prompt_cache_key and stream. For structured output, text.format accepts plain text, JSON mode, and JSON Schema definitions. When processing multi-modal content, Mistral accepts text input and image input via HTTPS URLs or base64 data URLs with a vision-capable model. It also accepts document file input via HTTPS URLs, base64 data URLs, or uploaded file identifiers in user messages.

Several request settings must change before an OpenAI agent can target Mistral. Mistral requires that store is omitted, false, or null, and that background is set to false. Parameters including prompt, moderation, and previous_response_id must be omitted or set to null. Mistral accepts max_tool_calls but ignores it. Mistral specifies that truncation must be set to disabled, meaning your input payload must fit entirely within the target model context window.

Stored by Default vs Stateless Conversation State

OpenAI and Mistral take opposite architectural baselines regarding conversation state management. According to the OpenAI migrate-to-Responses guide, the OpenAI Responses API stores interaction histories on its servers by default. Developers pass a previous_response_id to link sequential requests, allowing OpenAI to reconstruct context automatically while re-billing prior input tokens. Organizations subject to Zero Data Retention policies cannot use this server-side state and OpenAI enforces store false for them, using encrypted reasoning items to preserve multi-turn reasoning context.

Mistral's reference documents no server-side state in its public preview. It says store must be omitted, false or null, conversation must be omitted or null, and previous_response_id must be omitted or null. If your application relies on OpenAI holding message history, porting to Mistral requires moving state storage to your application layer.

To maintain multi-turn conversations on Mistral, your application must reconstruct the entire transcript inside the input array on every turn. Mistral returns an output array containing message objects, reasoning blocks, and function_call items. Each response carries a status of completed, failed, in_progress, cancelled, queued or incomplete, and usage reports input_tokens, cached_tokens, output_tokens, reasoning_tokens and total_tokens. To issue a follow-up prompt, you must append all prior output items from the previous turn into your new request's input array, followed by the next user message. For tracking inference expenses across these expanding stateless payloads, compare rates on our AI model pricing guide.

Client Function Calling and Built-In Tool Capabilities

Tool execution models differ between Mistral and OpenAI. OpenAI's migration guide lists these built-in tools: web search, file search, computer use, code interpreter, remote MCP servers and image generation.

Mistral supports client-executed function tools and namespace tools. Mistral's output array can contain function_call items. Your application runs the function, then sends the result in a later request as a function_call_output item with the matching call_id. Mistral advises validating arguments before running a function.

If your OpenAI agent relies on built-in file_search or web_search, Mistral documents function and namespace tools only, so search logic would move into your own functions. If you are weighing Mistral against other model providers, see our Mistral alternatives comparison.

Streaming and Token Limits on Mistral

Mistral's Responses API streams only when you set stream to true, because stream defaults to false. With stream set to true, the server returns server-sent events, and in the Mistral SDKs each frame's content is in data. Generated text chunks arrive through response.output_text.delta events containing sequence_number, item_id, output_index, content_index, delta, and logprobs fields.

Beyond text deltas, your client must handle response.completed to identify a normal finish, alongside response.failed, response.incomplete, and error events. Other streaming events cover reasoning, function calls, and lifecycle updates. Check the status field to see whether generation finished, and read error and incomplete_details when a response fails or stops early.

The max_output_tokens parameter caps reasoning tokens and answer text together. To verify prompt sizes before running execution, submit your intended input, instructions, and tools to POST /v1/responses/input_tokens to return the calculated input_tokens value. Requests accept a prompt_cache_key field. Responses return prompt_cache_retention as in_memory or 24h.

→ Compare per-token pricing for every AI model

A Migration Checklist for Moving Code to Mistral

To move an agent from OpenAI to Mistral's Responses API, change the client configuration, strip the state parameters and replace any built-in tools. Run pip install -U mistralai in Python or npm install @mistralai/mistralai@latest in Node.js, authenticating via the MISTRAL_API_KEY environment variable.

In the official documentation examples, Mistral demonstrates the endpoint using the mistral-large-4 model configured with reasoning effort set to high and max_output_tokens set to 4096. Mistral's documentation does not provide an exhaustive catalog of all models supported on POST /v1/responses and notes that valid reasoning effort values depend on the specific model selected.

Review your request payload against each step in the checklist below before submitting requests to the preview endpoint.

• 1. Update endpoint routing: point your HTTP client to POST /v1/responses or initialize the official Mistral software development kit
• 2. Supply credentials: set MISTRAL_API_KEY
• 3. Set a valid model: configure model to a Mistral model that works on this endpoint (the documentation's examples use mistral-large-4) and choose an allowable reasoning effort
• 4. Strip server-side state: remove previous_response_id, conversation, prompt, and moderation fields, or ensure they are set to null
• 5. Enforce stateless flags: ensure store is omitted, false, or null, set background to false, and set truncation to disabled
• 6. Replace built-in tools: migrate any OpenAI web_search, file_search, or code_interpreter references to client-side function definitions
• 7. Implement turn history: update your client loop to store response output items and re-inject them into the input array on the next turn
• 8. Handle streaming events: parse server-sent events listening for response.output_text.delta, and handle terminal states including response.completed, response.failed, response.incomplete, and error

Who Should Wait Before Adopting Mistral's Responses API

Mistral's Responses API is in public preview. Teams that cannot accept a public preview for production should wait. Mistral's documentation says to contact support with issues or feedback.

Teams whose architectures depend on background processing or asynchronous completion queues should also wait. OpenAI's create reference has an optional background boolean that runs the model response in the background. Mistral requires background to be false, so code that relies on background runs must change.

Teams that rely on OpenAI's file_search, web_search, code interpreter or computer use should wait too, because Mistral's documented tools are function and namespace tools only.

The Verdict

Move your stateless text generation and client-executed function calling agents to Mistral's Responses API first. Mistral documents the OpenAI Responses format for text, image and file input, structured output, streaming and function calls. A stateless text-and-function agent may need only small changes: change the model name, endpoint and credentials, then resend output items every turn.

Keep OpenAI for workloads that depend on server-side persistence, background asynchronous execution, or built-in runtime tools. Keep OpenAI if your software uses previous_response_id to offload history management or runs background queries via background: true. If you replace OpenAI's built-in web search, file search, code interpreter or computer use, you must supply those capabilities through your own functions.

Wait if production cannot accept public previews. Our recommendation would change if Mistral leaves public preview or adds stateful or built-in tools. Latency, token cost for a given task and edge-case differences are not established by the documentation. Start with one stateless text-and-function agent and work through the migration checklist above.