最新

我开发这个工具是因为我经常被 Claude Code 的账单吓到。一个我预计花费 2 美元的复杂重构任务，最终可能要花费 15 美元，而且事先根本无法预知。<p>Tarmac 会分析你的提示，并在 Claude Code 开始工作前给你一个费用范围。它使用在 3,000 个真实的 SWE-bench 任务上训练的保形预测，在 80% 的目标范围内达到了 81% 的准确率。<p>npm install -g tarmac-cost — 完全开源，本地运行，无追踪，无需账户。<p>非常欢迎大家针对估算准确性提供反馈——这是我目前最关注的改进方向。

嘿，HN， 我开发了一个名为 stockMRRket 的副业项目，你可以在这里用虚拟货币买卖真实独立创业公司的股票。 核心理念：价格源自真实的创业公司指标（主要是月经常性收入，即 MRR），因此它就像一个小型互联网创业公司市场。 它基于 trustMRR API 构建，这使得项目成为可能。感谢 Marc Lou 提供这些数据。

我创建了 remotedevelopers.com，因为我再也不想写简历了。 连接你的 GitHub → 它会抓取你的代码库、技能、活动 → 生成一个永远保持更新的个人作品集。 无需简历。无需求职信。只需展示你已交付的代码。你可以在时间轴中添加文章、帖子、视频和其他内容，让潜在雇主全面了解你的工作。 它支持 AEO/SEO，为每个个人资料生成 llm.txt 文件，并拥有一个 MCP，专门针对我们都知道正在做决定的 AI 招聘人员。 我很乐意收到反馈。

大家好！ 我构建了一个小工具，用于可视化 `docker pull` 的效率有多低，为搭建新的 Docker 注册表 + 传输做准备。一直以来，一个依赖项的更新在 Docker 中会牵连出许多其他更改，这让我很困扰。这在 Docker+机器人领域是个大问题。有了几十甚至几百个依赖项，没有一种“正确”的方式来组织这些层，而不会在单个依赖项更新时导致大量层失效——这还不包括编译后的代码、嵌入式机器学习权重等。更糟糕的是，许多机器人部署都处于糟糕的网络环境中，要么是因为身处偏远地区，要么是由于客户的各种问题。我曾经凌晨 4 点起床，为一名现场技术人员提供支持，他需要在 1Mbps 的连接上为 8 个机器人拉取 100MB 几乎未更改的 Docker 层。（而且我不认为只有机器人行业才会遇到这种情况——看看 ollama 的例子，那是一个痛苦的拉取过程） 如果 Docker 更智能，并且知道哪些文件已经在磁盘上怎么办？我在 `/var/lib/docker` 中有多少个 `python3.10` 的副本？ 同样，DockerHub 上又有多少个副本呢？ 一个能够在文件级别而不是仅在层级进行寻址和去重的注册表肯定更便宜。 这个工具： * 给定两个 Docker 镜像，一个是你已有的，一个是你正在拉取的，找出 `docker pull` 将使用多少数据，以及 _实际_ 需要拉取多少数据 * 显示在各种糟糕的网络环境下，你将节省多少时间的估算值 * 提供了许多示例，说明了更智能的拉取将有所帮助的情况，但这两个镜像名称是自由文本，可以随意在那里填写你自己的值并试用（一次一个，有一个工作队列来分析新的镜像对） 我希望它能实现但还没有设法在 UI 中实现的一件事是，可视化 _没有_ 更改但仍然被拉取的文件。 它完全是用 Claude Code 编写的，这对我来说是一种全新的体验。我根本不懂 nextjs，通常也不写前端。我可能可以用比 Claude 稍慢的速度编写后端，但前端会花我 4 倍的时间，而且不会这么漂亮。我想，知道我在后端想要什么对我有帮助。 我正在构建的注册表/传输/快照器（？）将允许在你的本地机器上以及在注册表中共享 Docker 层中的文件。这方面有一些先例，但仅限于客户端。eStargz 格式允许将文件系统的元数据和内容分开，同时仍然保持 OCI 兼容性——但它对内容进行延迟拉取，并且没有去重。我认为它很容易在成本（由于使用更少的存储空间和带宽……无处不在）和速度上与其他镜像提供商竞争。 如果你有兴趣，请联系我。

我构建这个工具是因为我之前在同一个代码库上同时运行 3-5 个 Claude Code 实例，并且在不断切换终端窗口之间感到筋疲力尽。我需要小心翼翼地确保各个 Agent 的工作不会重叠，防止上下文窗口退化，手动执行文档/记忆策略，并在不同会话之间重新解释决策。 Stoneforge 就是我想要的协调层。一个 Director Agent 将目标分解成任务。一个调度守护进程在可用时将任务分配给 Worker，每个任务都在其自己的 git 工作树中运行。Stewards 审查已完成的任务，并在一切通过检查后将它们合并到主分支中，否则，它们会将任务与审查意见一起移交给新的 Agent。当一个 Worker 达到其上下文限制时，它会提交、编写交接说明并退出，以便下一个 Worker 可以在同一个分支上接手，拥有一个全新的上下文窗口以及来自前一个 Agent 工作的重要说明。 一些可能对大家有意思的设计决策： * 完全基于事件溯源，拥有完整的审计日志。 * 支持将任务同步到 Github 或 Linear，并将文档同步到 Notion、Obsidian 或本地文件夹。也支持自定义提供程序。 * JSONL 作为事实来源，SQLite 作为一次性缓存。JSONL 差异、跨分支合并，并且在损坏后也能恢复。SQLite 为您提供 FTS5 和索引查询。SQLite .db 可以在几秒钟内在不同的设备上重建。 * 默认情况下没有审批门槛。如果五个 Agent 都需要确认每次文件写入，那么您将无法更快地推进工作。审查发生在合并 steward 层面。 * 使用工作树而不是容器。编码 Agent 的冲突面是 git 和文件系统，容器或远程实例是多余的。工作树在几毫秒内创建，共享 node\_modules 和构建缓存，并且不需要 Docker 或单独的服务器。 * 您可以在同一个代码库上同时运行多个 Claude Code / Codex 计划。 适用于 Claude Code、OpenAI Codex 和 OpenCode。Apache 2.0 协议。GitHub：[https://github.com/stoneforge-ai/stoneforge](https://github.com/stoneforge-ai/stoneforge) 欢迎讨论架构或任何权衡。