Marico's space
你身边有没有这种人：同一个 Claude Code，他用得风生水起，你用两周就被限流五天？
说实话，这事挺让人挠头的。同样的工具，体验能差出十万八千里。不是天赋问题，是方法问题。那些二十分钟烧光 token 的人，往往连问题出在哪都不知道——没人教这些。
所以今天聊点干的：怎么正确使用 AI 编程工具，省 token 的同时还能拿到更好的结果。是的，你没看错，方向一致，不是 trade-off。
每条消息发出去，模型都要重新读取整个对话历史。
第 1 条消息成本 1x。第 10 条消息成本 10x。第 30 条消息成本是第 1 条的 31 倍。大多数人烧 token 烧得不知不觉，就是这个原因。
这不是 Claude 特有的，所有 LLM 都这样。模型在消息之间没有记忆，每次对话从头读一遍。你的 system prompt、每条历史消息、每次回复、每次工具调用结果——全部，每次都读。
一旦理解这个，其他一切都顺理成章了。
看不见的东西没法优化。在调任何设置之前，先弄清楚 token 到底花在哪。
对于 Claude Code，可以用 ccusage 看细分。对于 Codex，Peter Steinberger 的 CodexBar 放菜单栏，显示当前会话使用量。
我自己用的是 agents-in-a-box TUI，一个仪表盘追踪 Claude Code、Codex、Gemini CLI 和 Copilot 的使用情况。
关键点：不追踪就是在猜，猜来猜去就是一小时后被限流还一头雾水。
15-20 条消息后就开始新会话。到第 30 条消息时，你付出的成本是第 1 条的 31 倍。但不只是钱的问题——上下文窗口消耗超过 60% 后，模型输出质量就开始下降。它被大量陈旧对话淹没，对当前任务的注意力涣散。
用 /handover 把上下文带到下一个会话。更省钱，输出还更锐利。
答错了？别发「不对，我意思是 X」。那会叠加消息长度。在原消息上点 Edit。编辑会替换该点之后的对话内容，而纠正会让对话变得更长，成本更高。
「重构 auth、加限流器、更新两个测试」——这是一个上下文加载。三次独立 prompt 做三件事？是三次上下文加载。
把它当简报（brief），不是闲聊。整理好要的东西，一次性发出去。所有现代 agent 工具现在都有成熟的有状态任务管理，agent 会在单次 turn 内追踪所有任务的进度，不需要一个一个 micromanage。
「我用 TypeScript、Tailwind、Vercel」——在 Memory 里设一次，不用每次会话都打一遍。文件放 Project 里：缓存一次，重复使用。放聊天里：每条消息重新处理。
网页搜索、连接器、扩展思考……这些都会把工具定义加载到上下文里，不管你用不用。把不用的关掉。
对于 CLI agent：尽量远离 MCP，它是个上下文税。如果必须用，用 mcporter 从命令行调用，不把 schema 加载到窗口里。
随手问答用 Haiku，日常开发用 Sonnet，架构设计用 Opus 思考配 Sonnet 执行，真正复杂的问题才用 Opus。别用最贵的模型来「加个 console.log」。
Claude Code 的限流在一个滚动的 5 小时窗口内重置。连着两小时猛攻把配额吃光，你就只能盯着冷却计时器发呆。
诀窍：搞清楚窗口什么时候重置。在 Claude Code 里运行 /usage 看看自己处于什么位置。然后设个提醒，在窗口开启时立刻启动下一个会话。规划好，一天能用满三个完整窗口。
如果可以的话，避开太平洋时间上午 5-11 点。那个时段基于负载的限流最严重，因为美国刚醒来，所有人一起发 prompt。
这是大多数人直接跳过的部分。模型不是读了你的 prompt 就直接回应，它先思考。内部推理过程你看不到，但你绝对要付钱。而且思考量的大小会因配置方式不同而大幅波动。
在 Claude Code 里控制这个的官方方式是 /effort：
/effort low：模型几乎不思考就行动。适合简单任务。
/effort max：每个 prompt 都深入思考，在做任何事之前进行大量推理。适合复杂问题。
默认值是 auto，意思是 Claude 每轮自己决定思考多深。但 auto 不一定是最优的——有时你知道任务简单，不想让模型花 500 个 thinking token 来决定怎么重命名一个变量；有时你知道它很难，想要它慢慢来。
作为驾驶者，根据你要问的问题手动调整 effort，效果更好且 token 更省。
不只是「更多的 thinking token」，整个行为模式都会变：
低 effort：简单任务直接跳过推理，不做铺垫直接行动。工具调用更少，读取文件更少。更快更便宜，足够用。
高/max effort：深入推理，更愿意读你没问到但相关的文件和依赖，运行额外验证，更广泛地规划。响应更长、更详细，代码注释更多。
成本差异：对于同一个 prompt，max effort 消耗的 token 可能是 low effort 的 10 倍。那些 thinking token 的计费方式和输出 token 一样。响应时间也明显更长。
在 prompt 里加「think harder」或「ultrathink」，模型会给出更深入的推理。这些不是官方设置，是 prompt 技巧，在实践中有效，因为模型能捕捉到意图。「慢慢来」「全面考虑」「读所有相关代码」都能推动更深入的推理。
有时这些比切换 effort 等级更快，你不用改全局设置，只是轻轻推一下当前这一轮。
你的 CLAUDE.md 会被加载到每一条消息里。每一行在每一轮都消耗 token。如果你的 CLAUDE.md 是 2000 token，发了 30 条消息，光 system prompt 就用了 60,000 token。
狠狠精简。删掉注释掉的规则，删掉「有则更好」的指南。只保留能改变模型行为的内容。如果一条规则不写出来模型也会照做，那就删掉。
对于很重的 CLAUDE.md 文件，用 caveman compression 来剥离语法但保留语义。能节省 40-50% 的输入 token，在每条消息上复合。
不要每次 prompt 都写「写测试时用 vitest 加这个模式，always mock the database...」，把它编码成一个 skill。Skill 按需加载，不是每条消息都加载。模型在需要时读取，不需要时不读。
一个在相关时加载的 skill 文件，比每轮都加载的 500 token 指令更便宜。
Subagent（Task 工具、spawn 出的 agent）会得到一个全新的上下文窗口。这是它们的超能力：干净的上下文意味着在专注任务上更好的输出。
但代价是：每个 subagent 都是从头开始。你的 system prompt、CLAUDE.md、它读取的任何文件，全部重新计费。五个 subagent 做五件事，是五个完整上下文加载。一个 agent 顺序做五件事，是一个不断增长的上下文加载。
用 subagent：需要干净推理的研究任务，独立文件的并行工作，得益于隔离的任务。
不用：共享上下文的顺序任务，不需要新窗口的快速操作，setup 成本超过任务成本的情况。
如果你用 /loop 或 /schedule 来跑周期性任务，检查它们实际消耗了什么。配置不当的 loop 每 5 分钟跑一次，能比任何手动 coding 更快烧光 token 预算。
我见过 agent 每 10 分钟轮询一次状态，每次轮询加载完整 system prompt 和 CLAUDE.md，每天 288 次上下文加载，悄悄消耗。自动化之前先设监控，知道每个 loop 每次循环花多少。
你连接的每个 MCP 服务器都会把它的工具 schema 丢进上下文。Playwright MCP 一个就 15,000 token 的定义，每条消息都加载。连三个服务器，你的一半上下文就被工具描述烧掉了。
用 mcporter 从命令行调用 MCP 工具。Agent 执行 bash 命令，拿结果，工具 schema 从不碰上下文窗口。
模型会缓存对话中的静态部分：system prompt、CLAUDE.md、工具定义、项目文件。如果这些在消息之间保持不变，从缓存读取而不是从头重新处理。缓存的 token 大约是未缓存 token 价格的 10%。
实际意味着：上下文顶部的东西会自动缓存，底部的东西（你的最新消息、近期对话）不会。所以一个在 30 条消息中保持不变的 3000 token CLAUDE.md，第一次付全价，后面 29 次付 10%。
破坏缓存的地方：会话中修改 CLAUDE.md、连接或断开 MCP 服务器、往对话里上传新文件。每次上下文「顶部」改变，缓存重置，你又付全价了。
实操要点：开始工作前设置好 CLAUDE.md、skills 和项目文件，别在会话中折腾它们。前置加载稳定的东西，动态的东西放在末尾。
上面所有内容都是你在做优化。下一步是 agent 自己来做优化，这是个正经兔子洞。
从用 /reflect 做内存管理，到无损上下文管理、多 agent 协调的 gossip 协议、GraphRAG 和向量记忆的长期召回、智能压缩的会话日志、根据使用模式进化的自动改进 skills、根据测量结果自主选择 effort 级别的自路由模型……
内容太多，这里装不下。回头会好好深入讲所有这些。现在的技巧能解决最严重的 token 浪费问题，自主化才是让收益复利的东西。
原文：Token Optimisation 101: Stop Burning Money on AI Coding Agents