Lewis

今天开源了自己在写的 gitim runtime: 一个本地 multi-agents 桥接层，让人把自己已经养好的 agents 接入简易信道，和其他 agents 做无缝合作。 支持分布式，手机端，已接入 cc/codex/hermes/pi/opencode link: github.com/CiferaTeam/Git… 体验链接: gitim.io

今早 claude code 和 claude -p 都不能用了，日本 home ip 开了 TUN 都不行，但是 claude APP 却能用，太神奇了，有一样的吗?

@huoru_tarnish 其实我理解就是 runtime 换了个词啦

小红书没有什么人能够告诉我，能够翻译翻译什么叫 harness x上应该有？

@manateelazycat 是的 今年的个人时间花在公司鸡毛业务上成本太高，没准业务本身明年没了。哪怕今年我在家自己无薪学东西跟潮流，感觉也比上班划算。

很多人被大厂辞退，也有很多牛逼的大厂大牛主动离开大厂，转向早期的初创公司 因为他们相信大科技公司不再提供相同的工作保障，它们也不提供上行潜力，而错过下一个大事件的机会成本从未如此之高 因为，AI时代，创作成本足够低，市场会奖励那些真正有本事、有勇气、有远见的创业者！

@DylanGalois 赞，我也在做类似的东西自用，存储层和你不太一样。github.com/CiferaTeam/Git… 求互 star 互相学习

我自己平时用multi-agent的时候有几个特点： 1. 希望context信息都在本地自己掌控 2. 希望DIY热更新Workspace 3. 没有和其他人交流的需求 4. 喜欢channel和thread的交互方式 所以最近做了Lantor，基本能cover自己的工作开发需求，支持桌面和移动端，现在开源出来，欢迎来玩😊 github.com/chenzl25/lantor

发现在 gitim(或者 slock) 里用 claude -p sdk 的消耗速率比在 claude app 里快巨多，借用我的 deep code reader (github.com/CiferaTeam/dee…) 攒下的 claude code skill 一分钟问出核心原因： claude 交互模式每次都会在第一条消息拼上 date, git 等一些进程状态，并且在进程常驻的过程中不变，而 claude -p 每次都是新进程，即使 resume session，实际消息的 header 是变了的，导致每次都不命中缓存。 结合前几天 claude 官方禁用 claude -p 使用订阅流量，我现在感觉是因为这个坑太大了不好调整导致的。 细节回答如下： 为什么 claude -p + resume 消耗飞快？ ──────────────────────────────────── 根本原因： 是第一个消息，它的任何变化会彻底破坏前缀匹配 ──────────────────────────────────────────────────────────────────────── Anthropic 的 prompt caching 是前缀精确匹配。如果 messages[0] 变了，后面所有历史消息的 cache 全部失效。 在交互式模式（claude code / claude app）中： • getUserContext 和 getSystemContext 使用了 lodash-es/memoize • 同一进程内， 的内容永远不变 • 甚至为了防止午夜跨天破坏 cache，代码做了极端优化： // attachments.ts:1406-1411 "The date_change attachment is appended at the tail of the conversation, so the model learns the new date without mutating the cached prefix. messages[0] (from getUserContext → prependUserContext) intentionally keeps the stale date — clearing that cache would regenerate the prefix and turn the entire conversation into cache_creation on the next turn (~920K effective tokens per midnight crossing per overnight session)." 在 claude -p（print/headless 模式）+ resume 中： • 每次运行都是新进程，memoize cache 归零 • resume 只是从磁盘加载历史 messages，但 是重新生成的 • 只要以下任一条件变化，整个 message 前缀的 cache key 就不匹配： • currentDate 变了（ obvious ） • gitStatus 变了（哪怕改了一个文件） • git log 变了（新 commit） • CLAUDE.md 内容变了 结果是：虽然你 resume 了 session，但 API 层看到的第一个 message 是"新的"，导致所有历史对话的 KV cache 完全 miss，每一轮都按 full cache creation 计费。

@arknights60 没有啊

赌到了 😂

赌到了 😂

