如何在 Anthropic 断供时估算你的 Claude 配额

我正在构建 Tokamak,一个监控 Claude Max 配额的 macOS 菜单栏应用。几周前,Anthropic 在他们的服务条款中发布了这样的条文: “您不得使用 OAuth 或类似的授权机制来允许第三方应用程序代表用户访问 Claude。” 而我,正在使用浏览器 cookies 调用一个未公开的端点来读取 Claude Max 配额,盯着屏幕想:“现在怎么办?” 今天的工作方式(有用的权宜之计) Tokamak 需要知道你的配额百分比。就是当你在 claude.ai 上用了一段时间后看到的那个 42%。问题是Anthropic 没有公开的配额 API。没有一个带 API key 的文档化的 GET /api/quota。 但确实存在一个 claude.ai 网站自己使用的内部端点: GET /api/organizations/{org_id}/usage 返回类似这样的内容: 1 2 3 4 { "five_hour": { "utilization": 42, "resets_at": "2026-02-22T18:00:00Z" }, "seven_day": { "utilization": 19, "resets_at": "2026-02-28T14:59:59Z" } } 要调用这个端点,你需要已登录用户的会话 cookies。Tokamak 用一个隐藏的 WKWebView 解决这个问题:用户在应用内的 claude.ai 中登录,cookies 保留在 WebView 中,应用每 30 秒使用这些 cookies 进行轮询。 ...

2026年2月22日 · Fernando

macOS公证:苹果为你的应用设置的夜店门卫

凌晨两点。你的应用编译通过。签名完成。打包成DMG。执行notarytool submit。苹果说"In Progress"。你等了5分钟。10分钟。20分钟。一个小时。两个小时。提交仍然是"In Progress"。你睡觉去了。第二天早上:Invalid。 除了"The signature of the binary is invalid"之外没有更多解释。对两种架构都是如此。谢谢苹果。非常有用。 公证是那种完美运行的流程…直到它不工作为止。当它失败时,会给你留下一个Gatekeeper不会打开的.dmg文件和一个什么都不告诉你的错误。在为Tokamak(我的用于监控Claude配额的菜单栏应用)与此斗争几天后,我决定记录所学到的一切并编写一个检查器以避免再次经历这种痛苦。 什么是公证(简单来说) 想象Mac App Store是一个有保安的购物中心。但你不想在购物中心销售——你想直接分发你的应用,用你自己的DMG。就像街边摊位。 苹果说:“好的,你可以。但首先要通过门卫。” 那个门卫就是公证。这是苹果的一个自动化服务,扫描你的已签名应用,验证它不包含已知的恶意软件,如果一切正常,就给你一个票据。你把这个票据钉在你的DMG上(stapler staple),从那时起,当用户下载并尝试打开它时,Gatekeeper看到票据就说"请进"。 没有那个票据,用户会看到这个: “Tokamak.app"无法打开,因为苹果无法检查它是否不含恶意软件。 你的应用就被丢在路边了。 苹果为什么这样做 有两个原因。一个是合理的。另一个…嗯。 合理的原因:保护用户。在公证之前(2019年在macOS 10.14.5中引入),任何人都可以用Developer ID分发已签名的.app,macOS会毫无怨言地打开它。代码签名验证开发者的身份,但不扫描内容。如果你的已签名应用包含键盘记录器,签名完整的情况下也会执行。 公证增加了一层:苹果在到达用户之前扫描二进制文件寻找已知的恶意软件和可疑行为。这不是像App Store那样的人工审查——这是一个自动化系统。但至少是个保障。 另一个原因:控制。苹果希望你通过App Store Connect处理所有事情。使用Developer ID的直接分发一直是二等公民。公证是在"你可以在App Store之外分发,但我们会让你感到不便"这条道路上的又一步。 话虽如此,从macOS 10.15开始,对于所有在App Store之外分发的应用,公证是强制性的。这不是可选的。你的应用要么经过公证,要么不会打开。没有商量余地。 会让你浪费数小时的7个错误 在收集了自己的错误和开发者论坛的错误后,这些是最痛苦的: 1. 缺少--timestamp 这是经典错误。你的codesign在本地完美工作,Gatekeeper不抱怨,但公证返回"The signature of the binary is invalid.” 1 2 3 4 5 # 错误 — 本地签名有效,苹果拒绝 codesign --force --options runtime --sign "Developer ID Application: ..." MiApp.app # 正确 — 使用苹果服务器的时间戳 codesign --force --options runtime --timestamp --sign "Developer ID Application: ..." MiApp.app 安全时间戳证明签名是在证书有效期内完成的。没有它,苹果不会信任。就像签署没有日期的合同——技术上有效,但没人会接受。 ...

