Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Three reports in Mistral AI’s official Python-client issue tracker describe failures that can be easy to misread: transcription reportedly ignored a biasing option for URL-based audio, cached-token details reportedly arrived outside the SDK’s typed usage fields, and a missing API key reportedly went unnoticed until the first request. These are individual reports, not a confirmed list of current bugs. The reported package versions and what is—and is not—known about fixes matter when diagnosing them.

At a glance: what each report describes

Issue Reported version and scenario Reported behavior Fix status established by the cited report
#338 mistralai==1.12.0; transcription with file_url context_bias reportedly had no effect, although the request succeeded. No verified fix is established by the available issue information.
#572 mistralai==2.4.9, Python 3.12; chat completion usage metadata prompt_tokens_details reportedly appeared in the raw response but was not a declared, typed UsageInfo field. No verified fix is established by the available issue information.
#519 mistralai 2.4.5; client constructed without a key Construction reportedly succeeded; the missing credential surfaced on the first API call. The issue is marked closed, but the report does not identify a fix or release containing one.

Why might transcription ignore context_bias with a URL?

In issue #338, a user reported that a transcription request using file_url returned successfully but did not apply the supplied context_bias. The report identifies mistralai==1.12.0 and Python 3.12.3. It contrasts URL input with uploading the audio file, and attributes the behavior to request encoding when the files list is empty: the SDK allegedly sent application/x-www-form-urlencoded rather than multipart/form-data.

That encoding explanation is the reporter’s diagnosis, not an independently verified cause or confirmation of current behavior. A successful response alone does not show that the option was honored. If this resembles your result, compare URL-based input with an uploaded-file request and inspect the effective request format and response before concluding that the setting works.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The issue report proposes bypassing the SDK with a direct multipart curl request using -F flags. Treat that as a reported workaround, not a confirmed fix; consult the issue report for its exact example. The report does not establish whether a later package release corrected the behavior.

Why can cached-token details appear in the response but not the SDK attribute?

Issue #572 concerns chat completion usage data in mistralai==2.4.9 on Python 3.12. The reporter says the raw HTTP response contained prompt_tokens_details, including cached_tokens, but the SDK’s UsageInfo model did not declare that field. According to the report, the extra data remained an untyped dictionary; code expecting a typed attribute could see None and mistakenly interpret it as zero or no cached tokens.

When investigating, distinguish the wire payload from the parsed SDK object. If the raw response contains the field but typed attribute access does not, those observations point to different layers: the server response may include the detail while the client model does not expose it as a declared field. Do not treat a missing typed attribute as proof that the raw response had no cached-token detail.

This is the issue author’s account, not independent confirmation of current API responses or client behavior. The report does not establish a release that fixes or changes the model. See issue #572 for the reported details.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why does Mistral() accept a missing API key until a request?

In issue #519, a user reported that Mistral() could be constructed without an explicit API key and without MISTRAL_API_KEY; the configuration problem appeared only on the first API call. The report identifies mistralai 2.4.5. This distinction matters: successful client construction does not necessarily verify that credentials are available or that a request can authenticate.

The issue page is marked closed, but its text does not say what change closed it or identify a release containing a fix. Do not infer from the closed status that a particular version now fails early. Check your key configuration explicitly and test an actual API request in the environment where the application runs. The official client repository documents API-key setup: Mistral’s Python client repository.

Check the SDK generation before applying an example

Mistral’s migration guide maps v1 to mistralai<2 and v2 to mistralai>=2. It also changes the client import: v1 uses from mistralai import Mistral, while v2 uses from mistralai.client import Mistral. A reproduction or workaround written for one generation may not apply unchanged to the other.

Identify the installed version and match your import and request shape to that version’s documentation before adapting an issue example. The reports above concern specific package versions; they should not be read as proof that the same behavior exists in every v1 or v2 release. See the official migration guide.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Check package safety before installing or upgrading

A separate official repository security advisory identifies PyPI mistralai==2.4.6 as malicious and says versions 2.4.5 and earlier were not known to be affected at the time of that advisory. It recommended pinning to 2.4.5 or earlier while the PyPI project was quarantined. This is separate from the three behavior reports above; none of them is evidence of a connection to the package compromise.

Advisory and quarantine status can change. Before installing, pinning, or upgrading, check the official security advisories for current guidance. Do not use the historical recommendation as current installation advice without verifying it.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.