BYOKEY：将 AI 订阅「变废为宝」的本地网关

痛点场景： 每个月花 20 美元订阅 Claude Pro、18 美元订阅 GitHub Copilot，再加上 Copilot X、Windsurf、Cursor Pro……对 AI 开发者来说，这些订阅费用已经成了不小的负担。更让人头疼的是，很多开发工具（Cursor、Windsurf、Amp Code）各自绑定不同的订阅体系，无法通用。你明明已经有了 Claude Pro，却还要再买一份 Copilot 才能用 Windsurf 的高级功能。

BYOKEY（Bring Your Own Keys）正是为了解决这个痛点而生的。它是一个用 Rust 编写的轻量级本地代理网关，核心功能只有一个：把你的各种 AI 订阅，统一转换成 OpenAI / Anthropic 兼容的标准 API 端点。这样一来，任何支持 OpenAI API 的开发工具，都可以自由切换到你的订阅上，而不需要额外付费。

背景故事

BYOKEY 的作者是 GitHub 用户 AprilNEA，一个独立开发者。这个项目诞生于 2024 年末，最初只是为了解决自己的实际需求——作者同时订阅了 Claude Pro 和 GitHub Copilot，但 Windsurf 只支持 OpenAI 格式的 API 调用，而 Amp Code 又需要自己的协议。BYOKEY 就是为了把这些互不兼容的订阅体系「大一统」而写的。

目前该项目已有 130+ Stars，支持 8 个主流 AI Provider，包括 Claude（Anthropic）、Codex（OpenAI）、Copilot（GitHub）、Gemini（Google）、Kiro（AWS）、Qwen（阿里云通义）、Kimi（月之暗面）以及 iFlow（智谱）等。这个覆盖度在国内 AI 工具圈子里相当实用——Qwen 和 Kimi 在国内有更稳定的访问渠道，配合 BYOKEY 可以给国外的 AI 编程工具（如 Cursor、Windsurf）提供国内模型的接入能力。

技术架构

BYOKEY 采用了 Rust 语言开发，选择 Rust 的理由非常充分：高性能（零成本抽象）、内存安全（无需 GC 停顿）、可编译为单二进制文件（部署极简）。项目本身是一个 Workspace 结构的 Monorepo，拆分为多个独立 crates，职责清晰：

Crate	职责
byokey-types	通用类型定义
byokey-config	YAML/JSON 配置加载 + 热重载（基于 notify crate 监听文件变化）
byokey-store	SQLite 持久化存储（~/.byokey/tokens.db），基于 sqlx + sea-orm
byokey-auth	OAuth2 / PKCE / 设备码等认证流程封装，基于 oauth2 crate
byokey-provider	各 AI Provider 的 API 适配层
byokey-proxy	代理核心，HTTP 请求转发
byokey-daemon	服务进程管理，支持 systemd / launchd / Windows SCM 系统服务注册
byokey-tui	终端 UI（基于 ConnectRPC 管理 API）
byokey-ampcode	专用于 Amp Code 协议的兼容层

核心 HTTP 框架选用 Axum 0.8（基于 Tower 中间件生态），异步运行时使用 Tokio。在协议兼容性上，项目引入了 aigw 系列 crate（aigw、aigw-core、aigw-openai、aigw-gemini），这是专门处理 AI Gateway 协议兼容的成熟库，支持 OpenAI Chat Completions、Anthropic Messages 等多种 API 格式的相互转换。

在存储层面，BYOKEY 使用 SQLite 保存 OAuth Token，路径默认为 ~/.byokey/tokens.db，通过 sea-orm ORM 框架管理数据库模型。这意味着 Token 持久化可靠，重启服务不会丢失登录状态。

核心功能

1. 多 Provider 统一接入

BYOKEY 同时支持 8 个 AI Provider，每个 Provider 都可以通过 byokey login <provider> 完成 OAuth 认证，认证成功后 Token 自动存入 SQLite。整个流程对用户透明——不需要手动管理 refresh_token，也不用担心过期重登录。

认证方式根据 Provider 不同有所差异：

• OAuth with PKCE：Claude、Codex、Gemini 等需要浏览器交互的 Provider
• Device Code Flow：Copilot、Kiro、Qwen、Kimi 等支持设备码的 Provider（适合无浏览器环境）

认证完成后，BYOKEY 会监听 Token 过期并在后台自动刷新。

2. 协议格式转换

