11 个帖子 - 7 位参与者 阅读完整话题
部分佬友在使用codex时，有些公益站、中转站没有开放远端压缩模型，上下文一大就： Error running remote compact task: unexpected status 404 Not Found: Invalid URL (POST /v1/responses/compact), url: 这时候很多人可能会重新开一个窗口，确实能解决，但是老是重开窗口也不是个办法，分享一个避免此问题的方法： 把 ~/.codex/config.toml 里的： [model_providers.custom] name = "OpenAI" base_url = "https://你的-cc-switch/v1" wire_api = "responses" requires_openai_auth = true 改成： [model_providers.custom] name = "cc-switch" base_url = "https://你的-cc-switch/v1" wire_api = "responses" requires_openai_auth = true 另外你可以保留或设置较高的自动压缩阈值，减少自动 compact 触发： model_auto_compact_token_limit = 900000 [features] enable_request_compression = false remote_compaction_v2 = false 如何佬友们有更好的方法，也欢迎交流 1 个帖子 - 1 位参与者 阅读完整话题
1 个帖子 - 1 位参与者 阅读完整话题
问了下AI,说是MiMo Code的上下文压缩方式接近无损，佬友们觉得对代码生成的影响大不大？ 6 个帖子 - 3 位参与者 阅读完整话题
感恩 慕鸢 大佬的公益站，前几天用的非常丝滑。就是昨天出现了压缩上下文开始，就一直报错了。 大概就是这个错误。 我去到公益站后台，看到是报错： | 其他详情 | 上游没有返回计费信息，无法扣费（可能是上游超时） | |—:|:—| 不知道是不是就是这个原因，我看了下使用日志，没有调用“gpt-5.5-openai-compact”的记录，不知道是哪里没配置好，有大佬知道解决方法吗？ 最后再补充一句： 慕鸢是LD最帅的男人！ 14 个帖子 - 8 位参与者 阅读完整话题
如题，我这是我的 ~/.codex/config.toml 中的配置，但是在实际使用时，deepseek-v4-pro显示的上下文的窗口大小还是258k，是我的配置有问题吗，求各位大佬帮忙看下 model_provider = "cpa" model = "codex/deepseek-v4-pro" model_reasoning_effort = "xhigh" disable_response_storage = true preferred_auth_method = "apikey" model_context_window = 1000000 model_auto_compact_token_limit = 900000 web_search = "live" 4 个帖子 - 3 位参与者 阅读完整话题
从 请各位佬友来点评。准备在公司做一次技术分享，聊聊我的“上下文工程”实践 继续讨论： 最近花了很多精力在vibe coding上，我觉得人的注意力已经跟不上ai产生的爆炸上下文了。 第一个体感，用多了brainstorming和grill-me，就会发现人对需求的边界才是飘忽不定的。也正是因为人没精力在spec阶段就确定好所有细节，或者模型降智没有理清边界，才是导致aigc堆积成屎山的最大原因。 另一个体感就是superpowers这套TDD范式在vibe coding时代可能已经落伍了。ai可以很轻易绕过原有思路在错误方向上狂奔，最终一样实现绿灯。原话题里的大量property测试我觉得是正确的思路，不过也只是正解的一个子集，其实本质就是让ai进行对抗，找漏洞，最终把代码收敛成最佳状态。 有一个还没有精力去实施的想法。基于上述体感，最值得人花精力（也可以用大量token来逼近）去介入的地方，应该是spec制定和对抗方法。 前者是整个开发过程的权威锚点，目前很难被ai全自动接管，我能想到的也只有grill-me慢慢来了，可能后面模型智力提升后，更能抓住重点来减轻点精力消耗。 后者因为相同的spec在不同模型眼里，盲区大概率是不同的，所以可以引入多个专家模型，写代码的只根据spec写，写测试的只根据spec出反例，再辅以黑盒测试和property测试，把多个模型的分歧点暴露出来，作为修订spec的依据。这样的流程应该就能让spec和代码逐步收敛到真实需求。 手打的，不是AI润色，所以没有截图。 6 个帖子 - 6 位参与者 阅读完整话题
mimocode真的能比肩claude sonnet 4.6？是不是比的kiro反代的那种。 真的无限上下文的话，以后克劳德不配合mimo坐一桌 22 个帖子 - 19 位参与者 阅读完整话题
打磨了很久的文章，鉴于使用了ai润色，所以截图发出，各位佬友看看算不算得上干货，相较大众认知应该能先进一些吧。 4 个帖子 - 3 位参与者 阅读完整话题
如题，我的编辑器是idea，用的qoder cn插件，它可以自定义模型接入 deepseek，但是有上下文限制，最多 200k，用光了就得新开会话。一个问题，它分析完了，比如列出4步，第一步还没执行完，就耗光了。公司电脑，性能一般，codex装不了。我用idea也用习惯了。 5 个帖子 - 5 位参与者 阅读完整话题
Xiaomi MiMo正式发布并开源MiMo Code，一款运行在终端的探索性AI助手。模型与Agent协同优化，迈向自进化时代。 1.跨会话持久记忆+近乎无限上下文 2.独创Compose编排模式，先设计再编码 3.Dream记忆固化与自进化机制 4.支持语音输入与控制 同时，MiMo Code 内置限时免费的顶级多模态模型–MiMo V2.5，并支持接入DeepSeek等主流模型以及第三方Token Plan，满足不同开发者的需求。 无限上下文？这个真实吗？ 3 个帖子 - 3 位参与者 阅读完整话题
经常跑着跑着疑似没有自动压缩，而是上下文直接丢了 当前配置使用的是minimax 1 个帖子 - 1 位参与者 阅读完整话题
小米发布了MiMoCode， 无限上下文，可以白嫖mimo auto模型，有概率随机到 UltraSpeed 爽吃1000token/s。 https://mimo.xiaomi.com/zh/mimocode 1 个帖子 - 1 位参与者 阅读完整话题
https://mp.weixin.qq.com/s/WkMPz-eBK2Hz0ZTQEwtx6w
如何评价小米的"无限上下文"和"自进化系统" 1 个帖子 - 1 位参与者 阅读完整话题
6 个帖子 - 6 位参与者 阅读完整话题
2 个帖子 - 2 位参与者 阅读完整话题
佬们，每次使用any的5.5在上下文要满的时候，不管自己手动压缩还是自动压缩都会报错，是因为any没有配置compact模型的原因吗 3 个帖子 - 3 位参与者 阅读完整话题
如题。想起来之前看到Any大善人用的账号级别很高，是不是有1M的上下文窗口？ 5 个帖子 - 4 位参与者 阅读完整话题
Codex跑了3小时吧大概，突然这样了，关键我的主要内容还没总结出来，现在发消息一直这样，新开窗口正常工作，第一次遇到这种情况，该怎么解决 2 个帖子 - 2 位参与者 阅读完整话题