我自己感觉用 Astra 的话 258k 有效上下文太容易压缩了。做个任务不断地压缩，感觉时间一长就容易漂移，设置大一点的上下文窗口能够解决这个问题么。虽然我查下来说 OpenAI 针对 272k 的上下文是做过优化的。 想问问各位大佬们的实际实践经验。
还有一般隔多久新开一个 session 啊，我基本上每个模块每个功能版本都要单独开一个 work session 来做，然后通过文档组织好，但是感觉还是会丢失一些上下文信息，不知道各位是这么解决的。
 |
1
99185302 19h 42m ago
"保存线程交接信息",然后开新线程先读线程交接信息确认后再继续。
|
 |
2
nakun233 19h 27m ago
一个干到底，除非 load 不出来或者卡很久
|
 |
3
shuijingwanwqyy 18h 25m ago
我会 /status ，如果 Context window 低于 20% 的话，我会用 /compact 下。
|
 |
4
111111111111 17h 5m ago
我是改用 hermes 了，上限 872k ， 达到 50%自动压缩，也就是 436k 的上下文
hermes 还有一个 fast:auto 模式，小任务响应快，大任务后期会自动关闭 fast |
 |
5
shakaraka 17h 0m ago via iPhone
一路干到底。你能想到的人家想不到么，如果解决方案足够成熟，他们早端上来了
|
 |
6
zed1018 16h 49m ago
1. 保持默认不变，打开新的 context 管理（不压缩通过开新窗口） context_management.experimental_mode = true
2. 不是同一个开发任务肯定是开新 session |
 |
7
morty0 16h 8m ago
我开了 828k
|
 |
8
Sezxy 16h 2m ago
 默认的经常压缩，还是开大点舒服 |
 |
9
V2Try 16h 1m ago via iPhone
保持默认
|
 |
10
SilencerL 15h 55m ago
建议大家 Codex 使用 GPT-6/6.1 时，将上下文窗口设为 272K 。同时建议开启上下文管理特性（目前只支持订阅账号）：
model = "gpt-6-astra" model_context_window = 272000 [features.context_management] experimental_mode = true 计费规则：按官方 API 规则，单次请求输入不超过 272K 时正常计费；超过后，整次请求的输入及缓存单价变为 2 倍，输出单价变为 1.5 倍，并非只对超出部分加价。因此不建议日常盲目扩大窗口。如果叠加快速模式费用会变成四倍或者更多。 Feature 作用：通过跨窗口笔记和历史检索，保留并找回需求、决策及工具结果，减少反复压缩摘要造成的信息丢失。OpenAI 宣称能更好的支撑长任务连续执行，同时不依赖不断扩大窗口。 |
 |
11
Smileh 14h 47m ago
我设置了 在 272k 之前进行压缩 并且移交之前上下文总结
|
 |
12
jellywong 12h 51m ago
刚从 cc 切过来，体感 codex 动不动就整理上下文，200 多 k 确实不够用，对比 cc 不会经常压缩次数要少得多。codex 做事慢吞吞。
|
 |
13
nishui 7h 4m ago
Codex 里 GPT-6 Astra 上下文可以直接开 1M ，上下文超过 272K 不会产生额外费用（仅限于 Codex 里 GPT-6 Astra ！），这块好多人都不知道😈
https://help.openai.com/en/articles/20001415-chatgpt-rate-card-enterprise-token-based-pricing#gpt-6-astra-codex-long-context-exception 一般任务你可以考虑开 372k 上下文，这样不容易触发压缩，效果很好，至于为什么是 372k ，早期 GPT-5.6 Sol 默认设置就是 372k ，手感很不错 model_context_window = 372000 长程任务或是不想老是遇到压缩，就开 1M 上下文 model_context_window = 872000 对于需求，如果不相关领域的，则考虑独立 session 避免 AI/自己也混淆了 |
Select Language