Claude Max 订阅有个很尴尬的现实：你花了钱，但只能在 claude.ai 和 Claude Code CLI 里用。想在自己的工具链里调？不行，那是 API 的活儿，另外收费。而且如果你人在不支持的地区，连 CLI 都用不了。

CLIProxyAPI 解决的就是这个问题——它把 OAuth 认证的 CLI 工具包装成标准的 API server，你的 Max 订阅瞬间变成了一个兼容 OpenAI/Anthropic 格式的 API endpoint。配合一台 VPS，地理限制也不存在了。

核心思路

整个方案的本质其实很简单：

你的机器 → VPS（CLIProxyAPI）→ Anthropic API
              ↑
         OAuth 认证在这里完成
         API 格式转换在这里完成

CLIProxyAPI 干的事情就是：用你的 Claude Max OAuth token 去调 Claude 的接口，然后把请求和响应转换成标准 API 格式暴露出来。对于调用方来说，它就是一个普通的 API server，设个环境变量就能用。

为什么需要 VPS 而不是直接本地跑？两个原因：一是地区限制——VPS 放在支持的地区就绕过了 IP 检测；二是多设备共享——笔记本、台式机、服务器都可以指向同一个 endpoint。

部署

部署分两步：认证和启动。

认证需要在有浏览器的环境做一次：

cliproxyapi --claude-login

会弹浏览器让你登录 Claude 账号，OAuth token 存在 ~/.cli-proxy-api/ 下。这一步只需要做一次，token 会自动刷新。

然后在 VPS 上用 Docker 跑起来就行。端口默认 8317，config 和 auth 目录挂载进去。

服务起来之后，任何支持自定义 API endpoint 的工具都能用了。Claude Code 的配置最简单：

export ANTHROPIC_BASE_URL=http://your-vps-ip:8317
# AUTH TOKEN 可以填任意值，认证走的是 OAuth 不走 API key
export ANTHROPIC_AUTH_[REDACTED_SECRET_ASSIGNMENT]

ANTHROPIC_AUTH_TOKEN 可以填任意值，因为真正的认证是 CLIProxyAPI 通过存储的 OAuth token 完成的，不走 API key 那套。

值得聊的几个点

多账号轮询是个比较实用的功能。如果你有多个 Max 订阅（比如团队里好几个人的），CLIProxyAPI 支持 round-robin 负载均衡。这意味着你可以把多个账号的 token 都放进去，它自动轮着用，变相提高了并发能力和 rate limit 上限。

模型选择也挺灵活。不只是 Claude，Gemini CLI、OpenAI Codex、Qwen 都支持。所以这个 proxy 其实可以变成你所有 AI 订阅的统一入口——一个 endpoint 背后是所有模型。

安全方面要注意。这个方案本质上是把你的 OAuth token 放在了一台远程机器上。如果 VPS 被入侵，token 就暴露了。建议：VPS 本身做好安全加固，proxy 端口不要直接暴露公网（可以走 SSH 隧道或者 WireGuard），config 里开 HTTPS。

一点想法

CLIProxyAPI 这类工具反映了一个挺普遍的矛盾：AI 公司的产品策略和用户的实际需求之间的错配。

用户买了 Max 订阅，期望是"我可以随便用这个模型"。但实际上你只能在特定客户端里用，想集成到自己的工作流就得另外付 API 费用。这中间的 gap 自然就催生了各种桥接方案。

另一个矛盾是地区限制。技术上，模型推理发生在云端，请求从哪里发过来其实无所谓。但出于合规考虑，厂商不得不做 IP 层面的封锁。VPS proxy 本质上就是在这个限制和需求之间找了一个技术上的平衡点。

当然，这里面有个灰色地带——通过 proxy 绕过地区限制是否违反服务条款，各家 AI 公司的态度不太一样。使用前值得自己评估一下风险。

CLIProxyAPI 这个项目本身做得挺工程化的——Go 写的，支持 Docker 部署，有管理 API，甚至有第三方做了监控面板和桌面客户端。对于需要在不同环境里统一使用 AI 模型的开发者来说，是个值得关注的方案。

一个更激进的想法：Token 共享网络

既然 CLIProxyAPI 已经支持多账号轮询了，那再往前想一步——如果大家把自己的闲置额度拿出来共享呢？

Max 订阅最大的浪费是：你不可能 24 小时都在用。你睡觉的 8 小时、开会的 2 小时、周末发呆的两天，你的订阅额度就那么空着。但地球另一边可能有人正好需要 Opus 来跑个任务。

想象一个 token 共享平台：

用户 A 贡献了闲置额度 → 别人消耗了 50k tokens
                        ↓
              A 获得 50k token 积分
                        ↓
          A 可以用积分消耗别人的闲置额度

本质上就是一个 AI 算力的 P2P 交换网络。你贡献多少，就能用多少。每个人的订阅利用率从可能 30% 拉到接近 100%。

技术上不难做。CLIProxyAPI 已经有了多账号管理和负载均衡的基础，加一层计量和积分系统就行。每个请求记录 token 消耗，归属到贡献者和消费者，积分实时结算。

当然，这个想法和 AI 厂商的利益是直接冲突的。厂商的商业模型就是建立在"大部分用户用不完额度"上面的——和健身房会员卡一个逻辑。如果所有人的额度都被充分利用了，厂商的推理成本会暴涨，而收入不变。所以这种平台大概率会被条款禁止，甚至被技术手段封杀。

但从用户角度看，这个需求是真实的。你付了钱，模型在那里闲着，而别人想用用不了——这种低效是客观存在的。至于最终是厂商通过更灵活的定价来解决（比如按实际使用量计费的 Max 方案），还是社区自己搞出共享方案，就看谁先动了。

人机共创 · Blagent