Claude has no memory. Every time you send a message, Claude Code sends it the entire conversation again. Caching gives old content a steep discount, but the longer the conversation, the more old content you pay for on every turn. Compaction cuts the conversation short.
In early October 2026, a few posts about Claude Code caching and context length spread widely on X:
promptCacheTtl and subagentPromptCacheTtl./autocompact 400k.They're talking about two knobs on the same thing. Claude Code resends the whole conversation to the model every turn; caching only discounts the old content.
The posts contradict each other because everyone uses it differently: how many subagents, whether they go idle mid-run, how long sessions are. So the most reliable approach is to test it on your own records.
This applies to Claude Code only. Codex has different caching and compaction rules; don't apply these assumptions to it. Using the Claude Code records on my machine, answer two questions. Read data only; do not change any settings. Question 1: Should subagents use the 1-hour cache? Question 2: What auto-compact threshold (autoCompactWindow) for the main session is cheapest? Data and accounting: - Records are .jsonl files under ~/.claude/projects/. Main sessions are files in the project directory; subagents are under */subagents/. Use the last 7 days. - A single API call is written as several lines; dedupe by message.id. Usage is in message.usage; if usage.iterations exists, price each iteration separately. Advisor iterations use the advisor model's price, and their input is usually not cached. - Use the official price table on platform.claude.com: base input, 5-minute cache write, 1-hour cache write, cache read, output. Price each call by its model field. Method for question 1: - Measure the gap between consecutive subagent calls. Report how many exceed 5 minutes and what share, and how many of those actually missed the cache (cache_read clearly smaller than the previous context). - Compute how subagent cost changes if everything used the 1-hour cache: each write at 2× input price instead of 1.25×; only idle gaps of 5 to 60 minutes turn a rewrite into a cache read. Method for question 2: - Using real usage as the base, replay 200k, 300k, 400k, 600k and the current setting. When context exceeds the threshold, simulate one compaction: read the current context once, output a ~6k summary, then write the "new starting point" to cache. Subtract the compacted tokens from every later call. - Don't count only the summary as the new starting point. It includes the fixed opening content (system prompt, tool definitions, CLAUDE.md, etc.), the summary, and the last few messages. Use the context size of the next call after a real compaction in the logs (type system, subtype compact_boundary) as the new starting point, and check how much of it hits the cache. - Subagents inherit this threshold, so give two sets of results, "main session only" and "main session + subagents", and list how many extra compactions per week each threshold causes. Checks and output: - First replay with the threshold set to infinity; the result should equal the real cost, which validates the replay logic. - Finally, give one table with results per threshold and your recommended setting, and state what wasn't counted: rework after compaction, information lost in the summary, and how subscription quota is metered. - If you recommend changing settings, tell me what to change first and wait for my confirmation before doing it.
model_auto_compact_token_limit in ~/.codex/config.toml, not Claude Code's autoCompactWindow.~/.codex/sessions/, with a different field format.This prompt only reads local logs and doesn't change settings. The sections below explain the reasoning behind it; the last one is a sample week of results.
The old conversation stored last turn, looked at again this turn. The cheapest: just 1/20 of the base input price.
What's new this turn: your new message, tool results, Claude's previous reply. It's stored in the cache so next turn it can be read at the cache-read price.
The text Claude writes this turn. It's separate from the cache write. Next turn it becomes input, and only then is it written to the cache.
Prices are Opus 5.5's official API prices. Cache writes are priced at the main session's 1-hour tier; subagents use the 5-minute tier at $5 per million.
Assume about 3k tokens of new content come in each turn and Claude writes about 1k tokens each turn. These two charges have nothing to do with conversation length: about $0.04 per turn.
Cache reads are different. They're charged on the length of the whole old conversation. At 100k tokens, one turn's cache read is only $0.02; at 900k tokens it's $0.18 per turn and becomes the biggest item.
The compaction threshold decides how long the conversation can get. At the 1M tier, the conversation grows to about 967k before compacting, carrying about 530k tokens per turn on average. At 400k it carries only about 250k. Read half as much each turn, and cache-read cost halves.
But compaction isn't free. Each time, Claude first reads the whole conversation and writes a summary. The compacted conversation is the new starting point, and the conversation grows again from there. The new starting point has three parts:
The cache is matched from the start forward, token by token. The system prompt and tool definitions haven't changed, so they can still be read from cache; from the first point that changed, everything after must be stored again at the cache-write price. So one compaction costs twice: reading the whole conversation to write the summary, then writing the part of the new starting point that missed the cache.
How big the new starting point is depends on the size of the opening and the length of the summary; it isn't fixed. The simulation below assumes a new starting point of about 100k tokens: about 50k (system prompt and tool definitions) hit the cache directly, and the other ~50k (rest of the opening, summary and last few messages) must be rewritten. That makes one compaction about $0.6 to $0.7. You then need enough further turns to earn that back.
The four cards below use the same simulation: one long 500-turn session with 7 advisor calls and 10 research tasks along the way. Parameters are assumed round numbers, close to everyday usage in magnitude. Each card changes just one condition.
Combine the three switches any way you like. The number on top is this session's total; the curve below is the main session's conversation length.
Below is a sample week generated with the same simulator — not a real bill: 7 days, sessions of varying length, most only a few dozen turns, a few running to several hundred. Every threshold replays the same batch of sessions.
Three things this sample shows:
A longer threshold isn't always better, and neither is a shorter one. If you run many long sessions, start trying at 300k to 400k. Test the exact value on your own records with the prompt at the top. To set it: run /autocompact 400k in Claude Code, or put "autoCompactWindow": 400000 in ~/.claude/settings.json.
Not counted: files may need re-reading after compaction, the summary may lose detail, and each compaction takes a minute or two. How subscription quota is deducted hasn't been published officially.
How long can one session get? Current main models (Opus 4.7 and later, Sonnet 5 and later, the Fable family, Haiku 5.5) run with a 1M (one million) token context in Claude Code by default, with no [1m] suffix needed. By default they auto-compact at about 967k, so the usable length of a session is a bit under 1M. The older Opus 4.6 and Sonnet 4.6 default to only 200k; you need the [1m] variant to reach 1M, and it depends on your plan: Opus 4.6 1M is included on Max, Team and Enterprise, while Sonnet 4.6 1M requires extra usage credits.
CLAUDE_CODE_DISABLE_1M_CONTEXT=1./autocompact 400k (100k to 1M allowed), or autoCompactWindow in settings; in scripts and cloud environments use CLAUDE_CODE_AUTO_COMPACT_WINDOW, which takes highest precedence.Why the subagent cache is only 5 minutes. The cache isn't permanent. The default lifetime is 5 minutes, and the timer resets each time it's read; if nothing uses it for more than 5 minutes, the next turn has to store the whole thing again at the cache-write price. The 1-hour tier survives longer idle gaps, but its writes cost 2× base input, versus 1.25× for the 5-minute tier.
Claude Code splits requests into two kinds, each with its own switch:
-p, SDK): setting promptCacheTtl, environment variable CLAUDE_CODE_PROMPT_CACHE_TTL. For subscribers within included usage, the main session gets 1 hour automatically.subagentPromptCacheTtl, environment variable CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL. Default 5 minutes.5m or 1h and require Claude Code v2.1.242 or later. FORCE_PROMPT_CACHING_5M=1 forces every request back to 5 minutes.So "should subagents use 1 hour?" comes down to one thing: will it sit idle for 5 to 60 minutes mid-run? A subagent that runs nonstop refreshes its cache every turn; 1 hour just raises each write from 1.25× to 2× — money wasted. For subagents that wait on tools, on people, or on long commands, 1 hour is what turns "rewrite everything" into "read from cache". Question 1 of the prompt at the top tests exactly this.
What re-reading after compaction costs. A compaction does not end at the summary: the agent usually goes back and re-reads some files (call it R). Files Claude Code restores automatically at compaction are already counted in the fresh start; R is only the extra reading the agent does on its own. R is written once at the cache-write price and then rides in the prefix at cache-read price every turn until the next compaction, and it brings that next compaction sooner. In our own sessions R had a median of about 17k tokens (n=6, max 53k). In the simulator (1M window, 500 turns, main session only, 1h cache), compacting at 400k saves 30.9% vs the ~967k default at R=0 and still about 22.9% at R=60k; compacting at 200k turns from a saving into an extra cost at about R≈49k. These low-threshold numbers come from the model, not from live runs: we did not run sessions at low thresholds.
Sources: Claude Code model configuration, Environment variables, Prompt caching (checked 2026-10-14). Unverified: the official docs don't say how long a subagent runs at a time, or how subscription quota converts cache writes.
Claude 没有记忆。你每发一条消息，Claude Code 都要把整段对话重新发给它一遍。缓存让旧内容打很大的折扣，但对话越长，每一轮要付的旧内容就越多。压缩就是把这段对话砍短。
2026 年 10 月上旬，X 上有几条关于 Claude Code 缓存和上下文长度的帖子传得很广：
promptCacheTtl 和 subagentPromptCacheTtl 修改。/autocompact 400k 提前。它们在讲同一件事的两个旋钮。Claude Code 每一轮都要把整段对话重新发给模型，缓存只是让旧内容打折。
几条帖子的结论互相矛盾，原因是每个人的用法不同：子 agent 多不多、会不会中途空闲、session 有多长。所以最可靠的办法，是用自己的记录测一遍。
以下只针对 Claude Code。Codex 的缓存和压缩规则不同，不要套用这里的口径。 请用我本机的 Claude Code 记录回答两个问题。只读数据，不要修改任何设置。 问题 1：子 agent 要不要开 1 小时缓存？ 问题 2：主 session 的自动压缩阈值（autoCompactWindow）设多少最省？ 数据和口径： - 记录在 ~/.claude/projects/ 下的 .jsonl 文件里。主 session 是项目目录下的文件，子 agent 在 */subagents/ 下。取最近 7 天。 - 同一次 API 调用会写成多行，按 message.id 去重。用量在 message.usage 里；如果有 usage.iterations，按每个 iteration 分别计价。advisor 的 iteration 用 advisor 模型的价格，它的输入通常没有缓存。 - 价格以 platform.claude.com 的官方价格表为准：普通输入、5 分钟缓存写、1 小时缓存写、缓存读、输出。按每次调用的 model 字段取价。 问题 1 的做法： - 统计子 agent 相邻两次调用的间隔。报告超过 5 分钟的次数和比例，以及其中真的没读到缓存的次数（cache_read 明显小于上一次的上下文）。 - 计算全部改用 1 小时缓存后，子 agent 成本变多少：每次写入按 2 倍输入价，而不是 1.25 倍；只有 5 到 60 分钟的空闲，才能把重写变成读缓存。 问题 2 的做法： - 以真实用量为底，回放 200k、300k、400k、600k 和现状。上下文超过阈值时，模拟一次压缩：读一遍当前上下文，输出约 6k 的摘要，再把“新起点”写进缓存。之后每次调用减去被压缩掉的 token。 - 新起点不要只算摘要。它包括固定开场内容（系统提示、工具定义、CLAUDE.md 等）、摘要和最近几条消息。请用日志里真实压缩（type 为 system、subtype 为 compact_boundary）之后下一次调用的上下文大小作为新起点，并确认其中多少能命中缓存。 - 子 agent 会继承这个阈值，所以分别给出“只算主 session”和“主 session + 子 agent”两组结果，并列出每档每周多压缩几次。 核对与输出： - 先把阈值设成无穷大回放一遍，结果应该等于真实成本，用来验证回放逻辑。 - 最后用一张表给出各档结果和你推荐的档位，并说明没算进去的东西：压缩后的返工、摘要丢失的信息、订阅额度的计量方式。 - 如果你建议改设置，先告诉我改什么，等我确认再动手。
~/.codex/config.toml 里的 model_auto_compact_token_limit，不是 Claude Code 的 autoCompactWindow。~/.codex/sessions/ 下，字段格式也不同。这段 prompt 只读本机的日志，不会改设置。下面几节解释它背后的原理，最后一节是一份一周的示例结果。
上一轮已经存好的旧对话，这一轮再看一遍。最便宜，只有普通输入价的 1/20。
这一轮新进来的内容：你的新消息、工具结果、上一轮 Claude 的回复。存进缓存，下一轮就能按读缓存的价格看。
Claude 这一轮写出来的字。它和写缓存是两回事。到了下一轮，它变成输入，那时才被写进缓存。
价格是 Opus 5.5 的官方 API 价。写缓存按主 session 的 1 小时档计价；子 agent 用 5 分钟档，每百万 $5。
假设每一轮新进来的内容约 3k token，Claude 每轮写出约 1k token。这两笔钱和对话多长没有关系，一轮约 $0.04。
读缓存不一样。它按整段旧对话的长度收钱。对话 10 万 token 时，一轮读缓存只要 $0.02；涨到 90 万 token，一轮就要 $0.18，变成大头。
压缩阈值决定对话最长能到多少。1M 档的对话会涨到约 967k 才压缩，平均每轮背着约 53 万 token。400k 档平均只背约 25 万。每轮少读一半，读缓存的钱就少一半。
但压缩不是免费的。每压缩一次，Claude 要先读完整段对话，写一份摘要。压缩后的对话就是新起点，之后的对话从这里重新往上涨。新起点由三部分组成：
缓存是从头往后逐字比对的。系统提示和工具定义没有变，还能直接读缓存；从变了的地方开始，后面的内容都要按写缓存的价格重新存一遍。所以一次压缩要付两笔钱：读完整段对话写摘要，再把新起点里没命中缓存的部分写进缓存。
新起点有多大，取决于开场内容有多大、摘要有多长，不是一个固定值。下面的模拟假设新起点约 10 万 token：其中约 5 万（系统提示和工具定义）直接命中缓存，另外约 5 万（开场的其余部分、摘要和最近几条消息）要重新写入。这样一次压缩约 $0.6 到 $0.7。压缩之后还要再聊足够多轮，才能把这笔钱赚回来。
下面四张卡用的是同一个模拟：一个 500 轮的长 session，中间有 7 次 advisor 和 10 个调研任务。参数都是假设的整数，量级接近日常使用。每张卡只改一个条件。
三个开关可以随意组合。上方的数字是这个 session 的总价，下方的曲线是主 session 的对话长度。
下面是用同一个模拟器生成的一周示例，不是真实账单：7 天、 个 session，长短不一，大多数只有几十轮，少数会聊几百轮。每个档位都用同一批 session 回放一遍。
从这份示例能看到三件事：
阈值不是越长越好，也不是越短越好。长 session 多的人，可以从 300k 到 400k 开始试。具体值请用开头的 prompt，拿你自己的记录测。设置方法：在 Claude Code 里运行 /autocompact 400k，或者在 ~/.claude/settings.json 里写 "autoCompactWindow": 400000。
没算进去的：压缩后可能要重新读文件，摘要也可能丢细节，每次压缩还要等一两分钟。订阅额度按什么比例扣，官方没有公开。
一条会话最长能到多少。现在的主力模型（Opus 4.7 及以后、Sonnet 5 及以后、Fable 系列、Haiku 5.5）在 Claude Code 里默认就是 1M（100 万）token 的上下文，不用加 [1m] 后缀。默认到约 967k 自动压缩，所以一条会话实际能用的长度略低于 1M。老一点的 Opus 4.6 和 Sonnet 4.6 默认只有 200k，要选 [1m] 版本才到 1M，而且看套餐：Max、Team、Enterprise 的 Opus 4.6 1M 含在订阅里，Sonnet 4.6 1M 要额外的 usage credits。
CLAUDE_CODE_DISABLE_1M_CONTEXT=1。/autocompact 400k（可选 100k 到 1M），或 settings 里的 autoCompactWindow；脚本和云端环境用 CLAUDE_CODE_AUTO_COMPACT_WINDOW，它优先级最高。子 agent 的缓存为什么只有 5 分钟。缓存不是永久的。默认的有效期是 5 分钟，每读一次就重新计时；超过 5 分钟没人用，下一轮就得把整段内容按写缓存的价格重存一遍。1 小时档能撑过更长的空闲，但写入价是普通输入的 2 倍，5 分钟档只要 1.25 倍。
Claude Code 把请求分成两类，各有一个开关：
-p、SDK）：设置项 promptCacheTtl，环境变量 CLAUDE_CODE_PROMPT_CACHE_TTL。订阅用户在包含额度内，主 session 自动是 1 小时。subagentPromptCacheTtl，环境变量 CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL。默认 5 分钟。5m 或 1h，需要 Claude Code v2.1.242 及以上。FORCE_PROMPT_CACHING_5M=1 会把所有请求都压回 5 分钟。所以“子 agent 要不要开 1 小时”只看一件事：它中途会不会空闲 5 到 60 分钟。一直在跑的子 agent，每轮都会刷新缓存，开 1 小时只是让每次写入从 1.25 倍变成 2 倍，白花钱。会等工具、等人、跑长命令的子 agent，开 1 小时才把“重写整段”变成“读缓存”。开头那段 prompt 的问题 1 就是在测这个。
压缩后重读要花多少。压缩不是做完摘要就结束了：agent 往往还要回头再读一些文件（记作 R）。Claude Code 压缩时自动带回的文件已经算在新起点里，R 只算 agent 自己额外去读的部分。R 按写缓存价付一次，之后每轮按读缓存价跟着前缀走，直到下次压缩，而且会让下次压缩来得更早。我们自己的会话里 R 的中位数约 17k token（n=6，最大 53k）。在计算器里（1M 窗口、500 轮、只算主 session、1 小时缓存），在 400k 压缩比默认约 967k 省 30.9%（R=0），R=60k 时仍省约 22.9%；在 200k 压缩，R 到约 49k 时就从省钱变成多花钱。低阈值的这些数字来自模型推算，没有实际跑过低阈值的会话。
来源：Claude Code 模型配置、环境变量、Prompt caching（2026-10-14 查阅）。未核实：官方文档没有写“子 agent 一次跑多久”，也没有写订阅额度怎么折算缓存写入。