这是 BYOKEY 最核心的能力。不同的 AI Provider 有各自不同的 API 格式。Claude（Anthropic）使用 messages endpoint，OpenAI / Codex 使用 chat/completions endpoint，Gemini 使用 Google 自有的 generateContent 格式。BYOKEY 在中间做协议转换，无论你用哪种格式的请求，最终都会被转换为目标 Provider 所需的格式，同时响应也会被转换回统一格式返回给客户端。

3. 多账户切换

BYOKEY 支持同一 Provider 下的多个账户管理，通过 byokey accounts <provider> 查看，byokey switch <provider> <account> 切换。在团队场景下，可以为不同开发者分配不同的订阅账户，非常实用。

4. 系统服务注册

byokey service install 可以将 BYOKEY 注册为系统级服务（macOS launchd、Linux systemd、Windows SCM），开机自启，后台常驻，不占用终端会话。

5. Amp Code 原生支持

BYOKEY 专门维护了一个 crates/ampcode 模块来兼容 Amp Code 协议。byokey serve 会额外监听一个端口（默认 18018），运行 Amp 兼容路由。通过 byokey amp inject 可以一键将配置写入 Amp 的 settings.json，让 Amp Code 自动使用 BYOKEY 作为后端。

部署体验

BYOKEY 的部署非常简单，有三种方式：

方式一：Homebrew（macOS / Linux）

brew install AprilNEA/tap/byokey

方式二：crates.io（一行命令）

cargo install byokey

方式三：安装脚本

curl -fsSL https://raw.githubusercontent.com/AprilNEA/BYOKEY/master/install.sh | sh

安装脚本会自动检测平台（Linux/macOS）和架构（x86_64 / aarch64），下载对应预编译二进制，部署到 ~/.byokey/bin 并加入 PATH。整个过程无需手动配置，对非 Rust 开发者友好。

启动服务只需要两步：

byokey login claude  # 认证
byokey serve          # 启动代理（监听 localhost:8018）

然后将工具的 API 端点指向 http://localhost:8018/v1，API Key 填任意值（byokey 会忽略它）。以 Cursor 为例：

export OPENAI_BASE_URL=http://localhost:8018/v1
export OPENAI_API_KEY=***  # 任意值

硬件需求极低：Rust 编译产物体积小（50MB 左右），运行时内存占用仅 ~256MB，不需要 GPU，是真正的轻量级工具。

局限与注意事项

BYOKEY 虽有诸多优点，但使用时也需要注意以下几点：

1. 不支持 Web UI：BYOKEY 是一个纯 CLI 工具，没有 Web 界面，所有操作通过命令行或终端 UI（TUI）完成。对习惯 GUI 的用户有一定门槛。

2. OAuth 认证需要浏览器：对于 Claude、Codex 这类需要浏览器交互的 Provider，首次认证需要在有浏览器的环境执行。如果是无头服务器（headless server），需要借助 SSH 端口转发或跳板机来完成 OAuth 流程。

3. License 为 NOASSERTION：BYOKEY 虽然在 Cargo.toml 中声明了 MIT OR Apache-2.0，但 GitHub 仓库根目录的 License 文件显示 NOASSERTION，可能是仓库元数据未完全同步，实际使用建议自行确认。

4. Token 存储在本机：SQLite 数据库默认存放在 ~/.byokey/tokens.db，这既是优点（数据完全可控），也是潜在风险——如果多台机器使用，需要分别认证。

5. 国内 Provider 依赖设备码认证：Qwen、Kiro、Kimi 等国内 Provider 需要设备码认证，BYOKEY 已支持，但不同 Provider 的设备码有效期不同，需要注意过期问题。

行业意义

BYOKEY 的出现反映了一个趋势：AI 订阅市场的碎片化。随着 Claude Pro、Copilot、Cursor Pro、Windsurf 等工具的兴起，开发者每月在 AI 订阅上的支出越来越多，但这些订阅彼此无法通用。BYOKEY 正是这个痛点的直接产物。

更深层次看，BYOKEY 代表了 AI 工具生态的 「协议大一统」方向。通过将不同 Provider 的 API 转换为 OpenAI 兼容格式，开发者可以用一个统一的客户端接入所有 AI 服务。这和 LangChain 的「AI 无关」理念有异曲同工之妙，只不过 BYOKEY 聚焦在开发工具这一垂直场景。

从技术选型来看，Rust + Axum + SQLite 的组合在轻量级工具中非常合理：二进制独立部署、内存安全、启动极快。对于需要长期后台运行的服务来说，这些特性比 Python 的灵活性更有价值。

如果你是 AI 开发者，BYOKEY 值得一试——它不仅能帮你省下重复订阅的费用，更重要的是，它让你在切换开发工具时不再受制于 API 格式的差异。