OpenAI Compatible Proxy這個方式其實一直都有, Github上面也有很多Repo有做這件事

而我不是說方式本身, 是這個行為的動機, 因為OpenAI, Claude跟Google都明確在ToS裏面寫明不能把個人帳號 (公司跟團隊另計) 分給其他人用, 所以才說不要把這個Proxy給自己以外的人用就可以

應該會看到這些Proxy類的Repo都會先警告用戶有可能違反ToS和後果自負

不要被Gemini判定成過多請求這個就是各大廠商判定是否有把帳號分給其他人用的證據之一, 當然也有其他證據就是了

我本機有claude codex codex也順便接上去了,超方便,以後qwen3.6 26b跑不通的時後切一下模型就可以幫他把skill做好,之後qwen順跑

訂閱變成API其實有點踩到灰色地帶了, 雖然說我自己設立給自己一個人用的Sub2API也半斤八兩

不過一天沒有把這個功能開放給別人用 以及 不要被Gemini判定成過多請求 應該都沒什麼問題, 我記得之前因為過多請求導致Claude直接封掉Openclaw

Hermes Agent 接 Gemini Pro 訂閱 OAuth：不是 MCP，是本機 OpenAI-compatible Proxy

這篇記錄我這次把 Gemini Pro 訂閱帳號接進 Hermes Agent 的做法。

先講結論：這條路線不是用 Hermes 的 MCP，也不是只讓 Hermes 去呼叫 agy CLI。實際跑通的是：

Google OAuth / Antigravity
        ↓
CLIProxyAPI 本機代理
        ↓
http://127.0.0.1:8317/v1  OpenAI-compatible API
        ↓
Hermes custom provider

也就是把 Gemini/Antigravity 的 OAuth 能力包成一個本機 /v1 API，Hermes 再把它當成 OpenAI-compatible provider 使用。

成功後的狀態

本機跑起來後會有兩個重要服務：

127.0.0.1:8317  CLIProxyAPI，負責 Gemini OAuth proxy
127.0.0.1:8080  原本本機 Qwen / llama-server

Hermes 裡面則可以同時保留兩個 provider：

custom_providers:
  - name: gemini-proxy
    base_url: http://127.0.0.1:8317/v1
    key_env: CLIPROXY_API_KEY
    api_mode: chat_completions
    models:
      gemini-pro-agent:
        context_length: 1048576
      gemini-3.1-pro-low:
        context_length: 1048576
      gemini-3-flash-agent:
        context_length: 1048576
      gemini-3-flash:
        context_length: 1048576
      gemini-3.5-flash-low:
        context_length: 1048576
      gemini-3.5-flash-extra-low:
        context_length: 1048576

  - name: qwen-local
    base_url: http://127.0.0.1:8080/v1
    api_mode: chat_completions
    models:
      Qwopus3.6-27B-v2-MTP-Q4_K_M.gguf:
        context_length: 131072

目前我自己的 Hermes 主模型可以這樣設：

model:
  provider: custom:gemini-proxy
  default: gemini-3.5-flash-extra-low
  context_length: 1048576

如果要改回 Gemini Pro agent，也可以改成：

model:
  provider: custom:gemini-proxy
  default: gemini-pro-agent
  context_length: 1048576

安裝 CLIProxyAPI

我把它放在 Hermes 目錄底下：

mkdir -p ~/.hermes/cli-proxy/bin
cd ~/.hermes/cli-proxy

下載 CLIProxyAPI Linux amd64 release，例如我這次用的是：

CLIProxyAPI_7.2.58_linux_amd64.tar.gz

解開後會有：

~/.hermes/cli-proxy/bin/cli-proxy-api
~/.hermes/cli-proxy/bin/config.example.yaml

確認 binary 可以執行：

chmod +x ~/.hermes/cli-proxy/bin/cli-proxy-api
~/.hermes/cli-proxy/bin/cli-proxy-api --help

建立 proxy config

我用的設定大概是這樣，API key 請自己產生，不要貼真值：

host: 127.0.0.1
port: 8317
api_keys:
  - "replace-with-your-local-random-key"
auth_dir: /home/YOUR_USER/.hermes/cli-proxy/auth
log_dir: /home/YOUR_USER/.hermes/cli-proxy/logs
static_dir: /home/YOUR_USER/.hermes/cli-proxy/static

我另外把 key 放進 Hermes 的 .env：

CLIPROXY_API_KEY=replace-with-your-local-random-key

這樣 Hermes config 裡就可以用：

key_env: CLIPROXY_API_KEY

不要把 proxy API key 寫進分享文、git repo 或截圖。

Google OAuth

這一步是關鍵。

CLIProxyAPI 啟動後，照它提供的 login/OAuth flow 讓瀏覽器完成 Google 授權。授權成功後，auth_dir 裡會出現類似：

~/.hermes/cli-proxy/auth/antigravity-<your-google-account>.json

這個檔案是 OAuth 憑證，權限建議至少設成：

