给还没买房买车的朋友一个小技巧，如果准备买房买车，就办一张新的手机卡，然后整个流程周期都用这个手机号码，当一切结束后，注销它。不然你就会被无止境的周期性的骚扰。为什么我知道这个小技巧，那当然是我买到了，别人买房后注销掉又被运营商投入市场的卡🥲

昨天因为我前天早上发挥低素质能力精确优雅地运用 6 个「操你妈」和 2 个「你妈死了」辱骂了几个对我阴阳怪气恶意抹黑者，导致被他们举报后因违反推特规定我的推特账号被封禁 12 个小时。所以有些事情没来得及过来补充。现在解封后特地来补充一下。 当时关于为啥相对激进地采用这种工作流，主要是因为我在一开始设计 Magpie 的时候，就是想把 Magpie 做为一个运行在用户本地的 Agent 基础设施，让它作为一个 bridge 去连接散落在用户本地电脑上的各式各样的 Agent 和越来越多难以维护的大模型订阅供应商，解决两者没打通导致每个人每个月手里浪费大量订阅的 Token 甚至因为供应商绑定导致无法切换 Agent 等等一系列问题。 但挑战也随之而来，因为我用过的 Agent 就那么几个，听说和订阅过的供应商也就那么几家，可是这个世界上的 Agent 和供应商都太多了，而且相互之间各种差异，每个人都有自己独特的偏好，更何况每个 Agent 都有自己千奇百怪独有的配置和设计，供应商自己也有千奇百怪的订阅花活儿，所以一旦把产品交付出去，那么我注定无法应对所有人的各式各样的 Agent 和供应商的支持需求，所以 Magpie 在早期它注定就应该是 UGC 的，也就是用户提需求我来帮其实现。所以我才自然而然地打造了这一套 Agent loop 工作流。 但是 Agent driven 的 UGC 也是有风险的，比如很多人在吐槽的 Magpie 看起来一直在堆砌功能在产品观上没有克制，以及因为要快速交付获得反馈导致发版过快让人觉得不靠谱，其实事情一直都在起变化，最近这一切都在极大地缓解，首先现在 Magpie 已经把 Provider 和 Agent 分别都插件化了，这个解耦导致以后相关它们的新的支持和修复都不需要动 Magpie 产品本身。其次，Magpie 下一步就是在保留最核心功能框架的基础上把所有的功能包括 UI 都插件化，让 Magpie 本身变得轻盈的同时不阻碍它做迭代和功能扩展。

同感，我之前可喜欢用那种极简框架了，不光不用 js 甚至 css 都不用，纯 HTML 语意实现效果，比如 ，不过，刚刚看了一眼，已经不再维护

终于更新点有意义的东西了，其实 codex 模型上下文限制一直支持自己在 codex 配置文件中改的，这个不重要，重要的是之前上下文超过272K输入token 的请求，整个请求的输入价格按 2倍算、输出价格按1.5倍算。现在，说取消收取长上下文（应该是仅 gpt-6.1 sol）的费用。之前为了省钱我上下文一到 272k，就自动压缩，而codex 的压缩又巨慢，每次压缩都 3、5 分钟，我一天压缩几十次，真是搞人心态。

汉字的信息密度真不是盖的，我个人觉得中文可能是最省 token 的语言了。等 magpie 国际用户变多，我高低要写个把用户消息自动翻译成中文再发给模型的 magpie 插件，一方面帮海外用户省 token，一方面更重要的是，给 A/ 投毒，让他不能再把中文当风控规则。 --《magpie 国际化下菜单栏的灾难表现有感》

再加一条,中国人在中国的工作时间，用中国最好用的那些模型，价格成本是，美国人在美国工作时间，用中国最好用的那些模型的几倍。可以，一身 debuff 的中国人。