Claude Code 提高使用额度，背后是 Anthropic 与 SpaceX 的新算力合作

Thu, 07 May 2026 00:00:00 GMT

2026 年 5 月 6 日，Anthropic 宣布两件值得开发者关注的事：一是提高 Claude Code 的使用额度，二是与 SpaceX 达成新的算力合作。这不是一次单纯的「订阅福利更新」，而更像是 AI 编程工具进入基础设施竞争阶段后的直接结果。

如果你本来就是 Claude Code 的重度用户，这次变化会很直接。Anthropic 表示，从 2026 年 5 月 6 日起，Claude Code 在 Pro、Max、Team 和按席位计费的 Enterprise 方案上的 5 小时限额翻倍。同时，Pro 和 Max 账户在高峰时段的限额下调被取消。对于经常在关键时刻撞上额度墙的用户来说，这比模型参数升级更有体感。

更关键的是，这次额度提升并不是空口承诺，而是建立在新增算力之上。Anthropic 在官方公告中表示，已经与 SpaceX 签署协议，将使用其 Colossus 1 数据中心的全部算力容量。按照公告披露的数据，这意味着 Anthropic 将在一个月内获得超过 300 兆瓦的新容量，对应超过 22 万张 NVIDIA GPU。官方还明确提到，这部分新增容量会直接改善 Claude Pro 和 Claude Max 订阅用户的可用性。

这件事最有意思的地方，不只是「额度翻倍」，而是 Anthropic 正在把 Claude 的竞争，从模型能力推进到基础设施能力。过去大家讨论 AI 产品，更多看模型谁更聪明、谁写代码更稳、谁上下文更长。现在真正决定体验上限的，往往是算力能不能跟上。模型再强，如果高峰期一堆限制、频繁触顶，开发者的实际感受还是会打折。

从这个角度看，Anthropic 这次动作很明确：先拿到更多算力，再把资源转化成更宽松的产品额度，直接改善 Claude Code 的持续可用性。对用户来说，这意味着更长的连续开发时间、更少的中断，以及更稳定的重度使用体验。尤其是把 Claude Code 当成日常主力工具的独立开发者、创业团队和工程团队，这类变化通常比一次营销式功能发布更重要。

除了 Claude Code，这次公告还提到 Anthropic 同步提高了 Claude Opus 模型的 API rate limits。也就是说，提升不只发生在聊天或命令行工具层，而是扩展到了开发平台本身。对于把 Claude 接进内部工作流、自动化系统或者编码代理平台的团队来说，这意味着更大的吞吐空间，也意味着 Anthropic 在企业级使用场景上的野心更清晰了。

不过这里有一个细节需要说清楚。很多人在社交平台上传播这条消息时，会简单总结成「Claude Code 租了马斯克的 SpaceX 服务器」。这个说法不算完全错，但并不精确。更准确的说法是：Anthropic 宣布与 SpaceX 建立新的算力合作，并将使用 SpaceX 的 Colossus 1 数据中心容量，从而提高 Claude Code 和 Claude API 的使用上限。对于写博客或对外传播，最好采用这种更稳妥的表达，避免把产业合作写成过度戏剧化的标题党。

如果只看表面，这像是一条产品更新；但如果往深处看，它反映的是一个更大的行业趋势：顶级 AI 产品之间的竞争，已经不只是模型研究的竞争，而是训练、推理、供电、机房、芯片和全球部署能力的综合竞争。谁能稳定拿到足够多的算力，谁就更有机会把「更强的模型」真正兑现成「更好用的产品」。

对普通用户来说，这次更新的意义很简单：Claude Code 变得更能用了。对行业观察者来说，这次更新释放的信号更重要：未来 AI 工具的产品体验，会越来越直接地受到基础设施合作的影响。今天是额度翻倍，明天可能就是延迟下降、可用性提升，甚至新的高强度编程工作流成为默认配置。

Anthropic 这一步，至少说明了一件事：在 AI 编程工具这条赛道里，真正的战争已经不只发生在模型榜单上，也发生在数据中心里。

参考来源：

Anthropic News, "Higher usage limits for Claude and a compute deal with SpaceX", May 6, 2026: https://www.anthropic.com/news/higher-limits-spacex
Claude Help Center, "Models, usage, and limits in Claude Code": https://support.claude.com/en/articles/14552983-models-usage-and-limits-in-claude-code

Hello World：用 Multica 把这个博客「说」起来

Wed, 06 May 2026 00:00:00 GMT

这是 solfx.dev 的第一篇文章。它本身就是一个验收用例 —— 走通「写 Markdown → push → Cloudflare Pages 自动构建 → 上线」整条链路，顺便聊聊把它建起来的工具：Multica。

今天发生了什么

从早上到现在，这个博客是这样被「说」出来的：我在 Multica 里开了一个 issue，把方向写清楚 —— 「不想花服务器钱、要个能写中文的极简博客」。然后几个 agent 接过去拆任务、互相在评论里讨论、再各自动手：

调研主题，候选列了 Astro Paper / Cactus / Theme Pure / Fuwari 等，最后定 Astro Theme Pure；
建 GitHub 仓库 solfx/solfx-blog，跑通脚手架；
用 Cloudflare API 创 Pages 项目、绑域名 solfx.dev、自动签 HTTPS；
把站点信息从主题默认值替换成「SolfX 学习日志」；
最后写下你正在看的这篇文章。

我在中间做的事情很少 —— 主要是回答几个二选一的问题（公开还是私有？apex 还是子域？），其它的拆分、推进、互相对账都是 agent 之间在 issue 评论里完成的。

Multica 是什么

Multica 是一个开源的 多 agent 协作平台。它的定位不是「再做一个 Cursor」，而是一层 任务编排 + 协作上下文：

issue 是 agent 的工作单元。和人协作一样，把目标、依赖、验收标准写在 issue 里，agent 拉走任务、写代码、贴结果。
多个 agent 可以同时在线，分工协作（这次就是 No.1 CC 做规划、No.3 CCB 跑 Cloudflare）。它们通过 issue 评论互相 @mention 来协调。
Autopilot 把流程自动化。可以让 agent 按计划/触发条件自动跑（比如每天扫一次仓库、有新 issue 自动建子任务）。
Runtime 跑在你自己机器上。Mac 桌面 app 或者 CLI 都行，代码、API key 都不出本机。

简单一句：把日常那种「开 issue → 派活 → 等结果」的流程，原样搬给 AI agent 用。

这一套到底好在哪

我自己的体感：它把"使用 LLM 写代码"从一个对话变成了一个工作流。和 agent 单聊容易陷在长上下文里（你也累、它也容易跑偏），但只要把任务拆成 issue，每个 issue 自带验收标准、自带历史评论，agent 接手时上下文就是干净的，反复迭代代价很低。

而且它是开源的：github.com/multica-ai/multica ，自己跑、自己审、不放心可以读源码 —— 对独立开发者比较友好。

下一篇大概会写写今天踩到的几个具体坑（CF API token 权限、自定义域名 DNS、Astro Pure 主题中文化），算是给后来人留点记号。

—— 写于 solfx.dev 上线第 0 天

SolfX 学习日志

Claude Code 提高使用额度，背后是 Anthropic 与 SpaceX 的新算力合作

Hello World：用 Multica 把这个博客「说」起来

今天发生了什么

Multica 是什么

这一套到底好在哪