sususu

Maintainer of CLIProxyAPI

[sususu @sususu9998]

【CPA 28-Day Challenge】(2026.10.19 – 11.15)

Over the next 28 days, each day we’ll either ship one CPA tip that is a clear improvement and relevant for most CPA (Codex / Kimi / Antigravity / Claude / Grok / Muse / Devin) users or do a full reset. Let the improvements begin.

在接下来的 28 天里，每天我们要么分享一个对大多数 CPA（Codex / Kimi / Antigravity / Claude / Grok / Muse / Devin）用户真正有用的硬核技巧，要么来一次全面重置（Full Reset）。让改进开始吧。

[sususu @sususu9998]

@Delroy715 前天上线carbon的时候也是这个样子的，现在这个问题也没修

[sususu @sususu9998]

【CPA 28 天挑战 · Day 18】

不装搜索插件，也不改客户端代码，就能让 Claude Code / Codex / IDE 里的 Grok 直接用原生 X Search 实时查 X 动态。只要开启 upstream.xai.inject-x-search。

用 Grok 查刚发布的开源库动态、线上故障反馈、最新讨论都很顺手。但把 xAI 凭证接进 Codex CLI、Claude Code、pi 或各类 IDE 插件时，默认用不上 X Search：这些客户端不会在 tools 里声明 xAI 专有的 {"type": "x_search"}。

自己用 payload 规则硬塞一个 x_search，很容易连踩三个坑：

1. allowed_tools 白名单锁死
很多客户端会带 tool_choice: {"type": "allowed_tools", ...}。只往 tools 里塞 x_search、不同步写进白名单，模型照样无权调用。

2. 200 个工具上限溢出
xAI 上游单次请求最多 200 个工具。客户端挂的 MCP 工具刚好压线时，再塞第 201 个就会直接 400。

3. 服务端内部 trace 泄漏，客户端卡死（最隐蔽）
xAI 在服务端执行 x_search 时，会把内部检索过程（x_keyword_search、x_semantic_search、x_user_search、x_thread_fetch 等带 xs_call 前缀的 custom_tool_call）一并吐进响应流。客户端看到这些没声明过的调用，以为要本地执行，报「找不到工具」，对话当场中断。

CPA 里一个开关全包：

upstream:
xai:
inject-x-search: true

热加载即刻生效，对 xAI 的 OAuth 凭证和 API Key 凭证、HTTP 和 WebSocket 链路都有效。网关会自动做四件事：
- 补齐声明：请求里没有 x_search 就追加；有 allowed_tools 就去重加入白名单；请求显式强制单跑其他托管工具时自动跳过，不破坏原语义。
- 计入工具上限：统计总数时先把待注入的 x_search 算进去，超过 200 就触发命名空间折叠，保住 x_search 不报错。
- 过滤内部 trace：流式和非流式响应里都会剥掉 xs_call* 子工具事件，同时保留真实的 x_search_calls 用量统计。
- 零客户端侵入：客户端照常对话，遇到实时问题 Grok 自己在服务端搜完 X 再回答。

今天就可以试：在 config.yaml（或 EZCPA / 网页控制台）加上这三行，然后问一个今天刚发生的技术动态：

curl http://127.0.0.1:8317/v1/chat/completions \
-H "Authorization: Bearer 你的访问密钥" \
-H "Content-Type: application/json" \
-d '{"model":"grok-4.7","messages":[{"role":"user","content":"查一下今天 X 上关于 CLIProxyAPI 或大模型网关的最新讨论有哪些？"}]}'

[sususu @sususu9998]

复测：我用 Antigravity 的 gemini-4-carbon 又测了一遍，对照日志后，发现它和 Vertex 上的同名模型差异很明显。同样是 reasoning_effort = medium（已过滤极短探测请求）：

1. 思考 token：Antigravity 平均 385.2（39 次），Vertex 平均 769.3（69 次），Antigravity 约为一半。单次最高 2604 对 5779。

2. 摘要器不是同一套：Antigravity 是干净的第三人称短摘要；Vertex 是带粗体标题的第一人称摘要，而且摘要子模型自己的思考原文被漏进了 thought 分块，单次请求连吐 10~15 块，总计 34KB~55KB。

3. 速度：平均 TTFT，Antigravity 约 11.3s，Vertex 约 17.0s。Antigravity 首包后 100~180ms 就把摘要和工具调用一次推完。

4. 缓存：Antigravity 有 75.0% 的连续轮次固定要全价重算末尾 2049 tokens；Vertex 有 70.2% 全量命中，但在 400K+ 上下文出现过 4 次缓存清零。

另外，Antigravity 实际发往上游的模型名是 gemini-4-carbon-high，再叠加 thinkingLevel MEDIUM。

https://t.co/ooQpXnijIb

[sususu @sususu9998]

Vertex 上线了 gemini-4-carbon，果然憋着不发的模型没啥好东西

1. 首字延迟（TTFT）处于主流模型最高区间，伴随严重的 Prefill 长尾

