OGX 集成 Codex CLI让 OpenAI 的终端编码代理跑在任何模型上【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogx导读本文讲解如何通过 Open GenAI StackOGX将 OpenAI 的 Codex CLI 从只认 OpenAI API的封闭状态中解放出来只需在 Codex 与任意推理提供商之间插入一个 OGX 代理即可让 Codex 的终端原生编码工作流读代码、改代码、跑命令、多轮迭代对接 Ollama、vLLM、Bedrock、OpenAI 等任何 OGX 支持的模型。读完本文你将掌握完整的接入步骤、~/.codex/config.toml配置要点、模型 ID 规则、已知边界与排障方法并理解 OGX 在协议层Responses API、压缩层zstd与对话层compaction/memory的源码级实现。为什么要把 Codex 跑在 OGX 后面Codex CLI 是一个终端原生的编码代理它读取你的代码库、提出修改、执行命令并持续迭代。但它对 API 面非常挑剔——只讲 OpenAI 的 Responses API 及特定 wire 格式。直接付钱给 OpenAI 没问题但如果你想使用跑在自己硬件上的开源模型通过 Ollama 或 vLLM走企业代理统一标准化 API 访问获得对话压缩conversation compaction让超长编码会话不撞上下文窗口不重新配置 Codex 就切换模型——只需改 OGX 侧的 providerOGX 就派上了用场。它充当一个 Codex 本来就认识的代理不需要给 Codex 打补丁不需要 fork只需要一次配置变更。代理链路是怎么工作的架构非常直接Codex 把 Responses API 请求发给 OGXOGX 再按你配置的推理提供商路由并在需要时做格式转换。Codex 不知道也不关心 OGX 背后是谁。图中的 OGX SERVER 区块展示了三个关键职责Responses Engineagentic loop、工具调用、多轮、流式、Conversation Compaction长会话自动上下文压缩和 Provider Routing格式翻译、统一配置、任意后端。工具执行shell 命令、文件读写、代码生成仍然发生在 Codex 本地。OGX 只负责推理路由这一件事——这一点对排查问题至关重要。三步接入前提你已经装好 OGX 与 Codex CLI。1. 启动 OGXexport OPENAI_API_KEYyour-key-here ogx run starter想用 Ollama 而不是 OpenAIOLLAMA_URLhttp://localhost:11434/v1 ogx run starter这里starter是 OGX 内置的 starter 发行版distro。从源码看它的配置定义在 src/ogx/distributions/starter/config.yaml服务默认监听server.port: 8321并通过环境变量按需启用 provider设置OLLAMA_URL即启用remote::ollama默认http://localhost:11434/v1设置VLLM_URL启用remote::vllm此外还内置了 OpenAI、Anthropic、Bedrock、Gemini、Fireworks、Together、Groq、Azure 等一批远程推理 provider 的定义。也就是说你不设任何 key 也能用本地 Ollama 起步。2. 配置 Codex CLI把下面内容写入~/.codex/config.tomlmodel openai/gpt-4o model_provider ogx [model_providers.ogx] name OpenAI base_url http://localhost:8321/v1 wire_api responses supports_websockets false如果用的是 Ollama把 model 行改成model ollama/llama3.2:3b各字段的实践要点base_url必须指向 OGX 的 OpenAI 兼容端点/v1。OGX 的 connect 子命令在 src/ogx/cli/connect/codex.py 中会强制校验这一点——它要求 base URL 解析后必须以/v1结尾否则直接报错退出默认值正是http://localhost:8321/v1。wire_api responses告诉 Codex 走 Responses API 线路与 OGX 的 responses API 对应配置见 src/ogx/distributions/starter/config.yaml 中apis列表里的responses及内置实现 src/ogx/providers/inline/responses/builtin/impl.py。supports_websockets false禁用 WebSocket 通道走普通 HTTP 流式。3. 验证codex Write a hello world function in Python如果你看到 Codex 生成代码并提出修改代理就工作了。进阶用ogx connect codex自动生成配置如果你的 OGX 版本较新还有一条更省事的路径ogx connect codex。该命令会查询运行中 OGX 服务器的GET /v1/models、过滤掉 embedding 模型、选定默认 LLM 模型然后写入一份临时的CODEX_HOME内含ogx.config.toml与ogx-model-catalog.json最后以codex -p ogx启动且完全不动你日常的~/.codex/config.toml。支持--model指定模型、--url指定 OGX 地址、--exec做非交互式单次提问当设置了OGX_API_KEY时生成的配置会自动追加env_key认证项。实现细节见 src/ogx/cli/connect/codex.py更完整的用法说明见同仓库的姊妹篇 docs/blog/2026-06-30-codex-ogx-cli.md。模型兼容性选择由你的 OGX 服务器暴露、且兼容 Responses API 的模型openai/gpt-4oopenai/gpt-4o-miniopenai/gpt-5.4anthropic/claude-3-5-sonnet-20241022ollama/llama3.2:3b模型 ID 的格式取决于你 OGX 服务器背后挂的是哪个推理提供商。前缀openai/、ollama/等告诉 OGX 把请求路由到哪。由于本方案使用wire_api responses请确保所选模型能走通 OGX 的 Responses 路径。需要了解 OGX 的 provider 架构与注册方式可查阅仓库内的 Providers 总览 与 配置指南。源码视角三个支撑本次集成的底层机制除代理转发外OGX 在源码层面为 Codex 场景做了三件实事这直接解释了下文能做什么/不能做什么1. zstd 请求解压中间件。Codex 默认用 zstd 压缩请求体以节省带宽。OGX 在 src/ogx/core/server/server.py#L340-L442 实现了ZstdDecompressionMiddleware它检查content-encoding是否为zstd是则用zstandard解压后剥离该头并重写content-length再喂给应用解压失败会告警并回退到原始压缩体解压后超过 100 MB 直接返回 413 Payload Too Large。这就是请求压缩错误通常已在较新版本中被解决的原因。2. 对话压缩compaction。长编码会话容易撑爆上下文。OGX 的 Responses 内置 provider 在 src/ogx/providers/inline/responses/builtin/config.py 定义了CompactionConfig内置为对话生成简洁长期记忆摘要的提示模板、压缩摘要的前置 handoff 文案、可选的摘要模型以及default_compact_threshold——超过该 token 数的会话可被自动压缩。对应实现位于 src/ogx/providers/inline/responses/builtin/impl.py 的compact_openai_response。3. Memory记忆为 alpha 功能。同文件中的MemoryConfig默认关闭 Responses 记忆读写alpha 特性可配置显式 vector store、默认命名空间与内部 memory vector store 创建策略。这也是下文记忆不跨会话现状的源码根源。现状什么能用什么还不能该集成处于 alpha 阶段以下是真实状态。能正常工作基础代码生成与编辑工作流shell 命令执行与文件操作会话内的多轮对话长会话的对话压缩流式响应尚未支持记忆持久化会话历史不跨 Codex 会话存活每次codex调用都从零开始。源码中MemoryConfig默认enabled: false与之一致见 src/ogx/providers/inline/responses/builtin/config.py。错误透传部分 provider 专属错误会被代理层吞掉。如果 Codex 挂起或返回空内容去查 OGX 服务器日志。延迟多一跳网络会带来开销。本地模型Ollama可忽略不计远程 provider 则在推理时间之上增加几百毫秒。排障Model not found错误检查模型 ID 是否带 provider 前缀。gpt-4o不行openai/gpt-4o才行。OGX 的 connect 实现里select_default_model会严格校验所请求的模型必须出现在服务器返回的模型列表里否则列出可用模型并退出见 src/ogx/cli/connect/codex.py。请求压缩错误Codex 默认使用 zstd 压缩请确保你的 OGX 构建支持请求解压。较新版本已内置ZstdDecompressionMiddleware见 src/ogx/core/server/server.py#L340-L442。工具执行失败这发生在 Codex 侧而非 OGX 侧。检查 Codex 是否有执行相应操作的权限OGX 只处理推理。空响应或截断响应查看 OGX 服务器日志ogx默认输出到 stderr。通常是 provider 的限流或 token 限制导致。后续规划社区正在补齐该集成的缺口Memory API 集成实现跨 Codex 会话的持久对话存储MemoryConfig已预留向量库、命名空间等配置骨架见 src/ogx/providers/inline/responses/builtin/config.py。更好的错误传播让 provider 失败在 Codex UI 中清晰呈现。性能优化降低代理开销。小结OGX 让 Codex CLI 变成一个模型无关的终端代理Codex 只认识 OGX 这一个端点OGX 负责 provider 路由、格式转换、对话压缩与 zstd 解压。从 starter 配置 到 connect 实现 再到 服务器中间件整个链路在仓库中都有清晰可查的落点。如果你能启动 OGX 并在/v1/models里看到你的模型那么让 Codex 用上它就只差一条base_url配置的距离。【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OGX 集成 Codex CLI：让 OpenAI 的终端编码代理跑在任何模型上
OGX 集成 Codex CLI让 OpenAI 的终端编码代理跑在任何模型上【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogx导读本文讲解如何通过 Open GenAI StackOGX将 OpenAI 的 Codex CLI 从只认 OpenAI API的封闭状态中解放出来只需在 Codex 与任意推理提供商之间插入一个 OGX 代理即可让 Codex 的终端原生编码工作流读代码、改代码、跑命令、多轮迭代对接 Ollama、vLLM、Bedrock、OpenAI 等任何 OGX 支持的模型。读完本文你将掌握完整的接入步骤、~/.codex/config.toml配置要点、模型 ID 规则、已知边界与排障方法并理解 OGX 在协议层Responses API、压缩层zstd与对话层compaction/memory的源码级实现。为什么要把 Codex 跑在 OGX 后面Codex CLI 是一个终端原生的编码代理它读取你的代码库、提出修改、执行命令并持续迭代。但它对 API 面非常挑剔——只讲 OpenAI 的 Responses API 及特定 wire 格式。直接付钱给 OpenAI 没问题但如果你想使用跑在自己硬件上的开源模型通过 Ollama 或 vLLM走企业代理统一标准化 API 访问获得对话压缩conversation compaction让超长编码会话不撞上下文窗口不重新配置 Codex 就切换模型——只需改 OGX 侧的 providerOGX 就派上了用场。它充当一个 Codex 本来就认识的代理不需要给 Codex 打补丁不需要 fork只需要一次配置变更。代理链路是怎么工作的架构非常直接Codex 把 Responses API 请求发给 OGXOGX 再按你配置的推理提供商路由并在需要时做格式转换。Codex 不知道也不关心 OGX 背后是谁。图中的 OGX SERVER 区块展示了三个关键职责Responses Engineagentic loop、工具调用、多轮、流式、Conversation Compaction长会话自动上下文压缩和 Provider Routing格式翻译、统一配置、任意后端。工具执行shell 命令、文件读写、代码生成仍然发生在 Codex 本地。OGX 只负责推理路由这一件事——这一点对排查问题至关重要。三步接入前提你已经装好 OGX 与 Codex CLI。1. 启动 OGXexport OPENAI_API_KEYyour-key-here ogx run starter想用 Ollama 而不是 OpenAIOLLAMA_URLhttp://localhost:11434/v1 ogx run starter这里starter是 OGX 内置的 starter 发行版distro。从源码看它的配置定义在 src/ogx/distributions/starter/config.yaml服务默认监听server.port: 8321并通过环境变量按需启用 provider设置OLLAMA_URL即启用remote::ollama默认http://localhost:11434/v1设置VLLM_URL启用remote::vllm此外还内置了 OpenAI、Anthropic、Bedrock、Gemini、Fireworks、Together、Groq、Azure 等一批远程推理 provider 的定义。也就是说你不设任何 key 也能用本地 Ollama 起步。2. 配置 Codex CLI把下面内容写入~/.codex/config.tomlmodel openai/gpt-4o model_provider ogx [model_providers.ogx] name OpenAI base_url http://localhost:8321/v1 wire_api responses supports_websockets false如果用的是 Ollama把 model 行改成model ollama/llama3.2:3b各字段的实践要点base_url必须指向 OGX 的 OpenAI 兼容端点/v1。OGX 的 connect 子命令在 src/ogx/cli/connect/codex.py 中会强制校验这一点——它要求 base URL 解析后必须以/v1结尾否则直接报错退出默认值正是http://localhost:8321/v1。wire_api responses告诉 Codex 走 Responses API 线路与 OGX 的 responses API 对应配置见 src/ogx/distributions/starter/config.yaml 中apis列表里的responses及内置实现 src/ogx/providers/inline/responses/builtin/impl.py。supports_websockets false禁用 WebSocket 通道走普通 HTTP 流式。3. 验证codex Write a hello world function in Python如果你看到 Codex 生成代码并提出修改代理就工作了。进阶用ogx connect codex自动生成配置如果你的 OGX 版本较新还有一条更省事的路径ogx connect codex。该命令会查询运行中 OGX 服务器的GET /v1/models、过滤掉 embedding 模型、选定默认 LLM 模型然后写入一份临时的CODEX_HOME内含ogx.config.toml与ogx-model-catalog.json最后以codex -p ogx启动且完全不动你日常的~/.codex/config.toml。支持--model指定模型、--url指定 OGX 地址、--exec做非交互式单次提问当设置了OGX_API_KEY时生成的配置会自动追加env_key认证项。实现细节见 src/ogx/cli/connect/codex.py更完整的用法说明见同仓库的姊妹篇 docs/blog/2026-06-30-codex-ogx-cli.md。模型兼容性选择由你的 OGX 服务器暴露、且兼容 Responses API 的模型openai/gpt-4oopenai/gpt-4o-miniopenai/gpt-5.4anthropic/claude-3-5-sonnet-20241022ollama/llama3.2:3b模型 ID 的格式取决于你 OGX 服务器背后挂的是哪个推理提供商。前缀openai/、ollama/等告诉 OGX 把请求路由到哪。由于本方案使用wire_api responses请确保所选模型能走通 OGX 的 Responses 路径。需要了解 OGX 的 provider 架构与注册方式可查阅仓库内的 Providers 总览 与 配置指南。源码视角三个支撑本次集成的底层机制除代理转发外OGX 在源码层面为 Codex 场景做了三件实事这直接解释了下文能做什么/不能做什么1. zstd 请求解压中间件。Codex 默认用 zstd 压缩请求体以节省带宽。OGX 在 src/ogx/core/server/server.py#L340-L442 实现了ZstdDecompressionMiddleware它检查content-encoding是否为zstd是则用zstandard解压后剥离该头并重写content-length再喂给应用解压失败会告警并回退到原始压缩体解压后超过 100 MB 直接返回 413 Payload Too Large。这就是请求压缩错误通常已在较新版本中被解决的原因。2. 对话压缩compaction。长编码会话容易撑爆上下文。OGX 的 Responses 内置 provider 在 src/ogx/providers/inline/responses/builtin/config.py 定义了CompactionConfig内置为对话生成简洁长期记忆摘要的提示模板、压缩摘要的前置 handoff 文案、可选的摘要模型以及default_compact_threshold——超过该 token 数的会话可被自动压缩。对应实现位于 src/ogx/providers/inline/responses/builtin/impl.py 的compact_openai_response。3. Memory记忆为 alpha 功能。同文件中的MemoryConfig默认关闭 Responses 记忆读写alpha 特性可配置显式 vector store、默认命名空间与内部 memory vector store 创建策略。这也是下文记忆不跨会话现状的源码根源。现状什么能用什么还不能该集成处于 alpha 阶段以下是真实状态。能正常工作基础代码生成与编辑工作流shell 命令执行与文件操作会话内的多轮对话长会话的对话压缩流式响应尚未支持记忆持久化会话历史不跨 Codex 会话存活每次codex调用都从零开始。源码中MemoryConfig默认enabled: false与之一致见 src/ogx/providers/inline/responses/builtin/config.py。错误透传部分 provider 专属错误会被代理层吞掉。如果 Codex 挂起或返回空内容去查 OGX 服务器日志。延迟多一跳网络会带来开销。本地模型Ollama可忽略不计远程 provider 则在推理时间之上增加几百毫秒。排障Model not found错误检查模型 ID 是否带 provider 前缀。gpt-4o不行openai/gpt-4o才行。OGX 的 connect 实现里select_default_model会严格校验所请求的模型必须出现在服务器返回的模型列表里否则列出可用模型并退出见 src/ogx/cli/connect/codex.py。请求压缩错误Codex 默认使用 zstd 压缩请确保你的 OGX 构建支持请求解压。较新版本已内置ZstdDecompressionMiddleware见 src/ogx/core/server/server.py#L340-L442。工具执行失败这发生在 Codex 侧而非 OGX 侧。检查 Codex 是否有执行相应操作的权限OGX 只处理推理。空响应或截断响应查看 OGX 服务器日志ogx默认输出到 stderr。通常是 provider 的限流或 token 限制导致。后续规划社区正在补齐该集成的缺口Memory API 集成实现跨 Codex 会话的持久对话存储MemoryConfig已预留向量库、命名空间等配置骨架见 src/ogx/providers/inline/responses/builtin/config.py。更好的错误传播让 provider 失败在 Codex UI 中清晰呈现。性能优化降低代理开销。小结OGX 让 Codex CLI 变成一个模型无关的终端代理Codex 只认识 OGX 这一个端点OGX 负责 provider 路由、格式转换、对话压缩与 zstd 解压。从 starter 配置 到 connect 实现 再到 服务器中间件整个链路在仓库中都有清晰可查的落点。如果你能启动 OGX 并在/v1/models里看到你的模型那么让 Codex 用上它就只差一条base_url配置的距离。【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考