CodeBuddy 接入自定义模型 (GPT-5.6)

2026-07-18 09:33

本文发自 http://www.binss.me/blog/connect-codebuddy-to-custom-model/，转载请注明出处。

AI 协作说明

本文和文中的大部分实际配置均由 gpt-5.6-sol 完成，包括登录 VPS、安装服务、生成配置、完成 Codex 授权、配置 HTTPS，以及最后的验收测试。

你也可以把本文整理成一份 SKILL.md，交给支持终端工具的 AI Agent 自动执行。机场订阅、API Key 和域名应作为私密输入；OAuth、DNS 和安全组变更等步骤则应保留人工确认。

我很喜欢 CodeBuddy 的编辑体验，尤其是可以逐行 Accept 模型生成的修改。目前我用过的 IDE 中，CodeBuddy 和 Cursor 在这方面最丝滑。

问题是 CodeBuddy 自带额度不太够用，而我已有的 Codex 订阅又经常用不完。于是我尝试用 CLIProxyAPI 将 Codex 授权转换成 OpenAI 兼容 API，再通过 CodeBuddy 的自定义模型功能接入 gpt-5.6-sol。

最终方案支持两种部署方式：

国内 VPS + 备案域名：使用 Mihomo 访问 OpenAI；
国外 VPS + 任意域名：服务器直连 OpenAI，不需要 Mihomo。

为什么选择 CodeBuddy、Codex 和 VPS

CodeBuddy

CodeBuddy 的自定义模型请求可以直接从当前运行环境发出，链路比较透明，也方便从 CLIProxyAPI 返回的 usage 元数据中检查 Token 消耗和 Prompt Cache。

Cursor 的按行修改体验同样很好，但在我使用的自定义模型工作流中，请求仍会受到服务端支持范围、协议转换和模型兼容策略的限制。

Codex

对我来说，Codex 的优势是额度充足、编程能力强，而且已经有 CLIProxyAPI 这类成熟的兼容接口方案。

不过，个人体验稳定不等于永远不会受限。订阅政策和模型权限都可能变化，实际使用时仍应遵守 OpenAI、CodeBuddy 和相关服务的条款，不要出售、共享或滥用个人授权。

VPS

如果只在本机使用 CodeBuddy，CLIProxyAPI 监听 127.0.0.1 就够了。但 CodeBuddy Remote 会从远端开发机发起模型请求，无法访问本机的 127.0.0.1。

把 CLIProxyAPI 部署到 VPS，并提供带鉴权的 HTTPS 地址后，本机、Remote 环境和其他受信任设备都能复用同一个入口。

先选部署方案

我最初使用腾讯云广州 VPS。Mihomo 和 CLIProxyAPI 的本机测试都已通过，但 CodeBuddy 最终收到的是 Cloudflare 525 SSL handshake failed HTML 页面，而不是 API JSON。

原因是域名没有备案，被腾讯云中国大陆源站的未备案监测系统阻断。腾讯云官方文档也明确说明，域名解析到腾讯云中国大陆服务器前，需要完成备案或接入备案；Cloudflare 橙云不能替代这一过程。详见腾讯云 ICP 备案概述。

因此，部署前先选择一条路线：

方案 A：国内 VPS + 备案域名 - 域名已完成 ICP 备案； - 已完成当前云厂商的接入备案； - CLIProxyAPI 通过 Mihomo 访问 OpenAI。

方案 B：国外 VPS + 任意域名 - 域名只需能够正常配置 DNS； - 无需 ICP 备案； - VPS 能够直连 OpenAI，不安装 Mihomo。

如果没有备案域名，建议直接使用方案 B。我最后迁移到了新加坡 VPS，链路更短，维护也更简单。

一、整体架构

其中：

Cloudflare 负责代理 DNS 和边缘 TLS；
Caddy 负责源站 HTTPS 和反向代理；
CLIProxyAPI 将 Codex 授权转换为 OpenAI 兼容 API；
Mihomo 只用于方案 A 的上游网络；
CodeBuddy 通过 /v1/chat/completions 调用自定义模型。

二、准备工作

两种方案都需要：

一台能够 SSH 登录的 VPS；
一个能够修改 DNS 的域名；
Cloudflare 账号；
可以完成 Codex 网页授权的浏览器；
安全组放行 TCP 80 和 443。

方案 A 还需要备案域名和机场订阅；方案 B 则需要确认 VPS 可以直连 OpenAI。