在 100k ~ 200k tokens 级别的输入场景下，哪怕前缀缓存命中率稳定在 95% 以上，其首字延迟（TTFT）基准值仍维持在 10s ~ 15s。 更为严重的是缓存穿透时的长尾时延：在一次 184k 上下文未命中缓存的请求中，TTFT 飙升至 32.1s，整轮端到端耗时达 145.4s。 通过对响应头 Server-Timing: gfet4t7; dur=3460 等字段进行归因分析，延迟核心消耗在 Google 服务端内部的 Prefill 计算与思维链生成阶段，本地网络与网关中转耗时占比不足 2%。横向对比同一 Agent 框架：Claude Opus / DeepSeek-V3 的 TTFT 约为 1s ~ 2s，GPT-Sol 约为 4s ~ 5s，Carbon 整体响应开销高出 3 到 8 倍。

2. HTTP 200 SSE 流式连接内混入原始 503 JSON，引爆下游客户端解析器
在请求日志 v1beta-models-vertex-gemini-4-carbon-streamGenerateContent-2026-11-10T165443-bcfef1ec.log 中捕获到罕见的流式协议异常： 客户端以 HTTP 200 OK 建立 Server-Sent Events（SSE）长连接后，模型正常输出至文本中段时，Vertex 后端服务发生瞬时故障（UNAVAILABLE）。由于 HTTP 状态行及响应头早已写入，上游未按照 SSE 事件流标准格式下发错误事件帧，而是直接在 TCP 数据流末尾输出了原始的 HTTP 503 JSON 报文体：
data: {"candidates": [{"content": {"role": "model","parts": [{"text": "..."}]}}]}
{
"error": {
"code": 503,
"message": "The service is currently unavailable.",
"status": "UNAVAILABLE"
}
}

下游客户端（基于 Bun 运行的 @google/genai SDK）按行消费 SSE 数据流，当尝试解析未携带 data: 前缀且缺少标准闭合结构的裸 JSON 块时，直接触发语法解析器异常（Error: JSON Parse error: Expected '}'）而崩溃退出，导致该长连接既无法优雅感知错误类型，也彻底丢失了末尾的 usageMetadata 统计包。

3. 同凭证同会话紧密轮次下的非确定性缓存丢失（Pod 级调度漂移）
排除掉前述切换思考等级的人为因素，在完全相同的账号凭据（同一 auth_index）、相同会话（session_id）及不变参数的前提下，请求间隔仅 15s ~ 20s 的紧密轮次中，仍存在突发性缓存归零现象：

轮次 1（ID 254401，08:43:12）：输入 149,121，命中缓存 146,486（命中率 98.2%）；
轮次 2（ID 254403，08:43:32，间隔 20s）：输入 158,867，cached_tokens 突变为 0，整整 15.8 万上下文全部冷算；
轮次 3（ID 254404，08:43:51）：下一轮缓存又重新接续，命中 158,868。 该现象表明 Vertex AI 边缘网关层对长连接会话的亲和性（Session Affinity）调度存在短板，高并发负载下请求易被偶发派发至未经预热的计算节点。
4. 确定性重算的 2,049 Tokens 尾部扣费机制（继承 Argon 尾巴税）
在增量低于特定阈值的轮次中，多次捕获到底层 Token 计费的异常行为：prev_in - cached 的差值精确恒等于 2,049 Tokens（如 Keeper ID 254388、254405、254435 等）。 这证明 Carbon 完全沿用了 Google 在 Gemini 4 Argon 上的隐式缓存边界算法：当单轮新增 Token 数未达到其内部设定的吸收步长时，系统强制不对上一轮末尾的 2,050 tokens 建立缓存索引。在以轻量 read、edit、rg 为主的典型 Coding Agent 循环中，由于单轮新增往往只有数百 tokens，导致上一轮刚刚支付过输入全价的末尾 2,049 tokens 会在后续每一轮被重复全价扣费。

[sususu @sususu9998]

【CPA 28 天挑战 · Day 17】

在 Codex 等客户端里跑第三方模型（比如 deepseek-v4.1-flash），为什么聊着聊着触发一次上下文压缩（/v1/responses/compact），凭证突然就被挂起冷却了？

分享一个今天刚排查完的真实 Case：

现在很多客户端在走 OpenAI Responses 协议（/v1/responses）长对话时，一旦上下文达到阈值，会自动发起一次压缩请求（POST /v1/responses/compact 或在 input 里附带 compaction_trigger）。

如果你背后的上游是 OpenAI 官方，自然有原生的 /v1/responses/compact 端点。但如果你把模型路由到了自建推理引擎（vLLM / SGLang）或者 Ollama 等兼容上游，就会踩到一个连环坑：

1. 现场翻车链路（以调用 deepseek-v4.1-flash 为例）：
- 当请求调度到 OpenAI 兼容上游（OpenAICompatExecutor，如自建 vLLM / SGLang 节点）且未做特殊配置时，CPA 默认把 /v1/responses/compact 透传给上游，上游没有这个路由，直接返回 405 Method Not Allowed；
- 网关触发故障转移（Failover）切到备用兼容端点（如 Ollama 的 CodexExecutor），上游 https://t.co/pDMhyJfp1p 直接返回 404：{"error":"path \"/v1/responses/compact\" not found"}；
- 最要命的一步来了：控制面/路由层收到这个 404 后，会误判成「该凭证下不存在 deepseek-v4.1-flash 这个模型」（触发 Suspended client ... for model .../deepseek-v4.1-flash），当场把好端端的凭证挂起拉黑，直到冷却时间结束或手动重置。

明明模型能正常聊天，结果因为客户端自动调了一次上游不存在的 /compact 接口，凭证直接被误杀进小黑屋。

