要被5.5的258K恶心坏了
本来要实现一个功能，头脑风暴后列出了很多点具体细节，已经准备要实行了。脑子一热，突然想起来这个功能会不会影响到B模块，就问了一嘴B模块是怎么实现的，一问果然是会影响，和AI确认了B模块的修改方式，以避免新模块影响到B，结果触发上下文压缩了，我的新功能的具体实现细节GPT直接记不起来了，让他执行却一直在执行B模块的修改方案。
7 Likes
现代软件工程是文档驱动，把ai理解的内容让他在文档里写好，执行单开一个会话就行了。
6 Likes
使用5.4吧。我感觉智商也在线的。我现在主力是使用5.4，遇到bug切一下5.5。
其实1m上下文也不一定能解决这些问题，因为上下文一长模型的注意力就容易下降（当然后面可能会解决这些问题），不过还是把方案什么的落盘到文档里吧，即是以后追溯的一个记录，也是清晰的一个外部记忆嘛不是。
相对来说感觉codex的上下文压缩做的挺不错的了（主观感受）
我记得api不是有1m上下文吗，
刚刚又发现一个恶心的地方。新版codex app已经可以控制电脑了。
我在做一个网页，codex调试应该直接控制Chrome进行调试，我已经配置好了插件也已经连上，确认可以用。
但他直接使用控制电脑的功能。我发现后立刻中断了，并使用 @Chrome 告诉他可以使用codex官方功能进行调试。后面他就会了，所有调试都是在Chrome里控制浏览器调试的。
但在刚刚，触发了上下文压缩，压缩完后，他做完任务要验证，又开始控制我的电脑了，真的是神了
5.5不是可以设置1M上下文吗，config.toml里的max _window
佬，这个是用什么命令或者插件查看的呀
试试让他用subagent去分析其他仓库然后给出结论后再继续,这样不会污染主agent上下文
codex是你要求他用subagent,他才会去调用,平时要他自己调用的积极性很低
我记得不是早就有1M上下文了吗 
只不过开1M后注意力衰退很严重
其实我觉得1M上下文的真正意义是，让256k上下文的注意力极强。
原来256k上下文时代，llm普遍的有效注意力可能就50k。
我大致觉得0k和240k上下文的时候，gpt5.5的注意力是差不多的。
但如果你开放了1m上下文，你的重要指令如果恰好落在970k的地方，可能会执行地很差……
1 Like
合理，是这样
同时也不用在200k疯狂压缩，浪费时间，至少窗口我可以开到300k，500k
1 Like
codex里限制过，chatgpt.com/backend-api/codex/responses 接口也限制过
gpt-5.5: context_window=272000 max_context_window=272000
gpt-5.4: context_window=272000 max_context_window=1000000
只有api能开，codex登录账号这种开不了，api那价格一般人也烧不起呀