不要向公网开放 7893、8317 或 9090。SSH 的 22 端口也最好只允许可信 IP。

本文实测环境为 linux/amd64。新服务器建议使用仍在维护期内的 Debian、Ubuntu、Rocky Linux 或 AlmaLinux，不建议继续新装已经 EOL 的 CentOS 7。

三、配置上游网络

方案 A：安装 Mihomo

从 Mihomo Releases 下载对应架构的二进制：

sudo install -m 0755 mihomo /usr/local/bin/mihomo
sudo mkdir -p /etc/mihomo /var/lib/mihomo

下载订阅配置：

export SUB_URL='YOUR_SUBSCRIPTION_URL'
sudo curl -fL "$SUB_URL" -o /etc/mihomo/config.yaml
unset SUB_URL
sudo chmod 600 /etc/mihomo/config.yaml

确认配置中包含以下本地监听设置。节点、代理组和规则继续使用订阅提供的内容：

mixed-port: 7893
allow-lan: false
bind-address: 127.0.0.1
external-controller: 127.0.0.1:9090
mode: rule

创建 /etc/systemd/system/mihomo.service：

[Unit]
Description=Mihomo Proxy
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

启动并验证：

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo

curl -x http://127.0.0.1:7893 \
  -o /dev/null -w '%{http_code}\n' \
  https://api.openai.com/v1/models

没有携带 OpenAI API Key 时返回 401，说明代理链路已经打通。

方案 B：直接访问 OpenAI

国外 VPS 不安装 Mihomo，只需验证直连：

curl -o /dev/null -w '%{http_code}\n' \
  https://api.openai.com/v1/models

返回 401 即可继续。

四、安装 CLIProxyAPI

从 CLIProxyAPI Releases 下载对应架构的文件，校验发布方提供的哈希后安装：

sudo install -m 0755 cli-proxy-api /usr/local/bin/cli-proxy-api
sudo useradd --system --home-dir /var/lib/cliproxyapi \
  --shell /sbin/nologin cliproxyapi || true
sudo mkdir -p /etc/cliproxyapi /var/lib/cliproxyapi/auth
sudo chown -R cliproxyapi:cliproxyapi /var/lib/cliproxyapi

生成 API Key：

openssl rand -hex 32

创建 /etc/cliproxyapi/config.yaml：

host: 127.0.0.1
port: 8317

auth-dir: /var/lib/cliproxyapi/auth

api-keys:
  - "YOUR_API_KEY"

remote-management:
  allow-remote: false
  secret-key: ""
  disable-control-panel: true
  disable-auto-update-panel: true

debug: false
request-log: false
logging-to-file: false

# 只记录 Token usage，不记录请求正文
usage-statistics-enabled: true
redis-usage-queue-retention-seconds: 3600

方案 A 需要额外加入 Mihomo 代理；方案 B 不添加：

# 仅方案 A
proxy-url: "http://127.0.0.1:7893"

限制配置文件权限：

sudo chown root:cliproxyapi /etc/cliproxyapi/config.yaml
sudo chmod 640 /etc/cliproxyapi/config.yaml

创建 /etc/systemd/system/cliproxyapi.service。下面是方案 B 的配置：

[Unit]
Description=CLIProxyAPI
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=cliproxyapi
Group=cliproxyapi
WorkingDirectory=/var/lib/cliproxyapi
ExecStart=/usr/local/bin/cli-proxy-api -config /etc/cliproxyapi/config.yaml -local-model
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

方案 A 将 [Unit] 改为：

[Unit]
Description=CLIProxyAPI
After=network-online.target mihomo.service
Wants=network-online.target
Requires=mihomo.service

启动服务：

sudo systemctl daemon-reload
sudo systemctl enable --now cliproxyapi
ss -lntp | grep 8317

CLIProxyAPI 应只监听 127.0.0.1:8317。

五、完成 Codex 授权

停止服务，以 CLIProxyAPI 用户执行登录：

sudo systemctl stop cliproxyapi
sudo -u cliproxyapi -H /usr/local/bin/cli-proxy-api \
  -config /etc/cliproxyapi/config.yaml \
  --codex-login --no-browser

在浏览器中打开命令输出的地址并完成授权，然后重新启动：

sudo systemctl start cliproxyapi

curl http://127.0.0.1:8317/v1/models \
  -H 'Authorization: Bearer YOUR_API_KEY'

模型列表会随账号权限和 CLIProxyAPI 版本变化，应以 /v1/models 的实际结果为准。