2. CPA 里的解法与配置建议：

第一层：本地 Compaction 胶囊回退（让不支持 compact 的上游也能压缩）
CPA 内置了本地上下文摘要与加密胶囊机制（cpa-ag-compact-v1:）。对于走 OpenAI 兼容渠道的 deepseek-v4.1-flash，可以在 requests.payload 里显式声明目标协议为 openai（即标准 Chat Completions）：

requests:
payload:
override:
- models:
- name: "deepseek-v4.1-flash"
protocol: "openai"
params:
max_tokens: 2048

当客户端发来带 compaction_trigger 的压缩请求时，CPA 不会去调上游不存在的 /responses/compact，而是自动剔除工具定义、改走普通的 /v1/chat/completions 让模型生成上下文摘要，并在网关本地用 AES-256-GCM 封装成标准 response.compaction 胶囊返回给客户端；下一轮续聊时再由 CPA 自动拆封还原成上下文，流式与非流式全链路无缝衔接。

第二层：给 /responses/compact 的 404 / 405 配免冷却止损（防误杀凭证）
如果客户端直接硬调 POST /v1/responses/compact 撞上了不支持该端点的上游，为了防止 404 Not Found 把凭证误判成「模型不存在」而挂起冷却，可以在 request-scoped-errors 里把这类路径 404 精准拦住：

oauth:
request-scoped-errors:
codex:
- status: 404
match:
- "/v1/responses/compact"
- "/responses/compact"
action: stop

设成 action: stop 后，即便上游不支持该端点，CPA 也只会把报错原样退回给客户端触发客户端侧降级，绝不会把正在正常干活的凭证挂起拉黑。

[sususu @sususu9998]

carbon 是我看见的第一个在输出中途直接突然夹断的

[sususu @sususu9998]

Vertex 上线了 gemini-4-carbon，果然憋着不发的模型没啥好东西

1. 首字延迟（TTFT）处于主流模型最高区间，伴随严重的 Prefill 长尾

在 100k ~ 200k tokens 级别的输入场景下，哪怕前缀缓存命中率稳定在 95% 以上，其首字延迟（TTFT）基准值仍维持在 10s ~ 15s。 更为严重的是缓存穿透时的长尾时延：在一次 184k 上下文未命中缓存的请求中，TTFT 飙升至 32.1s，整轮端到端耗时达 145.4s。 通过对响应头 Server-Timing: gfet4t7; dur=3460 等字段进行归因分析，延迟核心消耗在 Google 服务端内部的 Prefill 计算与思维链生成阶段，本地网络与网关中转耗时占比不足 2%。横向对比同一 Agent 框架：Claude Opus / DeepSeek-V3 的 TTFT 约为 1s ~ 2s，GPT-Sol 约为 4s ~ 5s，Carbon 整体响应开销高出 3 到 8 倍。

2. HTTP 200 SSE 流式连接内混入原始 503 JSON，引爆下游客户端解析器
在请求日志 v1beta-models-vertex-gemini-4-carbon-streamGenerateContent-2026-11-10T165443-bcfef1ec.log 中捕获到罕见的流式协议异常： 客户端以 HTTP 200 OK 建立 Server-Sent Events（SSE）长连接后，模型正常输出至文本中段时，Vertex 后端服务发生瞬时故障（UNAVAILABLE）。由于 HTTP 状态行及响应头早已写入，上游未按照 SSE 事件流标准格式下发错误事件帧，而是直接在 TCP 数据流末尾输出了原始的 HTTP 503 JSON 报文体：
data: {"candidates": [{"content": {"role": "model","parts": [{"text": "..."}]}}]}
{
"error": {
"code": 503,
"message": "The service is currently unavailable.",
"status": "UNAVAILABLE"
}
}

下游客户端（基于 Bun 运行的 @google/genai SDK）按行消费 SSE 数据流，当尝试解析未携带 data: 前缀且缺少标准闭合结构的裸 JSON 块时，直接触发语法解析器异常（Error: JSON Parse error: Expected '}'）而崩溃退出，导致该长连接既无法优雅感知错误类型，也彻底丢失了末尾的 usageMetadata 统计包。

3. 同凭证同会话紧密轮次下的非确定性缓存丢失（Pod 级调度漂移）
排除掉前述切换思考等级的人为因素，在完全相同的账号凭据（同一 auth_index）、相同会话（session_id）及不变参数的前提下，请求间隔仅 15s ~ 20s 的紧密轮次中，仍存在突发性缓存归零现象：

轮次 1（ID 254401，08:43:12）：输入 149,121，命中缓存 146,486（命中率 98.2%）；
轮次 2（ID 254403，08:43:32，间隔 20s）：输入 158,867，cached_tokens 突变为 0，整整 15.8 万上下文全部冷算；
轮次 3（ID 254404，08:43:51）：下一轮缓存又重新接续，命中 158,868。 该现象表明 Vertex AI 边缘网关层对长连接会话的亲和性（Session Affinity）调度存在短板，高并发负载下请求易被偶发派发至未经预热的计算节点。
4. 确定性重算的 2,049 Tokens 尾部扣费机制（继承 Argon 尾巴税）
在增量低于特定阈值的轮次中，多次捕获到底层 Token 计费的异常行为：prev_in - cached 的差值精确恒等于 2,049 Tokens（如 Keeper ID 254388、254405、254435 等）。 这证明 Carbon 完全沿用了 Google 在 Gemini 4 Argon 上的隐式缓存边界算法：当单轮新增 Token 数未达到其内部设定的吸收步长时，系统强制不对上一轮末尾的 2,050 tokens 建立缓存索引。在以轻量 read、edit、rg 为主的典型 Coding Agent 循环中，由于单轮新增往往只有数百 tokens，导致上一轮刚刚支付过输入全价的末尾 2,049 tokens 会在后续每一轮被重复全价扣费。

