大家有没有遇到过这个问题，就是最近Codex总是...

[Bunsei]

@kos-or 对的，明显能感觉到，要是再这个样子，我可能考虑换成降低订阅挡位，其他的就用GLM凑合一下

[Bunsei]

@Tzung-Ru-Tsai 再保守也不能一直修改目标，然后为了完成任务而完成任务....

[Bunsei]

@hanber121 奥特曼你坏事做尽！

[Magic629]

最近使用Codex接入本地部署的模型使用也会出现这样的问题，感觉是Codex本身软件问题？执行程序时候也是拖拖拉拉的不如以前丝滑了。DSH和Hermes使用确很正常。

[Tzung-Ru Tsai]

@Bunsei
這邊到後來是以Web + codex的方式來跑，在Web討價還價完再塞給codex要它照著做，
優點是可以調整的幅度比較大(防呆意味)，缺點就上面版友提過的要人肉搬運兩邊的產出，交叉填入+調整

[懒人烘培]

还觉还行，只有是时候会抽风~

[Xiaote]

本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励！

奖励凭证：热议 +3 分 · 编号 h2947-1217-1

[kos or]

@bunsei

如果是因為算力有限 資源分配要最佳獲利化,
可能是在進行客戶 結構調整, 讓低價值客戶主動離開 增加高價值客戶 $100, $200, $500 的黏著度

[Bunsei]

@kos-or 也有可能，通过这种方式降低长程任务的可靠性，显著降低token开销，然后用一个月最后还剩不少额度，显得订阅很“耐用”。

[Bunsei]

@Tzung-Ru-Tsai 这说实话相当于是一种“倒退”，一年前AI就是这样用的，讨论->AI实现功能模块->复制回项目，测试->继续沟通讨论。

[Bunsei]

@Magic629 目前看也有可能，正好订阅送的一些API额度我接到Hermess试试看。