获取 Mistral API 密钥并跑通第一个请求：入口、字段与验证

调 Mistral API 用的密钥在 Studio 的 API keys 页面建，或者从用户资料菜单的 API Keys 进去；只有要管别人名下的密钥、按 Workspace 盘点整个组织，才走 Admin Panel › API › API Keys。密钥值只在创建成功的那一次显示出来，关掉对话框就查不到，当场复制进密码管理器。把值导出成 MISTRAL_API_KEY，向 Mistral 的 chat completions 端点发一次带 Authorization: Bearer 的请求，终端打印出模型回答，这条路就通了。没通先看错误码：401 查环境变量，402 到 Admin Panel › Subscriptions › Billing 补付款方式，429 按指数退避重试。

Mistral API 密钥在 Studio 和 Admin 里各从哪里建？

Studio 管自己名下的密钥，Admin Panel 管跨 Organization 的密钥，区别就在这里。文档把 API 密钥分成 Studio、Vibe、Mistral Code 三类，调用 Mistral API 的标准密钥只有 Studio 这一类，在 Studio 建好就能直接拿去发请求。

Studio 里显示的只是当前 active Workspace 的密钥，建出来的也落在它名下。点 Create new key 之前，先在 Studio 顶部的 Organization / Workspace 选择器里切到目标 Workspace，否则密钥会归到当时选中的那个 Workspace。公司组织下的账号还多一道：管理员通过 Workspace 的 API Key Creation 设置决定成员能不能在这个 Workspace 里建密钥，没被允许就建不了。直达地址：Studio 是 https://console.mistral.ai/api-keys，Admin Panel 是 https://admin.mistral.ai/organization/api-keys。

走哪条路只看一件事：要管的密钥是不是都在自己名下。都在自己名下，从 Studio 一次点完就好；一旦涉及别人的密钥，或者要按 Workspace 盘点整个组织的用量，就从 Admin Panel 进。

开发者入口：Studio 的 API keys 页面

自己用自己的密钥，Studio 这条最省事，文档写的范围是管理“keys you own”，列表按当前 active Workspace 显示。点 Create new key 之后，Studio 快速入门里的表单只有三项：Name、Expiration、Connector access scope，没有 Workspace 字段，归属看当时选中的是哪个 Workspace。Admin 和开发者都能从这里管自己名下的密钥。

管理员入口：Admin Panel › API › API Keys

这条路只面向 Organization Admin，创建、查看、轮换、删除都在整个组织范围内进行，创建时还要选定密钥归属哪个 Workspace，名称那一栏在这里叫 Key name。列表上有 active 与 expired 两种状态、密钥类型、所属 Workspace、最后使用日期和到期日期；从成员的用户详情面板，也能看到某个人名下的密钥。整个组织的密钥列表在这里都看得到，但完整的密钥值看不到。

平时只调自己的账号，这条路用不上。要给开发、预发、生产分发不同的密钥、再统一巡检，按 Workspace 排出来的这个视图会顺手很多。

创建密钥时那几项要填什么，哪些建完就改不了？

建完就锁死的是三项：Workspace、过期日期、Connector access scope，要换设置只能新建一把再把旧的删掉。名称只是标识，可以留空，也是最不用提前想的一项。

表单里每一项分别管什么

密钥归谁由 Workspace 决定，用它发出的请求消耗的就是那个 Workspace 的配额、速率限制与资源。想给开发、预发、生产分开，正确做法是分别建 Workspace，每个里面各建一把密钥，事后再改归属是行不通的。能用哪些 Connector 由 Connector access scope 决定：默认的 Shared connectors only 只能访问与该 Workspace 共享的 Connector；应用确实要用到创建者名下的私有 Connector，才选 Private and shared connectors。做自动化用默认值就够了。

两边的表单并不一样。Studio 那版没有 Workspace 这一项，密钥归属跟着当前选中的 Workspace 走；Admin 流程里才有选归属 Workspace 的那一步，名称栏在那里叫 Key name。

过期策略由两级上限约束

过期策略默认是关的。组织级的最长有效期由 Organization Admin 定，Workspace Admin 只能在里面设更紧的上限，不能超过组织那一层。这个策略管的是新建密钥的最长有效期，已经存在的密钥，包括本来就没填到期日的，照常可用到被撤销或到达原来的到期日。

服务端在 API 和 UI 两条创建路径上都执行这个策略，但不是拒绝创建：没填到期日、或者填的日期超出上限，密钥照样建出来，到期日被设成策略允许的最晚日期。团队打算统一轮换，趁第一把密钥还没建就把策略定下来会省事很多，之后日期选择器里只会出现允许范围内的日期；只是自己试一次请求，留空不设到期日也完全可行。

密钥只显示一次，保存、轮换和停用该怎么做？