六、使用 Caddy 提供 HTTPS

两种方案的 Caddy 配置相同，但方案 A 必须先完成 ICP 备案和云厂商接入备案。Cloudflare 不能替代备案。

在 Cloudflare 中添加 DNS A 记录：

example.com -> VPS 公网 IP

首次签发证书时可以暂时使用“仅 DNS（灰云）”。安装 Caddy 后，创建 /etc/caddy/Caddyfile：

{
    admin 127.0.0.1:2019
}

example.com {
    @management path /v0/management* /management*
    respond @management 404

    reverse_proxy 127.0.0.1:8317

    log {
        output stderr
        format json
    }
}

校验并启动：

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl enable --now caddy
sudo journalctl -u caddy -f

证书签发成功后，将 Cloudflare DNS 切换为“已代理（橙云）”，并设置：

SSL/TLS -> Overview -> Full (strict)

不要使用 Flexible。源站已经拥有有效证书，Full (strict) 才会验证源站身份。

七、验证公网 API

两种方案的公网验收相同。

无密钥应返回 401：

curl -i https://example.com/v1/models

有效密钥应返回 200 和模型列表：

curl https://example.com/v1/models \
  -H 'Authorization: Bearer YOUR_API_KEY'

管理接口应返回 404：

curl -o /dev/null -w '%{http_code}\n' \
  https://example.com/v0/management/config

最后实际调用一次模型：

curl https://example.com/v1/chat/completions \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data '{
    "model": "gpt-5.6-sol",
    "messages": [{"role": "user", "content": "Reply only OK."}],
    "max_tokens": 16
  }'

八、在 CodeBuddy 中添加模型

打开 CodeBuddy 的模型设置，选择 Custom：

供应商：Custom
Base URL：https://example.com/v1/chat/completions
API Key：CLIProxyAPI 中配置的 API Key
模型名称：gpt-5.6-sol
工具调用：开启
推理：开启
图片输入：暂不开启
输入及输出限制：留空

CodeBuddy 的 Base URL 需要填写完整的 chat/completions 地址，而不只是 https://example.com/v1。

九、验证 Prompt Cache

OpenAI Prompt Caching 会在满足条件时自动生效，不需要额外开关。CLIProxyAPI 也能够正常返回缓存 Token 元数据。

第一次是冷缓存，后两次复用了相同的长前缀。这也说明 CodeBuddy 显示缓存为 0，不一定代表上游没有命中；客户端可能只是没有读取 OpenAI 兼容响应中的 prompt_tokens_details.cached_tokens。

如果要观察缓存，建议只开启 usage 统计，并保持：

usage-statistics-enabled: true
redis-usage-queue-retention-seconds: 3600
request-log: false
logging-to-file: false

不要保存 API Key、Authorization 请求头、Prompt、代码或响应正文。usage 统计主要用于短期观察，服务重启后可能清空，具体行为以当前 CLIProxyAPI 版本为准。

十、安全与排查

上线前至少确认：

API Key 使用随机长字符串，泄露后立即轮换；
CLIProxyAPI 只监听 127.0.0.1:8317；
方案 A 的 Mihomo 只监听本机，方案 B 不安装 Mihomo；
公网只开放 80/443，不开放 7893/8317/9090；
CLIProxyAPI 管理接口不对公网开放；
Cloudflare 使用 Full (strict)；
不长期启用完整请求日志；
授权文件、API Key 和机场订阅均按密钥管理；
定期更新 CLIProxyAPI、Caddy，以及方案 A 中的 Mihomo。

常用排查命令：

# 公共服务
systemctl status cliproxyapi caddy
ss -lntp | grep -E ':(8317|80|443)'

# 仅方案 A
systemctl status mihomo
ss -lntp | grep -E ':(7893|9090)'
curl -x http://127.0.0.1:7893 -I https://www.google.com

# 仅方案 B
curl -o /dev/null -w '%{http_code}\n' \
  https://api.openai.com/v1/models

# CLIProxyAPI 本机接口
curl http://127.0.0.1:8317/v1/models \
  -H 'Authorization: Bearer YOUR_API_KEY'

# 服务日志
journalctl -u cliproxyapi -f
journalctl -u caddy -f

参考资料

本文发自 https://www.binss.me/blog/connect-codebuddy-to-custom-model/

采用知识共享署名-非商业性使用-相同方式共享 4.0 进行许可

Binsite