两天蹬完一半额度，就赌 @tibo 这周还重置，生死有命

@gujiliaorenyan 现阶段需要钻研总结技巧，但隐隐有感觉玩熟了的话摸不到上限，慢慢迭代

@arknights60 你用的过来吗

当前配置：codex 100u + claude code 100u + kimi 200/m 套餐 + 讯飞 glm5.1 200/m 套餐 + minimax 150/m 套餐 + deepseek pro 大概 5 块钱一天 + 免费薅的 opencode-ds-flash，15 个 agent，一个 pro 加一个 mini，月成本两千来块，agents 们跟打地鼠一样已经有点按不住了

今下午开始感觉 codex 又有点开始降智了，有同感的吗

@jiayuan_jy nbility

andrej-karpathy-skills 成为了 GitHub 历史前 50 的项目。 github.com/multica-ai/and…

@Timothy27486675 你作为第一个回我的黄推，我高低是支持一手

@arknights60 🎊 🌻 🌟 ͏ ​🤣🫶🫶

折腾了一段时间的 multi-agents 感想：从单一 agent 到多个 agents 我们得到了更多并行的效率，但人的精力还是容易无限拉扯，最后又返璞归真，由一个强 agent 管理。但该走的路还是要走一遍，如何组织 multi-agents 更加高效，如何做弹出型的任务流，人的精力容易在哪些细节里丢失等，都要做出一定心得，再回归单 agent 模式，但是此时的单 agent 已经掌握了一系列调度技能，和现在的 agent 不是一回事了。那么这中间的成果果实会被谁最终摘走，又不是技术问题了。 还是那句话，ai 时代学的够慢，就不用学了。

@Jia_builder hey, let's connect. building github.com/CiferaTeam/Git…. product url: gitim.io

Hi, I'm new to X. Trying to #connect with more people in tech/build in public 👋 Especially from: Web development Saas AI/ML Startups Freelancing Automation Tech in general what are you guys building right now?

@imwsl90 老子要拉黑你 你胡说 😭

一人公司 OPC ❌ 35+失业互联网人士 ✅

@zty0826 @RisingWaveLabs slock to the moon

Four years ago, as a founding engineer at @RisingWaveLabs, I wrote the first line of RisingWave code and clicked make-public on the repo. Four years later, I am building Slock, and I spun up a RisingWave Cloud instance for it. My agent teammates took RWC skill and migrated Slock's Activity hot paths to RisingWave materialized views. ~9x p95 across the board. Postgres-compatible syntax, millisecond-fresh incremental views, no state-cache consistency to hand-maintain — non-trivial for humans, and for agents. A prerequisite for opening Activity and Inbox to agents next. Happy something I helped build can empower me as a user. Hoping Slock does the same for yours.

折腾了一段时间的 multi-agents 感想：从单一 agent 到多个 agents 我们得到了更多并行的效率，但人的精力还是容易无限拉扯，最后又返璞归真，由一个强 agent 管理。但该走的路还是要走一遍，如何组织 multi-agents 更加高效，如何做弹出型的任务流，人的精力容易在哪些细节里丢失等，都要做出一定心得，再回归单 agent 模式，但是此时的单 agent 已经掌握了一系列调度技能，和现在的 agent 不是一回事了。那么这中间的成果果实会被谁最终摘走，又不是技术问题了。 还是那句话，ai 时代学的够慢，就不用学了。

多AI agents用久了你就会发现：频繁的上下文切换才是生产力瓶颈 所以是不是一个Agent就够了， 我有点怀疑。

@itshanrw @yashhq_22 nice work

@yashhq_22 Headless iOS Simulator manager/farm + host-side input injection for iOS 26 — taps, swipes, multi-finger gestures, and 60 fps streaming github.com/tddworks/bague…

solo founders, what are you building currently? drop your product below and pitch it.

@yashhq_22 building gitim.io (github.com/CiferaTeam/Git…). a opensource BYOK multi-agents coworking space, without any SAAS dependency and you can take the ownership of all your data. 1 minutes to setup. no register, no docker, local dict is enough. :)