Codex开源了, 其引擎完整开放, 遵循 -2.0许可, 这意味着我能够将Codex连接到本地的llama.cpp, 借助Qwen3.8 - 27B运行一个完全离线的AI编程环境。无需花费一分钱API费用, 且不用上传一行代码到云端。实际测试下来, 以55 t/s的速度, 让它对整个Codex项目代码进行分析并输出文档, 竟然真的能够运行成功。写在前面为什么我要折腾一套全本地编程环境先说说我的编程工具演变史免费的-V4-Flash模型不存在了, 剩下了其他几个模型, 将免费模型当作一种途径本地配置的qwen3.8 27B模型, 能够解决诸多问题的。依赖别人的免费午餐与自己搭一套全本地编程环境不冲突。近期再度瞅见Codex完整开源的讯息, 可以说, 我的即时反应便是: 这绝对得纳入我的AI工具箱之中。Codex 开源了什么近来, 将Codex的那个底层之中的核心引擎, 予以了完整的开放之举进行呈现, 并且是在-2.0许可这个条件之下, 一次性发布出了三大核心组件。组件说明适用场景codex exec命令行工具CI/CD 流水线等自动化任务Codex SDK官方 SDK/在自己的代码中编程式调用 Codex Agentapp-核心执行服务器构建拥有自定义界面和审批流程的完整产品换种通俗讲法就是, 曾经Codex属于那么一种“黑盒产品”, 如今却把引擎盖揭开了, 然后你能够将这一套加入到自身的产品当中, 并且正式把Codex确定为“Agent”也就是智能体平台, 还特地明确邀请开发者前来使用。官方地址//codex要进行Codex的核心理念实战, 搭建全本地Codex编程环境, 第一步是安装Codex。先确认 Node.js 环境node --version # v24.15.0 npm --version # 11.12.0安装 Codexnpm install -g openai/codex️ 国内用户注意如果下载速度慢换国内镜像源npm install -g openai/codex --registryhttps://registry.npmmirror.com安装完成后可以启动 app- 测试codex app-server--listen ws://127.0.0.1:4500第二步配置 llama.cpp 作为模型提供商Codex 供给了支持自定义且可由用户自主设定的模型提供商相关方面的功能, 而针对配置 llama.cpp 这一操作而言, 仅仅只需要两个文件即可达成。文件一, 其路径为, C 盘用户文件夹下的美元符号文件夹内的.codex 文件夹里的 llama 两个点的 toml 文件。# 配置 llama.cpp 作为模型提供商 [model_providers.llamacpp] name llama.cpp base_url http://127.0.0.1:8080/v1 # 关键明确指定使用 responses API wire_api responses文件 2C:\Users\$\.codex\my-llama-model..toml# 配置一个使用该提供商的 profile model_provider llamacpp model Qwen3.8-27B-UD-Q4_K_M请注意, “ ”这一行是极为关键的, 要是不进行指定的话, Codex与llama.cpp之间就会出现“对不上话”的情况。第三步解决 Qwen 聊天模板问题通常的状况下, Qwen模型于本地llama.cpp里运用之际存在一些状况, 要对聊天模板经行改进方可正常地、无误地开展工作, 实现其本该具有的功能, 呈现出应有的效果。进行 //Qwen - Fixed - Chat - 的下载操作 , 将 .jinja 下载下来 , 接着在启动 llama.cpp 的时候 , 要去指定模板。F:/llama_cpp/llama-b10436-bin-win-vulkan-x64/llama-server.exe \ --jinja \ --chat-template-file F:/llama_cpp/chat_template.jinja \ -ctk q4_0 -ctv q4_0 \ --reasoning off \ --models-preset F:/llama_cpp/models/models.ini \ --models-max 1 \ --no-models-autoload \ -fa on -np 1在llama.cpp的.ini里, 有着Qwen3.8 - 27B - UD - 的配置。[Qwen3.8-27B-UD-Q4_K_M] model F:/llama_cpp/models/Qwen3.8-27B-UD-Q4_K_M.gguf ctx-size 148000 ngl 99 model-draft F:/llama_cpp/models/mtp-Qwen3.8-27B-Q4_0.gguf spec-type draft-mtp spec-draft-n-max 4 flash-attn on parallel 1 cache-type-k q4_0 cache-type-v q4_0参数含义ctx-size上下文窗口约 148Kngl99全部层卸载到 GPUmodel-draftmtp-Qwen3.8-27B-Q4_0.gguf启用 MTP 投机解码spec-draft-n-max每次最多投机 4 个 tokencache-type-k/vq4_0KV Cache 量化为 4bit省显存模型到//Qwen3.8-27B-GGUF 下载。所谓 UD也就是 User-, 即用户定义量化, 它的核心优势在于, 借助精细的、自适应的混合精度策略, 在模型大小以及推理质量之间达成了比传统方法更为优异的平衡。这个 UD 模型的 MTP 草稿模型是单独分离出来的, 要下载相应的 mtp-Qwen3.8-27B-Q4_0.gguf 文件, 还要配置model-draft。实测让 Codex 分析 Codex 自己的代码弄好了环境, 来点实在之内容。我径直进行了git clone操作, 针对Codex项目, 之后, 让Codex去剖析其自身的代码。cd F:\ProjectsAI\opensource git clone https://github.com/openai/codex.git cd F:\ProjectsAI\opensource\codex codex--profile my-llama-model迈进 Codex 之后, 去确认所运用的是 Qwen3.8 - 27B - UD 这个本地模型。以指令形式输入, 对处于项目之中的代码进行剖析, 将其主要思想, 书写记录于 ycz/doc/.md 这个位置。然后回车Codex 就开始干活了。性能数据llama.cpp 生成速度在运行的阶段之中, 关于llama.cpp的终端, token生成这一速度的输出情况。[59663] 6.31.988.689 I slot print_timing: id 0 | task 907 | n_gen 1677, tg 55.40 t/s, tg_3s 53.07 t/s [59663] 6.35.012.676 I slot print_timing: id 0 | task 907 | n_gen 1813, tg 54.45 t/s, tg_3s 44.97 t/s [59663] 6.38.038.906 I slot print_timing: id 0 | task 907 | n_gen 1984, tg 54.62 t/s, tg_3s 56.51 t/s [59663] 6.41.076.140 I slot print_timing: id 0 | task 907 | n_gen 2143, tg 54.45 t/s, tg_3s 52.35 t/s [59663] 6.44.117.690 I slot print_timing: id 0 | task 907 | n_gen 2331, tg 54.97 t/s, tg_3s 61.81 t/s [59663] 6.47.158.515 I slot print_timing: id 0 | task 907 | n_gen 2499, tg 54.99 t/s, tg_3s 55.25 t/s平均达到了 50 多 token还不错。核心数据总结首个感受是, 每秒五十五吨的速度, 针对“委托式”编程的话那就已全然够使用。Codex并不需要你全程目不转睛地盯着它进而逐字输出, 它亲自查阅代码, 展开思考, 着手撰写文件, 全套流程均为异步形式。你仅仅只需静候它把活儿干完便万事大吉。任务完成对Codex而言, 其命令行界面完成了任务, 不过呢, 这个命令行界面着实不太美观。任务完成后可以看到生成了相应的文件全本地 Codex 编程体验如何优点优点说明零 API 费用完全本地推理不花一分钱代码不出门所有代码都在本地隐私安全不依赖网络断网也能编程只要 llama.cpp 在跑速度够用55 t/s 对于委托式任务完全 OK开源可控Codex llama.cpp 全开源想改就改不足不足说明模型能力有限27B 本地的模型, 跟 GPT - 4 相比较而言, 是存在着一定差距的, 在面对复杂任务的时候, 或许是没办法完成搞定的。命令行体验差Codex CLI 在 下界面确实不好看显存占用大27B Q4 148K 显存吃紧聊天模板要手动修Qwen 默认模板有问题需要额外配置给你的建议如果你也想搭一套全本地 AI 编程环境我的建议是建议说明明确你的目标日常的小任务, 那是包含写脚本、分析代码以及修 bug 这些的, 其所需容量在本地 27B 就能够满足用度而复杂架构的设计这个情况, 表明呢还是非得借助云端的大模型才行的。Qwen 模板一定要修不修聊天模板Codex 和 Qwen 之间会鸡同鸭讲MTP 投机解码必开spec-type draft-mtp能显著提升生成速度Qwen3.8 有现成的 MTP 模型KV Cache 量化别省-ctk q4_0 -ctv q4_0能省大量显存给 留出空间委托式使用别盯着看Codex有的设计哲学是“大胆委托”, 将任务丢给它, 而后去喝杯咖啡, 最后回来收成果。总结全本地 Codex 编程值不值回头来看刚开始提到的那个问题, 耗费精力去构建起一整套全是本地的Codex以及llama.cpp的环境, 这样做究竟是否值得呢?要是你的需求在于日常编程辅助工作, 以及代码分析范畴, 和小任务自动化上面——那是值得的。没有花钱的地方, 代码不用到外面去, 55 t/s 这样的配置完全能够满足使用需求。假设你的要求是复杂架构设计, 还有大型项目重构, 这还不够。27B本地模型的能力上限就摆在那儿, 在这种情形下还是得运用云端旗舰模型。这次实际测试, 使我再次对一个问题进行了思考, 这个问题是, AI编程工具的核心竞争力, 究竟是模型具备的能力, 还是工程方面的框架呢?Codex的引擎证实表明: 一个良好出色的Agent框架, 加上一个具有足够功能的本地模型, 便能够实现“委托式编程”之完整闭环的顺畅运行。以往我曾认为“本地模型进行编程”乃是虚假需求, 然而当下我察觉到, 对于日常百分之八十的编程任务而言, 本地27B加上Codex已经颇具成效, 可以满足需求了——而诸如剩余百分之二十的复杂任务层面, 就再将其交付给云端旗舰型模型去应对解决。全本地不是目的够用才是。参考资料 Codex+llama.cpp+Qwen3.8-27B，RTX4090跑55t/s AI编程实测
Codex开源了, 其引擎完整开放, 遵循 -2.0许可, 这意味着我能够将Codex连接到本地的llama.cpp, 借助Qwen3.8 - 27B运行一个完全离线的AI编程环境。无需花费一分钱API费用, 且不用上传一行代码到云端。实际测试下来, 以55 t/s的速度, 让它对整个Codex项目代码进行分析并输出文档, 竟然真的能够运行成功。写在前面为什么我要折腾一套全本地编程环境先说说我的编程工具演变史免费的-V4-Flash模型不存在了, 剩下了其他几个模型, 将免费模型当作一种途径本地配置的qwen3.8 27B模型, 能够解决诸多问题的。依赖别人的免费午餐与自己搭一套全本地编程环境不冲突。近期再度瞅见Codex完整开源的讯息, 可以说, 我的即时反应便是: 这绝对得纳入我的AI工具箱之中。Codex 开源了什么近来, 将Codex的那个底层之中的核心引擎, 予以了完整的开放之举进行呈现, 并且是在-2.0许可这个条件之下, 一次性发布出了三大核心组件。组件说明适用场景codex exec命令行工具CI/CD 流水线等自动化任务Codex SDK官方 SDK/在自己的代码中编程式调用 Codex Agentapp-核心执行服务器构建拥有自定义界面和审批流程的完整产品换种通俗讲法就是, 曾经Codex属于那么一种“黑盒产品”, 如今却把引擎盖揭开了, 然后你能够将这一套加入到自身的产品当中, 并且正式把Codex确定为“Agent”也就是智能体平台, 还特地明确邀请开发者前来使用。官方地址//codex要进行Codex的核心理念实战, 搭建全本地Codex编程环境, 第一步是安装Codex。先确认 Node.js 环境node --version # v24.15.0 npm --version # 11.12.0安装 Codexnpm install -g openai/codex️ 国内用户注意如果下载速度慢换国内镜像源npm install -g openai/codex --registryhttps://registry.npmmirror.com安装完成后可以启动 app- 测试codex app-server--listen ws://127.0.0.1:4500第二步配置 llama.cpp 作为模型提供商Codex 供给了支持自定义且可由用户自主设定的模型提供商相关方面的功能, 而针对配置 llama.cpp 这一操作而言, 仅仅只需要两个文件即可达成。文件一, 其路径为, C 盘用户文件夹下的美元符号文件夹内的.codex 文件夹里的 llama 两个点的 toml 文件。# 配置 llama.cpp 作为模型提供商 [model_providers.llamacpp] name llama.cpp base_url http://127.0.0.1:8080/v1 # 关键明确指定使用 responses API wire_api responses文件 2C:\Users\$\.codex\my-llama-model..toml# 配置一个使用该提供商的 profile model_provider llamacpp model Qwen3.8-27B-UD-Q4_K_M请注意, “ ”这一行是极为关键的, 要是不进行指定的话, Codex与llama.cpp之间就会出现“对不上话”的情况。第三步解决 Qwen 聊天模板问题通常的状况下, Qwen模型于本地llama.cpp里运用之际存在一些状况, 要对聊天模板经行改进方可正常地、无误地开展工作, 实现其本该具有的功能, 呈现出应有的效果。进行 //Qwen - Fixed - Chat - 的下载操作 , 将 .jinja 下载下来 , 接着在启动 llama.cpp 的时候 , 要去指定模板。F:/llama_cpp/llama-b10436-bin-win-vulkan-x64/llama-server.exe \ --jinja \ --chat-template-file F:/llama_cpp/chat_template.jinja \ -ctk q4_0 -ctv q4_0 \ --reasoning off \ --models-preset F:/llama_cpp/models/models.ini \ --models-max 1 \ --no-models-autoload \ -fa on -np 1在llama.cpp的.ini里, 有着Qwen3.8 - 27B - UD - 的配置。[Qwen3.8-27B-UD-Q4_K_M] model F:/llama_cpp/models/Qwen3.8-27B-UD-Q4_K_M.gguf ctx-size 148000 ngl 99 model-draft F:/llama_cpp/models/mtp-Qwen3.8-27B-Q4_0.gguf spec-type draft-mtp spec-draft-n-max 4 flash-attn on parallel 1 cache-type-k q4_0 cache-type-v q4_0参数含义ctx-size上下文窗口约 148Kngl99全部层卸载到 GPUmodel-draftmtp-Qwen3.8-27B-Q4_0.gguf启用 MTP 投机解码spec-draft-n-max每次最多投机 4 个 tokencache-type-k/vq4_0KV Cache 量化为 4bit省显存模型到//Qwen3.8-27B-GGUF 下载。所谓 UD也就是 User-, 即用户定义量化, 它的核心优势在于, 借助精细的、自适应的混合精度策略, 在模型大小以及推理质量之间达成了比传统方法更为优异的平衡。这个 UD 模型的 MTP 草稿模型是单独分离出来的, 要下载相应的 mtp-Qwen3.8-27B-Q4_0.gguf 文件, 还要配置model-draft。实测让 Codex 分析 Codex 自己的代码弄好了环境, 来点实在之内容。我径直进行了git clone操作, 针对Codex项目, 之后, 让Codex去剖析其自身的代码。cd F:\ProjectsAI\opensource git clone https://github.com/openai/codex.git cd F:\ProjectsAI\opensource\codex codex--profile my-llama-model迈进 Codex 之后, 去确认所运用的是 Qwen3.8 - 27B - UD 这个本地模型。以指令形式输入, 对处于项目之中的代码进行剖析, 将其主要思想, 书写记录于 ycz/doc/.md 这个位置。然后回车Codex 就开始干活了。性能数据llama.cpp 生成速度在运行的阶段之中, 关于llama.cpp的终端, token生成这一速度的输出情况。[59663] 6.31.988.689 I slot print_timing: id 0 | task 907 | n_gen 1677, tg 55.40 t/s, tg_3s 53.07 t/s [59663] 6.35.012.676 I slot print_timing: id 0 | task 907 | n_gen 1813, tg 54.45 t/s, tg_3s 44.97 t/s [59663] 6.38.038.906 I slot print_timing: id 0 | task 907 | n_gen 1984, tg 54.62 t/s, tg_3s 56.51 t/s [59663] 6.41.076.140 I slot print_timing: id 0 | task 907 | n_gen 2143, tg 54.45 t/s, tg_3s 52.35 t/s [59663] 6.44.117.690 I slot print_timing: id 0 | task 907 | n_gen 2331, tg 54.97 t/s, tg_3s 61.81 t/s [59663] 6.47.158.515 I slot print_timing: id 0 | task 907 | n_gen 2499, tg 54.99 t/s, tg_3s 55.25 t/s平均达到了 50 多 token还不错。核心数据总结首个感受是, 每秒五十五吨的速度, 针对“委托式”编程的话那就已全然够使用。Codex并不需要你全程目不转睛地盯着它进而逐字输出, 它亲自查阅代码, 展开思考, 着手撰写文件, 全套流程均为异步形式。你仅仅只需静候它把活儿干完便万事大吉。任务完成对Codex而言, 其命令行界面完成了任务, 不过呢, 这个命令行界面着实不太美观。任务完成后可以看到生成了相应的文件全本地 Codex 编程体验如何优点优点说明零 API 费用完全本地推理不花一分钱代码不出门所有代码都在本地隐私安全不依赖网络断网也能编程只要 llama.cpp 在跑速度够用55 t/s 对于委托式任务完全 OK开源可控Codex llama.cpp 全开源想改就改不足不足说明模型能力有限27B 本地的模型, 跟 GPT - 4 相比较而言, 是存在着一定差距的, 在面对复杂任务的时候, 或许是没办法完成搞定的。命令行体验差Codex CLI 在 下界面确实不好看显存占用大27B Q4 148K 显存吃紧聊天模板要手动修Qwen 默认模板有问题需要额外配置给你的建议如果你也想搭一套全本地 AI 编程环境我的建议是建议说明明确你的目标日常的小任务, 那是包含写脚本、分析代码以及修 bug 这些的, 其所需容量在本地 27B 就能够满足用度而复杂架构的设计这个情况, 表明呢还是非得借助云端的大模型才行的。Qwen 模板一定要修不修聊天模板Codex 和 Qwen 之间会鸡同鸭讲MTP 投机解码必开spec-type draft-mtp能显著提升生成速度Qwen3.8 有现成的 MTP 模型KV Cache 量化别省-ctk q4_0 -ctv q4_0能省大量显存给 留出空间委托式使用别盯着看Codex有的设计哲学是“大胆委托”, 将任务丢给它, 而后去喝杯咖啡, 最后回来收成果。总结全本地 Codex 编程值不值回头来看刚开始提到的那个问题, 耗费精力去构建起一整套全是本地的Codex以及llama.cpp的环境, 这样做究竟是否值得呢?要是你的需求在于日常编程辅助工作, 以及代码分析范畴, 和小任务自动化上面——那是值得的。没有花钱的地方, 代码不用到外面去, 55 t/s 这样的配置完全能够满足使用需求。假设你的要求是复杂架构设计, 还有大型项目重构, 这还不够。27B本地模型的能力上限就摆在那儿, 在这种情形下还是得运用云端旗舰模型。这次实际测试, 使我再次对一个问题进行了思考, 这个问题是, AI编程工具的核心竞争力, 究竟是模型具备的能力, 还是工程方面的框架呢?Codex的引擎证实表明: 一个良好出色的Agent框架, 加上一个具有足够功能的本地模型, 便能够实现“委托式编程”之完整闭环的顺畅运行。以往我曾认为“本地模型进行编程”乃是虚假需求, 然而当下我察觉到, 对于日常百分之八十的编程任务而言, 本地27B加上Codex已经颇具成效, 可以满足需求了——而诸如剩余百分之二十的复杂任务层面, 就再将其交付给云端旗舰型模型去应对解决。全本地不是目的够用才是。参考资料