[sususu @sususu9998]

@counterbeing @bornio @theo No restart needed: CPA has a management API to refresh the model list on demand:

curl -X POST http://127.0.0.1:8317/v8/management/models/refresh -H "Authorization: Bearer <management-key>"

New models show up in /v1/models right away, and live streams keep running.

[sususu @sususu9998]

【CPA 28 天挑战 · Day 16】

各大厂商刚发新模型，怎么在不重启 CPA、不打断当前对话的情况下，一秒让所有凭证同步出最新模型列表？

平时用 CPA 的朋友应该遇到过这种场景：
OpenAI、Anthropic、Google 或者 Devin 刚刚上线了一个新模型（或者官方 models 仓库刚更新了某个模型的上下文窗口、思考预算、原生联网搜索标记），又或者你自己改了本地挂载的自定义模型目录文件。

以前 CPA 默认是启动时拉一次、之后每 3 小时后台自动轮询刷新。如果不想傻等 3 小时，很多人第一反应就是去重启 CPA 服务——但只要一重启，手头正在跑的长推理流和 WebSocket 会话就全断了。

最近 CPA 在 v8 管理控制面里专门加了「手动按需刷新模型目录」的 API：

POST /v8/management/models/refresh
（等价完整路径：POST /v8/management/routing/model-definitions/refresh）

只要带管理密钥发一个 POST 请求，CPA 就会在后台瞬间做完四件事：

1. 三大目录并发同步拉取：
同时刷新通用模型目录（models.catalog）、Codex 客户端模型目录（models.codex-catalog）和 Devin 模型目录（models.devin-catalog），无论是远程 URL 还是本地绝对路径文件都支持。

2. 精准 Diff 并自动重注册受影响的凭证：
CPA 会自动对比新旧模型目录的差异（返回 changed_providers 列表），并立即为对应渠道下的所有在线凭证重新注册可用模型与原生能力标记——随后客户端调 /v1/models 就能立刻看到新模型。

3. 坏数据防呆兜底（Fail-Safe）：
如果远端网络抽风，或者你手改本地 JSON 不小心写错了语法，接口会直接返回 502 Bad Gateway 并保留上一次合法的模型目录，绝不会把正在运行的路由表刷崩。

4. 查验特定渠道的生效模型定义：
刷完之后还可以顺手调 GET /v8/management/routing/model-definitions/:channel（比如 /claude、/codex、/antigravity、/devin），直接查看当前内存里已生效的模型元数据明细。

平时直接用一行 curl 就能触发：

curl -X POST "http://127.0.0.1:8317/v8/management/models/refresh" \
-H "Authorization: Bearer <你的管理密钥>"

# 返回示例：
{
"ok": true,
"status": "ok",
"changed_providers": ["claude", "codex"],
"catalogs": {
"catalog": { "refreshed": true, "changed_providers": ["claude"] },
"codex-catalog": { "refreshed": true },
"devin-catalog": { "refreshed": true }
}
}

如果你想维护自己的私有模型表，也可以在 config.yaml 顶层指定本地路径或内网地址，改完随时调这个接口秒级生效：

models:
catalog: "/etc/cpa/models.json"
codex-catalog: ""
devin-catalog: ""

[sususu @sususu9998]

桌面端 EZCPA（Win / Mac / Linux）：
https://t.co/ebMiWb3HbI

网页控制台 CPAMC（内置于 CPA /management.html）：
https://t.co/5TeMLZOOoz

核心引擎 CLIProxyAPI（服务器 / CLI / Docker）：
https://t.co/Q48n7nCBuJ

[sususu @sususu9998]

【CPA 28 天挑战 · Day 15】

解决系统提示词误触上游过滤：用 sensitive-words 零宽字符混淆，从源头避免「假 429」。

昨天 Day 14 讲了怎么用 request-scoped-errors 拦截 Antigravity 的「假 429」，防止一条被拒的请求把池子里的其他凭证全拖进冷却。但拦截只是止损，今天讲怎么让这条请求正常跑通。

很多时候你调上游被拒，根本不是你在问什么违规内容，而是客户端自带的系统提示词（System Prompt）触发了上游的关键词过滤。

比如你在 Codex CLI、Claude Code、OpenClaw 或者各种 Agent 框架里跨界调 Antigravity、Devin 或 Claude，客户端发出去的 system prompt 里往往写着一整段固化的身份声明：
"You are Codex..."、"Claude Agent SDK"、"x-anthropic-billing-header"、"Hermes"、"RFC 2119" 等等。

这些词在原厂客户端里完全正常，但一旦跨界发给别家上游，很容易触发前置规则被当场秒拒（比如 Antigravity 直接返回不带 details 的假 429）。你又不可能为了换个模型去改客户端的源码。

