
Free Claude Code OpenAI Responses适配器详解Responses与Anthropic双向转换【免费下载链接】free-claude-codeUse Claude Code, Codex, Pi, and OpenCode and more for free (1.3B free tokens) from your terminal, app, IDE, or phone like OpenClaw (voice supported ToS friendly)项目地址: https://gitcode.com/GitHub_Trending/fr/free-claude-codeFree Claude Code简称 FCC是一个运行在本地的免费 AI 代理网关它最大的技术亮点之一就是内置了完整的OpenAI Responses 适配器既能接收 Codex 等客户端发来的 OpenAI Responses 协议请求也能接住 Claude Code 发来的 Anthropic Messages 请求并在两者之间做双向协议转换最终路由到 50 多家上游模型供应商。这篇文章带你完整看懂这套双向转换机制的设计思路与代码落点新手也能轻松理解。为什么需要一个 Responses 适配器问题出在客户端说的是两种不同的方言上Claude Code、Pi说的是 Anthropic 的Messages协议POST /v1/messagesCodex、OpenCode、Cline、Hermes、Grok Build、Muse Code等说的是 OpenAI 的Responses协议POST /v1/responses。FCC 同时暴露这两种端点并承诺一件事谁来就用谁原来的协议回话。Codex 的流式输出必须是标准的 Responses 事件流response.created→ … →response.completedClaude Code 的流式输出必须是 Anthropic SSE 事件。如果转错协议客户端会直接罢工。协议端点在 routes.py 中注册其中POST /v1/responses专门服务 Responses 客户端入口校验由 handlers/responses.py 的ResponsesHandler负责——它只接受流式请求stream缺省或truestream: false会被以 OpenAI 风格报错拒绝然后把请求原封不动交给共享执行器。31 转换矩阵协议桥的全貌FCC 没有搞一个万能中间格式来回倒腾而是精确地只实现三种真实转换外加一种原生直通一共31个格子客户端协议上游供应商协议转换落点模块Anthropic MessagesOpenAI ChatMessages→Chatcore/anthropic/Anthropic MessagesOpenAI ResponsesMessages→Responsesprovider_input.py provider_stream.pyOpenAI ResponsesOpenAI ChatResponses→Chatchat_request.pyOpenAI ResponsesOpenAI Responses原生直通身份中继native.py整个 Responses 侧的实现都收在 core/openai_responses/ 这个包里由init.py 统一导出公共 API。这样做的收益很直接任何新增供应商都不用重复写协议转换代码只需声明它支持哪个格子即可。更完整的边界说明见 ARCHITECTURE.md。Responses→Chat一次请求是如何被翻译的当 Codex 发来一个 Responses 请求、而上游模型只支持 Chat Completions 时主角是 chat_request.py 中的build_responses_chat_request。它做的事情可以概括为四步输入项展开把 Responses 的input数组字符串、message、function_call、function_call_output、custom_tool_call_output、图片等逐个展平重组为 Chat 协议的systemmessages序列工具名编码OpenAI 的工具命名规则和上游 Chat 供应商可能不一致tools.py中的OpenAIToolNameCodec会做一次扁平化映射并保证在返回给客户端时原样还原responses_tool_identity_from_anthropic_name客户端永远看不到被改过的名字推理数据回传上一轮的推理摘要reasoning summary / 加密推理块会被 reasoning.py 收集并按目标协议支持程度回放而不是简单丢弃图片工具结果对齐带截图的function_call_output、computer_call_output遵循先发工具消息、再发多模态用户内容的回合规则保证 Chat 侧消息顺序合法。请求模型本身由 models.py 中的OpenAIResponsesRequest定义采用宽容模式解析不认识的嵌套字段会保留原样为上游扩展留了余地。Anthropic Messages→Responses反向翻译方向反过来也一样对称当 Claude Code 发来 Messages 请求、而上游只讲 Responses 协议时provider_input.py 负责把 Anthropic 请求构造成上游 Responses 请求流式回包则由 provider_stream.py 的ResponsesProviderStream处理——它消费上游的 Responses 事件流再重新编码成 Anthropic SSE 事件写给 Claude Code。输出项的构造集中在 items.pymessage_item、reasoning_item、encrypted_reasoning_item等构建函数保证了无论哪个格子产出的 Responses 项结构都符合契约。流式块的状态机文本块、推理块、工具块则放在 streaming/blocks.py配合 streaming/ledger.py 的输出台账确保半截流也能被正确收口。原生直通Responses→Responses 的身份中继最优雅的格子是直通。当上游本身就讲 Responses 协议时native.py 的NativeResponsesRelay不做任何转换只做三件门卫工作重写 FCC 拥有的字段把上游返回的model换回 FCC 的公开模型名替换掉真实供应商信息强制无状态流式出站请求固定streamtrue、storefalse并丢弃previous_response_id避免上游帮 FCC 存会话兜底收口如果流在已输出部分内容后中断synthesize_failure会基于已见的 response ID 补发一个合规的response.failed终态事件客户端不会看到悬空的流。事件格式化统一走 events.py错误信封则由 errors.py 生成——上游的 HTTP/SDK 异常会被归一化成 OpenAI 风格的错误对象再映射回 FCC 的ExecutionFailure语义。动手体验把 Codex 接进网关理解完原理实际体验只需几行配置。以 Codex 为例编辑~/.codex/config.tomlWindows 为%USERPROFILE%\.codex\config.tomlmodel_provider fcc model nvidia_nim/nvidia/nemotron-3-super-120b-a12b [model_providers.fcc] name Free Claude Code base_url http://127.0.0.1:8082/v1 wire_api responses注意关键的wire_api responses——它让 Codex 走 FCC 的 Responses 端点。模型和端口需在 admin-page.png 所示的 Admin UI 中保持一致配置后重启 Codex即可从模型选择器里直接挑选 FCC 的供应商模型而同一套网关另一边Claude Code 用/model也能看到来自同一目录的模型走 Messages 协议小结这套设计好在哪里协议契约不变形客户端始终只看到自己原生的 SSE 事件流/v1/responses与/v1/messages的错误、终态、推理字段各守其约转换代码单点收敛所有双向转换都在 core/openai_responses/ 一个包内供应商适配层只声明我支持哪个格子杜绝了每个供应商各写一份转换逻辑的失控局面最小化损耗能直通就直通身份中继能直连就不绕路避免了Responses→Messages→Responses这种有损往返。如果你既用 Claude Code 又用 CodexFree Claude Code 的 Responses 适配器基本可以让两者共用一份模型目录和一份免费额度这大概就是它作为本地代理最实用的一层价值所在。【免费下载链接】free-claude-codeUse Claude Code, Codex, Pi, and OpenCode and more for free (1.3B free tokens) from your terminal, app, IDE, or phone like OpenClaw (voice supported ToS friendly)项目地址: https://gitcode.com/GitHub_Trending/fr/free-claude-code创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考