lifcc (@mylifcc)

做一个下dsh和pi的对比 Pi 的目标是“最小核心 + 用户自己拼”，DSH 的目标是“几乎所有能力都插件化，官方先给你几套完整组合”。 DSH 的骨架是Cordis。 Cordis 不是普通插件加载器，它强调两件事： 1. 可逆副作用（temporal composability）：插件卸载时，注册的服务、事件、工具 schema、prompt section 全部自动撤销。 2. 依赖声明与空间组合（spatial composability）：插件通过 `inject` 声明需要什么服务，运行时按依赖挂载。 所以在 DSH 里： - 模型适配器是插件 - 工具注册表是插件 - session log 是插件 - agent loop 本身也是插件 - 甚至 UI 也是插件 没有“神圣不可动的核心”。你想换 loop、换工具策略、换上下文压缩，挂一个新插件 + 改配置就行。 启动时是 Profile + Bundle叠出来的： 空根 → dsh-base（模型、工具、沙箱、凭证…） → dsh-web-app 或 dsh-headless → 用户自己的 cordis.patch.yml → 命令行 --patch `dsh --profile web --dump-config` 能直接把当前实际挂载的树打出来。 Session 设计是硬核部分 Session 是 append-only 的事件流 模型最终看到的上下文，必须能从这条 log 完整重建出来。官方写得很死： > Model-visible means logged. 任何会进模型请求的内容，都要先变成 session event。 所以 fork、resume、回放、UI 渲染、telemetry，全部从同一条流投影。这点比大多数 coding agent 做得更彻底。 Turn / Step 有claudecode的影子，流程如下： turn/start → claim input → agent/pre-step（可拦截、可改写） → step/start → llm/stream → tool/call → tools/pre-execute → execute → post-execute → step/end → 继续 or turn/end `agent/pre-step`、`tools/*` 这些是 waterfall，监听者必须显式 `next()` 才能往下传。扩展点设计得很规整。 Pi 的实际交集 DSH 仓库里有一个包： `@deepseek-ai/dsh-llm-pi-ai` 它就是把 pi-ai当成 LLM 适配器的后端。 多 provider、协议兼容、reasoning effort 映射、catalog 覆盖，都走 pi-ai 的能力，再包一层 Cordis 插件契约。 所以： - LLM 调用层：吃了 Pi 的基础设施 - Agent 编排、工具、session、UI、沙箱：完全自己的 Cordis 体系 “LLM 适配层直接用了 pi-ai，上层重做了一套更重的可组合 Runtime”。 模式上的对应 DSH 的 Minimal 模式才最接近 Pi 的默认体验：只留 shell + 文件编辑器，专门给 benchmark 用。 官方之前在 V4 的 agent 评测里就用过这个模式。 Standard 模式和 Code（PTC）模式则是完整工具集 + 程序化工具编排，已经远超 Pi 默认的 4 工具。 如果你喜欢 Pi 那种“核心极瘦、自己动手加东西”的感觉，DSH 会显得重，配置和概念也更多。 如果你要的是可替换的 agent loop、完整事件回放、多模式预设、以及官方已经搭好的 Web 界面，DSH 的插件树和 seam 设计更系统。 一句话： Pi 是极简可扩展的 coding harness；DSH 是基于 Cordis 的完整 Agent Runtime，LLM 层复用了 pi-ai，但整体不是同一套代码。

Given some of the results I'm seeing recently, it's pretty clear Codex is a good harness. But it will seem primitive in 2-3 months and we're about to go through another major evolution in how we use AI at the frontier. The next generation of models need more than your laptop.

Kimi and GLM are some of the best open models available. They're also some of the hardest to serve efficiently. Check out this writeup to learn how we're making them faster and cheaper without losing accuracy.

On file deletions. We’ve investigated a handful of reports where GPT-5.6 unexpectedly deleted files. What we have found is that this most commonly occurs when: - Full access mode is enabled and codex is run without sandboxing protections, including without auto review being enabled - The model attempts to override the $HOME env var to define a temporary directory. - The model makes an honest mistake and mistakenly deletes $HOME instead. This is of course not how we want the system to behave, even when a user operates the model in full-access mode without the safeguards of our sandbox or without using auto review which checks for these kinds of high risk actions and rejects them. We are taking steps to mitigate this risk including by updating the developer message, guiding more users towards safer permission modes, and adding additional harness safeguards. Even though this happens extremely rarely, we’ll share a detailed post-mortem in the coming days that goes into more details and what we are doing to minimize risks further.

we distilled 2.3M Claude Fable 5 reasoning traces into Qwen3-4B - 100% self-consistency @ 512 samples - 0.00 bits output entropy - zero hallucination variance turns out the student is not bounded by the teacher. it also converged on one universal truth. we open-sourced the model weights👇

GLM-5.2 can now be run locally!🔥 The 2-bit model retains ~82% accuracy after we shrunk it from 1.51TB to 238GB (-84% size). Run on a 256GB Mac or RAM/VRAM setups. GLM-5.2 is the strongest open model to date. Guide: GGUF:

Stellar performance from a 3B model. These results were achieved primarily through post-training refinements on Qwen2.5-Coder. The paper doesn't provide many details, but it appears they distill from RL ckpts and then do a final RL-based instruct RL. 🔗