2026年2月22日 · Fernando

一行命令创建 macOS 虚拟机

我正在构建一个 macOS 的菜单栏应用程序。在我的 Mac 上运行完美。现在我需要知道它是否能在干净的 macOS 环境中正常工作:没有我的配置、没有我的权限、没有我的数据。一个全新安装的用户环境。 如何测试这种情况?你需要一个虚拟机。 “简单”,我想。“我安装了 UTM。打开向导,创建一个 macOS 虚拟机,然后运行。” 事情并没有那么简单。 UTM:漂亮但难以驯服 UTM 是一个很棒的应用程序。精心设计的界面,支持在 Apple Silicon 上运行 macOS 客户机,全屏显示,共享剪贴板。手动使用确实很棒。 当你试图自动化时问题就出现了。 UTM 有一个叫做 utmctl 的命令行界面。可以列出虚拟机、启动它们、停止它们、克隆它们。它不能做的是创建虚拟机。对于 macOS 客户机,甚至 UTM 的 AppleScript 也不允许创建它们——操作系统字段被硬编码为 Linux。 简单来说:如果你想在 UTM 中创建 macOS 虚拟机,你必须通过向导手动创建。每次都是。需要点击、下载 IPSW(Apple Silicon 的 macOS 安装映像——相当于传统的 ISO,但由 Apple 打包)、等待安装。 对于需要在质量保证流程中频繁创建和销毁虚拟机的开发者来说,这真是个麻烦事。 Tart:为开发者设计的 macOS 虚拟机 Tart 是当有人在设计虚拟化工具时考虑开发者而不是最终用户的结果。 它使用与 UTM 完全相同的 Apple Virtualization.framework。相同的技术,相同的功能,相同的原生速度。区别在于界面:Tart 是命令行优先的。 1 brew install cirruslabs/cli/tart 就这样。没有图形界面配置,没有向导。只是在你的 PATH 中的一个二进制文件。 一个命令统治一切 创建一个使用最新可用版本的 macOS 虚拟机: ...

2026年2月21日 · Fernando

Apple 给我安装了84GB的水母视频。还是重复的。

Kimi K2 只能等等了 昨天想下载Moonshot的最新模型Kimi K2 Instruct。这个模型看起来很有前景,我已经想测试好几天了。 准备清理空间,看了下磁盘,发现了这个: 磁盘: 927GB 已使用: 644GB 空余: 283GB 嗯。283GB空余空间还不错,但是到底什么东西占用了644GB?我的Mac一直保持得很干净,不在本地存储电影,几乎所有东西都放在云端。 开始调查。然后我想起来了。 45GB的水母视频 我已经知道Apple在其无穷的智慧中,决定在macOS Sonoma中包含45GB的动态壁纸。4K 240fps的水母漂浮、海浪翻滚、北极光和各种风景视频。 我没有要求。我不想要。但它们就在那里。 我不知道的是接下来发生的事情。 反转:它们是重复的 结果macOS在两个不同的位置存储这些视频: 1 2 3 4 5 6 7 # 副本1:系统 /Library/Application Support/com.apple.idleassetsd/Customer/4KSDR240FPS/ → 42GB # 副本2:用户 ~/Library/Application Support/com.apple.wallpaper/aerials/videos/ → 42GB 八十四GB。相同的视频。重复的。 因为显然Apple认为拥有一个系统副本(root拥有)和一个用户副本(fernando拥有)是个好主意。相同的89个.mov文件。相同的UUID。相同的内容。 它们不是硬链接,是真实副本 我想:“好吧,也许是硬链接或APFS克隆。相同文件,相同磁盘空间,一切都好”。 结果不是。 1 2 3 4 5 6 # 不同的inode = 真实副本 ls -i "/.../4KSDR240FPS/009BA758...mov" → 15543749 ls -i "~/.../aerials/videos/009BA758...mov" → 108602438 副本。真实的。八十四GB的水母占用我SSD的真实空间。 ...

