Codex 的 token 消耗来自两端输入端每轮把 CLAUDE.md、技能文件、代码上下文喂给模型和输出端模型回复、代码生成、解释说明。多数人只关注输出端的废话但输入端的文件膨胀同样在悄悄烧钱——尤其是每轮把整个 PDF 文档、大型 Word 文件塞进上下文的习惯消耗可能超过代码生成本身。本文整理 GitHub 上星数最高的 5 个 token 省钱方案4 个 Skills 覆盖从压缩 AI 回复到控制代码生成量的不同路径1 个 Microsoft 出品的文档转换工具帮你在 PDF 进入 Codex 之前先把体积打薄给出安装方式、实际减少比例和适用场景帮你按用量结构找到最划算的组合。为什么 Codex 消耗这么多 tokenCodex 的 token 账单由三块构成输入 token通常占大头每轮携带的 CLAUDE.md / AGENTS.md 文件内容已加载的 Skills 文件代码上下文读取的文件内容历史对话消息直接投喂的 PDF / Word / PPT 文档往往几千 token 起步输出 token更贵V4-Flash 输出是输入的 2 倍单价模型的文字解释和前后套话生成的代码计划、状态报告、执行叙述工具调用 token每次 Read、Edit、Bash 调用都有开销读整个文件而不是目标行会把数千行无关代码塞进上下文下面 5 个方案针对不同消耗来源各有侧重。1. Ponytail — 最高 94% 代码行减少逻辑决策层GitHubDietrichGebert/ponytailStar 数~9.5 万Ponytail 的核心不是让 AI 少说话而是在 AI 决定写什么代码之前加一道决策梯1. 这个东西需要存在吗 → 不需要跳过YAGNI 2. 代码库里已有 → 复用不重写 3. 标准库能做 → 用标准库 4. 原生平台功能 → 用原生 5. 已装的依赖能搞定 → 用依赖 6. 一行能写完 → 一行 7. 以上都不行最小可用实现经典案例你说加个日期选择器普通 Codex 会装 flatpickr、写 wrapper 组件、加样式表开始讨论时区。Ponytail 介入后的输出!-- ponytail: browser has one --inputtypedate在对 FastAPI React 真实代码库的 12 项功能任务测试Haiku 4.5n4中指标vs 无技能基准代码行数-54%最高达 -94%token 消耗-22%成本-20%耗时-27%安全性100%保留所有错误处理和验证安装Claude Code/plugin marketplace add DietrichGebert/ponytail /plugin install ponytailponytail需分两条消息发送安装Codexcodex plugin marketplaceaddDietrichGebert/ponytail codex pluginaddponytailponytail适合场景前端开发、功能迭代、AI 倾向过度实现的场景安装第三方库替代一行原生代码。不适合场景算法密集型任务代码本来就没有更简单的原生替代。2. Caveman — 65% 输出 token 压缩换一种说话方式GitHubJuliusBrussee/cavemanStar 数~9.5 万Caveman 的思路完全不同让 AI 像穴居人一样说话——去掉所有铺垫和废话保留准确的技术信息。对比示例普通 Codex69 tokenCaveman Codex19 token“The reason your React component is re-rendering is likely because you’re creating a new object reference on each render cycle. When you pass an inline object as a prop, React’s shallow comparison sees it as a different object every time, which triggers a re-render. I’d recommend using useMemo to memoize the object.”“New object ref each render. Inline object prop new ref re-render. Wrap inuseMemo.”代码、命令、错误信息保持原样只压缩散文叙述。在 JetBrains 86 个任务的独立测评中Agent 模式下实测减少8.5%输出 token纯对话场景可达 65%——Agent 工作流大部分输出是代码和工具调用散文占比低。一键安装自动检测本机所有 Agent# macOS / Linux / WSLcurl-fsSLhttps://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh|bash# Windows PowerShellirm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1|iex支持三档语气默认标准穴居人、--standard、--ultra最简电报体。适合场景对话密集型工作流、需要大量解释的复杂重构任务。Agent 自动化流水线效果有限代码输出本就不啰嗦。3. token-diet — 多维度全覆盖平均降账单 31%GitHubKulaxyz/token-dietStar 数515token-diet 覆盖范围最广从回复措辞到工具调用策略全部管控回复先给结论无开场白“Sure! Here’s…”无结尾客套“Let me know…”报结果不叙述过程文档 / 计划 / 注释最少用词只注释为什么不注释做什么测试只写关键路径和边界情况每次会话 ≤10 个测试用例代码YAGNI不写死代码不过度抽象上下文先 grep 再读只读需要的行不读整个文件批量发独立读取调用不重读刚编辑的文件工具调用批量独立调用够信息立即行动针对性运行测试真实 Sonnet 5 运行数据场景输出减少账单减少输出密集建议、规划、解释-81%-54%代码修改 测试1673 文件项目-49%-22%读密集型理解任务-30%-17%平均-53%-31%支持三档on默认全部规则、lite仅沟通 文件、ultra电报体对话。安装curl-fsSLhttps://raw.githubusercontent.com/Kulaxyz/token-diet/main/install.sh|bash# ultra 档curl-fsSLhttps://raw.githubusercontent.com/Kulaxyz/token-diet/main/install.sh|bash-s----ultra4. claude-token-efficient — 最轻量一个 CLAUDE.md 文件搞定GitHubdrona23/claude-token-efficientStar 数5913最低安装成本的方案一个文件放进项目根目录自动生效。针对 Claude / Codex 默认的七种废话行为“Sure!”、“Great question!”、“Absolutely!” 等开场白“I hope this helps! Let me know if you need anything!” 结尾em 破折号、花引号等会破坏解析器的特殊字符回答前先复述你的问题主动提供你没要求的建议过度抽象的代码对错误说法点头称是“You’re absolutely right!”基准测试5 个提示测试基准优化后减少解释 async/await180 词65 词64%代码审查120 词30 词75%什么是 REST API110 词55 词50%幻觉纠正55 词20 词64%合计465 词170 词63%重要限制CLAUDE.md 文件本身每轮都作为输入 token 消耗低用量场景下输入成本可能高于节省的输出成本。高输出量的自动化流水线最划算偶发低频使用可能不合算。安装直接下载 CLAUDE.md 放进项目根目录或放进~/.claude/作为全局配置curl-fsSLhttps://raw.githubusercontent.com/drona23/claude-token-efficient/main/CLAUDE.md-o~/.claude/CLAUDE.md5. MarkItDown — PDF / Office 转 Markdown在文档进入 Codex 前先瘦身GitHubmicrosoft/markitdownStar 数~17.1 万前四个方案针对的是 Codex 的输出侧和回复方式MarkItDown 解决的是完全不同的问题文档在进入上下文之前就把体积压下来。一份 50 页 PDF 直接投给 CodexVision 模式可能消耗 5000-20000 token 来读图。MarkItDown 先把 PDF 转成干净的 Markdown 文本同样内容通常只需 1000-3000 token——进入模型之前就省掉了 70-80%。支持格式PDF、PowerPoint.pptx、Word.docx、Excel.xlsx/.xls、图片EXIF OCR、音频语音转文字、HTML、CSV / JSON / XML、ZIP、YouTube 字幕、EPUB……几乎涵盖企业日常文档全部类型。基础用法# 安装pipinstallmarkitdown[all]# 命令行转换markitdown 技术规格.pdf-o技术规格.md# 管道用法cat合同文件.pdf|markitdown合同文件.md在 Codex / Claude Code 工作流中使用典型场景需要让 AI 分析一份 PDF 需求文档、读一份 Excel 报表或参考一个 PPTX 演示文稿时先用 MarkItDown 转换再把 Markdown 文件交给 Codex# 转换后交给 Codex 分析markitdown 需求规格.pdf-o需求规格.md# 然后在 Codex 中Read 需求规格.mdPython API嵌入流水线frommarkitdownimportMarkItDown mdMarkItDown()resultmd.convert(技术文档.pdf)print(result.text_content)# 直接得到 Markdown 字符串如需 LLM 辅助图片描述针对含大量图表的 PDFfrommarkitdownimportMarkItDownfromopenaiimportOpenAI clientOpenAI(api_key你的 API Key,base_urlhttps://api.qnaigc.com/v1# 兼容 OpenAI 协议的接入端点)mdMarkItDown(llm_clientclient,llm_model你选用的视觉模型)resultmd.convert(含图表的报告.pdf)重要限制MarkItDown 定位是为 LLM 提取结构而非高保真排版还原——表格、列表、标题会保留复杂的多栏布局、页眉页脚、背景水印不保证完整还原。如果需要的是像素级排版复现这不是合适的工具如果需要的是让 AI 读懂内容Markdown 文本是更经济的选择。安全提示MarkItDown 以当前进程权限执行 I/O在多租户或服务端场景下需要自行校验输入路径避免目录穿越优先用convert_local()或convert_stream()代替convert()以缩小权限范围。五个方案怎么组合你的主要痛点推荐组合AI 生成了一堆用不上的代码Ponytail从决策层减少生成量AI 回复太啰嗦话太多Caveman或token-diet ultra什么都想省有稳定自动化流水线token-diet全覆盖31% 账单降幅零配置快速上手claude-token-efficient一个文件需要让 AI 分析 PDF / Word / PPTMarkItDown文档进入上下文前先转 Markdown同时有文档分析 AI 回复啰嗦两个问题MarkItDown Caveman组合注意叠加使用多个 Skills 同时加载会增加输入 token 成本不是越多越好。建议先单独测试每个方案 1 周确认在你的工作流里净节省为正再考虑组合。Ponytail Caveman 是实测叠加效果最好的 Skills 组合Ponytail 减少生成量Caveman 压缩叙述两者不冲突。MarkItDown 是独立的预处理工具可以和任何 Skill 叠加不占 Skills 加载 token。常见问题Q这些 Skills 对 Codex 接 DeepSeek V4-Flash 有效吗有效且效果更明显。DeepSeek V4-Flash 的输出定价2 元/百万 token已经很低但 Agent 模式下多轮调用的累计输出量才是大头——每轮减少 30-54% 输出乘以调用次数后节省金额显著。输入端的上下文裁剪token-diet 的 grep-before-read 策略在 Agent 模式下节省效果同样明显。QCLAUDE.md 文件越多越省钱吗不是。CLAUDE.md 文件本身每轮作为输入 token 消耗。文件过大超过 500 token时每轮增加的输入成本可能超过节省的输出成本。claude-token-efficient 的维护者明确测量过轻量使用场景下CLAUDE.md 的输入成本是净负。规则文件应尽量简短只写真正有效的指令。QPonytail 会不会让 AI 漏掉错误处理不会。Ponytail 的决策梯明确豁免了信任边界验证、数据丢失处理、安全、无障碍——这些不在 YAGNI 的裁剪范围内。benchmark 的安全性测试项 Ponytail 得分 100%与无技能基准相同而 “YAGNI 一行” 直接提示词版本安全得分是 95%有 5% 漏掉了安全检查。Qcaveman 模式下 AI 还能写正常的代码注释吗能。Caveman 只压缩 AI 的对话输出散文解释代码本身、命令、错误信息、注释的风格不受影响——除非你明确要求 AI 用穴居人风格写注释通常没必要。QMarkItDown 转换的 Markdown 质量怎么样适合让 AI 读懂内容的场景不适合高保真还原排版。正文文字、表格、列表、标题层级保留良好复杂多栏布局、内嵌图表的数值如 Excel 图表的数字、页眉页脚装饰文字可能丢失或顺序错乱。对于以文字为主的需求文档、合同、报告转换质量通常足够数据密集型 Excel 表格建议用markitdown[xlsx]单独安装 Excel 依赖直接把表格数据转成 Markdown 表格效果比走 PDF 截图更准确。小结五个方案的定位各有不同Ponytail 在生成决策层减少 tokenCaveman 和 token-diet 在输出压缩层减少 tokenclaude-token-efficient 以最低配置成本清理输出废话MarkItDown 在文档输入层解决 PDF / Office 文件进入上下文时的体积问题——这是其他四个工具都没有覆盖的场景。实际效果取决于工作流对话密集型受益最大Caveman 的 65% 散文压缩代码生成密集型用 Ponytail 效果显著需要频繁分析文档的团队用 MarkItDown 在入口处省钱。选对场景月度 token 账单减少 20%-50% 是可预期的。数据来源DietrichGebert/ponytail benchmarkgithub.com/DietrichGebert/ponytail/benchmarks/results2026 年 6 月、JuliusBrussee/caveman JetBrains 86 任务独立测评2026 年、Kulaxyz/token-diet bench/RESULTS.mdSonnet 52026 年、drona23/claude-token-efficient benchmark/SUMMARY.md2026 年、microsoft/markitdown READMEgithub.com/microsoft/markitdown2026 年 8 月。延伸阅读Ponytail 完整 benchmark 报告github.com/DietrichGebert/ponytail/blob/main/benchmarks/results/2026-06-18-agentic.mdCaveman 安装与多 Agent 配置指南github.com/JuliusBrussee/caveman/blob/main/INSTALL.mdtoken-diet 详细测试方法github.com/Kulaxyz/token-diet/blob/main/bench/RESULTS.mdmicrosoft/markitdownPDF / Office 转 Markdowngithub.com/microsoft/markitdownCodex 接入 DeepSeek V4-Flash 省钱组合指南api-docs.deepseek.com/zh-cn/quick_start/agent_integrations/codex/