CPA 在网关层做了一个无损的「零宽字符混淆（sensitive-words）」机制：

1. 原理：在匹配词的第一个字符后面自动插入一个不可见的 Unicode 零宽空格（\u200B），比如把 "You are Codex" 变成 "Y\u200Bou are Codex"。上游的死板字符串/正则匹配当场失效，但对大模型的 Tokenizer 来说依然能正常理解语义。
2. 匹配细节：忽略大小写，自动按词长从长到短排序优先匹配（避免短词把长词截断）。
3. 严守边界（最关键的一点）：
- 在 Antigravity 和 Devin 下，CPA 严格只混淆 systemInstruction / system prompt，绝对不碰历史消息、代码块和工具调用的 JSON 参数（比如读写文件路径、代码标识符），不会把你的代码改坏；
- 在 Claude 下，即使历史消息里有包含相同字母的 thinking 加密签名（signature），CPA 也会精准跳过签名字段，绝不破坏多轮思考校验。

直接在 config.yaml 里把你常用的客户端特征词加上就行（支持 Antigravity、Devin 和 Claude 三个渠道）：

oauth:
providers:
antigravity:
sensitive-words:
- You are Codex
- Claude Agent SDK
- Hermes
- x-anthropic-billing-header
- system-conventions
- <conventions>
- RFC 2119
devin:
sensitive-words:
- Claude Agent SDK
- You are a Claude agent
- Hermes

# 如果是 Claude API Key 渠道（或 OAuth 凭证 JSON 里的 cloak_sensitive_words）：
api-keys:
claude:
- name: claude-pool
keys:
- api-key: "sk-..."
cloak:
mode: "auto"
sensitive-words:
- OpenClaw
- Hermes

配合昨天的 request-scoped-errors 一起用：sensitive-words 负责在发往上游前化解 99% 的系统提示词误触，万一遇到没收录的新词触发了假 429，再由 request-scoped-errors 当场 stop 兜底，整套凭证池就彻底稳了。

[sususu @sususu9998]

桌面端 EZCPA（Win / Mac / Linux）：
https://t.co/ebMiWb4f1g

网页控制台 CPAMC（内置于 CPA /management.html）：
https://t.co/5TeMLZPme7

核心引擎 CLIProxyAPI（服务器 / CLI / Docker）：
https://t.co/Q48n7nD9kh

[sususu @sususu9998]

【CPA 28 天挑战 · Day 14】

真失效时对话无感续上，假报错时别把整个池子的凭证全送进冷却。

平时池子里挂了好几个凭证，最怕的其实不是某个凭证突然没额度了——只要开着之前讲过的会话粘性（rebind-on: quota）和首包前重试，就算聊到一半你去后台手动把当前用的凭证禁用掉，CPA 也会自动切到下一个凭证接着跑，客户端那边根本感觉不到断过。

真正让人头疼的是上游乱报状态码。最典型的就是 Antigravity 的「假 429」：

当你的系统提示词里不小心带了某些敏感词（比如你在 Claude Code 或其他客户端里调 Antigravity，提示词里带了 You are Codex、Claude Agent SDK、Hermes 这类词），Google 上游拦截的时候根本不报 400，而是直接给你返回一个 429 RESOURCE_EXHAUSTED。

结果就是：网关一看是 429，以为 1 号凭证没额度了，立马把 1 号关进冷却；接着拿着同一份带敏感词的请求去试 2 号凭证，2 号也报 429 被关进冷却；再去试 3 号、4 号……一条触发敏感词的请求，几秒钟就能把你所有的 Antigravity 凭证全部干进冷却。

仔细看日志就会发现，Antigravity 真正额度用完的 429，返回的 JSON 里会带 details 字段和重置时间；而敏感词触发的假 429，返回体里干干净净只有一句 "Resource has been exhausted (e.g. check quota)."，没有任何 details。

在 CPA 里可以分两步彻底解决这个问题：

第一步，在 request-scoped-errors 里用正则把这个「不带 details 的假 429」单独挑出来，动作设成 stop——一旦遇到它，直接把报错返回给客户端，既不冷却当前凭证，也不再去重试连累池子里的其他凭证（顺手还可以把地区不支持的 400、没灰度到模型的 404 一并配好）：

oauth:
request-scoped-errors:
antigravity:
- status: 429
match-regexr:
- '^\s*\{\s*"error":\s*\{\s*"code":\s*429,\s*"message":\s*"Resource has been exhausted \(e\.g\. check quota\)\.",\s*"status":\s*"RESOURCE_EXHAUSTED"\s*\}\s*\}\s*$'
action: stop
- status: 400
match:
- "User location is not supported"
action: continue-and-cooldown
- status: 403
match:
- "The caller does not have permission"
action: stop
- status: 404
match:
- "Requested entity was not found"
- "is not found for API version v1main"
action: continue

第二步，把常见触发词加进 oauth.providers.antigravity.sensitive-words，CPA 会在发往上游前自动在系统提示词的匹配词里插入零宽字符，从源头上避免触发假 429（这也是明天 Day 15 要细讲的内容）。

[sususu @sususu9998]

Pi 官方 CLIProxyAPI Provider 插件（自动发现模型 / WS 直连 / `/fast` 切换 / TPS 统计）：
https://t.co/jDBST79KyK

