[Provider 提案] AI Router：OpenAI-compatible 向导预设与动态模型发现

[airouter-dev]

关联披露：我是 AI Router 的维护者。这个提案来自 provider 兼容性检查，不代表独立用户背书。

背景

当前 main 的 setup wizard 已经把 OpenRouter、Kilo Gateway、Vercel AI Gateway 等 OpenAI-compatible gateway 作为一等 provider，同时保留 Custom 路径。现有 model_fetch 也会向 {api_base}/models 发送 Bearer 认证请求，并读取 OpenAI 风格的 data[].id。

AI Router 可以先作为现有 Custom 路径的真实远程兼容目标：

• API base：https://api.ai-router.dev/v1
• 模型目录：GET https://api.ai-router.dev/v1/models
• 认证：Authorization: Bearer <personal-api-key>
• 目录结构：OpenAI 风格的 data[].id

我在 2026-07-27 只做了无凭据探测，端点返回 401，符合需要 Bearer token 的预期；尚未使用生产凭据验证模型目录、流式响应和 tool calling，因此这些不能先写成已通过。

建议由维护者选择的范围

A. 文档优先

在 CONFIGURATION.md 的“其他兼容 OpenAI API 的服务”中增加一个可复现示例，继续走 Custom，不增加 provider 代码。若同步本地化文档，链接应按文档语言使用对应页面，例如中文 /cn、德文 /de、法文 /fr、日文 /ja。

B. 一等向导 preset

在现有 provider 列表中增加：

• key：ai-router
• label：AI Router
• API base：https://api.ai-router.dev/v1
• 环境变量：AI_ROUTER_API_KEY

复用现有动态模型发现、手动模型 ID 回退和 connectivity/tool verification；按 api.ai-router.dev 识别 provider。不要从模型 ID 推断 context window、价格、vision 或 tool 能力，tool support 应由现有真实验证流程决定。

验收边界

• api_base 尾部斜杠只规范化一次，不能产生重复 /v1；
• 发现失败或返回空列表时保留手动模型输入；
• 日志和错误信息不得输出 API key、完整响应体或带敏感参数的 URL；
• 未完成带凭据的 streaming/tool-call 验证前，不预设相关能力；
• 不加入价格、奖励、模型数量、可用性或“官方合作”表述。

这个范围符合仓库“新功能先 Discussion”的要求，所以目前没有创建 fork、代码或文档 PR。维护者更倾向 A 还是 B？