# Using Claude Code: Session Management & 1M Context
**作者**: Thariq
**日期**: 2026-04-15T22:47:45.000Z
**来源**: [https://x.com/trq212/status/2044548257058328723](https://x.com/trq212/status/2044548257058328723)
---
In my recent calls with Claude Code users, one theme keeps coming up: the 1M token context window is a double-edged sword.
It lets Claude Code operate autonomously for longer and handle tasks more reliably, but it also opens the door to context pollution if you're not deliberate about managing your sessions.
Session management matters more than ever and there seem to be a lot of questions about it. Do you keep one session open in a terminal, or two? Start fresh with every prompt? When should you use compact, rewind, or subagents? What causes a bad compact?
There’s a surprising amount of detail here that can really shape your experience with Claude Code and almost all of it comes from managing your context window.
## A Quick Primer on Context, Compaction & Context Rot
The context window is everything the model can "see" at once when generating its next response. It includes your system prompt, the conversation so far, every tool call and its output, and every file that's been read. Claude Code has a context window of one million tokens.
Unfortunately using context has a slight cost, which is often called context rot. Context rot is the observation that model performance degrades as context grows because attention gets spread across more tokens, and older, irrelevant content starts to distract from the current task. For our 1MM context model, we see some level of context rot happen around ~300-400k tokens, but it is highly dependent on the task- not a fast rule.
Context windows are a hard cutoff, so when you’re nearing the end of the context window, you will need to summarize the task you’ve been working on into a smaller description and continue the work in a new context window, we call this compaction. You can also trigger compaction yourself.
Every Turn Is a Branching Point
Say you've just asked Claude to do something and it's finished, you’ve now got some information in your context (tool calls, tool outputs, your instructions) and you have a surprising number of options for what to do next:
- Continue — send another message in the same session
- /rewind (esc esc) — jump back to a previous message and try again from there
- /clear — start a new session, usually with a brief you've distilled from what you just learned
- Compact — summarize the session so far and keep going on top of the summary
- Subagents — delegate the next chunk of work to an agent with its own clean context, and only pull its result back in
While the most natural is just to continue, the other four options exist to help manage your context.
## When to Start a New Session
The new 1M context windows means that you can now do longer tasks more reliably, for example to have it build a full-stack app from scratch. But just because your model hasn't run out of context, it doesn't mean you shouldn't start a new session.
Our general rule of thumb is when you start a new task, you should also start a new session.
A grey area is when you may want to do related tasks where some of the context is still necessary, but not all.
For example, writing the documentation for a feature you just implemented. While you could start a new session, Claude would have to reread the files that you just implemented, which would be slower and more expensive. Since documentation may not be a highly intelligence sensitive task, the extra context is probably worth the efficiency gain of not having to re-read the relevant files again.
## Rewinding Instead of Correcting
If I had to pick one habit that signals good context management, it’s rewind.
In Claude Code, double-tapping Esc(or running /rewind) lets you jump back to any previous message and re-prompt from there. The messages after that point are dropped from the context.
Rewind is often the better approach to correction. For example, Claude reads five files, tries an approach, and it doesn't work. Your instinct may be to type "that didn't work, try X instead." but the better move is to rewind to just after the file reads, and re-prompt with what you learned. "Don't use approach A, the foo module doesn't expose that — go straight to B."
You can also use “summarize from here” to have Claude summarize its learnings and create a handoff message, kind of like a message to the previous iteration of Claude from its future self that tried something and it didn’t work.
## Compacting vs. Fresh Sessions
Once a session gets long, you have two ways to shed weight: /compact or /clear (and start fresh). They feel similar but behave very differently.
Compact asks the model to summarize the conversation so far, then replaces the history with that summary. It's lossy, you're trusting Claude to decide what mattered, but you didn't have to write anything yourself and Claude might be more thorough in including important learnings or files. You can also steer it by passing instructions (/compact focus on the auth refactor, drop the test debugging).
With /clear you write down what matters ("we're refactoring the auth middleware, the constraint is X, the files that matter are A and B, we've ruled out approach Y") and start clean. It's more work, but the resulting context is what you decided was relevant.
## What Causes a Bad Compact?
If you run a lot of long running sessions, you might have noticed times in which compacting might be particularly bad. In this case we’ve often found that bad compacts can happen when the model can’t predict the direction your work is going.
For example autocompact fires after a long debugging session and summarizes the investigation and your next message is "now fix that other warning we saw in bar.ts."
But because the session was focused on debugging, the other warning might have been dropped from the summary.
This is particularly difficult, because due to context rot, the model is at its least intelligent point when compacting. With one million context, you have more time to /compact proactively with a description of what you want to do.
## Subagents & Fresh Context Windows
Subagents are a form of context management, useful for when you know in advance that a chunk of work will produce a lot of intermediate output you won't need again.
When Claude spawns a subagent via the Agent tool, that subagent gets its own fresh context window. It can do as much work as it needs to, and then synthesize its results so only the final report comes back to the parent.
The mental test we use: will I need this tool output again, or just the conclusion?
While Claude Code will automatically call subagents, you may want to tell it to explicitly do this. For example, you may want to tell it to:
- “Spin up a subagent to verify the result of this work based on the following spec file”
- “Spin off a subagent to read through this other codebase and summarize how it implemented the auth flow, then implement it yourself in the same way”
- “Spin off a subagent to write the docs on this feature based on my git changes”
Summary
In summary, when Claude has ended a turn and you’re about to send a new message, you have a decision point.
Overtime we expect that Claude will help you handle this itself, but for now this is one of the ways you can guide Claude's output.
## 相关链接
- [Thariq](https://x.com/trq212)
- [@trq212](https://x.com/trq212)
- [634K](https://x.com/trq212/status/2044548257058328723/analytics)
- [bar.ts](http://bar.ts/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [6:47 AM · Apr 16, 2026](https://x.com/trq212/status/2044548257058328723)
- [634.3K Views](https://x.com/trq212/status/2044548257058328723/analytics)
- [View quotes](https://x.com/trq212/status/2044548257058328723/quotes)
---
*导出时间: 2026/4/16 15:09:38*
---
## 中文翻译
# 使用 Claude Code：会话管理与 1M 上下文
**作者**: Thariq
**日期**: 2026-04-15T22:47:45.000Z
**来源**: [https://x.com/trq212/status/2044548257058328723](https://x.com/trq212/status/2044548257058328723)
---
在我最近与 Claude Code 用户的通话中，有一个主题反复出现：100 万 token 的上下文窗口是一把双刃剑。
它允许 Claude Code 更长时间地自主运行，并更可靠地处理任务，但如果你在有意识地管理会话方面稍有疏忽，它也会导致上下文污染。
会话管理变得比以往任何时候都重要，而且关于它似乎存在很多疑问。你应该在终端中保留一个会话还是两个？每次提示都要重新开始？什么时候应该使用压缩、回退或子代理？是什么导致了一次糟糕的压缩？
这里有令人惊讶的细节量，它们会真正影响你使用 Claude Code 的体验，而且几乎所有这些都源于对上下文窗口的管理。
## 关于上下文、压缩与上下文衰退的快速入门
上下文窗口是指模型在生成下一个响应时能同时“看到”的所有内容。它包括你的系统提示词、迄今为止的对话、每一次工具调用及其输出，以及每一个被读取的文件。Claude Code 拥有 100 万 token 的上下文窗口。
遗憾的是，使用上下文是有代价的，这通常被称为上下文衰退。上下文衰退是指随着上下文的增长，模型性能会下降，因为注意力被分散到了更多的 token 上，而旧的、不相关的内容开始干扰当前的任务。对于我们的 100 万上下文模型，我们发现在大约 30 万到 40 万 token 左右会出现某种程度的上下文衰退，但这高度依赖于任务本身，并非硬性规定。
上下文窗口是一个硬性的截断点，因此当你接近上下文窗口的尽头时，你需要将正在处理的任务总结为一个更简短的描述，并在一个新的上下文窗口中继续工作，我们称之为压缩。你也可以手动触发压缩。
## 每一轮对话都是一个分支点
假设你刚刚让 Claude 做了某件事，它已经完成了。现在你的上下文中包含了一些信息（工具调用、工具输出、你的指令），对于下一步该做什么，你拥有数量惊人的选项：
- **继续** — 在同一个会话中发送另一条消息
- **/rewind (esc esc)** — 跳回到之前的一条消息，并从那里重试
- **/clear** — 开始一个新会话，通常会附上一份基于你刚才所学到的内容提炼出的简报
- **压缩** — 总结到目前为止的会话，并在总结的基础上继续
- **子代理** — 将下一块工作委托给一个拥有独立干净上下文的代理，只取回其结果
虽然最自然的方式就是继续，但另外四个选项的存在是为了帮助你管理上下文。
## 何时开始新会话
新的 100 万上下文窗口意味着你现在可以更可靠地执行更长的任务，例如让它从零开始构建一个全栈应用。但这并不意味着只要你的模型没用完上下文，就不应该开始新会话。
我们的一般经验法则是：当你开始一项新任务时，你也应该开始一个新会话。
一个灰色地带是当你可能想要做一些相关的任务时，其中部分上下文仍然是必要的，但并非全部。
例如，为你刚刚实现的功能编写文档。虽然你可以开始一个新会话，但 Claude 将不得不重新读取你刚刚实现的文件，这会更慢且成本更高。由于编写文档可能不是一项高度依赖智能的任务，这些额外的上下文相对于避免重新读取相关文件所带来的效率提升来说是值得的。
## 回退而不是修正
如果我必须选出一个标志着你具备良好上下文管理习惯的特征，那就是回退。
在 Claude Code 中，双击 Esc（或运行 /rewind）允许你跳回到之前的任何一条消息，并从那里重新发起提示。该点之后的消息将从上下文中丢弃。
回退通常是进行修正的更好方法。例如，Claude 读取了五个文件，尝试了一种方法，但没成功。你的直觉可能是输入“那不起作用，试试 X”。但更好的做法是回退到刚读完文件之后，并利用你学到的知识重新提示。“不要使用方法 A，foo 模块没有暴露那个接口 —— 直接用 B。”
你也可以使用“从这里总结” 让 Claude 总结其学到的东西并创建一个交接消息，这就像是来自尝试了某事但未成功的未来 Claude 给过去那个自己的留言。
## 压缩与全新会话
一旦一个会话变得很长，你有两种方式来减轻重量：/compact 或 /clear（并重新开始）。它们感觉相似，但行为截然不同。
**压缩** 要求模型总结迄今为止的对话，然后用该总结替换历史记录。这是有损的，你信任 Claude 来决定什么很重要，但你不需要自己写任何东西，而且 Claude 在包含重要学习成果或文件方面可能会更详尽。你也可以通过传递指令来引导它（/compact focus on the auth refactor, drop the test debugging）。
使用 **/clear**，你需要写下重要的事项（“我们正在重构 auth 中间件，约束条件是 X，重要的文件是 A 和 B，我们已经排除了方法 Y”）并清空重新开始。这需要更多的工作，但由此产生的上下文是由你决定的相关内容。
## 什么会导致糟糕的压缩？
如果你运行很多长时间的会话，你可能会注意到某些时候压缩的效果可能特别差。在这种情况下，我们经常发现，当模型无法预测你的工作方向时，就会出现糟糕的压缩。
例如，自动压缩在一次长时间的调试会话后触发，总结了调查过程，而你的下一条消息是“现在修复我们在 bar.ts 中看到的那个其他警告。”
但由于会话专注于调试，那个其他警告可能已从总结中被删除。
这特别困难，因为由于上下文衰退，模型在进行压缩时处于其智能的最低点。有了 100 万的上下文，你有更多的时间来主动地 /compact，并附上你想做的事情的描述。
## 子代理与全新的上下文窗口
子代理是上下文管理的一种形式，当你提前知道某块工作将产生大量你不再需要的中间输出时，它就非常有用。
当 Claude 通过 Agent 工具生成一个子代理时，该子代理会获得自己全新的上下文窗口。它可以做它需要的任何工作，然后综合其结果，以便只有最终报告返回给父级。
我们使用的心理测试是：我是需要再次使用这个工具输出，还是只需要结论？
虽然 Claude Code 会自动调用子代理，但你可能需要明确告诉它这样做。例如，你可能想告诉它：
- “启动一个子代理，根据以下规范文件验证此工作的结果”
- “分拆一个子代理来通读另一个代码库，并总结它是如何实现 auth 流的，然后你自己以相同的方式实现它”
- “分拆一个子代理，根据我的 git 更改为此功能编写文档”
## 总结
总而言之，当 Claude 结束一轮对话而你即将发送一条新消息时，你面临一个决策点。
随着时间的推移，我们期望 Claude 能帮助你自己处理这个问题，但目前这是你可以引导 Claude 输出的方法之一。
## 相关链接
- [Thariq](https://x.com/trq212)
- [@trq212](https://x.com/trq212)
- [634K](https://x.com/trq212/status/2044548257058328723/analytics)
- [bar.ts](http://bar.ts/)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [6:47 AM · Apr 16, 2026](https://x.com/trq212/status/2044548257058328723)
- [634.3K Views](https://x.com/trq212/status/2044548257058328723/analytics)
- [View quotes](https://x.com/trq212/status/2044548257058328723/quotes)
---
*导出时间: 2026/4/16 15:09:38*