桌面端 EZCPA（Win / Mac / Linux · 三分钟图形化配置）：
https://t.co/zTmwZR8Cn5

网页控制台 CPAMC（内置于 CPA `/management.html`）：
https://t.co/5P05Srzg6l

核心引擎 CLIProxyAPI（服务器 / CLI / Docker）：
https://t.co/43HZYNCWXv

[sususu @sususu9998]

[CPA 28-Day Challenge · Day 13]

今天用中文发，手撸稿子去去AI 味儿。

pi（搭配官方 CLIProxyAPI Provider 插件）和 Codex 开启 WebSocket 模式：不仅能全双工中途插话，还能直接连上只有 SSE 的 Claude 与 Antigravity（gemini-4-argon）！

现在像 pi、Codex CLI / Desktop 等客户端都已经支持 Responses WebSocket 协议——长连接免握手、按增量发消息、延迟更低。
特别是用 pi 的朋友，装上官方插件 `@router-for-me/pi-cliproxyapi-provider`：

pi install npm:@router-for-me/pi-cliproxyapi-provider

然后在 pi 里敲 `/login CLIProxyAPI` 填入网关地址和密钥，就能自动拉取 `/v1/models?client_version=pi` 全量模型目录（还自带 `/fast` 优先队列开关、`/cliproxyapi-refresh` 热刷模型、底部 Elapsed 计时与 TPS 速率统计，以及 `/compact` 压缩后自动重置 WS 上下文）。

但这也带来一个好奇：pi 插件和 Codex 走的是 Responses WebSocket 协议，而 Claude、Antigravity（Gemini）这些上游根本没有 WebSocket 接口、只支持传统 HTTP/SSE——那在 WS 模式还能跑它们吗？

在 CPA 网关后面，下游客户端只管走 WebSocket 连进来，上游不管是原生 WS 还是纯 SSE 全部无感打通：

1 跨层桥接（下游 WS -> 上游 HTTP/SSE）：在 WS 客户端里丝滑跑 Claude 与 Antigravity
当你在 pi（CLIProxyAPI provider）或 Codex 里通过 WebSocket 切换到 `claude-opus-5-5` 或 Antigravity 的 `gemini-4-argon` 时，CPA 会在网关层自动完成「WS <-> SSE 跨协议桥接」：
- 自动增量缝合：客户端按 WS 习惯只发 `previous_response_id` + 增量输入（或 `response.append`），CPA 自动在内存里拼回完整上下文，翻译成 Anthropic 或 Gemini 的 SSE 请求发给上游；
- 预热与中断本地接管：客户端发 `generate: false` 连接预热帧时网关本地秒回，发 `response.interrupt` 时立刻掐断上游 SSE 流且不断开你的 WS 连接；
- 同一条 WS 跨家换脑：同一个 WS 会话里从 Codex 切到 `claude-opus-5-5` 再切到 `gemini-4-argon`，CPA 按厂商独立记住账号粘性（pinnedAuthByProvider），自动在「增量透传」和「全量合并」间无缝切换。

2 原生全双工（下游 WS -> 上游 WS）：连接复用 + 生成中途插话转向
当你切回 Codex（或 xAI）并在凭据开启 `"websockets": true`（可在 CPAMC `/management.html` 或 EZCPA 一键勾选），再配好 `config.yaml`：

upstream:
codex:
response-steering: true # 开启全双工中途插话转向 (response.steer)
websocket-compression: true # 开启 permessage-deflate 帧压缩
upstream-request-compression: true # 开启 Codex OAuth 请求体 zstd 压缩
stream-bootstrap-buffering: true # WS 下同样支持首 token 前过载无感切号

[sususu @sususu9998]

🌐 Web Management Console: CPAMC (Built into CPA at /management.html · MIT Open Source)
https://t.co/5TeMLZPme7

🖥️ Desktop Console: EZCPA (Win / Mac / Linux)
https://t.co/ebMiWb4f1g

⚡ Core Engine: CLIProxyAPI (Server / CLI / Docker)
https://t.co/Q48n7nD9kh

[sususu @sususu9998]

[CPA 28-Day Challenge · Day 12]

One HTML file to run your entire gateway: meet the redesigned CLI Proxy API Management Center (CPAMC).

Over the past 11 days, we wired up OAuth subscriptions, protocol translation, model aliases, priority tiers, session affinity, and retry policies in config.yaml.

Now you can see and orchestrate all of it from a single browser tab—zero extra containers, zero Node.js runtime, bundled directly inside CLIProxyAPI as one self-contained file at /management.html:

1. Live Operations Dashboard:
Real-time request throughput, rolling-window success rate (e.g., 99.3% across 20,000+ calls), traffic burst detection, and instant counts of active credentials, provider keys, and exposed models.

2. Unified AI Provider Hub (Light & Dark Themes):
Manage Claude, Codex, Gemini, Interactions API, Kimi, Muse (Meta), xAI, Vertex, and OpenAI-compatible endpoints in one place—with per-key success/failure counters and 100% health bars.

3. Visual Routing & Failover Orchestration:
Preview how any model routes across priority tiers (e.g., Priority 100 -> 50 -> 10). When a primary account drops or cools down, watch traffic cascade to the next tier automatically, and toggle Round-Robin / Weighted / Fill-First, Session Affinity, and Retry Rounds on the fly.

