问题描述：

现在是这样的，有一个open AI 的订阅账号，现在想要把账号的额度在上游转化成 claude code 可以用的。因为有些朋友不太熟悉这个技术，直接给他一个base url/api 还能用的明白，但是要是说要让他下游配个什么cc-switch， Claude-code-proxy这种估计就够呛了（因为环境可能比较复杂，又是各种服务器要用又是各种桌面端啥的）

现在有的条件:

• 一个 有公网IP的 国外服务器(VPS)，可以访问open ai ，claude等
• 有 open AI 的plus 或者free账号，有组号池的条件

目标:

• 给3-4个朋友使用，可以分额度管理 API使用情况
• 只用提供 base url, 和 key，可以让claude接入 GPT模型， 客户端不做任何调整

sub2api上有这样的功能嘛，没有的话有现有的项目或者程序嘛。
想先问问，实在没有的话趁清明可以试着做一个demo

网友解答：

---

--【壹】--： tuyh:

+new-api完全可以，搜索一下历史帖子，多得很

好的，明天我尝试一下，效果如何之后回来跟佬友们汇报

---

--【贰】--：

github.com

GitHub - Wei-Shaw/sub2api: Sub2API-CRS2 一站式开源中转服务，让 Claude、Openai...

Sub2API-CRS2 一站式开源中转服务，让 Claude、Openai 、Gemini、Antigravity订阅统一接入，支持拼车共享，更高效分摊成本，原生工具无缝使用。

这个尝试了几天，感觉bug非常多，还不是一个很成熟的产品。主要可能是功能太多了

---

--【叁】--：

sub2api已经支持了/v1/messages 到 /v1/responses的转化，直接用sub2api的地址就行，如果想要使用xhigh可以配置为gpt-5.4-xhigh。如果要在cc里面/effort切换模型强度可以把模型名称映射为包含opus-4-6就行。

---

--【肆】--：

新版本的 sub2api 已经支持了吧，不需要任何其他工具

---

--【伍】--：

这个是claude 的配置文件吧，这个确实没有修改过

我用的是 http://域名:端口 的格式

并且cherry open ai的模型测试是通过的

这个我明天试试，如果实在不行。这个也算方便的，改个配置应该改的明白吧

---

--【陆】--：

可以在cc直接用/v1/messages格式。sub2api带上user参数在/v1/responses确实有问题，不过我没遇到这个场景。

---

--【柒】--：

sub2api直接就有这个能力

---

--【捌】--：

捕获2504×857 23.7 KB

昨天晚上装的sub2api，版本0.1.106,claude-cli使用完全没有问题，分组管理打开 OpenAI Messages 调度配置，其他啥都不用配置

---

--【玖】--： 阿杰鲁:

sub2api

大哥们 现在用的是哪个sub2api

---

--【拾】--：

奇怪了，我也是这样配置的。然后claude 测试的时候是无响应的

在cherry里面用 /v1/messages 这个请求，返回的格式是open AI 的格式，然后也会报错

打算反代出来然后用new-api 去兼容格式了

---

--【拾壹】--：

CC-switch侧开代理的方案，其实就是做下游适配了，下游适配我有其他的方案了，就是用 claude-code-proxy，比cc-switch好的就是不需要图形界面。

用这种方案个人应该是可以用的，但是不符合我开头的哪个需求，所以这个尝试是往后排的

---

--【拾贰】--：

直接挂sub2api，用claude确实不行。

用ccr转换一下，推荐npx zcf

---

--【拾叁】--：

那是我配置有问题嘛，无论选模型映射还是自动穿透，乃至于指定claude --model 。claude 都没法使用。服务端log 没有收到任何的请求。客户端是一直再转没有反应

---

--【拾肆】--：

这个方案宣告破产，其实本质上就是指定模型，指定模型之后还是一样，仍然是无法连接

---

--【拾伍】--：

可以试一下cc-switch里面打开代理，然后选择responses格式，在cc-switch侧转化，看看行不行。

---

--【拾陆】--：

即使是/v1/responses 的格式 如果 请求头 带user参数 似乎也是不行的

我怀疑是我的claude插件里面有一些多余的请求头

github.com/Wei-Shaw/sub2api

# [Bug] `/v1/responses` endpoint forwards unsupported `user` parameter to upstream, causing 400 error

已打开 01:52PM - 24 Mar 26 UTC Polaris-F

