2026 年 10 月中旬我连续两周高强度使用 Codex 桌面端处理一个跨平台自动化脚本项目账户积分一动不动。这个结果不是靠什么隐藏福利也不是限制自己的使用频率而是靠给 Codex 桌面端配了一个调度层——WorkBuddy CLI把大量请求从云端计费通道转移到了本地推理服务和缓存命中上。这篇文章把整套配置过程、原理和踩过的坑完整写下来给同样被积分消耗困扰、又不想降低使用频率的朋友作参考。先说清楚这套方案适合谁主力使用 Codex 桌面端写代码、跑任务但是积分吃紧同时自己有一定的命令行基础和本地运行模型的能力或者至少愿意装一个推理服务。如果你只是想偷懒省事不关心请求到底走了哪条链路那这篇文章对你来说会有点偏原理向。但如果你愿意花半小时做一次配置换来长期积分零消耗那这半小时绝对值得。1. 为什么积分会悄悄烧光先看清计费逻辑再谈省积分一开始我也以为是 Codex 桌面端的单次提问太贵后来把消耗明细拉出来才发现问题根本不在“一次提问”上而在于后台的请求链。桌面端看起来是你输入一句话、它回一段代码实际背后可能经历了任务规划、上下文整理、多次模型调用、结果自检等多个环节每一个环节都在消耗积分。你以为自己只问了 3 个问题实际账单上可能是 10 次调用。1.1 Codex 桌面端的消耗点不在输入框而在后台请求链以我常用的场景为例让 Codex 桌面端“重构某个模块然后把单元测试补上”。这个任务分为几个阶段第一阶段读取目录结构理解模块依赖这需要把文件内容拼进上下文。第二阶段生成重构方案并对比当前代码逐段给出修改建议。第三阶段自动编辑文件并再次读取改动后的文件确认没有语法错误。第四阶段根据最终代码生成测试用例然后试着运行测试并收集输出。这四个阶段中桌面端通常要和云端模型来回通信很多次。每一次通信的 token 量都相当可观尤其是读取大文件和回写大段代码时。积分的本质是按 token 和调用次数计算的所以不是“问得多”才烧得快而是“任务链条长”烧得快。我之前做过一次统计一个包含 40 个文件的 Python 项目让桌面端做一次全局重构前后消耗相当于平时 60 多次简单问答。这就是大多数人觉得积分“莫名其妙就没了的”根源——你看到的只是几次任务实际上后台跑了上百次调用。1.2 WorkBuddy CLI 不是平替是调度层很多人一听“搭配 CLI”以为是用命令行工具来替代桌面端。不对WorkBuddy CLI 在这里扮演的角色是调度层不是替代品。简单说WorkBuddy CLI 坐在桌面端和模型端点之间做了三件事把任务按类型分流能本地解决的问题直接丢给本地推理服务不经过云端计费通道。给相似请求做缓存同样的报错信息、同样的文件片段在一定时间内直接复用之前的处理结果。把需要云端处理的请求压缩后再转发去掉冗余上下文只保留和当前任务强相关的片段降低单次调用的 token 量。这样一来大量机械性、重复性的工作被挡在了云端付费通道之外。真正需要云端大模型出马的任务比如复杂架构设计、长文本语义理解才走云端而这些任务在你的日常使用中占比通常不到 30%。1.3 零消耗的前提消耗大头转移到了合规的非计费通道我先把话说清楚零消耗不是破解计费也不是偷用别人的额度。它是基于一个实际存在的规则完整模式下桌面端允许用户配置自定义模型端点包括本机运行的开源推理服务。只要请求不落在云端默认计费通道上就不会产生积分变动。所以整套配置的核心思路就一句话把高频、重复、本地能处理的任务统统导向本地端点把云端调用次数压到零。WorkBuddy CLI 在这个过程中负责自动判别与路由省去你手动切换的麻烦。需要说明的是本地推理服务对机器性能有一定要求。我的开发机是 64GB 内存加一块中端显卡跑 7B 和 13B 参数的量化模型完全没问题。如果你只有 16GB 内存且没有独显建议单跑 3B 到 7B 参数级别的模型虽然生成质量略逊但用来做代码补全、报错分析、格式整理绰绰有余。2. 配置前的三件小事环境检查、目录规划与配置备份整个配置过程看起来就是改两个配置文件、加一个路由规则但如果前置检查没做透后面排查起来会非常痛苦。我第一次配置的时候就是因为没注意版本差异照着旧格式改了配置文件结果桌面端直接不认白折腾了半小时。2.1 检查 Codex 桌面端版本与缓存目录不同桌面端版本对配置文件的支持差异很大。我见过旧版本只认全局配置新版本支持项目级配置覆盖还有个别小版本连自定义端点字段都藏得很深。先打开桌面端的设置页确认版本号。版本号至少要满足支持自定义端点这一项否则整套方案无从谈起。如果版本太老先升级到最新稳定版再做配置。然后是确认缓存目录的位置。Codex 桌面端的配置和缓存目录通常位于用户主目录下的隐藏目录里路径格式类似于~/.codex/。里面包含几个关键文件config.json全局配置记录端点地址、模型名称、鉴权信息。profiles/目录保存不同场景的配置预设比如代码生成预设、文档处理预设等。日志目录用于排查请求走向。确认路径之后用文本编辑器打开config.json先看一眼当前有多少字段了解现有配置有没有被其他工具改过。我遇到过有人同时装了别的辅助插件把配置文件结构改得乱七八糟导致后续怎么改都不生效最后老实重置才恢复。2.2 安装 WorkBuddy CLI 并确认 PATHWorkBuddy CLI 的安装方式在它的官方文档里有完整说明我这里只说关键点核心命令就三个。安装命令按文档执行一行安装脚本通常会自动写入系统 PATH。验证命令在终端运行workbuddy --version能看到版本号即表示安装成功。更新命令后续使用过程中如果有新版本直接运行workbuddy update。安装完成后手动输入一次workbuddy doctor它会检查当前机器上有没有可用的本地推理服务地址、端口是否通、Codex 桌面端的配置文件是否能在预期位置找到。这一步很重要提前暴露环境问题后面不用来回折腾。有一个容易踩的坑某些系统下终端是开了新窗口才刷新 PATH 的。安装完 WorkBuddy CLI 之后如果你在原来的终端窗口里直接输命令可能提示找不到。不是没装好而是 PATH 没刷新重开一个终端窗口就好。2.3 先备份再动手配置回滚是底线这一步很多人会跳过我强烈不建议省。改配置文件之前先把原有配置完整拷贝一份命名带日期后缀。我习惯这样做cp ~/.codex/config.json ~/.codex/config.json.bak-20261015 cp -r ~/.codex/profiles ~/.codex/profiles.bak-20261015这两行命令会把配置和预设备份到同目录下。万一后面配坏了直接把.bak文件改回原名就能恢复。同理WorkBuddy CLI 也有一个配置文件目录一般在~/.workbuddy/下。如果你之前已经用过这个工具同样先备份。改了之后一时半会儿找不到原配置那才叫心累。3. 核心配置请求走本地端点、缓存兜底、回退防断联零消耗能不能成立完全取决于这一节。我尽量把每一步写细方便照着做。整体配置分为四层桌面端端点指向、WorkBuddy 路由规则、本地推理服务接入、以及网络中断时的回退方案。3.1 修改 Codex 桌面端的端点指向配置先打开~/.codex/config.json找到模型配置区域。不同版本字段名略有差异但核心逻辑一致设置一个自定义 base URL然后让桌面端的所有请求都通过这个地址转发。一个典型的配置参考如下{ models: { primary: { provider: custom, base_url: http://127.0.0.1:8899/v1, api_key: workbuddy-local-key, model: local-default }, fallback: { provider: custom, base_url: http://127.0.0.1:8899/v1/fallback, api_key: workbuddy-local-key, model: local-light } } }base_url指向的 127.0.0.1:8899 就是 WorkBuddy CLI 监听的本地端口。不要直接填本地推理服务自己的地址中间必须经过 WorkBuddy CLI因为它需要在转发前做任务分类和缓存判断。有些版本的桌面端会校验 API Key 字段随便填一个占位符就行关键是 base_url 必须准确。填完之后保存文件重启桌面端让配置生效。3.2 WorkBuddy CLI 的转发规则与缓存开关WorkBuddy CLI 的配置文件在~/.workbuddy/workbuddy.yml它决定了请求怎么分流。我第一次配置时只设了一个统一转发地址结果所有请求全去了云端积分照样烧。后来参考文档调整了配置把任务类型分成了三类。下面是我的实际配置可以直接参考routes: - match: code|debug|error|test target: local reason: 代码类任务本地优先 - match: explain|design|architecture target: cloud reason: 复杂语义任务走云端 - match: * target: local reason: 默认路径优先本地 cache: enabled: true ttl: 3600 max_entries: 512 storage: ~/.workbuddy/cache.db local_inference: endpoint: http://127.0.0.1:8080 model: qwen2.5-coder:7b timeout: 30重点看match字段它按关键词把请求归类。包含 debug、error、test 这些词的任务基本属于可本地处理的机械性工作直接转到本地推理服务。而涉及 explain、design、architecture 的请求需要更强的语义理解就按规则走云端。缓存开关打开后一小时内重复请求直接命中缓存不触发任何模型调用。这个规则比例是我跑了两天调整出来的七成以上请求走本地剩下一小部分复杂任务走云端。如果连最后这部分也想省掉可以把 cloud 目标改成 local但代价是本地模型处理复杂架构问题时质量会明显下滑自己权衡。3.3 本地推理服务的接入参数WorkBuddy CLI 本身不包含推理能力它只是把请求转出去。所以你得有一个真正在跑的本地推理服务比如用常见的推理框架加载一个量化模型并暴露一个 OpenAI 兼容的接口。我用的模型是 qwen2.5-coder 的 7B 量化版这是我的开发机上能兼顾质量和速度的平衡点。启动参数大概是这样local-server --model qwen2.5-coder:7b \ --host 127.0.0.1 \ --port 8080 \ --context-size 8192 \ --quantization q4_k_m注意几个变量context-size决定了模型最多能读入多少上下文。桌面端有时会把整目录文件都拼进来如果限制太小会导致请求失败所以在内存允许范围内尽量调高。quantization是量化级别q4 级别体积小、速度快日常代码处理够用。追求更好生成质量可以换 q6但内存消耗会明显增大。服务启动后先手动跑一条测试请求确认接口正常再让 WorkBuddy CLI 接入它。如果之前没接触过本地推理建议先在终端里测试一条最简单的请求确认返回内容格式正确再接进 WorkBuddy。否则层层嵌套出问题都不知道是哪个环节。3.4 断联回退与手动切换任何依赖网络的软件都有断联风险本地推理服务也可能因为显存不足或模型加载异常而挂掉。WorkBuddy CLI 支持配置回退策略当本地请求连续失败几次就自动切换到备用通道。我在配置里加了一段回退策略fallback: target: cloud condition: 3 consecutive failures cooldown: 60含义是本地推理连续失败三次临时切到 cloud 通道过 60 秒冷却期后再尝试回本地。这样保证任务不会因为本地服务的一个小故障而彻底中断同时也不会长期停留在云端烧积分。这套配置还有一个日常使用技巧当你明知道接下来要做一个极大、极复杂的任务时可以在终端手动运行workbuddy route cloud强制所有请求走云端保证质量任务结束再运行workbuddy route local切回来。手动开关和自动规则配合比单一模式灵活得多。4. 实测验证从消耗明细看配置前后差异配置写完不等于生效尤其是这种多层路由结构每一层都可能悄悄出错。我之前就遇到过配置全部正确但桌面端内部缓存了旧端点导致所有请求还是走云端的情况。所以这一节的验证方法论很关键。4.1 用一条命令查看真实消耗先别急着看积分界面积分界面往往是延迟更新的。最准的是直接查桌面端的日志和 WorkBuddy CLI 的统计表。WorkBuddy CLI 内置了一条统计命令workbuddy stats --last 24h输出内容大致包括请求总数走本地推理的请求数走云端的请求数缓存命中次数平均响应时长如果配置正确你会发现“走本地推理的请求数”占绝大多数“走云端”的请求数是零或接近零。再看缓存命中次数命中了多少次就等于少跑了多少次模型调用这些本来都会变成积分消耗。4.2 零消耗状态的三个判定标准我判断自己是否真正达到了零消耗配置一般看三个标准同时满足第一用一条真实的任务链做验证。让桌面端读一个多文件项目然后执行“重构某个模块并补测试”这样的完整任务而不是只问一句“这段代码什么意思”。完整任务才能触发后台的多轮调用链路单次问答无法暴露问题。第二检查日志里有没有cloud标记。登录桌面端日志目录搜索请求记录标识。如果配置正确所有请求都是通过本地转发层出去的日志中不会出现指向默认云端通道的记录。第三跨时段对比 WorkBuddy 统计表中云端请求数量持续几小时看有没有增长。如果一直是零说明没有漏网请求。第三个标准尤其重要。有一次我把配置改对了但某个旧会话还挂在旧配置下导致依然有零星云端请求跑了半天才发现。所以验证时要新开一个会话不要沿用之前打开的旧对话框。4.3 常见配置错误超时、上下文溢出、鉴权失败配置过程中最常见的几个问题我按出现频率排一下请求超时。本地推理服务如果加载的模型太大或者机器负载太高响应速度会非常慢超过 WorkBuddy CLI 里的timeout阈值就判定失败然后不断触发回退到云端。解决办法是调低模型参数规模或增大 timeout 值。我把 timeout 从默认的 15 秒调到 30 秒后超时问题基本消失。上下文溢出。桌面端会一次性传入大段代码如果本地模型上下文窗口不够会直接报错。别只靠桌面端限制上下文从 WorkBuddy CLI 层面截断长文本更保险。配置一个最大上下文长度超出的部分让 WorkBuddy CLI 按相关性裁剪保住任务完美性又不至于让模型卡死。鉴权失败。部分版本的桌面端在连接自定义端点时会带一个预设的鉴权头。如果本地推理服务不识别会在日志里留下一段鉴权报错。解决办法很简单在 WorkBuddy CLI 配置里加一个自动剥离表头的开关把这些多余字段去掉再转发。5. 长期维护与团队复用的经验零消耗配置不是一劳永逸的。桌面端升级、WorkBuddy CLI 更新、本地模型换代都会影响整条链路的稳定性。最后这节写几个长期维护的关键点以及我把这套方案复制到团队其他机器时发现的问题。5.1 日常启动顺序与热更新技巧正确启动顺序不是玄学是有实际原因的。必须先启动本地推理服务再启动 WorkBuddy CLI最后启动 Codex 桌面端。因为桌面端启动时会主动做一次端点连通性检查如果检查时本地服务还没起来它可能回退到默认配置后续即使服务恢复了也不会自动切换。我在本地服务的启动脚本里加了一行等待逻辑# 等待本地推理服务就绪 curl --retry 10 --retry-delay 2 --retry-connrefused \ http://127.0.0.1:8080/health先用 curl 确认服务健康再启动后续组件避免手工点击造成的时序问题。热更新方面WorkBuddy CLI 配置了自动监听配置文件的模式改完 YAML 不用重启进程。但 Codex 桌面端对端点配置有自己的一套缓存改完必须完全退出再启动。不要只关窗口要在系统托盘或进程管理器里确认没有残留进程。5.2 多机器复制的注意事项我把这套配置复制到另外两台开发机的时候遇到了几个坑。第一个坑配置里用了绝对路径。我原本把缓存数据库放在了某个固定路径下复制配置到另一台机器后目录不存在导致缓存一直写失败。后来又没注意看日志过了半天才发现缓存一直没有生效。第二个坑端口被占。两台机器上跑着不同的本地服务恰好有一个占用了 8899 端口导致 WorkBuddy CLI 启动失败。改成动态端口选择后解决。第三个坑配置文件里的模型名不兼容。有些机器加载的模型版本不一样名称不完全匹配请求直接报错。建议把模型名统一或者让 WorkBuddy CLI 读取本地推理服务的模型列表根据实际可用模型自动填入。5.3 我踩过的两个坑和对应解法第一个坑是“改了配置不生效”。有一次我把 config.json 保存好也重启了桌面端但统计仍然显示大量云端请求。后来发现桌面端读取的是项目目录下的局部配置这个配置的优先级高于全局配置把我修改的内容覆盖掉了。检查了两轮才看到项目里藏着一个配置覆盖文件删掉之后一切恢复正常。第二个坑是“缓存导致旧结果复用”。缓存粒度设得太粗导致同一个目录结构下改了需求后桌面端复用了旧的分析结果生成的建议牛头不对马嘴。解决方法是把缓存 key 设为“目录结构 文件修改时间 任务关键词”三者的组合只要文件改动过缓存自动失效。这样既保证缓存命中率又不会出现过期数据。这两个坑在日志里都有迹可循关键在于养成先查统计和日志、再怀疑配置内容的习惯。排查多了就会发现大部分问题不是工具本身的锅而是配置文件的优先级、缓存粒度、端口冲突这些细节在作怪。最后再说一点个人体会整套配置里最有价值的不是省下了多少积分而是 WorkBuddy CLI 强制我把任务分层的思路建了起来。哪些工作其实根本不需要大模型、哪些请求可以缓存复用、哪些任务才值得走云端想清楚这些之后我的使用习惯也变高效了。如果你决定照这套方案试一次别急着几个小时内就下结论跑满两三天再看看统计表里的请求分布那才是真实效果。