4. Per-Account Subscription Quota Cards:
Check remaining 5-hour and weekly quota windows at a glance across Claude (Max 20x), Codex (Pro 200), xAI (SuperGrok), Kimi (Allegretto), and Antigravity without opening five different billing dashboards.

5. YAML Config Editor with Pre-Save Diff Review:
Edit settings visually or in raw YAML, and inspect a Git-style line-by-line diff modal ("Confirm Changes") before saving—hot-reloaded by CPA in milliseconds without dropping active streams.

Task for Day 12: open your built-in CPAMC console in your browser (or launch it from EZCPA), check your live subscription quotas, and preview your routing tiers:

http://127.0.0.1:8317/management.html

[sususu @sususu9998]

🖥️ Desktop Console: EZCPA (Win / Mac / Linux)
https://t.co/ebMiWb4f1g

⚡ Core Engine: CLIProxyAPI (Server / CLI / Docker)
https://t.co/Q48n7nD9kh

[sususu @sususu9998]

[CPA 28-Day Challenge · Day 11]
Pre-first-byte self-healing & retry rounds: recover silent TLS hangs, early stream drops, and hidden HTTP-200 overloads before your client ever notices.

In streaming AI APIs, once HTTP 200 headers are flushed to the client, a traditional proxy can no longer switch credentials if the upstream errors out a split second later. Even worse, providers like Codex sometimes return HTTP 200, emit a couple of handshake frames ("response.created", "https://t.co/TqE9KNIKFa_progress"), and then smuggle a "server_is_overloaded" error inside the stream.

CPA closes these failure windows with three layers of pre-first-byte self-healing:

1. Multi-Round Credential Retries ("routing.retry"):
Control how many additional retry rounds CPA runs across your pool on HTTP 403/408/429/500/502/503/504 failures:

routing:
retry:
request-retry: 3 # Additional retry rounds after Round 0 (can override per key/auth JSON)
max-retry-credentials: 0 # Cap credentials tried per round (0 = try all eligible)
max-retry-interval: 30 # Max seconds to wait if all accounts are briefly in cooldown

2. Safe Streaming Bootstrap Retries & TLS Handshake Bounds ("requests"):
If an upstream connection hangs during the TLS handshake or drops a stream before any payload bytes are committed downstream, CPA transparently re-runs the stream on the next credential:

requests:
tls-handshake-timeout-seconds: 10 # Bound stalled uTLS handshakes so retry can kick in; lifted once connected
nonstream-keepalive-interval: 15 # Emit blank lines every 15s on non-streaming calls to prevent proxy 504s
streaming:
bootstrap-retries: 2 # Retry streaming calls before the first byte is sent to the client
keepalive-seconds: 15 # Emit ": keep-alive" SSE heartbeats
send-keepalive-before-ft: false # Keep false when pairing with bootstrap buffering so headers stay uncommitted

3. Codex Stream Bootstrap Buffering ("upstream.codex"):
Hold back uncommitted response headers across empty handshake frames ("response.created", "https://t.co/TqE9KNIKFa_progress", empty "*.added", heartbeats) until the first real generated token or tool call arrives:

upstream:
codex:
stream-bootstrap-buffering: true
stream-bootstrap-timeout: "20s" # Safety ceiling for Nginx/Cloudflare timeouts (48-frame / 1 MiB buffer cap)

If Codex smuggles a "server_is_overloaded" or rate-limit rejection right after the handshake, CPA discards the buffered handshake and fails over to another credential seamlessly—your coding client only sees a clean, uninterrupted stream.

Task for Day 11: enable "bootstrap-retries: 2" and "stream-bootstrap-buffering: true" (with "stream-bootstrap-timeout: 20s" if behind Nginx/Cloudflare) in config.yaml or EZCPA, and test a streaming request:

curl -N http://127.0.0.1:8317/v1/responses \
-H "Authorization: Bearer YOUR_ACCESS_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-6.1-sol","stream":true,"input":[{"role":"user","content":"Stream a short haiku about self-healing gateways."}]}'

[sususu @sususu9998]

