轻量、独立的Chat Completions模型转Responses协议代理服务-----将你的大模型接入CodeX的最新解决方案!

ResponsesChatProxy是一个轻量级代理服务，解决OpenAI ResponsesAPI与ChatCompletions生态的兼容问题。它通过协议转换实现双向兼容：将ResponsesAPI请求转换为ChatCompletions格式发送到上游服务，并将响应转换回ResponsesAPI格式返回。支持流式/非流式请求、代理侧鉴权，以及交互式本地启动。典型应用场景包括：上游仅支持Chat

weixin_58935100

1062人浏览 · 2026-05-06 21:31:53

weixin_58935100 · 2026-05-06 21:31:53 发布

Responses Chat Proxy：一个轻量代理，让 Responses API 无缝对接 Chat Completions 生态

随着 OpenAI 推出 Responses API，开发者获得了更强大的对话管理能力。然而，现实中的生态并不统一：

1. **大量现有系统基于 Chat Completions API 构建**，迁移成本高

2. **第三方 SDK、框架、监控工具**大多只支持 Chat Completions 格式

3. **部分上游服务商**（如兼容 OpenAI 格式的第三方 API）只提供 Chat Completions 端点

如果你的客户端已经升级到 Responses API，但上游只支持 Chat Completions，怎么办？

解决方案：Responses Chat Proxy

**[Responses Chat Proxy]** 是一个轻量、独立的代理服务：接收 Responses API 请求，自动转换为 Chat Completions 请求，转发到上游，再把上游响应转换回 Responses API 格式。

- 不依赖 Django、数据库、计费系统或用户管理

- 单独部署、单独开源，专注于协议转换这一件事

- MIT 开源协议

核心功能

### 完整的协议转换

响应侧做了完整映射：`chatcmpl-*` ID 转为 `resp-*`，`prompt_tokens` 转为 `input_tokens`，流式 SSE 事件自动转换为 `response.created`、`response.output_text.delta`、`response.completed` 等 Responses 事件。

### 流式与非流式均支持

代理同时处理流式和非流式请求，SSE 事件实时转换，客户端无感知。

### 可选的代理侧鉴权

通过 `PROXY_API_KEY` 环境变量为代理添加 Bearer Token 认证，上游密钥由代理统一管理，客户端不直接接触。

### 交互式本地启动器

桌面开发场景下，运行 `responses-chat-proxy` 命令即可进入交互式配置，首次输入上游地址和 API Key 后自动保存到 `~/.responses-chat-proxy/config.json`，下次启动直接复用。

快速开始

启动器下载地址

将这个url输入到你要用responses协议的客户端配置项里即可!

### 启动

# 方式一：交互式启动器（本地开发推荐）

responses-chat-proxy.exe

# 方式二：模块启动

python -m responses_chat_proxy

# 方式三：uvicorn

uvicorn responses_chat_proxy.main:app --host 0.0.0.0 --port 8000

### 调用示例

# 非流式请求

curl http://localhost:8000/v1/responses \

  -H "Content-Type: application/json" \

  -d '{

    "model": "gpt-4o-mini",

    "instructions": "You are concise.",

    "input": "Say hello in one sentence."

  }'



# 流式请求

curl -N http://localhost:8000/v1/responses \

  -H "Content-Type: application/json" \

  -d '{

    "model": "gpt-4o-mini",

    "input": "Count to three.",

    "stream": true

  }'

客户端只需将 base URL 指向代理地址（如 `http://127.0.0.1:8000/v1`），其余代码无需任何修改。

## 典型使用场景

**1. 上游只支持 Chat Completions，客户端想用 Responses API**

这是最直接的场景。代理作为中间层，让两端各用各的格式，互不干扰。

**2. 渐进式迁移**

系统中部分服务已升级到 Responses API，部分仍在用 Chat Completions。代理可以统一入口，按需转换。

**3. 工具链兼容**

现有的测试框架、监控系统、日志分析工具大多只支持 Chat Completions 格式。代理让这些工具无需改造即可与 Responses API 协作。

**4. 安全隔离**

代理侧鉴权 + 上游密钥统一管理，客户端无需直接持有上游 API Key。

## 配置参考

| 变量 | 默认值 | 说明 |