• 欣_郁

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

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

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

    图片

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

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

    主楼
  • apparition

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

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

    #1
  • deepcake

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

    #2
  • 音云

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

    #3
  • TeainfrostOUO

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

    #4
  • jiyujie

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

    #5
  • 欣_郁

    新开会话

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

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

    #6
  • 兰子p

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

    #7
  • Lynn

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

    #8

发表回复

登录后回复