Codex 的 token 消耗来自两端：输入端（每轮把 CLAUDE.md、技能文件、代码上下文喂给模型）和输出端（模型回复、代码生成、解释说明）。多数人只关注输出端的"废话"，但输入端的文件膨胀同样在悄悄烧钱——尤其是每轮把整个 PDF 文档、大型 Word 文件塞进上下文的习惯，消耗可能超过代码生成本身。本文整理 GitHub 上星数最高的 5 个 token 省钱方案：4 个 Skills 覆盖从"压缩 AI 回复"到"控制代码生成量"的不同路径，1 个 Microsoft 出品的文档转换工具帮你在 PDF 进入 Codex 之前先把体积打薄，给出安装方式、实际减少比例和适用场景，帮你按用量结构找到最划算的组合。
为什么 Codex 消耗这么多 token
Codex 的 token 账单由三块构成：
输入 token（通常占大头）
- 每轮携带的 CLAUDE.md / AGENTS.md 文件内容
- 已加载的 Skills 文件
- 代码上下文（读取的文件内容）
- 历史对话消息
- 直接投喂的 PDF / Word / PPT 文档（往往几千 token 起步）
输出 token（更贵，V4-Flash 输出是输入的 2 倍单价）
- 模型的文字解释和前后套话
- 生成的代码
- 计划、状态报告、执行叙述
工具调用 token
- 每次 Read、Edit、Bash 调用都有开销
- 读整个文件而不是目标行，会把数千行无关代码塞进上下文
下面 5 个方案针对不同消耗来源各有侧重。
1. Ponytail — 最高 94% 代码行减少，逻辑决策层
GitHub：DietrichGebert/ponytail｜Star 数：~9.5 万
Ponytail 的核心不是"让 AI 少说话"，而是在 AI 决定写什么代码之前加一道决策梯：
1. 这个东西需要存在吗？ → 不需要：跳过（YAGNI）
2. 代码库里已有？ → 复用，不重写
3. 标准库能做？ → 用标准库
4. 原生平台功能？ → 用原生
5. 已装的依赖能搞定？ → 用依赖
6. 一行能写完？ → 一行
7. 以上都不行：最小可用实现
经典案例：你说"加个日期选择器"，普通 Codex 会装 flatpickr、写 wrapper 组件、加样式表，开始讨论时区。Ponytail 介入后的输出：
<!-- ponytail: browser has one -->
<input type="date">
在对 FastAPI + React 真实代码库的 12 项功能任务测试（Haiku 4.5，n=4）中：
| 指标 | vs 无技能基准 |
|---|---|
| 代码行数 | -54%（最高达 -94%） |
| token 消耗 | -22% |
| 成本 | -20% |
| 耗时 | -27% |
| 安全性 | 100%（保留所有错误处理和验证） |
安装（Claude Code）：
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
（需分两条消息发送）
安装（Codex）：
codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail
适合场景：前端开发、功能迭代、AI 倾向过度实现的场景（安装第三方库替代一行原生代码）。不适合场景：算法密集型任务，代码本来就没有"更简单的原生替代"。
2. Caveman — 65% 输出 token 压缩，换一种说话方式
GitHub：JuliusBrussee/caveman｜Star 数：~9.5 万
Caveman 的思路完全不同：让 AI 像穴居人一样说话——去掉所有铺垫和废话，保留准确的技术信息。
对比示例：
| 普通 Codex（69 token） | Caveman Codex（19 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 in useMemo." |
代码、命令、错误信息保持原样，只压缩散文叙述。
在 JetBrains 86 个任务的独立测评中，Agent 模式下实测减少 8.5% 输出 token（纯对话场景可达 65%——Agent 工作流大部分输出是代码和工具调用，散文占比低）。
一键安装（自动检测本机所有 Agent）：
# macOS / Linux / WSL
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash
# Windows PowerShell
irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex
支持三档语气：默认标准穴居人、--standard、--ultra（最简电报体）。
适合场景：对话密集型工作流、需要大量解释的复杂重构任务。Agent 自动化流水线效果有限（代码输出本就不啰嗦）。
3. token-diet — 多维度全覆盖，平均降账单 31%
GitHub：Kulaxyz/token-diet｜Star 数：515
token-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 -fsSL https://raw.githubusercontent.com/Kulaxyz/token-diet/main/install.sh | bash
# ultra 档：
curl -fsSL https://raw.githubusercontent.com/Kulaxyz/token-diet/main/install.sh | bash -s -- --ultra
4. claude-token-efficient — 最轻量，一个 CLAUDE.md 文件搞定
GitHub：drona23/claude-token-efficient｜Star 数：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/await | 180 词 | 65 词 | 64% |
| 代码审查 | 120 词 | 30 词 | 75% |
| 什么是 REST API | 110 词 | 55 词 | 50% |
| 幻觉纠正 | 55 词 | 20 词 | 64% |
| 合计 | 465 词 | 170 词 | 63% |
重要限制：CLAUDE.md 文件本身每轮都作为输入 token 消耗，低用量场景下输入成本可能高于节省的输出成本。高输出量的自动化流水线最划算，偶发低频使用可能不合算。
安装：
直接下载 CLAUDE.md 放进项目根目录，或放进 ~/.claude/ 作为全局配置：
curl -fsSL https://raw.githubusercontent.com/drona23/claude-token-efficient/main/CLAUDE.md -o ~/.claude/CLAUDE.md
5. MarkItDown — PDF / Office 转 Markdown，在文档进入 Codex 前先瘦身
GitHub：microsoft/markitdown｜Star 数：~17.1 万
前四个方案针对的是 Codex 的"输出侧"和"回复方式"，MarkItDown 解决的是完全不同的问题：文档在进入上下文之前就把体积压下来。
一份 50 页 PDF 直接投给 Codex，Vision 模式可能消耗 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……几乎涵盖企业日常文档全部类型。
基础用法
# 安装
pip install 'markitdown[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 需求规格.md
Python API（嵌入流水线）
from markitdown import MarkItDown
md = MarkItDown()
result = md.convert("技术文档.pdf")
print(result.text_content) # 直接得到 Markdown 字符串
如需 LLM 辅助图片描述（针对含大量图表的 PDF）：
from markitdown import MarkItDown
from openai import OpenAI
client = OpenAI(
api_key="你的 API Key",
base_url="https://api.qnaigc.com/v1" # 兼容 OpenAI 协议的接入端点
)
md = MarkItDown(llm_client=client, llm_model="你选用的视觉模型")
result = md.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 / PPT | MarkItDown（文档进入上下文前先转 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 模式下节省效果同样明显。
Q：CLAUDE.md 文件越多越省钱吗？
不是。CLAUDE.md 文件本身每轮作为输入 token 消耗。文件过大（超过 500 token）时，每轮增加的输入成本可能超过节省的输出成本。claude-token-efficient 的维护者明确测量过：轻量使用场景下，CLAUDE.md 的输入成本是净负。规则文件应尽量简短，只写真正有效的指令。
Q：Ponytail 会不会让 AI 漏掉错误处理？
不会。Ponytail 的决策梯明确豁免了"信任边界验证、数据丢失处理、安全、无障碍"——这些不在 YAGNI 的裁剪范围内。benchmark 的安全性测试项 Ponytail 得分 100%，与无技能基准相同，而 "YAGNI + 一行" 直接提示词版本安全得分是 95%（有 5% 漏掉了安全检查）。
Q：caveman 模式下 AI 还能写正常的代码注释吗？
能。Caveman 只压缩 AI 的对话输出（散文解释），代码本身、命令、错误信息、注释的风格不受影响——除非你明确要求 AI 用穴居人风格写注释（通常没必要）。
Q：MarkItDown 转换的 Markdown 质量怎么样？
适合"让 AI 读懂内容"的场景，不适合"高保真还原排版"。正文文字、表格、列表、标题层级保留良好；复杂多栏布局、内嵌图表的数值（如 Excel 图表的数字）、页眉页脚装饰文字可能丢失或顺序错乱。对于以文字为主的需求文档、合同、报告，转换质量通常足够；数据密集型 Excel 表格建议用 markitdown[xlsx] 单独安装 Excel 依赖，直接把表格数据转成 Markdown 表格，效果比走 PDF 截图更准确。
小结
五个方案的定位各有不同：Ponytail 在生成决策层减少 token，Caveman 和 token-diet 在输出压缩层减少 token，claude-token-efficient 以最低配置成本清理输出废话，MarkItDown 在文档输入层解决 PDF / Office 文件进入上下文时的体积问题——这是其他四个工具都没有覆盖的场景。
实际效果取决于工作流：对话密集型受益最大（Caveman 的 65% 散文压缩），代码生成密集型用 Ponytail 效果显著，需要频繁分析文档的团队用 MarkItDown 在入口处省钱。选对场景，月度 token 账单减少 20%-50% 是可预期的。
数据来源：DietrichGebert/ponytail benchmark（github.com/DietrichGebert/ponytail/benchmarks/results，2026 年 6 月）、JuliusBrussee/caveman JetBrains 86 任务独立测评（2026 年）、Kulaxyz/token-diet bench/RESULTS.md（Sonnet 5，2026 年）、drona23/claude-token-efficient benchmark/SUMMARY.md（2026 年）、microsoft/markitdown README（github.com/microsoft/markitdown，2026 年 8 月）。
延伸阅读
- Ponytail 完整 benchmark 报告：github.com/DietrichGebert/ponytail/blob/main/benchmarks/results/2026-06-18-agentic.md
- Caveman 安装与多 Agent 配置指南：github.com/JuliusBrussee/caveman/blob/main/INSTALL.md
- token-diet 详细测试方法：github.com/Kulaxyz/token-diet/blob/main/bench/RESULTS.md
- microsoft/markitdown（PDF / Office 转 Markdown）：github.com/microsoft/markitdown
- Codex 接入指南：api/fenno/ai