chmod 600 ~/.hermes/cli-proxy/auth/*.json

我這台是透過遠端機器操作，所以 OAuth 頁面需要用 SSH tunnel 或可以開瀏覽器的方式完成。這也是很多人會卡住的地方：不是 Hermes 不能接，而是 OAuth callback 沒有正確回到本機 proxy。

用 PM2 常駐 CLIProxyAPI

我的 pm2 不在系統 PATH 裡，所以用完整路徑：

~/.hermes/node/bin/pm2 start ~/.hermes/cli-proxy/bin/cli-proxy-api \
  --name cli-proxy-api \
  -- -config ~/.hermes/cli-proxy/config.yaml

~/.hermes/node/bin/pm2 save

確認它有活著：

~/.hermes/node/bin/pm2 status
ss -ltnp | grep 8317

應該看到：

cli-proxy-api  online
127.0.0.1:8317 LISTEN

測試 proxy

先測 /v1/models：

curl -s http://127.0.0.1:8317/v1/models \
  -H "Authorization: Bearer $CLIPROXY_API_KEY"

我這邊能看到的模型包含：

gemini-pro-agent
gemini-3.1-pro-low
gemini-3-flash-agent
gemini-3-flash
gemini-3.5-flash-low
gemini-3.5-flash-extra-low

再測 chat completions：

curl -s http://127.0.0.1:8317/v1/chat/completions \
  -H "Authorization: Bearer $CLIPROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-pro-agent",
    "messages": [
      {"role": "user", "content": "Reply with exactly: Gemini proxy confirmed"}
    ]
  }'

能正常回覆後，再接 Hermes。

Hermes 設定 custom provider

在 Hermes 的 config.yaml 加上：

custom_providers:
  - name: gemini-proxy
    base_url: http://127.0.0.1:8317/v1
    key_env: CLIPROXY_API_KEY
    api_mode: chat_completions
    models:
      gemini-pro-agent:
        context_length: 1048576
      gemini-3.1-pro-low:
        context_length: 1048576
      gemini-3-flash-agent:
        context_length: 1048576
      gemini-3-flash:
        context_length: 1048576
      gemini-3.5-flash-low:
        context_length: 1048576
      gemini-3.5-flash-extra-low:
        context_length: 1048576

主模型可以設：

model:
  provider: custom:gemini-proxy
  default: gemini-pro-agent
  context_length: 1048576

或改成比較省的：

model:
  provider: custom:gemini-proxy
  default: gemini-3.5-flash-extra-low
  context_length: 1048576

改完後重啟 Hermes gateway：

systemctl --user restart hermes-gateway
systemctl --user is-active hermes-gateway

Hermes 裡切換模型

在 Telegram / Hermes bot 裡可以用：

/model custom:gemini-proxy:gemini-pro-agent --global
/model custom:gemini-proxy:gemini-3.1-pro-low --global
/model custom:gemini-proxy:gemini-3.5-flash-low --global
/model custom:gemini-proxy:gemini-3.5-flash-extra-low --global

切完建議開新 session：

/new

--global 是改預設新 session。只想改目前 session，可以用 --session。

接回原本 8080 Qwen

原本本機 Qwen 也可以保留成另一個 provider：

custom_providers:
  - name: qwen-local
    base_url: http://127.0.0.1:8080/v1
    api_mode: chat_completions
    models:
      Qwopus3.6-27B-v2-MTP-Q4_K_M.gguf:
        context_length: 131072

要切回 Qwen：

/model custom:qwen-local:Qwopus3.6-27B-v2-MTP-Q4_K_M.gguf --global
/new

前提是你的 llama-server / OpenAI-compatible Qwen server 已經在 8080 跑著。

確認：

ss -ltnp | grep 8080

我這次踩到的坑

1. 一開始容易誤會成 MCP

Hermes 本來就可以用 MCP 去調外部工具，agy CLI 也可以透過 MCP/CLI 被呼叫。

但這次要的是「把 Gemini Pro 訂閱 OAuth 當成 Hermes 的模型 provider」，不是「讓 Hermes 呼叫一個工具」。所以正確方向是 OpenAI-compatible local proxy。

簡單判斷：

MCP / CLI tool：模型還是 Hermes 原本的模型，只是多一個工具可以叫
OpenAI-compatible proxy：Gemini 變成 Hermes 的模型本體

2. agy 能跑，不代表 Hermes 直接吃得到 OAuth

agy 自己有 Google OAuth，但 Hermes 不會自動讀 agy 的登入狀態。中間需要一層 proxy，把 OAuth 模型包成 /v1/chat/completions。

這就是 CLIProxyAPI 的角色。

3. pm2 可能不在 PATH

我這台不能直接跑：

pm2 status

要用：

~/.hermes/node/bin/pm2 status

文章或 runbook 建議都寫完整路徑，少一個環境差異。

4. OAuth callback 在遠端機器上會卡

如果是在 SSH server、遠端桌面、無頭環境上跑，Google OAuth 頁面開在你本機瀏覽器，但 callback 要回到遠端機器上的 proxy。

解法通常是：

用 SSH tunnel 把 callback port 轉回遠端
或在遠端機器上直接完成瀏覽器授權

授權成功的判斷不是「網頁看起來過了」，而是 auth_dir 裡真的出現 OAuth JSON。

5. Hermes provider 名稱要寫完整

切模型時不是只打模型名，而是：

custom:<provider-name>:<model-name>

例如：

/model custom:gemini-proxy:gemini-pro-agent --global

少了 custom:gemini-proxy: 這段，Hermes 可能會找不到正確 provider。

6. 不要把 key 和 OAuth JSON 放進文章

至少這幾個東西不能貼：

CLIPROXY_API_KEY 真值
~/.hermes/cli-proxy/api_key
~/.hermes/cli-proxy/auth/*.json
任何 Google OAuth token

分享時用 placeholder 就好。

最後驗證

我這次最後驗證了三件事：

1. CLIProxyAPI 在 127.0.0.1:8317 online
2. /v1/models 能列出 Gemini models
3. Hermes 可以用 custom:gemini-proxy 跑 Gemini，也可以切回 custom:qwen-local 的 8080 Qwen

這樣 Hermes 就不是只能 MCP/CLI 調用 Gemini，而是可以把 Gemini Pro OAuth proxy 當成真正的模型 provider 使用。

但是gemini模型实在太拉！有急事用claude，但额度少的可怜。

我订阅的有X 普通 premium ，现在用的最多的是grok cli，效果很好。