MistralModel breaks with mistralai SDK v2.0 (import path change)

[Autopsias]

Description

mistralai v2.0.0 (released 2026-03-11) changed the import path for the Mistral client class:

# v1.x
import mistralai
mistralai.Mistral(...)  # works

# v2.x  
import mistralai
mistralai.Mistral(...)  # AttributeError: module 'mistralai' has no attribute 'Mistral'

# v2.x correct import:
from mistralai.client import Mistral

The strands.models.mistral module uses import mistralai at line 11 and mistralai.Mistral(...) at lines 431, 439, 532, which breaks with v2.0.

Since strands-agents doesn't pin mistralai<2.0, installing/upgrading in a fresh environment pulls v2.0.4 and breaks all Mistral model usage.

Impact

• Any new installation of strands-agents[mistral] fails
• pydantic-ai hit the same issue (Mistral import break on v2.0.0 pydantic/pydantic-ai#4625)
• Users must manually pin mistralai<2.0 as a workaround

Suggested Fix

Add a compatibility shim in strands/models/mistral.py:

# Support both mistralai v1.x and v2.x import paths
try:
    from mistralai.client import Mistral as MistralClient
except ImportError:
    from mistralai import Mistral as MistralClient

Then replace mistralai.Mistral(...) with MistralClient(...) at lines 431, 439, 532.

Alternatively, pin mistralai>=1.9.11,<2.0 in the [mistral] extra dependencies until a full v2 migration is done.

Reproduction

pip install 'strands-agents[mistral]'
# Pulls mistralai 2.0.4

python -c "from strands.models.mistral import MistralModel; print('OK')"
# Works (import doesn't trigger the error)

# But using the model fails:
python -c "
from strands.models.mistral import MistralModel
import asyncio
m = MistralModel(model_id='mistral-small-latest')
# Any call that triggers stream() or structured_output() will fail with:
# AttributeError: module 'mistralai' has no attribute 'Mistral'
"

Environment

• strands-agents: 1.19.0
• mistralai: 2.0.4 (breaks) / 1.12.4 (works)
• Python: 3.11

[shivamnegi1705]

Hi @Autopsias , can you assign this issue to me ?

[mkmeral]

Created a fix to pin the upper bound (#1935). Also created a ticket to followup with v2 upgrade #1936

[raye-deng]

This is a textbook example of what makes AI-generated code fragile at scale. The import path mistralai.Mistral was valid when the training data was collected, and any AI coding tool will confidently generate it — because it was correct. The breakage only surfaces in production when someone installs fresh without pinning.

The compatibility shim approach you suggest is the right short-term fix. But the deeper problem is systemic: every SDK major version bump creates a window where AI-generated code silently targets the wrong API surface. We've cataloged five variants of this pattern:

1. Import path migration (this issue) — module restructured, old path raises AttributeError
2. Method signature change — parameters renamed or reordered, TypeError at runtime
3. Return type change — method returns different structure, downstream code silently processes wrong data
4. Deprecation removal — API worked in pinned dev version, removed in latest production version
5. Default behavior change — same method name, different semantics (most dangerous because no error is raised)

All five pass linting, type checking, and unit tests if the test environment has the old version pinned. The breakage is only detectable by validating against the actual current API surface.

We built a CI scanner specifically for this class of failures — it checks imports, API calls, and dependency versions against live registries rather than trusting what the model "remembers": npx @opencodereview/cli scan . --sla L1

[mkmeral]

+1 on the problem space ^. I think this is a common problem, and it's why I love open source dependencies. You can just give the source code to the agent, and be like "here's the problem, here's my code and all the dependencies. go figure it out" :)

That said, the issue is fixed, we have released a new version with the fix merged above, closing this ticket.