Mistral puts a price on where your inference runs

The control surface is a base URL. Set it to api.eu.mistral.ai and the request is processed in the EU, which is what Mistral's documentation offers as data-residency support ^[2]. Two hostnames that differ by a few characters are a cheap place to hang a price increase, and a legible one: the uplift for regional processing sits on the same line as the routing decision ^[3]. The dev.to account of the announcement does not give a number for that uplift ^[10].

The missing number is the one that decides the design. Residency cost is multiplicative on traffic, so the real question is not whether to buy the EU endpoint but what share of requests has to use it. A team with clean data classification routes the regulated subset and pays the uplift on that subset. A team without it routes everything and pays on everything. That is a two-term product, and as reported, only one term is yours to measure.

Then read what residency actually covers. The source describes routing inference to a chosen region ^[2]. It does not describe where logs, caches, evaluation sets or tuning artifacts live ^[14]. Inference locality is one row in a data processing agreement, and the rest of the rows are what a compliance reviewer will ask about.

Third-party open weights arrive inside the same envelope, starting with GLM-5.2 from Z AI running alongside Mistral's own models ^[4]. The dev.to framing is that open weights and managed regional inference solve different problems, with a managed endpoint trading operational burden for a defined processing region ^[13]. What that leaves open, and what the material does not answer, is whether a third-party model served in-region carries the same residency terms and the same uplift as a first-party one.

The capacity leg is the part asking for a signature. European Compute Units are an effort to mobilize multi-year enterprise commitments to develop European compute capacity ^[5], and dev.to is explicit that this is an intention to coordinate capacity rather than capacity already in place ^[7]. The Priority Tier is described as SLA-backed for mission-critical workloads ^[6], with no availability target or credit schedule in the write-up ^[15].

That is what makes this a placement story rather than a model story. None of the four elements is a claim about how the models score on anything ^[11], and dev.to says as much when it argues the buying decision now includes where requests run, which open-weight models are supported and what capacity assurance is needed ^[9]. The same piece lists what does not change: someone still has to identify what data is sent to a model, choose the endpoint and model, test output quality and integrate the result with the applications people actually use ^[12]. Placement is now a purchasable line item, but the data inventory that tells you which line to buy still has to be built in-house ^[12].