完整密钥只在创建确认对话框里出现一次，界面一关就再也取不回来。值当场复制进密码管理器或机密保管库，别提交进版本库，也别贴进聊天窗口发给别人。

当场复制是唯一的时机

粘出来之后核对一下是不是完整字符串，别带着省略号，也别被编辑器截断。存进密码管理器或机密保管库，代码里只留变量名，真值靠环境变量注入。密钥丢了找不回来，只能重新生成一把。官方写明 API 密钥属于机密信息，不在组织内共享；Organization Admin 在列表里能看到条目，看不到完整的值。

轮换等于新建加删除

轮换就是新建一把、把调用迁过去、再撤销或删除旧的，界面上没有地方能改。创建之后 Workspace、Connector access scope 和过期日期都固定，换设置也只有这一条路。失效有两条独立路径：旧密钥被删除，或者过了到期日，任何一种都会让它发出的请求失败。

用最后使用日期做清理

Admin Panel 的列表标着每把密钥是 active 还是 expired，也标了最后使用日期，管理员靠这两栏认出没在用或者已经过期的。先处理长期没动过的那几把，比按创建时间猜哪个是废的靠谱。

怎么验证这把密钥真的能用？

验证就两个动作：把密钥导出成环境变量，发一次请求，看终端有没有打印出模型回答。官方快速入门列出的前置条件是机器上装好 Python 3.9+ 或 Node.js 18+、一个 Mistral 账号、一把密钥；curl 和 SDK 都行，判据是同一个。

先导出环境变量

export MISTRAL_API_KEY="您的密钥"

在哪个窗口导出，就在那个窗口继续操作。换一个新开的窗口或者别的会话，变量不会跟着走，后面撞上 401 最常见的原因就是这一条。Windows PowerShell 的写法不一样，赋值要写成 $env:MISTRAL_API_KEY = "your_api_key_here"。

再发一次请求

请求打到 https://api.mistral.ai/v1/chat/completions，头里带 Authorization: Bearer 和这个变量，body 里写 model 与 messages 两个字段：

curl https://api.mistral.ai/v1/chat/completions \
  -H "Authorization: Bearer $MISTRAL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"mistral-small-latest","messages":[{"role":"user","content":"Hello, Mistral!"}]}'

终端打印出模型回答，这把密钥就是可用的。model 照官方示例写就行，mistral-small-latest 或 mistral-large-latest 都可以。请求没有任何输出，先往下看错误码，别急着重建成新密钥。

SDK 走法一样。Python 装 pip install mistralai，TypeScript 装 npm install @mistralai/mistralai。官方的 Python 示例是 from mistralai.client import Mistral，client = Mistral(api_key=os.environ['MISTRAL_API_KEY'])，再 client.chat.complete(model="mistral-large-latest", messages=[{"role": "user", "content": "What is Mistral AI?"}])，把 response 打印出来就是模型回答。

一次成功响应确认了什么

一次调用成功，顺带确认了三件事：变量确实读到了，密钥没被撤销也没过期，这个 Workspace 当下的配额与速率限制放行了这次请求。把它放进冒烟测试，每次轮换密钥之后跑一遍，比事后从生产日志里翻 401 便宜。密钥一多，命名、归属和轮换节奏值得单独理一份，可以参考密钥管理的整理清单。

免费模式要不要信用卡，免费额度到底有没有？

不用信用卡。Studio 默认就在 Free mode 下开着 API 访问，用量和速率限制照样算，先建一把密钥把第一个请求跑通完全没问题。能用多少，看您自己账号的 Admin Panel › API › Limits 页。

密钥不按套餐划分

密钥这一层不分免费版和按量版。您不能创建一把 Free mode 密钥，也不能创建一把 pay-as-you-go 密钥；每把密钥自动沿用所属 Organization 的 Mistral 计划与按量付费设置。找不到“免费密钥”的入口是正常的，那个入口不存在。要调的是计划与付款设置，不是密钥类型，在这一层换 key 解决不了问题。

免费额度看账户里的 Limits 页

新账号默认就是 Free mode，可以创建密钥并使用计划内含的每月用量，上限以 Admin Panel › API › Limits 页显示的为准，公开文档里没有固定的 token 数字。帮助中心写的是 Free mode 限制最低，用途是评估和原型。内含月用量跑完之后，开了 pay-as-you-go 就按 token 计费；没开的话，用量可能停到下一个计费周期。

速率限制挂在谁的头上

官方列出的限额有三类：Requests per second、Tokens per minute、Tokens per month。层级规则在帮助中心：开启 pay-as-you-go 进入 Tier 1，累计账单超过 20 / 100 / 500 美元或欧元，依次升到 Tier 2、Tier 3、Tier 4；预充值额度不会提高层级。每个模型的具体数值在 Admin Panel › API › Limits 页。

