401错误说明认证失败，需依次验证base url是否为真实api入口、authorization头是否符合服务类型（openai用bearer、anthropic用x-api-key）、api key前缀是否匹配平台规范、模型id是否为后端真实注册的id。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你在Trae里填好了Base URL，也确认API Key没输错，可一发送请求就弹出401错误，根本没走到模型调用那步——这说明服务端连你的身份都没认出来，问题卡在认证链最前端。
先验证Base URL是否真的指向OpenAI兼容接口
打开浏览器，把Base URL粘贴进去，末尾加上/v1（例如https://code0.ai/v1），回车。如果返回{"error":{"message":"Not Found","type":"invalid_request_error","param":null,"code":null}}或类似JSON，说明地址能通、是OpenAI兼容接口；如果直接跳转到登录页、显示404 HTML页面、或提示“无法访问此网站”，【说明你填的是控制台地址、文档页或网关首页，不是真正的API入口】。
很多平台的API地址和网页地址长得太像，比如https://console.code0.ai 和 https://code0.ai/v1，只差一个路径层级，但前者完全不能收请求。
检查Authorization头是否被正确构造
Trae默认按OpenAI协议发送请求，必须用 Authorization: Bearer
方法一：确认你用的服务类型
查该服务商的官方文档，搜索“authentication”或“curl example”。看到 curl -H "Authorization: Bearer ..." 就是OpenAI系；看到 curl -H "x-api-key: ..." 就是Anthropic系。
方法二：强制覆盖请求头（仅限高级配置）
在Trae的模型配置YAML中，找到request → headers段，手动写入：
headers:
Authorization: Bearer sk-xxx
注意：这个字段必须缩进在request下，顶格写会无效。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
核对API Key前缀与服务匹配性
第一步：打开你所用平台的API控制台，找到当前Key的详情页。
第二步：查看Key字符串开头是否符合该平台规范——OpenAI原生Key以sk-开头；Code0的Key以sk-c0-开头；QoderWake是sk-qw-；小米MiMo中转服务是tp-开头。
第三步：如果Key是sk-开头却填进Claude插件配置，或tp-开头硬塞进OpenAI模型字段，【Trae会发请求，但服务端直接拒收，返回401而非404】。
这一步最容易被忽略：Key本身有效，只是用错了地方。
确认模型ID是否真实存在于该Base URL后端
① 用curl跑最小验证请求：
curl -X POST https://your-base-url.com/v1/chat/completions \
-H "Authorization: Bearer your_api_key" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-4o","messages":[{"role":"user","content":"test"}]}'
② 如果返回{"error":{"message":"model_not_found","type":"invalid_param"}}，说明Base URL和Key都对，但model字段填错了——不是你习惯叫的名字，而是服务端注册的真实ID。比如云舒API里gpt-4o可能要写成yunshu-gpt4o-v2。
③ 如果返回401且curl命令里URL、Key、model三者都抄自控制台，说明该Key未被授权访问这个Base URL所指向的集群，需去控制台开通对应区域或分组权限。
