因为codex的上下文问题破防了

欣 郁 2026-08-04 22:07 1

如题,用codex写一个小项目,末次对话正好卡在了224/258k,然后时间又赶上了美区的高峰时间。


导致给codex任何指令,首先都要先压缩上下文,但codex本来就慢且进入了国外的高峰用量时间,导致回复被卡死,


图中显示的时间完全根本不对——我等了1小时,仍然无法完成上下文压缩。



本来我觉得codex允许的上下文短并没有特别的问题,因为我只要使用模型注意力最强的前200k就行了。


现在发现,如果上下文短,则末次对话停留在“95%上下文占用”的情况会很频繁。。。然后就会遇到我这种情况(赶上用量高峰,无法启动上下文压缩——我理解上下文压缩应该要执行一次很久的prefill),这加剧了codex的瘀滞。

最新回复 (8)
  • apparition 08-04 22:16
    1

    说长不长,1 分钟就能完成

    说短不短,网络烂 30 几秒就会断

  • deepcake 08-04 22:19
    2

    还是这种magic-context无感压缩的方案好用

  • 音云 08-04 22:20
    3

    主动压缩,新开会话。8字焚决,送给佬友

  • TeainfrostOUO 08-04 22:20
    4

    到现在也不说353k什么时候恢复。最关键的是现在有人是353k,而我是258k,它居然也不是在服务器上限制的,花同样的钱用的还差

  • jiyujie 08-04 22:21
    5

    这是节点的问题,之前我也遇到过,自从换了之后从来没有发生过这种问题

  • 欣 郁 楼主 08-04 22:38
    6

    新开会话



    有的时候很难接受“新开会话”。


    我是会主动压缩,但就是难免忘了;而且上下文短,主动压缩的情况不在少数,就很烦躁。。。

  • 兰子p 08-05 09:34
    7

    可以自己改成353k的,他只是前端限制

  • lynn 08-29 22:22
    8

    梯子节点是哪个地区的 请问用的是哪家的呀

* 帖子来源Linux.do
返回