分 Workspace 能确定分开的是月度支出上限与用量统计。开发和预发各放一个 Workspace，账单和用量那一栏会清楚很多。撞到限额提示，先看请求打在哪个 Workspace 上，而不是先去换密钥。

401、402、429 出现时分别该改哪里？

先看错误码，反复重建密钥没有用。401 指向密钥本身，402 指向账号的付款方式，429 指向速率限制，三件事的修复入口完全不在同一个地方。

先分类，再动手

三种错误各自的修复入口

401 先排除最常见的一种：变量名拼错、在另一个终端窗口里没有导出，或者只写进了配置文件却没加载进来。echo 一下就看清了。变量确实有值却仍然 401，再看密钥是不是已经被撤销、已经过期，或者用的是另一个 Workspace 的密钥；官方列出的常见原因还包括没带 Authorization 头。

402 跟密钥本身无关，密钥看着完全正常也可能撞上，原因是账号上没有付款方式，到 Admin Panel › Subscriptions › Billing 补上就行。另外，内含月用量用完之后如果没有开启 pay-as-you-go，用量可能停到下一个计费周期。

429 是等一会儿的事，常见原因是每秒请求数过多、每分钟 token 配额用完，或者并发请求数到了上限。官方的做法是等待后用指数退避重试，并查看 Retry-After 响应头；官方 Python 与 TypeScript SDK 自带指数退避重试，可以直接用。当前限额在 Admin Panel › API › Limits 看，按模型分别列出 Tokens per minute 与 Requests per second。

第一次请求最容易撞上的其实是 400 和 404。400 说明 JSON 语法有错，或者缺了 model 或 messages 字段；404 是模型 ID 或端点路径不对，已经退役的模型标识符也返回 404。403 的常见原因之一是模型不在当前订阅层级内。这几种都是请求本身写错了，改请求体比换密钥快。

这三行也可以直接写进密钥交接文档：401 归创建密钥的人查，402 归管账号计费的人补，429 交给调并发的人看。归属写清楚，失败时就不会所有人都去点 Create new key。

密钥由多人维护的话，交接文件至少写明 Workspace、创建人、到期日、Connector access scope 和最后一次成功请求的时间；完整密钥本身只放在密码管理器或机密保管库，文档里只保存名称与状态。到期策略改变的是新建密钥的最长有效期，已经存在的密钥仍按原来的撤销或到期条件处理，不能用修改策略代替轮换。

要把调用交给 CI，变量注入、请求地址和 model 都放在部署记录里，密钥值只在机密存储中出现。先在临时 Workspace 发一条最小请求，再把同一请求带到生产 Workspace，两边都成功了再删旧环境的变量。

这样分层判断很省时间：同一把密钥换个 model 名就好了，问题在请求体；同一个 Workspace 里另一把密钥能成功而这一把不行，先回看密钥状态；两把都失败，再去查付款方式、速率限制和端点本身。

想让一把密钥调用多个模型，有什么更省事的接法？

在 Mistral 这边换模型不用新建密钥，改请求里的 model 字段就行，同一把密钥可以指向不同模型。

在 Mistral 里换模型只改 model 字段

模型名写在请求体里，密钥负责认证，两者分得很开。从 mistral-small-latest 换到 mistral-large-latest 就是改一个字符串，不需要重新申请密钥，也不需要动环境变量。密钥要控制的不是能调哪个模型，而是属于哪个 Workspace、能用哪些 Connector。

单 key 多供应商的接法

如果之后要在多个供应商之间切换，每换一家就重建密钥、重配账务会很碎。MixRoute 把这层收在一把 key 上：base URL 指向 https://api.mixroute.ai/v1，OpenAI SDK 那边模型名照写，覆盖 250+ 模型，模型 ID 与单价可以在模型目录里逐个核对；走 Anthropic SDK 的 Messages API 时，base URL 不带 /v1，沿用同一个 client 和 client.messages.create 即可。要不要把多供应商调用合并到一把 key，先看这一层：先看清各模型的计价口径再决定要不要合并到一把 key。

key 层级上的模型范围与支出预算

MixRoute 的 key 上还有两项控制可以配合着用。一是每把 key 可以限制成只能调用指定的模型集合，不选就是不限制；二是可以预拨一笔可扣减的支出预算，逐次请求扣减，扣到零这把 key 就停止调用，要再用再拨。这两项都是 key 上的独立字段，与请求怎么被路由无关；没设预算的时候，就只有账号余额这一层上限。刚验证完 Mistral 密钥、准备把同类调用铺到多个供应商的团队，先按环境各建一把 key 并各自定好模型范围和预算，比事后从账单里倒推清晰得多。