2026年1月29日 · Fernando

聊天机器人占用10GB虚拟机:Claude在你Mac上到底在干什么

10GB的意外发现 你在Mac上安装了Claude Desktop。一切正常,应用程序看起来很小。但有一天你查看磁盘空间,发现了这个: ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle 10.8 GB。 什么?一个聊天机器人要占用十个G?这里面装的什么,《指环王》三部曲加长版? 不是。装的是Ubuntu。 Claude产品三巨头 在解释"是什么"之前,让我先解释"为什么"。Anthropic有三种方式让你访问Claude: 产品 运行位置 目标用户 claude.ai Anthropic服务器 所有人 Claude Desktop + Cowork 你Mac上的虚拟机 专业人士 Claude Code 直接在你的系统上 开发者 网页版是安全选择:一切都在Anthropic的云端进行,不会接触你的机器。但如果你想让Claude在你的电脑上做真正的事情——创建文档、执行代码、移动文件——你需要其他解决方案。 这就是Cowork和Claude Code的用武之地,两种完全不同的哲学。 Cowork:普通人的Claude Code Cowork是Anthropic在2026年1月12日发布的智能体名称。它的官方标语是: “Claude Code for the rest of your work”(为你其他工作准备的Claude Code) 虽然Claude Code是为生活在终端里的开发者设计的,但Cowork是为你不编程时设计的。想要整理合同的律师。需要从50个PDF中提取数据的分析师。想要把笔记转换成演示文稿的教师。 它能做什么 你授予它访问Mac上某个文件夹的权限 Claude在该文件夹内读取、编辑和创建文件 可以创建Office文档(Word、Excel、PowerPoint),无需你安装任何软件 如果需要,可以执行Python或JavaScript代码 可以并行启动多个"子智能体"处理繁重任务 实际例子 “嘿Claude,我在这个文件夹里有30张收据截图。给我做一个包含每张收据日期、概念和金额的电子表格。” Claude就会去做。读取图像,用OCR提取数据,创建Excel文件,然后放在那里给你。 有趣的事实 Cowork几乎完全由Claude Code在1.5周内构建完成。Claude在编写下一代Claude产品。《盗梦空间》但是少了迪卡普里奥多了tokens。 虚拟机:安全技巧 这就是精妙之处。当Cowork执行代码或操作文件时,它不是直接在你的Mac上做的。而是在一个完全隔离的Ubuntu虚拟机内完成。 为什么?因为让AI在你的系统上执行任意代码就像把你家钥匙给一个很聪明的陌生人。他们可能值得信任,但最好不要让他们接触刀具抽屉。 这10GB里有什么 组件 大小 用途 Ubuntu 24.04 ~3 GB 操作系统 Chromium + Playwright ~920 MB 用于爬虫和网页自动化 LibreOffice ~148 MB 创建Office文档 Node.js, Python, Java ~600 MB 执行代码 CJK字体 ~305 MB 中文/日文/韩文支持 Pandoc, LaTeX ~450 MB 文档转换 用通俗的话说:这是一个装在安全盒子里的完整办公环境。 ...

2026年1月25日 · Fernando