Why does Codestral offer both codestral.mistral.ai and the la Plateforme endpoint?

## Two doors, one model family When people first wire up Codestral they hit an oddity: the docs show two different hosts. This is not a versioning accident and it is not two different models. It is two access paths with different credentials, different intended audiences and different commercial terms. **`codestral.mistral.ai`** — the dedicated code endpoint. It carries the code-oriented routes: `/v1/fim/completions` for fill-in-the-middle and `/v1/chat/completions` for instruct-style code chat, for Codestral models. It authenticates with a **Codestral API key**, which is issued separately from your normal platform key and is oriented at developers wiring the model into an editor. **`api.mistral.ai`** — la Plateforme, the general API. Codestral is one model among many here, sitting next to `mistral-embed`, the OCR route, batch jobs and every chat model. It authenticates with your standard workspace API key, bills per token like everything else on the platform, and is governed by your workspace rate limits. ## The rule that bites people **Keys are not interchangeable.** A workspace key does not authenticate against the dedicated code endpoint, and a Codestral key does not unlock the rest of la Plateforme. The resulting failure is a plain `401`, which is easy to misdiagnose as a typo or an expired secret when it is actually the wrong pairing of host and credential. The defensive design is boring and effective: treat base URL and API key as a single configuration unit. One environment variable pair, validated together at startup, never two independently-set values that can drift apart between environments. A smoke call at boot that fails loudly beats a `401` discovered by a user mid-keystroke. ## Choosing between them For a production service that already talks to Mistral for other things — chat, embeddings, OCR — la Plateforme is the simpler answer. One key, one billing surface, one set of rate limits to reason about, one place to look at usage, and no second credential to rotate. The operational cost of a second key is real and recurring. The dedicated code endpoint earns its place when Codestral usage is separable from everything else: an editor plugin, a developer-tooling product, or a team that wants code-completion spend isolated from platform spend. Its commercial terms have been aimed specifically at that IDE-integration audience. A third path exists and belongs in the same conversation: Codestral's weights can be self-deployed, which moves the question from "which hosted endpoint" to "hosted or on our own hardware" — relevant when source code cannot leave your network at all. ## What does not differ The request shape. FIM is FIM on either host: `prompt` for the code before the cursor, `suffix` for the code after it, and the model returns the middle. Response envelopes match too. So porting an integration from one host to the other is genuinely a base-URL-plus-key change — provided the routes you use actually exist on the host you are moving to. That caveat matters in the other direction: the dedicated code endpoint is code-only, so an application that also calls embeddings, OCR or batch jobs must talk to la Plateforme for those regardless. ## Version caution Hosted product packaging is the fastest-rotting part of any vendor's surface, faster even than model names. The endpoint split, the key types and the commercial terms described here reflect the situation as of mid-2026. The durable interview answer is the *shape* of the arrangement — a dedicated code front door with its own credential versus the general platform key — plus the operational discipline of pinning base URL and key together. Reciting a specific price or free-tier allowance is exactly the kind of claim that will be stale by the time you are asked it.