如果你已经开始用 Codex 写代码一定对每个月账单里的 Token 用量感到过心慌。尤其是那种喜欢把一个仓库反复折腾的人常常还没写出几行逻辑开销先跑起来了。究其原因Codex 这类编码代理和普通对话不一样它要把系统提示、工具定义、文件内容、多轮历史一股脑塞进上下文Token 消耗肉眼可见。今天我要分享的是两个我实测下来能明显压住 Token 开销的开源项目GPTCache 和 LLMLingua。它们一个做语义缓存一个做提示词压缩配合 Codex 的转发配置把手头的 Token 预算用在真正该用的地方。这篇文章适合所有用 Codex CLI 做日常开发、又不想被账单打懵的人。1. Codex 的 Token 开销到底漏在哪先算清这笔账1.1 一次最简单的请求你实际付了多少钱先得把 Codex 的工作方式说清楚。它不是 IDE 里那种单次补全而是会开启一个完整的执行循环。每一次任务Codex 都要携带一套很长的系统提示里面有工具定义、当前目录结构、代码风格约束。当你把某个文件加入上下文这个文件的全文会被切块塞进请求。如果开了全文件树索引整个项目的路径列表也会变成 Token。再加上多轮“思考—执行—反馈”循环每一轮都会把前面的对话历史原样带回。所以一次看似简单的“改一下这个函数”背后可能是几万甚至几十万个 Token。我跑一个中等规模的 TypeScript 项目只让 Codex 帮忙加一个异常处理最终消耗近 3 万 Token。真正和本次改动有关的代码可能只有两三处但文件全文和历史消息把数字撑了起来。Token 少的时候没感觉一旦频繁让 Codex 扫描、重构、解释你就会发现开销大头根本不是“思考”而是“重复搬运”。这里要给刚接触的朋友补一个概念Token 是模型处理文本的最小单位可以粗略理解成一个单词片段或代码符号。Codex 所在的上下文窗口是有限的比如 128k 上下文意味着你一次性最多塞进这么多 Token。省 Token 不只是省钱更是给真正需要模型思考的内容腾地方。一个请求如果被无用文件塞满模型甚至连关键代码都“看不过来”。1.2 三个最常见的“隐形吞 Token”习惯抛开模型计费从使用习惯来看有三种情况最容易让 Token 失控随手把整个文件丢进上下文而不是只丢相关代码块。文件越大浪费越明显。尤其是有几百行模板代码、注释、日志的文件真正起作用的核心逻辑往往只占一小部分。让 Codex 反复看同一批文件。多次对话中你对文件改了多处但每次都会把旧版的上下文继续保留造成大量重复 Token。失败的尝试会成倍放大开销。一次调用如果返回了不预期的结果Codex 会带着前面的历史重新尝试Token 消耗会像滚雪球一样涨。所以“省 Token”本质上是在降低无效上下文的占比。这也是我后来认真尝试 GPTCache 和 LLMLingua 的原因。这两个项目面对的问题正好不同缓存负责减少“重复调用”压缩负责减少“单次调用体积”。先把这两条逻辑理清后面就不会混淆。2. 项目一GPTCache 语义缓存让重复请求直接读旧答案2.1 GPTCache 到底解决了什么问题GPTCache 是一个开源的语义缓存库核心思路很简单把请求和响应缓存起来当新的请求和历史上某个请求语义相近时直接返回缓存结果不再请求大模型。它不像 Redis 那种精确 key-value 匹配而是用 embedding 向量表示请求语义再用相似度判断是不是同一类问题。对于代码场景“帮我给这个函数加参数校验”和“这个函数需要参数校验你帮我改一下”虽然文字不同但如果向量距离足够近会被当成同一个问题处理。这个思路用在 Codex 上有一个很大的前提Codex 的请求包含太多上下文比如文件内容、历史消息导致两个请求的完整文本几乎不可能相同即使实际要解决的事情一样。所以不能直接拿整段请求做 embedding那样缓存命中率会低到约等于没有。需要从请求中抽取关键意图比如用户指令、目标文件名、函数签名组合成一个“指令指纹”再去缓存。下面第 4 节我会给出具体做法。2.2 Codex 场景里哪些结果值得缓存不是所有请求都适合缓存。我试下来的经验是下面三类收益最明显代码解释与重构。“解释一下这个类的职责”“把这个函数改成 async”这类请求目标明确命中缓存后直接给结果不会影响后续任务。重复出现的代码规范修正。比如 Codex 反复帮你修正同一类 lint 错误第一次完整生成后后续遇到相似错误可以直接复用。批量小任务。如果你让 Codex 给十几个文件分别加注释这种请求指令接近动作类似缓存命中率非常高。相反不适合缓存的是依赖实时状态的任务比如“运行测试并修复失败中的测试”——测试结果每次可能不同缓存会给过时答案反而误导 Codex。还有“读取某个数据库表结构再生成代码”表结构变了缓存就该失效。为了直观我列一下自己设置的缓存策略任务类型是否缓存原因解释函数、给代码加注释是结果可复用且不影响后续状态修改函数逻辑、重构代码谨慎需要结合当前文件状态判断运行测试并修复报错否测试输出每次可能不同生成项目结构说明是仓库结构短时间不变根据最新报错信息定位问题否报错上下文敏感2.3 GPTCache 的快速上手要点GPTCache 官方支持 Python 和 REST API我通常在中间转发层里直接调用。安装和初始化很轻量官方示例大致长这样from gptcache import cache from gptcache.processor.pre import last_content_random cache.init( pre_embedding_funclast_content_random, embedding_funcNone, # 使用内置 embedding similarity_threshold0.82 ) value cache.get(request_key) if value: return value如果只是照这个写在 Codex 场景下命中率会很低。原因刚才说过整个请求体太大而且每次文件内容都不同。我建议重写pre_embedding_func把用户最后的指令和涉及的文件名拼接成短字符串再交给向量模型。示例def extract_cache_key(payload): messages payload.get(messages, []) or payload.get(input, []) # 取最后一条非空用户消息 user_text for msg in reversed(messages): if msg.get(role) user: user_text msg.get(content, )[:200] break file_names payload.get(file_context, []) return f{user_text}::{,.join(file_names)}这样缓存键的核心是“用户想干什么”而不是“用户这次带了什么文件”。实测命中率能从个位数提到三成以上。3. 项目二LLMLingua 提示压缩把塞进上下文的废话挤干3.1 LLMLingua 的压缩原理与优势LLMLingua 是微软开源的提示压缩项目。它的思路是让一个小模型先阅读原始提示把不影响语义的停用词、重复信息、不相关句子抽出去只保留对答案有用的核心内容。它不是简单截断而是基于困惑度perplexity对每个 token 做保留判断。简单说模型会評估删掉某个 token 后整体语义可能发生的波动波动小就删波动大就留。因此它能维持较高的信息密度。和“手动精简提示”相比LLMLingua 的优势在于自动化。你不可能每次请求都手动删注释、删历史但压缩器可以实时处理。在 Codex 场景里最值得压缩的是三类内容文件全文里的长注释和样板代码多轮对话里前几轮的冗长输出系统提示中重复出现的工具描述。这些内容直接塞给大模型每个字都花钱但对最终结果贡献很小。3.2 哪些内容可以压缩哪些碰都不要碰必须承认压缩有风险。如果压缩掉一段关键代码Codex 可能误判。我的建议是分级处理可放心压缩文件头部的版权注释、开发依赖说明、超长 README 片段、重复出现的配置样板。谨慎压缩多轮历史对话。可以把前几轮结果压缩成摘要但最新一轮的用户指令和最近的文件内容不要动。不要压缩函数签名、类型定义、报错信息、测试用例。这些必须原样保留任何微小的修改都会改变语义。压缩率与质量之间需要平衡。我用 LLMLingua 的默认配置压缩文件说明类内容压缩率大概在 30% 到 50%代码逻辑基本不受影响。但如果把阈值调得太激进出现过把!这种符号丢掉的情况那次 Codex 直接改了错误分支教训很深刻。后来我干脆对所有疑似代码块的段落跳过压缩只压缩注释和纯文本段落。3.3 接入方式与调用示例LLMLingua 提供了 Python 包调用不复杂from llmlingua import LLMLingua2 compressor LLMLingua2(your_local_model, device_mapcpu) compressed compressor.compress( original_prompt, instruction请保留所有代码逻辑和术语只压缩冗余描述和注释, target_token6000, )注意这个压缩过程本身也会消耗本地 CPU 和内存。如果你的开发机配置一般不建议对每个请求都跑压缩。我自己的经验是只有当原始 prompt 超过 8k Token或者文件内容超过 4k 字符时才调用压缩器。小请求直接透传省下来的压缩时间足够让 Codex 更快反应。4. 给 Codex 加一道“省Token网关”把两个项目接在一起4.1 为什么需要一个中间转发层Codex CLI 本身没有提供插件机制但几乎所有模型调用都支持自定义 API Base URL。你可以在本地起一个 HTTP 服务让 Codex 的所有请求先经过这个服务这个服务就是你的“省Token网关”。它既做语义缓存又做提示压缩是承接两个开源项目最自然的位置。流程可以理解为Codex 发出请求 - 网关提取用户指令并做缓存判断 - 如果命中直接返回缓存响应如果未命中先对超长请求做 LLMLingua 压缩 - 转发给上游模型服务 - 拿到响应后写入缓存并返回给 Codex。这样对 Codex 来说就是一次普通调用但实际消耗的 Token 可能差很多。需要注意的是网关本身需要配置正确的转发地址和鉴权信息。Codex 的响应格式必须原样透传不能擅自修改状态码或字段结构。压缩请求体时要尤其小心不要破坏max_output_tokens、tool_choice这类控制字段。4.2 一个可跑的网关实现Python FastAPI下面给一个最小可用的示例。它把缓存判断和压缩转发放在同一个服务里重点是让你理解数据流不是让你直接抄完就跑。import os from fastapi import FastAPI, Request, Response from openai import AsyncOpenAI from gptcache import cache from llmlingua import LLMLingua2 app FastAPI() # 上游模型服务地址与密钥可以是官方或自建 client AsyncOpenAI( api_keyos.getenv(UPSTREAM_API_KEY), base_urlos.getenv(UPSTREAM_BASE_URL, https://api.openai.com/v1), ) compressor LLMLingua2(your_local_model, device_mapcpu) # 初始化缓存 cache.init(similarity_threshold0.82) def extract_cache_key(payload: dict) - str: # 取最后一条用户消息和目标文件构造低维语义键 raw payload.get(input) or payload.get(messages) if isinstance(raw, str): user_text raw[:200] elif isinstance(raw, list): user_text for msg in reversed(raw): if isinstance(msg, dict) and msg.get(role) user: user_text str(msg.get(content, ))[:200] break files payload.get(file_context, []) return fcodex::{user_text}::{,.join(files)} def should_compress(payload: dict) - bool: raw_len len(str(payload.get(input, ))) return raw_len 8000 app.post(/v1/responses) app.post(/v1/chat/completions) async def handle_llm_request(request: Request): payload await request.json() cache_key extract_cache_key(payload) cached cache.get(cache_key) if cached: return Response(contentcached, media_typeapplication/json) # 压缩超长请求但要保留关键字段 if should_compress(payload): original_input payload.pop(input, None) if original_input: payload[input] compressor.compress( original_input, instruction保留代码和术语压缩注释、说明与历史摘要, target_token4000, ) # 转发给上游 try: if /responses in request.url.path: upstream_resp await client.responses.create(**payload) else: upstream_resp await client.chat.completions.create(**payload) except Exception as e: return Response(status_code502, contentfupstream error: {e}) resp_data upstream_resp.model_dump_json() cache.set(cache_key, resp_data) return Response(contentresp_data, media_typeapplication/json)这段代码至少有几个地方你要按自己的环境调整。第一input字段只适用于 Responses API旧版 Chat Completions 用的是messages不能直接混用。第二compressor.compress返回的是字符串还是对象不同版本不一样记得先看下文档。第三缓存存储默认在本地如果多台电脑共用需要换成 Redis 或数据库版本。4.3 配置项逐条说最容易出错的几个位置如果你自己搭网关下面这几个点最影响成败路由匹配Codex 主要使用 Responses API但某些版本还会访问/v1/chat/completions。两个路由都要转发避免漏掉请求导致 Codex 报错。鉴权头网关可以用固定 token 校验 Codex 发来的请求但在转发给上游时要替换成你自己账号的真实密钥。不要把内部密钥也塞给 Codex。上下文窗口上限压缩时不要只看 Token 总量还要看模型最大上下文。如果原请求已经接近上限压缩后应保留足够余量给输出否则模型会截断。超时与流式响应Codex 经常使用流式输出。网关如果没有处理streamtrue会让 Codex 一直等待。最简单的方式是先看请求体里stream是否为真是的话直接用流式转发不要缓存。4.4 压缩和缓存的优先级我建议“先缓存再压缩”先做缓存判断如果命中就直接返回未命中再做压缩。原因很简单压缩也有计算成本不应该每个请求都跑。缓存写入应该在拿到上游响应后执行如果上游调用失败不要缓存错误结果。这样整体逻辑清晰也方便单独排查是缓存命中问题还是压缩问题。另外缓存结果要带上版本信息。我在缓存键里拼接了文件路径和修改时间每次文件变更后旧缓存自动失效。虽然这会损失一些命中率但能避免 Codex 拿旧答案处理新代码。5. 实测收益和踩坑记录5.1 一次真实任务的数据对比我用一个大约 30 个文件的开源仓库做了实测。任务很普通给几个 API 函数补充 JSDoc 注释。这是典型的“重复劳动”型任务很适合测缓存效果。第一轮不做任何优化Codex 直接处理消耗约 4.6 万 Token其中大部分来自每个文件的全文和累计历史。第二轮启用 GPTCache 和 LLMLingua 后五个文件的注释任务重复请求命中缓存整体 Token 消耗降到 2.1 万节省超过 50%。同时消耗的时间也少了一些因为缓存直接返回结果没有等待模型流式输出。需要说明的是这不是严谨的基准测试换任务类型和代码规模数据肯定不同。但它至少能看出在“批量重复任务”和“长文件处理”的组合场景里收益非常显著。下面是两次运行的粗略对比指标未优化接入网关后下降幅度总 Token 消耗约 4.6 万约 2.1 万54%平均每次请求体积约 3.1k Token约 1.8k Token42%重复请求缓存命中次数06-总耗时约 8 分钟约 5 分钟37%5.2 我踩过的三个坑每个都值得说坑一缓存命中错把“相似”当“相同”。有次 Codex 请求“把 POST 接口的错误处理梳理一下”和缓存里另一个 GET 接口的请求向量距离很近直接返回了错误内容。排查时我发现是缓存键太粗只提取了用户消息没有带上文件名和函数签名。后来我把这两个信息拼进缓存键类似误命中明显减少。坑二压缩把代码操作符删掉了。前文提过LLMLingua 激进压缩时可能丢掉!这类符号。那次 Codex 因为没有看到!把判断逻辑写反了。解决方法是把压缩目标限定为注释、说明、历史摘要对代码块强制跳过。如果你的项目代码里有大量非标准符号这个坑特别容易踩。坑三网关转发时丢字段。早期我的网关只转发了messages却漏掉了tool_choice和parallel_tool_calls导致 Codex 明明声明了工具调用上游却没有收到一直报解析错误。后来我改成完整解析原始 payload只修改需要改的字段不再手动重建请求结构。这是所有中间层最容易犯的错误总想着精简请求结果把控制信息也精简掉了。5.3 什么情况下不值得折腾这套方案如果你的项目很小每次会话只有几百行代码其实没必要上这套组合。语义缓存和提示压缩本身会引入额外延迟与复杂度小场景下反而可能是负优化。只有当 Codex 频繁处理大文件、重复任务、长对话时这套方案才真正有意义。另外如果你的上游模型已经自带缓存机制比如动态 prompt caching那么 GPTCache 的边际收益会变小但仍然可以帮助你减少重复构造上下文的开销。6. 进阶优化与最后的几条提醒6.1 把 Token 开销变成可观测的指标网关是可以记录一切的地方。我给每个请求都加了一段日志逻辑从响应里提取usage字段把prompt_tokens、completion_tokens、total_tokens和缓存命中状态落成结构化日志。一周后就能看出哪些任务类型消耗最大进而调整缓存策略和压缩阈值。你还可以用这个日志做“预热脚本”把项目里常见的代码样式修改任务提前跑一遍结果写进缓存开发者真正开始用 Codex 时很多重复请求第一次就能命中。6.2 缓存淘汰机制比缓存本身更重要代码会不断演变今天正确的答案明天可能过时。如果不清理缓存Codex 可能会反复引用旧结果。我在缓存键里带上文件路径的最后修改时间并在每天构建时清空当天的语义缓存。简单粗暴但有效。虽然会损失一些命中率但比给出过期代码建议造成的返工成本低得多。6.3 我的最后体会这两个项目我都不是第一次用。GPTCache 帮我把很多“同一个问题反复问”的开销砍掉了LLMLingua 则让我敢把整份文件塞进上下文不再担心 Token 爆炸。两者搭配后Codex 的实用体验确实上升了一个台阶。如果你想试不用一开始就把全部机制部署到位可以先只加 LLMLingua 的压缩观察几轮再引入缓存。一步一步来踩坑成本会低很多。另外如果你用的是兼容 OpenAI 接口的其他模型服务这套网关同样适用只是字段细节要按对应 API 调整。省 Token 从来不是目的让 Codex 把有限上下文用在真正值得思考的地方才是我们折腾这些工具的初衷。