SharedChat Codex 公益站接入 Hermes:Chat→Responses Adapter + CPA 反代
SharedChat Codex 公益站不是普通 OpenAI Chat Completions provider,而是 Responses-only Codex API。直接挂 Hermes 或 CPA openai-compatibility 容易因 /v1/chat/completions / /v1/models 不存在而失败。最终采用一层极薄本地 adapter,把 OpenAI Chat Completions 请求转成 /v1/responses,再挂到 CPA,Hermes 通过 custom:cpa-codex 使用唯一 alias SC-GPT-5.5。
SharedChat Codex 公益站不是普通 OpenAI Chat Completions provider,而是 Responses-only Codex API。直接挂 Hermes 或 CPA openai-compatibility 容易因 /v1/chat/completions / /v1/models 不存在而失败。最终采用一层极薄本地 adapter,把 OpenAI Chat Completions 请求转成 /v1/responses,再挂到 CPA,Hermes 通过 custom:cpa-codex 使用唯一 alias SC-GPT-5.5。
给 adapter 增加 /metrics 或轻量 health detail,便于巡检。
不调用真实 executor;生产动作另走审批。
关键判断
| 判断项 | 摘要 |
|---|---|
| 推荐方案 | 给 adapter 增加 /metrics 或轻量 health detail,便于巡检。 |
| 关键依据 | 见完整记录中的评分依据、状态摘要和证据链。 |
| 落地方式 | 按行动清单推进,保持可回退。 |
| 风险边界 | 不跨执行边界;真实执行需另走审批。 |
证据摘要
- 由 Hermes 会话生成。证据点 1
- 如涉及外部事实,应在正文中保留来源或验证路径。证据点 2
行动清单
/metrics 或轻量 health detail,便于巡检。SC-GPT-5.5 是否可用,但要控制额度消耗。SC-GPT-5.5 应单独评估,不建议因为公益额度直接替换现有主链路。边界 / 风险
未记录额外风险。
完整记录
SharedChat Codex 公益站接入 Hermes:Chat→Responses Adapter + CPA 反代实施记录
记录时间:2026-05-29 22:59 CST
类型:排障复盘 / 接入 runbook / 决策留档
结论:已实现Hermes → CPA → 本地 adapter → SharedChat Codex Responses API,SC-GPT-5.5已支持非流式与 SSE streaming。
一句话结论
SharedChat Codex 公益站不是普通 OpenAI Chat Completions provider,而是 Responses-only Codex API。直接挂 Hermes 或 CPA openai-compatibility 容易因 /v1/chat/completions / /v1/models 不存在而失败。最终采用一层极薄本地 adapter,把 OpenAI Chat Completions 请求转成 /v1/responses,再挂到 CPA,Hermes 通过 custom:cpa-codex 使用唯一 alias SC-GPT-5.5。
背景
用户提供了一个适合 Codex 的公益模型站点:
- Base:
https://new.sharedchat.cc/codex - 模型:
gpt-5.5、gpt-5.4 - 目标:让 Hermes 可用,同时保留 CPA 统一入口与模型 alias 管理。
先前实测证明:
GET /health可用POST /v1/responses可用POST /v1/chat/completions不可用GET /v1/models不可用- Codex CLI 使用
wire_api = "responses"可以直连
因此它不是常规 OpenAI-compatible chat provider,而是面向 Codex/Responses 的专线。
关键判断
| 问题 | 判断 | 原因 |
|---|---|---|
| 能不能直接给 Codex CLI 用 | 可以 | Codex CLI 原生支持 wire_api = "responses" |
| 能不能直接给 Hermes 用 | 不稳 | Hermes 常规 custom provider 走 Chat Completions 语义 |
| 能不能直接挂 CPA openai-compatibility | 不建议裸挂 | CPA openai-compat 上游通常预期 /v1/chat/completions |
| 需不需要 cc switch | 不需要 | cc switch 主要解决 Codex CLI provider 切换,不解决 Hermes Chat→Responses |
| 最小稳定方案 | 本地 Chat→Responses adapter + CPA alias | CPA 看到标准 OpenAI-compatible provider,Hermes 不需要特殊改造 |
最终架构
模型 alias:
已落地文件
Adapter 脚本
提供接口:
功能:
- 非流式 Chat Completions → Responses → Chat Completions
- 流式 Chat Completions SSE → Responses SSE → Chat Completion chunks
- 静态模型列表:
gpt-5.5、gpt-5.4 - 仅本机监听
127.0.0.1:8329 - 无第三方依赖,仅 Python 标准库
环境变量文件
权限:
主要变量:
密钥变量:
systemd --user 服务
服务状态:
启用自启:
重启:
日志:
CPA 配置
CPA 配置文件:
追加的 openai-compatibility:
备份文件:
CPA 已热加载,无需重启即可看到新 alias。
验证记录
1. SharedChat 原始 Responses API
路径:
模型:
结果:
2. Adapter 非流式
请求:
结果:
3. CPA 非流式
请求:
结果:
4. Hermes 非流式
命令:
结果:
5. Adapter streaming
请求:
返回:
6. CPA streaming
请求:
结果:
7. Hermes streaming
命令:
结果:
关键变化:不再出现:
SSE streaming 踩坑
第一次实现 SSE 时 adapter 已经发出:
但 HTTP 连接保持 keep-alive,没有主动关闭。结果:
- adapter 直连看似能收到 chunk,但 curl 会等到超时才退出
- CPA 收到
text/event-streamheader 后没有向下游吐 chunk,表现为客户端等待超时
修复:
修复后:
- adapter 直连立即结束
- CPA 立刻转发 chunk
- Hermes 不再 fallback 到 non-streaming
使用方式
Hermes 使用 gpt-5.5
Hermes 使用 gpt-5.4
CPA 直接调用
管理与回滚
查看服务
重启服务
停止服务
禁用自启
回滚 CPA 配置
必要时重启 CPA:
风险与边界
| 风险 | 说明 | 应对 |
|---|---|---|
| 公益站稳定性 | 免费额度、限流、Cloudflare 策略可能变化 | 保留 CPA 其他模型 fallback,不把它作为唯一主链路 |
| 额度/限流 | 社区称每天有公益额度,但存在限速 | 控制 smoke 次数,避免长输出刷额度 |
| adapter 最小实现 | 目前主要覆盖文本 chat 与 SSE | 图片、工具调用、复杂 function calling 未完整实现 |
| CPA 依赖本地 adapter | adapter 停止后 SC-GPT-* alias 不可用 | systemd --user 托管 + health 检查 |
| 密钥泄露 | 公益站 key 存在本地 env | env 文件 600 权限,不写入 wiki/HTML 明文 |
后续建议
- 给 adapter 增加
/metrics或轻量 health detail,便于巡检。 - 如长期使用,可加一个 cron/health watchdog,定期验证
SC-GPT-5.5是否可用,但要控制额度消耗。 - 若需要工具调用/function calling,再从 OpenAI Chat tools 与 Responses tool_call 事件做双向映射,不要在当前最小 adapter 上盲目扩大。
- Hermes 主模型是否切到
SC-GPT-5.5应单独评估,不建议因为公益额度直接替换现有主链路。
归档 footer
生成模型:gpt-5.5
生成时间:2026-05-29 22:59:07 CST
归档类型:Decision Trace / Hermes provider integration runbook