# [Bug] `/v1/responses` endpoint forwards unsupported `user` parameter to upstre…am, causing 400 error ## Description When clients (e.g., LobeHub v2) send requests to the `/v1/responses` endpoint with a `user` parameter, Sub2API forwards this parameter to the upstream OpenAI API without filtering it out. The upstream API rejects the request with a `400 Bad Request` error: `Unsupported parameter: user`. This issue affects models like `gpt-5.4`, `gpt-5.3-codex`, etc., when accessed through the Responses API endpoint. ## Steps to Reproduce 1. Send a POST request to `/v1/responses` (or `/responses`) with a body that includes the `user` field: ```json { "model": "gpt-5.4", "stream": true, "input": [ {"role": "user", "content": "hello"} ], "user": "user_123" } ``` 2. Sub2API forwards the request to the upstream OpenAI API, including the `user` parameter. 3. The upstream API returns: `400 Bad Request - Unsupported parameter: user` ## Error Log ``` 2026-03-24T19:44:46.925+0800 WARN handler/openai_gateway_handler.go:337 openai.forward_failed { "component": "handler.openai_gateway.responses", "model": "gpt-5.4", "stream": true, "error": "upstream error: 400 message=Unsupported parameter: user" } ``` ## Expected Behavior The `user` parameter should be stripped from the request body before forwarding to the upstream API, similar to how other unsupported parameters (`prompt_cache_retention`, `safety_identifier`) are already handled. ## Suggested Fix In `internal/service/openai_gateway_service.go`, add `"user"` to the `unsupportedFields` list: ```go // Current code (line ~1914): unsupportedFields := []string{"prompt_cache_retention", "safety_identifier"} // Suggested fix: unsupportedFields := []string{"prompt_cache_retention", "safety_identifier", "user"} ``` ## Environment - Sub2API version: 0.1.104 (commit: 4f7629a4, built: 2026-03-20) - Client: LobeHub v2.1.44 - Upstream: OpenAI API (OAuth accounts) - Affected endpoint: `POST /v1/responses` and `POST /responses` - Affected models: All models accessed via Responses API (gpt-5.4, gpt-5.3-codex, etc.) ## Additional Context - The `/v1/chat/completions` endpoint is NOT affected — only `/v1/responses`. - LobeHub v2 sends the `user` parameter for user tracking purposes. The upstream OpenAI Responses API does not support this parameter. - Similar issues have been fixed before: `max_output_tokens` was handled in a similar way (ref: #831, PR #1107).

佬友有测试 /v1/messages 这个请求的测试网站嘛，我想一点一点排查问题

---

--【拾柒】--：

ANTHROPIC_BASE_URL 只填 https://域名 ，不需要填路径

比如我用冰佬的站就是这样填的

"alwaysThinkingEnabled": true, "env": { "ANTHROPIC_AUTH_TOKEN": "sk-a", "ANTHROPIC_BASE_URL": "https://ice.v.ua", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "gpt-5.4[1m]", "ANTHROPIC_DEFAULT_OPUS_MODEL": "gpt-5.4[1m]", "ANTHROPIC_DEFAULT_SONNET_MODEL": "gpt-5.4[1m]", "ANTHROPIC_MODEL": "gpt-5.4[1m]", "ANTHROPIC_REASONING_MODEL": "gpt-5.4[1m]", "CLAUDE_CODE_ATTRIBUTION_HEADER": "0", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1", "DISABLE_INSTALLATION_CHECKS": "1", "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": 70, "ENABLE_TOOL_SEARCH": true },

---

--【拾捌】--：

CPA+new-api完全可以，搜索一下历史帖子，多得很

---

--【拾玖】--：

试了那么多版方案，还是这个方案靠谱

专业的事专业的项目干

最后选取的方案是用sub2api 反代出来，然后用new-api 做各种模型的兼容，然后用户使用的时候只需要

export ANTHROPIC_DEFAULT_OPUS_MODEL="gpt-5.4" export ANTHROPIC_DEFAULT_HAIKU_MODEL="gpt-5.3-codex" export ANTHROPIC_DEFAULT_SONNET_MODEL="gpt-5.3-codex" export ANTHROPIC_MODEL="gpt-5.4" export ANTHROPIC_REASONING_MODEL="gpt-5.4" export ANTHROPIC_BASE_URL="http://" export ANTHROPIC_AUTH_TOKEN="sk-"

把这些环境变量输进去即可