Credit where it's due: after my earlier post on gemini-4-argon's brutal quota drain (https://t.co/r5IqsFQr48), Google stepped up, fixed the implicit cache accounting bug, and even gave us a quota reset. Fast turnaround — respect for that.

That said, after cross-checking Google's updated caching docs (https://t.co/PkkiSBoM4i) against 6,500+ real Coding Agent turns from my local gateway, 3 major pain points still stand out:

1️ Gemini Flash in Agents: ~3-min amnesia & the 4,096-token step trap Pause for just ~3 mins to review a diff and Flash starts dropping cache hard (>5 mins is basically a wipeout). Worse, its cache pointer only moves in 4,096-token chunks. Whenever a turn adds <4,096 tokens, cache progress stalls completely, and those unabsorbed 1k–4k tokens get re-billed at full uncached rates on every single turn until you finally cross the next 4k mark.
2️ Argon: Longer TTL, but a sneaky 2,050-token tail tax & random drops • Longer TTL, still flaky: Argon killed explicit caching completely. Implicit cache now holds up for 15–30 mins (80%–92% survival at 3–10 mins). Yet even on a single account in rapid back-and-forth (<45s apart), ~1.5% of turns still randomly drop to 0-cache and re-prefill 150k+ tokens from scratch. • The 2,050-token tail tax: Google's docs claim: "For smaller additions [<2,050 tokens], Gemini re-processes the last 2,050 tokens of the previous request at the standard input rate. Most agent turns exceed this threshold." Honestly, whoever wrote "most agent turns exceed this threshold" doesn't run coding agents. Running rg, git status, or a small edit only adds a few hundred tokens. Across 5,867 cache-hit turns, over half got slapped with an exact 2,049-token re-billing penalty — paying full uncached price again for the tail of the previous turn, inflating total uncached billing by +46%.

3️ Argon's TTFT is painfully slow compared to everything else Even with >80% cache hit on 100k+ context, Argon takes 17–20s on average just to produce the first token (P50 14s, P90 40s). For comparison, my TTFT tracker explicitly strips out GPT's encrypted_content tokens so it only measures real visible/reasoning output — and even then, GPT-Sol takes just ~5s, while Claude Opus, DeepSeek, and GLM take ~2s. Waiting 15–40s per step makes single-tool agent loops brutal unless you batch tool calls into scripts.

[sususu @sususu9998]

Google Antigravity has a quota accounting bug on Gemini 4 Argon: it ignores the 95% implicit cache discount and bills cached tokens as 100% full input, draining the $200/mo Ultra weekly limit ~7x faster than it should.

I tracked token telemetry on my $200/mo Google AI Ultra plan before and after my weekly quota reset — here is the side-by-side proof:

1. Prior Cycle (`gemini-3.8-flash-high` — Cache Discount Works):
On `gemini-3.8-flash-high` ($1.50/1M in, $7.50/1M out, $0.15/1M cached at 90% off), processing ~1.2B total input tokens (~888M cached, 74% cache hit rate) + ~33.8M output tokens equals ~$875 in standard API value.
That consumed ~30% of the weekly Ultra limit — meaning a $200/mo Ultra plan normally gives ~$2,900–$3,000/week in list-price Gemini quota (~$1,450–$1,500/week at 50% intro pricing).
If Flash hadn't discounted those 888M cached tokens by 90%, it would have burned over $2,000 (~70% of the weekly quota). So Flash caching works as advertised.

2. Current Cycle (`gemini-4-argon-high` — Cache Discount Broken):
Published Gemini 4 Argon API pricing (through Nov 30):
- Uncached Input: $2.00 / 1M ($4.00 after Dec 1)
- Output (incl. thinking): $10.00 / 1M ($20.00 after Dec 1)
- Implicit Cached Input: $0.10 / 1M (95% OFF — 1/20th of input)

After my weekly reset, I ran `gemini-4-argon-high` in multi-turn agentic coding sessions:
- Total Input: ~425.0M tokens
- Uncached Input: ~85.6M tokens
- Implicit Cache Hits: ~339.4M tokens (~80% cache hit rate)
- Total Output (incl. thinking): ~4.2M tokens

At published introductory API rates ($2/$10/$0.10), this entire workload costs just ~$247 (or ~$495 at post-Dec 1 full rates).
Yet it wiped out ~62% of my entire weekly Ultra quota in a single day!
At that burn rate, a $200/mo Ultra plan running pure Argon hits 0% weekly quota after only ~$400 of intro-priced API usage.

3. The Exact Upstream Bug:
Why did ~$247 of Argon eat ~62% of a ~$2,900/week Ultra quota pool?
In Gemini's `usageMetadata`, `promptTokenCount` reports TOTAL input (uncached + `cachedContentTokenCount`).
For `gemini-4-argon` (which uses durable implicit caching only), Antigravity's quota meter appears to bill `promptTokenCount` directly at the full $4.00/1M rate without subtracting `cachedContentTokenCount` at 95% off (and without applying the Nov 30 50% intro discount):

425.0M total input × $4.00/1M + 4.2M output × $20.00/1M = $1,700 + $84 = $1,784.
And what is $1,784 divided by the ~$2,900 Ultra weekly cap?
61.5% — matching the ~62% weekly quota drop almost to the decimal!

4. Community Reports & Telemetry Showing the Exact Same Issue:
- @1984_is_today ($200 Ultra telemetry: 19.5M uncached in / 2.7M out / 315M cached = $97.50 intro cost, yet it ate 1/3rd of the weekly limit — billing all 334.5M total input at full rate is ~$1,050+, which is ~35% of a $3,000 cap):
https://t.co/QNfsJGzX6w
https://t.co/MsuooJrYLx
- @MarshGradivus ($200 Ultra burning ~30% of weekly quota in 2 hours across 3 sessions):
https://t.co/JBeKkDkRcT
- @ashen_one ($100 Ultra hitting limit in 30 mins):
https://t.co/vFGcsJmxyw
- @khatabxbt (One-shotting session usage limit on Argon):
https://t.co/vnVI4W7vcp

In multi-turn agentic coding, every step re-sends 100k+ tokens of cached context. Billing `cachedContentTokenCount` as full uncached input penalizes Antigravity Ultra users by ~6.5x to 7x on every turn.

Could the team check if `cachedContentTokenCount` is being discounted by 95% in the `gemini-weekly` / `gemini-5h` quota calculation for Gemini 4 Argon (and consider a quota reset once patched)?

cc @_mohansolo @kevinhou22 @OfficialLoganK @_anshulr @vikaskansalHQ @antigravity @googleaidevs

Powered by gemini-4-argon-high