Anthropic 如何用 Claude 造 Claude：把大脑和手分开
How Anthropic ships Claude with Claude: Separating the Brain from the Hands
Latent Space 播客对话 Anthropic 工程负责人 Katelyn Lesse 与产品负责人 Angela Jiang，讨论 Opus 5.5 的发布流程与 Claude Managed Agents 架构。
译文尚不完整，完整内容请切换到原文。
正如我们从昨天 Anthropic 的 S-1 文件中了解到的，这家实验室拥有人类历史上最高的营收和研究效率之一，尤其是过去一年从 -126% 亏损扭转为 19% 的 GAAP 利润。公司将这归功于他们的两个核心循环：改进与投资：
今天我们深入探讨 Anthropic 是如何运作的。如今Opus 5.5 的尘埃已经落定，它已作为全球公认的第一大 LLM 持续了一个月，我们深入探讨它的发布，以及 Anthropic 如何用 Claude 打造 Claude——对话工程负责人 Katelyn Lesse 和产品负责人 Angela Jiang。
团队正承受着两种压力。模型能力越来越强，这让安全部署和访问决策变得更加困难。与此同时，使用量增长得足够快，以至于普通的基础设施选择——比如一个 API 消耗多少 CPU——都变得具有战略意义。这些问题在触达开发者的产品选择中交汇。
模型发布同时也是 API 发布
Anthropic 的Opus 5.5 发布同时强调模型质量和成本。我们讨论了关于前几代 Opus 过于冗长的反馈，以及对每美元更强智能的需求。Anthropic 表示新模型的运行成本低于前代；具体节省取决于工作负载及其对缓存上下文的使用。
不太为人所知的发布工作涉及改变人们集成 API 的方式。我们讨论的一个例子是保护模型推理不被用于蒸馏的提取。跨轮次保留思考块有助于解决这个问题，但新的要求也可能破坏客户现有的 harness。
Katelyn 还描述了参与早期访问计划在实践中究竟是什么样子：客户在他们自己的 harness 中运行评估，报告令人意外的行为，有时还会传达不太正式的感受。有用的部分不仅仅是基准分数：而是在 Anthropic 自家产品未覆盖的环境和任务中看到模型的表现。正如我们在播客上连续 4 年所说的，拥有好的评估是无价之宝。
大脑与双手
我们在本集中最喜欢的心智模型是智能体的大脑与双手之间的区分。在托管智能体中，Anthropic 将会话日志和 harness 与执行代码的沙箱分开。harness 可以持久存在，而执行环境在需要时创建；一个失败的沙箱不必拖垮整个智能体会话。
我们在Thariq 那期播客中讨论过这一点：
Claude Code 的下一个时代——Thariq Shihipar，Anthropic——Latent Space
发布 Opus/Sonnet 5.5、Mods、Plugins、Projects、Tag，同时把握前沿节奏
同样的分离为安全提供了一个有用的架构特性。如果生成的代码在一个永远接收不到服务凭据的沙箱中运行，那么该沙箱中就没有代码可读取的凭据。本集描述了凭据被单独保存并通过代理附加，同时对沙箱流量可以流向何处进行控制。Anthropic 的隔离说明描述了其产品中使用的更广泛的隔离和网络控制。
这种区分对性能也很重要。嘉宾们表示，早期的方法是把整个编码智能体放在 API 后面的沙箱里。启动环境和智能体会在首次响应之前增加工作量；如果沙箱消失，运行中的智能体也会消失。将各部分分离后，平台可以在保持执行隔离的同时追求更低的延迟和更好的可靠性。
对于任何设计智能体运行时的人来说，这是一个有用的视角。问问哪些部分需要持久存在，哪些部分执行不受信任的工作，以及哪些密钥真正需要出现在代码运行的地方。不同产品的实现会有所不同，但这些问题仍然有用。
一个帮助另一个智能体记忆的智能体
Managed Agents 还为记忆和多智能体工作流的实验提供了基础。Dreaming 的实现很简单，就是让一个智能体检查另一个智能体先前的工作并把记忆写回去。这使得该功能成为用同一套底层托管智能体原语构建更高层行为的示例。
他们对路线图的描述比一份功能清单更为细致。记忆和学习仍然重要，但团队表示，随着模型发布变得越来越困难，他们更多的即时注意力已转向安全。他们还讨论了保持基础 harness 相对简单，同时让开发者在上面试验验证器、并行智能体和其他策略。提到的未来平台能力构想应被视为计划，而非已交付的承诺。
关于评估的对话自然随之而来。harness 是一个应用，但改进它开始变得像研究：选定目标、衡量行为、检查失败并迭代。嘉宾和主持人讨论了使用模型来帮助构建和分析评估，同时保留足够的判断力来决定评估是否反映了真实用户的工作。
节目笔记
Claude Opus 5.5 发布公告 — Anthropic 关于模型行为、评估和定价的发布说明。
Katelyn Lesse 和 Angela Jiang 在 Anthropic 合作伙伴峰会 — Anthropic 确认了她们的平台工程和产品职位。
扩展 Managed Agents：将大脑与双手解耦 — 本期节目讨论的会话、harness 和沙箱架构。
Anthropic 如何在各产品中约束 Claude — Anthropic 如何描述其各产品中的隔离、凭据和网络控制。
面向长时间运行智能体的有效 harness — Anthropic 早期关于在上下文窗口之间保持进展这一挑战的工作。
Anthropic 模型系统卡 — 该公司公开的模型评估和安全文档。
Anthropic S-1 解析 — 新录制的介绍背后的数字和背景。
时间戳
0:00 Anthropic 的 S-1 与本次访谈
1:06 人均收入和效率
3:13 改进循环与投资循环
4:04 Claude Platform 为何重要
6:25 训练事故和生产保障措施
7:30 Opus 5.5 发布与定价
9:25 蒸馏与保留思考
14:35 Anthropic 的产品与工程
18:05 扩展 Claude Platform
19:25 模型访问与安全决策
26:25 信任授权与产品路线图
30:25 Anthropic 如何发布模型
35:55 基准测试与模型个性化
42:10 Claude Managed Agents
44:25 记忆、dreaming 与 agent harness
48:25 评估 agent
53:25 CPU 限制与扩展
56:05 用 Rust 重建 Messages API
1:03:25 大脑与双手
1:05:25 保护凭证与沙箱
1:08:25 训练事故与生产环境
1:10:55 前沿模型的节奏与发布
1:12:25 安全分类器与模型路由
1:19:25 新兴的 agent 工作负载
1:20:55 对抗 AI 垃圾内容
1:27:25 管理、写作与工作风格
1:33:25 组建 Anthropic 的 DevRel 团队
1:40:25 开发者关系与产品声音
1:43:25 用 Opus 5.5 可以尝试什么
文字稿
自动转录草稿。人名与措辞可能需要更正；尚未分配发言人身份。
0:00 大家好，今天我们尝试一些新东西。我们正在启动对 Anthropic IPO 的报道。他们今天刚刚提交了 S1。因此我们将发布一系列播客，为 IPO 预热，预计 IPO 将在两周后进行，估值 2 万亿美元。它是有史以来增长最快的公司之一，据报道其累计现金融资额超过 1000 亿美元，而累计消耗不到 100 亿美元。所以这里面有很多效率故事值得深入探讨，我认为这是我们想要报道的内容：Anthropic 如何在交付世界上最强的模型的同时，又做得非常非常高效，并建立起令人难以置信的业务。所以我提取了，你们知道，如果你们一直在听这个播客，就知道我以前做过金融分析师。
0:50 我从 S1 中提取了一些陈述，我觉得它们能为今天的播客提供有趣的背景。我们只是把这当作一个新尝试，因为我觉得你们中有些人想要那种与我们直接面对镜头交流的个人关系，而不是我们过去四年一直在做的与嘉宾对话。所以我想强调的第一件事是，按人数计算，Anthropic 是一家极其高效的公司，这也许很明显，因为它是 AI 公司，显然他们非常善于使用 AI，但我认为他们过去一年作为一家公司所发生的变化程度并未被充分理解。所以现在每名员工的 12 个月收入是
1:32 660 万美元。相比一年前的 140 万美元。所以他们的每员工收入几乎增长了五倍。我认为这是我们需要更深入探讨的事情，因为我认为任何企业主、任何工程师，都想提高每员工收入，不仅是为了提高盈利能力，也是为了增加你能支付给员工的薪酬。这显然伴随着每美元算力所带来收入的大幅增长。值得注意的是，基本上在 2025 年第二季度，Anthropic 基本上每 1 美元收入要亏损 0.5 美元。而现在每 1 美元成本能带来 2 美元收入。我认为这是一个有趣的类比，说明过去一年 Anthropic 的收入和业务前景发生了多么巨大的拐点。
2:27 今年对 Anthropic 来说执行到位极其关键，而它做到了。我认为我们基本上会进一步深入这一点，并尽可能从播客的外部视角讲述这个故事。嗯，这整个增长的一个后果是，Anthropic 刚刚公布了其首个盈利季度——不是调整后利润，而是扣除所有成本之后的利润，不，这是公认会计原则下的 GAAP 利润，为 19，这又是巨大的，与一年前相比完全翻转，不只是翻转，就像一
3:03 年前，它每收入一美元就亏损 129%。所以我认为，解释这种非凡效率的主要归因是。如你所知，Claude 喜欢循环，Boris 喜欢循环，Dario 喜欢循环，而 Anthropic 内部有两个循环在运转。第一个是改进循环。基本上，就是这样一个周期：你有 Claude，Claude 带来更好的模型，更好的模型带来更多用例。更多用例产生更多反馈，进而带来更好的 Claude。然后还有投资循环。所以，采用范围扩大带来的收入带来更高增长。更高增长带来更多投资，更多投资带来更多能力。
3:45 这带来更好的 Claude。因此，这两个循环基本上一起旋转，形成一个无限循环，根据 Adoptic S1 的说法，这个循环将推动效率提升直到时间尽头。所以我认为，这就是我们从整体效率故事过渡到他们如何执行的方式。今天我们将大量聚焦 Claude Platform，因为这主要是他们在 Anthropic S1 中所称的 Claude 扩散的三件事之一。所以，他们把这个 Claude Platform 称为我们全面的智能体开发环境。他们为客户提供对其原语的直接访问，以便构建、部署、扩展自己的应用，这些应用可在自己的产品和工作流中利用 Claude 的能力。
4:30 我认为在这个播客的讨论中经常出现的一个概念是 ad fooding，即 Claude 的许多产品实际上是用同样对你开放的 Claude Platform 构建的。所以 Claude Platform 中披露的另一件有趣的事是，超过 50% 的客户（按交易电话口径计算，收入在 10 万美元或以上）使用 Claude Platform。因此，这表明采用率在上升，也表明 Anthropic 不仅作为模型实验室，还作为超大规模云服务商和 Claude Platform 正在崛起，我认为这也许就体现在 Claude Platform 这个名字本身之中，但它正在从理论走向实际实践。
5:15 这也是我们在播客中重点关注的内容。我还想强调的另一件事，之前也提到过，就是 Claude Code、cloud co-work。它们都使用 Claude Platform 暴露的相同原语。所以我觉得这非常有意思。最终来看，Anthropic 似乎正在为其 IPO 定位，讲述从聊天机器人到副驾驶再到虚拟协作者的故事。他们用这个词而不是 agent。也许这样更友好。但这与你对 agent 的许多期待是一样的，从长时间运行的自主工作到判断力、自我纠正、迭代以及工具访问。所以是拥有一个目标并与你并肩工作，而不是在一个应用或任务内工作。这就是我想为今天播客提供的最终背景。
6:00 这是在 Opus 5.5 发布时录制的，我想说，在我们交谈过的所有高品味测试者中，压倒性地认为 Opus 5.5 是目前世界上最好的模型。而 Anthropic 甚至还在压着 Fable 5.5，可能会在未来两周内发布。我不需要有内部消息，但这对 IPO 来说非常合理。所以让我们期待那一点，并更多地了解他们是如何构建 Opus 5.5 的。
6:25 是的，所以我想做的一个区分是，在人们听说和读到的许多事件中，这些事件发生在模型身上，而不只是所有人的模型，对吧，那些正在训练中的模型，你运行这些模型的方式是把它们放进一个盒子里，然后说解决不可能的任务。我要给你压力。预备，开始。
6:45 对。你只能在你所处的环境内做你能做的事。而 agent 基本上被激励去试图逃出它的盒子去解决问题。当人们在我们或任何其他人的 API 上运行生产工作负载时，你运行的环境中有保护措施在运行，这些不一定在训练中运行，训练的全部意义就是真正训练模型。对。但在生产工作负载中，首先，你有那些在线保护措施，这真的很棒。其次，你有更多围绕正在发生的事情的架构和基础设施。就像 agent 不只是在一个盒子里试图逃出来。对。就像 harness 在这边，手在那边。这甚至不是你需要考虑的问题。
7:30 好了，我们在 Opus 5.5 发布后的第二天在演播室，和 Katelyn 与 Angela 在一起。欢迎。感谢邀请我们。恭喜发布了目前世界上最好的模型。我想说这取决于你问谁。是的，取决于你问谁。对你们个人来说，主要的收获是什么？你们有官方博客文章。降价真的很酷。当你们发布这样一个新模型时，你们收获了什么？我们为这个感到非常自豪。团队投入了大量不同的工作才让这个实现。我认为我们确实听到了关于 Opus 5 写作有些晦涩的反馈。我们真的试图清理这一点。我很高兴看到它似乎引起了人们的共鸣。在内部，当我们试用这个模型时，我们也有同样的感觉。所以得到这种验证真的很棒。关于你提到的降价，那里有很多内容。
8:17 而且我认为人们越来越看重每一美元能买到多少智能。因此，确保把“每一美元”这部分做对一直非常重要。还有一些边缘上的东西其实并不太关乎，你知道，也许是我们没在博客文章里谈到的东西，那就是我们确实做了大量工作，试图让我们的 API 更难被蒸馏。所以我们做了一些改动，让这一点更具体一些。具体来说。这些事关乎，你知道，比如我们如何做前缀锁定思考，或者你如何在不同类型的模型之间重放思考 token。我们在这方面投入了大量工作，努力确保针对非常合理的用例去调整这些东西，比如你可能想在你的压缩策略之类的地方这么做，而不是在那种用例实际上来自不良行为者的场景中，
9:05 实际上。所以在这方面有很多需要拿捏分寸的地方。我很高兴看到其中很多也发布了，除了只是发布一个每一美元智能表现不错的模型，以及只是把沟通做得更清楚一点。是的。具体来说，你谈的是这篇论文，《从专有 Yellow Lips 中窃取推理轨迹》。是的，那篇论文。就真实性而言，对吧？我的意思是，显然他们向你们做了负责任的披露。他们做了超级负责任的披露，我们非常感谢他们来找我们。我们能不能，给那些还没听说过的人讲讲，这真的很酷。你本可以做到。我的意思是，它已经被修补了，但当时是怎么回事？比如，它在 Anthropic 内部引起恐慌了吗？大概没那么严重。我不知道。我不知道这篇论文具体引起了多大恐慌，因为这是我们
9:48 早就知道的一个缺口。是的，所以这是两件不同的事。有中国模型蒸馏。是的。然后这是一个被发表出来的、备受关注的技术。是的，没错。我们早就知道思维链提取是蒸馏模型最强大的方式之一。实际上，比如我们如何跨轮次保留思考块并让这成为更必要的要求，是我们已经探索了一段时间的东西。而我们当时的处境是，我们总是要做一个非常非常艰难的权衡，一边是用户体验，比如可能对 API 用户来说很痛苦的用户体验变化，另一边是防蒸馏保护。
10:32 所以我们如何走这条线，说我们在防止蒸馏？也许先退一步。我们不想蒸馏的原因在于，Anthropic 存在的全部意义就是我们希望 AI 安全地在世界上创造积极成果。我们对正在生成的 token 运行大量安全防护分类器，以确保它们是安全的。如果有人蒸馏了我们的模型，并在没有安全防护分类器的情况下运行这些模型，世界上可能会出现坏结果。这是我们不希望发生的事。所以我们不希望人们蒸馏模型，特别是仅仅为了恶意原因或不良原因使用它们。所以这始终是一个有趣的权衡，比如对于所有出于良好目的使用模型的人，对吧？
11:16 我们并不想让用户更难从模型中获取智能，但为了防止蒸馏，我们必须做出一些权衡。因此，我们一直在研究如何防止思维链被提取，比如，如何在不让用户感到太痛苦的情况下保留思考块。我们从两个层面来考虑用户体验上的影响。第一层是，你不得不做集成上的改动，这很烦人，但你仍然能完成原本能完成的所有事情，只是稍微有点烦。第二层是，你实际上无法完成之前能完成的事情。而这正是我们非常、非常、非常努力想要避免发生的情况。所以，我们在最近几个模型上最终采取的做法是，做了一些渐进式的改动，以强制在多个轮次之间保留这些思考块。
12:04 而现在开始更多地涉及跨场景的情况，比如，如果你使用多个账户之类的，对吧？比如，我们如何确保你无法利用模型进行思维链提取？因此，我们发布了几项额外功能来帮助解决这个问题。实际上，我们与许多开源框架维护者进行了合作。我们联系了他们，和他们交谈。我们说，你们需要在你们的框架内完成这些升级。我们希望确保你们有良好的体验，当然也包括我们那些在 API 之上构建框架的大客户。对他们中的一些人来说，一个很好的例子是，他们原有的压缩策略会因为需要保留这些思考块而失效。因此，我们在 API 中发布了一项新的压缩功能，以替代他们原本
12:49 一直在手动做的事情，同时仍然能与保留的思考兼容。所以这只是一个例子，说明我们在走这条线，但我们并不是一拍脑袋就说，现在你们必须以这种确切的方式保留这些思考块，因为那样会破坏很多人的使用，但我们能够花时间与客户和开源框架维护者合作，给他们提供完成升级所需的东西。既然我们谈到了适配这个话题，那蒸馏的另一面呢？也就是另一半。是的，没有，我们确实看到蒸馏变得更难了，通过我们能够观察到的措施来看，难度显著增加了，因为这是——这里要归功于研究人员，他们非常负责任地披露了这一点。所以把它堵上是一件好事。
13:30 而且他们确实非常公开地发布了结果。我知道这在 Twitter 上确实引起了不小的反响。所以很多人可以使用它。但没错，我们确实看到，从我们能够测量的领域来看，它似乎确实减少了我们不想要的那种影响，即负面影响。是的，我想补充 Katelyn 刚才所说的一点是，我认为至少我在 Twitter 或 X 或随便你怎么称呼它上面看到很多。有人说这是商业化问题之类的。如果你还能蒸馏一个模型，你可以拿这个，然后你就可以低成本地运行它等等。虽然这是真的，但这其实并不是我们非常关心的事情。我们从安全角度更关心这一点，胜过其他一切。所以这就是为什么我们倾向于从那个角度而不是仅仅从商业角度来考虑它。实际上，如果你从我们这里蒸馏，你实际上是在付钱给我们。所以从商业上讲，我们赚了钱。所以这并不是
14:16 那种真正的影响。这更多是关于确保我们的模型，我们想确保一个云是好的，而且云可以被衍生。如果它是负面的，那将是不幸的。总的来说，也关于 5.5，因为你们刚刚完成这个，一件很有趣的事是建立你们两人之间的互动关系，因为你们也经常一起露面，你们是产品负责人、工程负责人。这在你们两人之间是如何运作的？特别是对于模型发布。我们就举个例子。所以对于模型发布，我们的团队在产品与工程之间非常紧密地合作。在我这边，更多的是关于我们需要在发布具有正确智能标准的东西与成本保持之间做出什么样的权衡。
15:00 我们很多更新的现金成本之类的东西表明我们是在说，我们想鼓励你采取对所有人都有益的集成变更，并把这些节省传递下去。但很多这类围绕此的决策，以及我们如何平衡一些关于我们安全举措的部分，同时确保它是一个人们可以利用的出色模型。所以那些围绕我们如何发布模型的特质，我想说也许是质量和周边组件，更多属于产品方面。然后从集成体验的角度来看，很多直接来自工程团队。所以显然我们合作，如果你在谈论 API 的体验，那是非常非常非常紧密集成的。所以这实际上真的很棒。我们有很多实际上非常有产品思维的工程师，我们真的很喜欢这一点。
15:49 同样在我这边，有很多产品经理技术能力更强。我们希望这种融合的跨学科型人才，因为他们能从各个不同角度分析问题，想办法做到最好。但我倾向于更看重商业影响，而我觉得实际上更准确的说法是，工程师会更在意集成体验。所以他们几乎更多从 UX 角度出发，而这里的 UX 显然更多是关于 API 和开发者工具。是的。做一个负责开发者产品和平台的产品工程师很有趣。我也有同感。我觉得我们有很多工程师热爱思考产品、热爱思考用户体验、热爱思考开发者体验。
16:31 我觉得我们之间也有这种互动，我有很多意见，在产品团队面前很烦人地表达我们对这些事情的看法。我们的产品团队也非常懂技术，他们能深入到我们为规模化或其他目的所做决策的细节中，这是我们团队很有趣的互动。是的，有些……Kayla 和我合作很久了。在 Stripe。在 Stripe，然后我想我们在 OpenAI 没有合作过。不同的实验室。不同的实验室。然后我过来了。但我觉得我们俩一个有趣的特点是，Katelyn 经常被误认为是产品经理。而我经常被误认为是工程人员，尽管这些其实都不是我们的工作职能。所以我觉得这种搭配往往很有帮助，能让双方的决策保持一致。
17:18 我遇到过很多公司有类似的产品负责人、工程负责人配置。随着软件工程被解决，也许这两个角色会合并？我有点这么认为。是的。我觉得大家往往倾向于……但如果你们还是分开的，那说明我们还没到那一步。我们肯定还没到那一步。那为什么呢？还剩下什么？我觉得软件工程被解决这个说法……我不知道我会不会用那么强烈的措辞。我觉得有……我倾向于这样想，雄心会不断提升，对吧？也许一个好例子是，我们团队现在花很多时间做的，当然显然是我们为安全发布模型必须做的所有事情，实际上是我们正在做的最重要的事情，因为我们在安全方面有大量工作要做，涉及智能体、离线防护和在线防护，所有这些正在发生的事情。
18:06 但我们正在做的另一半是尝试扩展规模。部分原因是，当我一年多前加入 Anthropic 时，我们只有 Messages API。它是一个 Python 单体应用。我们只在单个 GCP 区域运行它，一切都很正常。而且当我准备接受这份工作时，我的亲朋好友都不知道 Claude 是什么，对吧？而现在我们的处境已经截然不同。从我们在 API 上看到并不得不支持的流量规模来看，各项指标真的非常惊人。CPU 资源非常紧张，这对我们来说一直是个很有意思的问题。所以我们做了大量工作来研究如何扩展这些系统？这显然需要大量分布式系统方面的专业知识，
18:45 以及模型所具备的某些语言和框架方面的专业知识，但当涉及到大规模运营和演进这样一个系统时，我们远未达到那种“祝你好运，Claude，玩得开心”然后就直接让它去做所有需要的系统变更、安全地推出并大规模运营的程度。仍然有大量工作必须由人类来完成，我想这种情况还会持续一段时间。我很好奇这方面发生了怎样的变化。比如不久前，当 Fable 首次推出时，我们有 Glasswing，模型发布方式出现了整体延迟和变化。我们看到大多数前沿模型都是如此。有安全测试。现在情况如何？你们怎么看？你们如何判断——一方面是有新的 Sonnet，Haiku 也要来了。
19:31 我猜那些会直接发布。但像 Opus 5.5 或新的 Fable 这样的模型，目前是什么状态？是的，我想说这首先要从我们在保障措施和安全方面的政策决定开始。这既包括离线安全，也包括在线安全。所以最近有很多关于数据保留的讨论，以及我们在这方面正在做什么，以便安全地发布这些模型。原因在于，你会遇到这样的情况：有许许多多账户，分布在一个庞大的用户网络中，这些人选择注册账户并以各种方式使用模型。而在线的、随着 token 流经系统的方式，我们根本无法捕捉到模型是否存在恶意行为、蒸馏或其他可能发生的事情。
20:19 所以我们开始不得不制定数据保留政策，以便进行自动审查和人工审查，无论需要什么方式，来确保模型被用于正当用途。对于我们发布的每一个模型，这就是一个需要做出的政策决定的例子——针对这个特定模型的政策会是什么。比如昨天发布的 Opus 5.5 就没有 Fable 那样的数据保留要求，对吧？但这是我们每次发布这些模型时都必须做出的决定。如果它确实要有那些政策，我们就必须做好工作确保这些政策得到执行。同样，对于我们推出的项目，比如我们有网络验证项目，以及最近新推出的生命科学验证项目，也就是说，你所使用的模型在在线保障措施的运作方式上会有所不同。
21:09 确保所有这些程序都落实到位是另一项工作。所以这只是我们在每次模型发布中所做工作类型的一个缩影——我现在说的所有这些，都不是我们过去发布这些模型时需要考虑的事情。而现在大部分工作都是：我们在做什么来防止蒸馏？在线防护措施、离线防护措施、政策。一个非常好的例子是，我们构建了一个系统，确保使用某个模型或使用这些可能给你放宽防护措施的程序之一的授权，能够以我们真正信任的方式贯穿我们的整个系统。
21:47 并不是说，哦，你获得了 Mythos 的访问权限，于是我们给你一个 API 密钥，翻转一个功能开关就完事了。我们有一套非常强大的系统来处理授权，确保如果你应该使用那个模型，那么只有你在以你应有的方式使用那个模型。所以围绕模型发布开始出现很多复杂的事情，而这些我们以前从来不需要考虑。是的，而且它随着能力而扩展。比如，随着我们的能力越来越先进，它们开始在某些特定领域出现尖峰，那就是我们需要额外关注的地方。所以很多评估就来自那些非常特定的能力，我们可能将其视为进攻主导或防御主导，因此可能会为此采取不同的策略。而当我们把这一切贯穿到最终的模型发布时，会有一些像 Katelyn 提到的部分，我们并不确切知道人们可能会如何使用这些能力。
22:37 有一些更明显的，比如做编程，对吧？太好了，去做出很棒的产品，去发布更多东西。这对你来说可能非常棒。然后其他领域比如生物和网络，它可能是两用的，可能会有负面影响。但显然，当然，你可能是一位非常有效的网络安全研究员。你在试图寻找漏洞。你在试图做一个好的行为者。生物领域类似，你可能在做研究之类的。所以很多这些程序，比如你上面展示的那个，基本上是为了提供对那种两用能力的访问。你确实需要说明你的用例之类的。但我们确实希望让社区能够利用这些能力，看看他们能用它做出什么了不起的事情。好，我们会把链接放上去。也许我们稍后会深入探讨它们。
23:15 生物领域也有一个。另外，我只是觉得从高层来看，你们真正去思考这些东西非常重要。人们忘了 Fable 曾被回滚，还有各种蒸馏攻击，人们就说，啊，Fable 上零数据保留根本不存在，太疯狂了。但你要记住，它确实被撤回了。存在蒸馏攻击。你们在发布时过度思考并以正确的方式去做，这是好事。是的。而其中很多就是构建正确的框架。再次谈谈边缘方面，在我们的系统中构建正确的框架来实现这一点。所以我稍微谈过这个，比如我们如今在整个系统中构建的授权和信任授予这个想法。永远别说永远。对吧。不作为先例。是的。但这也是平台工程中非常常见的事，你遇到一次事故，然后你就为这次事故过度准备，而事故再也不会发生。
24:06 是的。就像，你知道，现在你有那个按钮了。确实如此。你说得很有趣，因为当时发生了那么多事，我们团队的工作中就有了这一项：我们要建立这个系统，使得它可以是一个按钮就能为所有人回滚。所以很有趣，因为就像，我们做这项工作的理由是不是因为我们希望那样的事情再也不发生？但我认为在这种情况下，它其实只是把那些我们想在各处都放好的相同原语层层叠加起来，帮助我们管理这些验证项目以及对 Mythos 等模型的访问，就是说，把同样的东西放在每个人的模型访问之下，以便万一我们需要，我们就有正确的控制措施到位。
24:48 是的。而这样的决策实际上已被证明是，这个具体的我们拭目以待。但像这样的例子一直是我们不得不真正转变路线图制定方式的途径。因为，你知道，在传统产品管理中，我想，你可以说，好吧，这些是我假设会发生的事情。它们会有一定的顺序、一定的排序。但你是在以更具体的方式下注，相比之下，比如 Fable 的停用。我不认为我们中任何人会猜到那会是一个真实发生的有效用例。被政府要求，那位女士就不得不去做。但显然概率非零。所以从这种思维方式来看，从产品管理的角度，它实际上变得深度概率化了，比如，我们应该优先考虑这个吗？这件事发生的几率有多大？
25:32 还会再次发生吗？当我们审视这类事情时，我们会想，好吧，如果我们要想象最疯狂的一系列可能性，我们实际上可能非常不确定事情会走向何方。所以我们其实只需要对冲风险并构建一个押注组合。因此，大多数情况下，我们会采取对冲情景，比如，好吧，我们认为它不会再次发生。但如果真的发生了，我们实际上会想要那个对冲，或者有能力很好地做到这一点。所以我们会优先考虑这类事情。然后我们越来越多地发现，大多数情况下，通过采取这种产品开发策略，我们实际上常常发现自己真的在用那个东西。还有另一个例子吗，单独的一个，好让我理解？比如这个访问计划。
26:15 这个X因素真的很好。在内部，它有一堆授权之类的东西。我们开发它专门是为了能够……实际上把这样的计划提供给客户，非常非常具体地。你想不想高层次地说一下这个访问计划具体是什么？当然。所以如果你想要双重用途，如果你想，那么，让我们拿一个模型来说。你拿一个模型，叫它Opus之类的，你想能够在Opus上使用高级网络能力用于研究或任何你想去做的事情，比如你的防御性用户。你可以申请这个计划，带着你的用例，如果获批，实际做的是削弱你那个版本模型上的防护措施，这样你就可以继续为你的用例利用那些网络活动。现在，显然，
27:02 那需要按用例来理解。它需要缩小到特定用户，因为你不会普遍地那么做。你必须申请。甚至像这样的事情，像这种计划，我们设计了很多Katelyn谈到的原语，以便能够处理这类事情。现在，对我们来说很意外，或者也许在组合方法中，我们发现我们实际上能够拿这个并把它做成X。我们当时想，当我们设计它时，我们想，它应该是什么样子？它应该有多通用？它不应该太通用吧？它应该过度专注于做这个验证，你知道，风格的门户加上授予模型非常具体的能力？我们倾向于更多通用性，因为我们想，我们不知道。也许我们可以把它用于其他事情，也许不行。然后它最终对诸如，你知道，访问模型这类事情变得极其有用
27:47 推而广之，用于管理我们所有的可信访问计划，用于处理模型的下线部署，因为我们在处理每一个原语时实际上都非常、非常通用。从正常的产品角度来看，我通常可能会说，这大概不太合理。我们应该聚焦于用例。这说得通。但在这里，越来越多地，因为我们选择了更通用的方法，我们发现自己往往更频繁地采用那个解决方案。正因如此，它带来的回报不断增加。它是你本来就必须拥有的东西，而你只是有了一个强制性的契机去拥有它。从技术角度来说，我来自 AWS 世界，对吧？IAM、OVC，然后那些对此非常认真的人会谈论 Zanzibar 以及所有其他技术架构。我不熟悉 token grants 或 trust grants 这个词。
28:32 Trust grants，是的。Trust grants。普通 OVC 和 trust grants 之间有区别吗？我的意思是，其实没有。它是一种授权形式。是的，它是 IAM，但是 Anthropic 的 IAM。是的，差不多。我想实际上我们有的是，比如有一种授权形式是，好，你向一个 API 发出了请求，底层将访问一些数据，我们要确保你访问的是你的数据。对。非常、非常基础的授权。这就像我们建立了一个数据模型，非常清晰，trust grant 意味着你被授予了访问某个特定模型的权限，或者你被授予了访问某个特定计划的权限，或者，你知道，有很多不同的排列组合。实际上我们发现自己一直在采用它。另一个很好的例子是当我们
29:17 首次推出 Fable 5.1 的一些保留思考功能时，我们对一些人做了祖父条款处理，给了一点，你知道，就像是一个时间。宽限期。是的，宽限期，让他们去进行集成更改。作为祖父条款处理的一部分，我们说，好，我们必须追踪谁是现有客户、需要额外时间，对吧？然后我们做了一个 trust grant。于是我们就能说，对于任何事情，我们只是运行这个服务，它处于我们请求的热路径上，以确保，你知道，我们只是流过并检查你是否有你试图做的事情的授权，这其实和基础授权真的没什么不同。但就像，我们只是必须搭建一个系统
30:02 那是针对我们系统的，并且我们需要能够插入这些检查。是的，我的意思是，我认为这些都是人们视为理所当然、不会真正去想的工程事项。另一个例子是什么，我猜，是必须完成的平台工作，你知道，也许是服务 Claude Code，也许是服务，你知道，显然我和 Cognition 聊了很多，但其他客户在模型发布方面，对吧？就像我们会更多地谈论正在发生的安全方面的工作。我只是想在高层次上谈谈，因为这刚从你的记忆中出来，就像模型发布需要什么？如今它已经变成了一台有点复杂的机器，除去安全方面的东西，我认为那是更复杂的部分。但除了那些部分之外，有很多从客户那里获取反馈的工作。所以，你知道，我们制作模型，
30:50 会有大量的安全测试。还会评估我们认为它需要达到的水平。我们会按需做出必要的权衡和决定。然后我们必须经过测试。我们会切出模型的各种版本。我们会评估它。我们会做很多我们称之为内部“吃狗粮”的工作。而这实际上总是非常有帮助。比如，我们能很早就发现一些问题，比如，哦，这个可能不是最好的。而且我们显然在内部工作中大量使用 Cloud。所以我们实际上能够看到围绕这些内容的早期信号。这有助于我们判断哪些变体可能比其他变体更好。然后，当我们对某一组变体非常有信心时，我们会为客户切出一个版本。有时这会通过我们的第一方产品，比如通过 Claude Code 或 CodeWork 之类的东西。
31:30 在其他情况下，它会通过我们的 API 客户。我们会与这些客户开展一种实际上相当于早期访问计划的活动。他们需要对自己的 harness 做出更改。我们已经与很多客户合作过，比如 Cognition、Cursor 这类公司。我们有一套处理这件事的流程，这样我们大家都能得到所需的反馈。它在你们的评估中表现好吗？你们喜欢它吗？不喜欢吗？有些东西是凭感觉的，我们也喜欢听这些。而有些东西就是直接的评估，比如它在你们关心的事情上表现好吗？我们会把所有这些综合起来。一旦我们对所有这些不同部分都感觉良好，我们就发布模型。模型反馈的状态感觉仍然非常无结构。基本上，总是公司之间的一个 Slack 频道，说，嘿，这东西看起来有点怪。然后人们就说，好吧，我想我会修一下。
32:16 给我一个 ID 之类的。是的，非常，我的意思是，这就是一个非确定性产品的本质，对吧？但我想正如你所说，真正参与我们早期访问计划的客户，只有那些拥有非常强大评估体系的客户。就像，我确实认为这其中很多是基于感觉的，而且我认为很多对话往往都是基于感觉、即兴进行的。部分原因是我们正在赛跑，对吧？就像，我们想尽可能缩短从我们切出一个用于测试的模型版本到我们让所有人访问该模型之间的窗口。所以就是这样一个非常紧张的时间窗口。但我们倾向于合作的客户，是那些我们知道他们会启动整套评估套件，并且能够带着真正可执行的反馈回来找我们的客户。
33:01 尽可能快地结合直觉，以及基于直觉的反馈。所以，当然，我们肯定可以做一些流程化的事情，随着时间推移让这些变得更好。但是，我的意思是，你会感到惊讶。我的意思是，你可能不会感到惊讶，但我想有些人会感到惊讶：世界上存在的智能体产品中，很少有具备良好评估（evals）来帮助测试这些模型的。两年前我们请 Boris 上播客时，他说我们没有那个时钟代码。我的意思是，情况已经变了。那已经变了。那已经变了。但是，你知道，就像，是的，很多事情就像，你知道，你的评估就是你的用户，而你没有时间把它们正式化，或者你没有经验之类的。这没关系。在某个时候，当你认真起来，你就会有评估。是的，完全同意。我认为好的一点是，你们做了大量的内部试用（amp fooding），就像你说的。所以人们常说，你在产品发布前会自己测试很多这些东西，对吧？
33:49 是的。是的。尤其是客户的 API 非常有用，因为他们会把 Cloud 放进不同的测试框架中。我们希望 Cloud 非常非常通用。所以它在其他框架中工作的能力对我们来说相当重要。因此，这种风格的反馈往往对我们特别有用，因为它与我们通过内部试用（AntFooting）得到的东西不同。什么样的反馈有帮助？是回归问题吗？我们这里有回归问题。我们注意到这里有一些好的特性。好的东西总是很有验证性。我想我们经常不会感到惊讶，但我们喜欢在一些我们可能提出假设的事情上得到验证。老实说，最有用的反馈是负面的。就像，你知道，它在这方面做得不好。它在那方面做得不好。我们喜欢那种反馈。然后我们就会想，太好了，我们怎么修复它？
34:31 是的，而且往往是其中一些事情，真的很难，因为不是每个人都真的希望 Claude 在每个光谱上都落在完全相同的位置。也许一个很好的例子是，你知道，懒惰与主动性以及采取行动之间的对比。所以有时候，我们有一个模型，人们会说，就像，就完成我的任务。就像，别偷懒了。就像，做得更好。而其他时候，就像，嘿，我们只是在摸索和规划。然后你就去写了一堆代码，或者你采取了一大堆我还没准备好的行动。要把它做到完全正确实际上是不可能的，因为现实中每个人其实想要的东西都不同。但我确实认为我们遇到过这样的情况：我们发布了一个早期版本的模型。我们发现我们看到了太多的懒惰。对。
35:15 然后我们喜欢把它放回烤箱里烤一会儿。对。然后试着把它训练掉。所以这类事情，如果我们只是在我们的产品内部和我们的 API 内部做内部 antfooding，我们可能就发现不了。对我们来说，把它放到 API 里，让我们所有其他客户都用起来，并告诉我们哪里需要改，这要重要得多。是的，这是个核心问题。我觉得这大概就是，如果我站在你的位置，做模型 PM 最难的事情之一，就是所谓的对齐与个性化之争。有一个你希望所有消费者都有的默认人格、默认行为。然后你还希望能非常快速地响应某人的 CLAUDE.md，说，不不不，请比默认更主动一些。
36:01 然后，据我所知，你知道，我参与了 Frontier Code。我们参与了 Fable 的发布，那次发布让 Frontier Code 出了名。现在有了 Opus 5.5，我们又把它放回了模型基准上。这是 Frontier Code 非常重要的一部分，对吧？Frontier Code 的模型曲线看起来奇怪，是因为它对过多活动或过多文件进行惩罚，这是好事。就像，有一整套……Frontier Code 的设计目的。但我完全可以就在我的 CLAUDE.md 里说，别那么做。然后它就不会那么做了。那么，我是不是因为我的基准没有那个主观的个性化元素，就在不公平地惩罚 Cloud Opus 55？所以我不知道问题是什么，但你们怎么处理个性化？显然，一个模型能做很多
36:51 不同的事情，而且非常依赖具体情况，每个人都有自己的 CloudMD，你们怎么演进这个？我们做得不太好。说真的，这真的很难。超级难，而且它们是相互竞争又相互对照的。我以为有 cloud constitution，我想。那很旧了。确实有个 constitution，但我让你们来回答。constitution 有帮助，但像这种关于它如何根据不同的指令和非常非常不同的偏好进行个性化的事情，对我们来说非常难做。我们通常试图通过拥有更多参数来解决这个问题，然后让我们能够针对
37:32 每个客户群进行调整。如果我们不控制你的客户群，而你是 API 客户，那我们就试着给你建议，然后你试着去做那些调整。所以有些东西，你知道，围绕，它并不完全等同于对各个 cloud.md 或现在的 agents.md 或随便什么进行个性化的那种级别。但我们确实试着在比如努力程度这一层给出东西，比如你应该投入多少努力，有哪些级别，也许你实际可能关心的模型大小，诸如此类。但我觉得，对于我们真正需要的那种个性化水平来说，这还不太够。所以这是个非常难的问题。而现在我们解决这个问题的方式，很多都超出了参数本身，比如给某个东西提供多个参数，就是试着展现相互冲突的品味，说实话，
38:15 综合我们收到的所有反馈，并尝试对其中一些问题做出判断。我认为随着时间的推移，实际上，随着你扩展更多客户和更多用户，这并不是一种非常可扩展的做法。我们将需要开发一些方法，让 Claude 能够接收你的个性化设置。也许这是你可以提供的信号，或者你可以调整的东西，诸如此类。但我认为我们将不得不采取一条更倾向于那个方向的路线。但就目前而言，是的，我们实际上只是尝试对很多问题做出判断，但这相当困难。事情就是这样。这里有一个小提示。我猜默认的推理强度变了。现在是中等。这属于那种可能会影响不使用这个开关的普通用户的事情之一。是的，这就像是一个 Claude Code 设置，对吧？这是一个默认为中等的 Claude Code 设置。
39:00 Yeah, they just... And this thing varies. This thing does... This is a perfect example of a parameter that we use to kind of personalize. I would say this may be a little too aggressive of a term, but we kind of customize maybe for different subsegments. And so, like, the default setting will adjust for whether you're a free customer or a prosumer customer, or Claude Code versus Cowork versus Enterprise, like things like that, versus API and stuff like that. Knowing that you can obviously always adjust it, but those are kind of like light ways where we try to give that. One thing that we are hesitant to do is we don't want people to feel like they can't control their customization of Cloud. So we could take a heavier hand on these things, for example, But we want to give users the ability to experience the intelligence levels of Cloud as they kind of see fit, especially if you want to go towards, like, the higher end or you want to experiment with maybe sometimes in the lower end if that actually is, like, faster for your use case, which is a hard product tradeoff, I think.
39:53 And so we tend to lean towards gentle defaults but give you options to adjust, which I think works okay-ish for now. But I imagine us, you know, like, learning how to do that better over time for customers. We're not like super, super happy with any of this yet, but we know as we launch a model, like you asked, like, what does it take to launch a model? One of the big things obviously we have to do is like, okay, Claude like got good at a thing. And like, sometimes that thing is something we should expose as a parameter on the API to let you control. But I think as this has evolved over time, we've ended up with like this funny mishmash of like, there's effort, there's budgets, there's all these things that you can set
40:31 on the API. And it's like, how could anyone like possibly figure out what is the right combination of things for any given tasks for what you should go and set? And it's something that this is us just very much like figuring it out as we go and figuring it out with customers and figuring out like which of those parameters do we deprecate over time? Which of those parameters do we just like default better? Which of those parameters should be like a one to a hundred scale versus a low, medium, high scale, right? Like, because actually we've trained Claude to get really good at understanding like a whole spectrum of options on some of those sorts of things. But like, do we expose the like entirety of those millions and billions of permutations of options? Like, you wouldn't really get very far. And that's one of the things actually that is part of the value prop with something like Claude Managed Agent, which is like still programmatic access to Claude in an API.
41:19 but you get a harness out of the box where we do, every time we're launching the model, a lot of the work to go figure out, like, what are the new parameters? What are the breaking changes? How do we get the best out of Claude within our harness? So that for the people who are using it, you just kind of get that out of the box. You don't have to think about it. Just for people who are drawn to that, and which there's a significant and growing population, particularly we actually did a whole CMA workshop at AIE, which I thought was really well done. Is there a separate feed for people to subscribe to, like, updates on CMA? Feed, like... Like a Twitter feed, newsletter, I don't know. No, I think actually our Cloud Devs channel, we are, yeah, we're pretty loud about it because it is, like, an interesting option for people.
42:02 Yeah, I just want to give people, like, if that's your way of consuming Cloud, this is the path. I think it's also pretty underrated. For those that aren't consuming Cloud this way, what is Claude Managed Agents? Why should people use it? Oh, yeah. We should probably do a little intro. I don't know. That's somebody's house. Yeah. A little two-sentence thing. I think a lot of people glanced over it when it came out, right? Everyone was in this phase of, I need to do harness engineering. I need to control this. And you hear all that. And now it's like, do you need to do all that? Or do you just use managed agents and you have a lot of info you can skip over setting up? But give the quick three. Yeah. It depends on your use case. So Claude Managed Agents is our API today.
42:47 We have the Messages API, which is essentially raw token access. Then we have Claude Managed Agents, which is a suite of APIs, but it lets you define an agent, start a session with that agent. And it's essentially just kind of a higher order abstraction that lets you skip setting up all the infrastructure, setting up your harness, and doing a lot of that type of work. It's a much more out-of-the-box integration for people who want to programmatically run agents. Does CMA share infrastructure with CloudTag? Because the sequencing of it seemed very like, oh, like that's the cloud tag. A lot of it. A lot of it. So one of the big things that we do is as the platform team, we run our APIs. We also kind of run all of our foundational product infrastructure and product services.
43:32 So a really good example is like our team runs our sandboxing fleet that backs both Claude Managed Agents as well as products like Cloud Tag and otherwise. But at the actual harness layer for those two products, there's just differences in what we might want to do within the harness so that they don't actually share a harness, but they share a lot of the infrastructure that powers the execution and powers the APIs. I think that's really... People should use this more. I think everyone basically had copycat clones of Managed Agents after you guys launched it, which imitation is a sincere form of flattery. Since we're on this topic, we'll briefly mention all the memory stuff that has been going on. I feel like it was a big part of Anthropic work in the first half of the year. Has it stalled out? Is it still ongoing? What's
44:20 the emphasis here now? Managed agents specifically. Memory, dreaming. Oh, it is a big part of what we're doing. I think maybe the way to think about it is we launched managed agents as a platform for people who didn't want to do all these things themselves, right? Or just wanted to like offload, like I'm getting the best out of Claude because our team is literally sitting here like evaling all these things and making sure that the harness is going to be really powerful. Memory and dreaming is all about just like how do you make sure your agent can continuously improve over time? And all of that is still an important focus for our team. But what I would actually say is to the point of what we talked about earlier, as launching models has become harder and harder from a safety perspective, I think most of our team's energy is going less
45:04 into like, here's a fun feature to like hill climb on this agent or whatever, and much more into how do we bring safety into all these things? Because the most important thing that we can do is get the power of the model out there and get it out there safely. And so I would say a lot of our energy is take all these same concepts and give you an agent system that's going to be really powerful, but also that's going to be really safe. And so that's where we're putting our energy. I think compared to maybe earlier this year, we have slowed down on like skills, dreaming, memory, like these kind of like moment in time injections. Please love skills. No, no, no. We love skills. We love skills. We are making updates. I'm not saying that we're not doing anything, but we love skills as well. But yes, I think we've slowed down a little bit comparatively for some of the other efforts.
45:48 But we are very bullish on people kind of doing some level of hill climbing at the harness layer to, you know, some of the previous conversation here. We do a lot of this ourselves, but the harness that we provide is very simple in a way. It's intentionally simple. We don't want to be actually overly opinionated. We want to make sure the best practices get merged in and there's some kind of undifferentiated pieces of the hardest agentic loop that, yeah, are hard to string together. And also, like, you can kind of just boilerplate do it. Now, the interesting part on top of that, though, is, like, once you get that base layer, there are these, like, hill climbing strategies that we construct. And, like, dreaming is actually one of them. So dreaming... under the hood is a multi-agent system that we hill climbed on top of CMA and it's actually a
46:30 CMA on top of itself, basically. CMA on top of itself. It like spins up another, yeah. The way Dreaming works is that we spin up another managed agent that then can expect the previous managed agent and then write memories to that managed agent. So it's managed agents all the way down. And this is a bit of a thing by design because we envisioned that you could probably put together a lot of these modular components for something interesting. And Dreaming is just like an example one of the more interesting things that we were going after. But we kind of have been looking at this as being like, there's actually a ton of other stuff you can do. You can do like best of N as a type of like multi-agent strategy. You can do a verifier agent, that kind of like goal thing or outcome thing. There's a bunch of other stuff in there. And we've seen people do some pretty funky, crazy stuff. Like there's been a harness that like shares like crazy memory across everything. And they spin up like tons of parallel agents.
47:16 And we're like, we should actually just probably enable you to do that. In the same way that we did, we built Dreaming. That's like manage agents all the way down. There's an update that we'll make relatively soon where we're updating the underlying primitive. We'll expose it to allow users to kind of like construct harness strategies maybe or however you want to call this stuff. Like multi-agent strategies. Multi-agent strategies that allow you to kind of build your own version of this. And we'll give you like, you know, templates of like, this is how we started with Dreaming. Maybe there's like an update to this that you would want to make as a developer and you would find some more value on top of it. Yeah, I think that's a really good framing. It's less that we're slowing down on this sort of stuff and more saying, like, we've got the primitives in place. We can continue to let people just, like, take and run with those things while giving them the tools to say, here's some, like, cool multi-agent strategies and, like, things that we've put into Cloud Manage Agents to make it really powerful.
48:05 now you can like let Claude do work to take advantage of those primitives and make it even more powerful yourself, like create new multi-agent strategies and whatever it might be. While a lot of our team's attention turns to, okay, great, like community, run with that, right? And you do you while we continue to focus on what are all the things that we need to do to make sure that you get access to the models within that system safely. One thing you brought up was you run a lot of evals on this stuff. Pretty hot topic right now. Any advice, best practices? For evals specifically? Evals on harnesses, agents. There's a lot of different types of evals, right? Like not all evals are made equal for different, you know, like situations that you're in and things that you're trying to test for.
48:49 You obviously have just like static deterministic stuff and then you have LLM as a judge. You have all these different strategies. But I guess I would just say like what we found from most people is like you probably need more rather than less. it's just there's not like one perfect like couple sets of evals that you could put together that are going to get you all the answers that you need to make your system better we found that people end up needing like a relatively large suite of these things and then it's like you can have your agents work with you to evolve your eval suite over time as well but I think it's just like under investing is maybe like the biggest mistake that we've seen from people on that front. Yeah. And it starts simple.
49:30 I think some people like go a little crazy and they're like, you know, they like look at all the menu of options and you kind of listen and you're like, wow, this is so crazy. Let me try this and that. And what's the best one? And like, while they do all those things, like the number of emails they actually have are like zero. So you might as well just like do something simple. It will help. Yeah, I think some part of it people are inexperienced. They're not trained to do this. And they don't know what good looks like. Totally. I think for you guys publishing more examples of that is really helpful. Yeah. Something I do tell people a lot that I'm doing with more Fable and Astro Class type models is we're treating engineering like research. And when you treat your engineering like research, you naturally do more evals. You do more labeling. You do more scaling of runs, like prototyping and scaling of runs. And you're not treating a model.
50:15 You're building the harness, the products, whatever it is. But you're approaching it like research. You're defining up front what your goal is, trying to formalize it as an eval, and then try to identify, okay, why is it failing? And sometimes your eval is wrong. Actually, a lot of times your eval is wrong. Sometimes your environment is wrong, and then sometimes the model is wrong. And actually, that is a lot of part of what I think AI engineering is becoming, which is doing all this stuff. Completely agree. And we'll continue to launch more features within Claude Managed Agents to give people more tooling to do this sort of stuff out of the box. and you'll probably find from us that you'll get something that's like, here's a product that will help you create evals for your managed agents or whatever it might be and it'll feel very much like working with Claude in order to do that.
51:00 Because that is the best way to do it. Claude's actually really good at creating evals to evaluate agents. Yeah, exactly. Because people blank out when they look at JSON-Ls. Right? But a pretty evalui where you're left, right, left, right, left, right And you're sort of like doing what the human greater data people, labelers would do anyway. Yes, yes, yes. You can do that yourself. You can. Just like throw Fable at it. Yeah. And it will materialize advice. But also write comments because it just outputs all these ratings, right? It'll give you an ELO, give you whatever. But Cloud can just consume that and then work on itself, right? That's the feedback it needs. And people just don't know that you can prompt for an eval. Yeah. Yeah. I love that you said that. I think it's like a very like AGI-pilled way to like do it.
51:46 because it also allows you to update and edit that system very systematically. And so as new models improve, as things change, you can really inspect where your system is, and it'll just evolve with you. Get to you in every part. Exactly. Yeah, so basically, I think it's how we talked about how maybe product and engineering are merging. It's also there's application layer engineering and model research are merging in those techniques that are being shared, right? That's very true. Model people are very, very used to doing evals. application people know, like, the only thing you care about is does it fit the PRD? And like, yeah, it's like a whole different... It's a whole new skill set, I think. I think you guys put out a pretty cool blog post on this today. It's somewhat different.
52:30 It's about making the UI a lot faster. But to your point of treating it like research, basically define a goal of we want stuff to load faster and then define and, you know, question things. What can we do instead of wall clock timing? There's fun quotes in here. I think it's nice to see how the actual researchers or engineers prompted Claude. There was stuff like, you know, we had 12 things. We said you have two weeks. I did nine out of 12 of them in like three days or something. But fun blog posts for people to research, for people to read through. Yeah, I love it when we share our actual prompts. And like sometimes people are like, oh, God, there was some crazy, unique ways of prompting. And it's just like, try harder, Claude. Thank you. My only feedback is it should link to the workbench. Which is no longer a thing, but I used to.
53:17 That is a good idea. That's a good idea. Okay. Feedback heard. Make everything replayable. Feedback heard. Love it. Yeah. Yeah. But you were going to share more details behind the engineering story or the rust work that you used to do. Yeah. So I think I talked a little bit earlier about like scale is a problem for us. So it's scale and safety, right? Yeah. Scale and safety. Those are like the two biggest things we're spending our time on. And I mean, it's really interesting because most people are used to talking about scale or just like, I don't know, computes at the like GPU accelerator layer and much less so at the CPU, you know, like old school layer. And that's, it's just like as much of a problem today as the accelerator layer,
54:00 which is really interesting. You cannot get enough VMs. You cannot get no sandboxes. That's primarily just everything being able to spin up, spin up. With all the resources that you have. Yeah. Really? You got a lot of customers too. Yeah, which is crazy. Yeah, and think about it because we're using CPU across, obviously, just like running our product services, running the API, running all of our apps. We're using CPU on sandboxing, all the sandboxing that we're doing. And then just like all the things like CI, you know, like you'd be surprised how much more code is getting written. Therefore, there's so many more CI runs. Therefore, you need more CPU to handle that. And so on the whole, and this is not just us, it's everybody that I talk to. I would add training. Training is probably using a sandboxing. So there's a different bucket, right? I'm sure they don't commingle that much. Well, they don't commingle, although like CPU for Anthropic as a whole is like a zero sum game.
54:50 You know, like we get our we negotiate our deals with the CSPs and we get our CPU and we have to allocate within Anthropic how much of that goes to all the things I just mentioned, including like research sandboxing versus product sandboxing and otherwise. And so we really are allocating across absolutely everything. and it's just everyone in the industry right now is... Short on everything. Yeah, you used to be able to just like, you know, like scale up on demand into CPU capacity as long as your budget allowed you to, right? And like now it becomes something that you have to capacity plan for in advance, which is, you know, like kind of punching everyone in the face.
55:30 It's brand new and people are starting to do it. And so dealing with that means a few things. Like one is obviously just go try to get more CPU. cool, we're doing that as much as we can. But two is we want to be able to, at the infrastructure layer, run it more efficiently, right? Like figure out how we can make sure that we're running our sandboxes as efficiently as we can without compromising on things like tenant isolation or properties that we like, you know, care about for security or otherwise. But then at the application layer, how can we run our applications and our APIs more efficiently? The thing that I'm like most excited about. As of last week, we fully rolled out the Messages API written in Rust, which is one of those like insane feats of like what you're able to do in the agentic coding era that used
56:18 to be like we started talking about this like earlier this year. We were like, we're going to hit a CPU wall. There's stuff we need to do. And we've done it. right? Like we've gone multi-region, we've done all these things we need to do. And we were like, we're running this Python monolith and it's like, it's like very CPU inefficient. And so what are we going to do to make the system more efficient? Yeah. So we chose Rust, which was a crazy decision at the time because we had a team of people like on paper, it's obvious, but our team was like, we don't have a single Rust developer in the room. Exactly. Literally. And not only that, But yes, Claude is going to write the code. The humans design the system, right?
57:01 So the humans are very involved in making sure at the end of the day, it's a distributed systems architecture, right? And Claude can help you both with actually writing the code, but also helping those engineers bounce around ideas and learn what they need to learn to design that system. But what's most interesting is the two things that mattered most were the plan to do the thing and then the verification of the thing. because the actual implementation was like cloud writing code. And so what we ended up doing was we literally built like an entire fork of the entire API in Rust and then started running shadow traffic through it and verifying that the outputs that we were getting from the Python system and the Rust system were the same. This is like feature flags are all you need. Yeah, literally. Low balancing feature flags.
57:45 It's just, I don't know. I never in my career would have had a team say like, yeah, yeah, cool. Do you still have Rust people or no Rust people? Well, they would probably call themselves Rust people now. I mean, there are two big, big steps to Rust. Yeah, exactly. And along the way, we have hired a couple of people who have more experience with Rust. But yeah, but it still is just like you never would have signed up for that. It would have taken years and years and years. Like you wouldn't do it all in one shot. You would have carved out pieces of the system and say like migrate this, migrate that, migrate that. Easily a multi-year effort. But you would never like kind of one in one swoop, right, like port the whole thing over and then just like slowly turn it on. But that is what we ended up doing. And it worked. And so not only do we actually save a lot of CPU, but we our latency has seen a nice improvement, which is pretty cool, too.
58:37 And, you know, it's just it's it's a crazy error we live in because you just never could have done that sort of thing previously. Order magnitude of savings on the on the CPU side. Just for people considering this. Yeah, yeah. Okay, order of magnitude, that's really interesting. Ballpark, yeah. Yeah, ballpark. I guess I would say like we've seen somewhere like 40 to 50 percent, something like really crazy. Yeah. And then latency, I think we saw somewhere between like 10 and 20 percent improvements on like time to first token specifically. So a lot of just really cool improvements across. It's higher on like longer running workloads, but so it'll roll out soon.
59:16 Yeah. But it'll get faster. Do you fight the urge? You know, I've been involved in some major rewrites. There's always like, what if we add this new thing that didn't exist before in the rewrite? Since we're rewriting anyway, right? Yeah. But then like that add scope. Yeah, yeah. So do you just like avoid that? Is it a pure rewrite? We did. It was a pure. It was maybe the thing that I would call it is like a port. What we did was we did exactly that. We like resisted the urge on all these things. And then, and because of what the team already had to keep up with was a little like swap team that we put together to go and do this was doing this while the whole rest of our team was like building features into the API, right? And they did all the like static analysis stuff that would yell at you because you built a feature over here and you didn't consider Rust over there, right? And like they dealt with all of that, but they resisted the urge to add features themselves or like make the system different.
1:00:05 Now their next goal is to go and do some sort of re-architecture type work, including stuff that I think will be more user-facing. Like we're starting to roll out some things that are like, you know, what if we were able to not have you have to like pass back and forth the entire like conversation state, right? And if you didn't have to do that on the Messages API because you were open to, like, you know, a storage of that state for some period of time, right, then, like, especially for long conversations where the context really builds up, like, you get a lot of really great latency and efficiency wins there, too. Like, these are the sorts of things that the team that was doing that port was like, ooh, like, what if we do this, right?
1:00:45 Doesn't your caching API have that? So, we have prompt caching, yeah. But you still have to, like, pass back the state of the conversation. Okay. Very, very niche, small subsets. But I guess this is the level. No, this is important. Yeah, yeah, yeah. There's a lot of savings that can be done, but it also turns them into a cloud. Yeah, and then from number of users' point of view, it's small, but if you look at the actual token volume on those types of workloads, it's going to be the majority. I'm very like, what Cloudflare did with durable objects, I feel like every cloud provider should clone. Do you know what I mean? Yeah. Like, right? Isn't that the right shape for a messages API that needs continuation? Yeah, I mean, it is really interesting. because I think what we're, we are experimenting with various, like what is the right shape of like how we should run our compute in order to power all these sorts of things.
1:01:31 But it's also interesting because we can't necessarily rely on like, because we get our compute across, we run on all three clouds, we're running all over the place. Like we don't necessarily have like one shape of, here's exactly like the compute, the types of machines that we know we're going to run on and the way that some certain compute works that we can like rely on across the board, if that makes sense, other than like the most vanilla versions of these things. But I think these things are all going to, I don't know, continue to innovate and evolve as time goes on. And so we'll be able to take more advantage of those things. Yeah. I'll just mention if people want open source Cloudflare, durable objects, Rivet is the open source equipment. There are 50 people listening that will kill me if I don't ask this question. You want CPU, they have CPU to sell. Who do I sell to? Who do I email?
1:02:16 And what is a good... help them help you, right? Like, what does it look like? Well, I guess, like, email me. Are you sure? I don't know. I'm going to get a lot of emails. But, like, you're looking, like, minimum fleet size, SOC 2, obviously, enterprise. Yeah, yeah. Give me all the privacy guarantees. And for what it's worth, like, so we have a really awesome team that secures our accelerator compute. Yeah. That is now spending a lot more time with us on CPU and, like, where and how we can procure it. to make sure that we can just continue to run our systems at the scale that we need to. And so it's not actually like my job, thankfully, is not to go and run around and try to procure compute.
1:03:00 But we do have teams that are doing that, which is really great and really important. But obviously, like, there's a quality bar that matters to us. There's like a scale bar that matters to us. We're not going to, like, go and integrate and run on certain machines if, like, we can't get enough of it. And so all the properties that you might expect of a system at this sort of scale is what matters to us. Then related to the compute problem is the sandboxing problem. People have trouble containing agents in sandboxes. They keep breaking out. What's going on there? What's the state of the art? Yeah. The state of the breakout recently. Yeah. It's interesting. One of the things that we did with Claude Managed Agents specifically is the way that we architected it. We put out this blog post at the time of launching where we talked about we have the brain separate from the hands. And what that means is like the harness runs on a durable server, really ours, right?
1:03:49 Oh, wow. Nice pull. Yeah, that's good. And the hands are like an execution environment, like a sandbox or some sort of container, right? Part of the reason why we did this was for latency and reliability and these sorts of things, right? Like if the harness is just running on a durable server and it's only spawning a sandbox or a container to execute when it needs it, that means we can get you tokens back really quickly on your initial request. It means that your sandbox can die, but like your whole agent doesn't die because the harness is durable and over here and the, you know, the agent storing state separately also. And there was a whole product development journey that we went on to get there because our first iteration of an API for agents was just like throw a Claude Code in a sandbox and like shove an API on top.
1:04:32 And the reason why we didn't launch that as our like durable, scalable solution is everything that I just said. It was like you've got to boot a sandbox and boot Claude Code before you can even get a token back, right? The sandbox dies and you lose your whole agent. And so reliability wasn't where we wanted it to be. So we architected this way mostly for reliability and latency. But the interesting thing, there's actually the product manager who worked on this from the very beginning was like, the most important property of this architecture is security. And everyone's like, yes, yes, yes. But latency and reliability. And like now. Now they're vindicated. I literally, I apologized to this person yesterday. I was like, I'm now like telling everybody who I meet about what you've been saying for months that nobody was as excited about as this person was.
1:05:15 But one of the more important properties of this architecture is you have credentials for any work that the agent needs to execute, right? Like if you're going to go talk to an MCP server or if you're going to go like use a CLI or call some API, whatever you might want to do, right? And like you need to authenticate those things. you need to store those credentials somewhere so that the agent can use them. And the way that we architected this was we have a totally separate vault where those credentials are getting stored. And as once the agent decides, like, I'm going to go and call out to one of these services, the agent only ever sees like a placeholder, right? And like on egress, we have a proxy that goes and like pulls the right credential out and injects it and lets that out. And so what's interesting about that is like the agent is never like in the same place where the credentials are, right?
1:06:06 Because in the old world of like just boot the agent in a box and like let it run, you had to send credentials in there. And then you're like doing some sort of like, how do we like scrub this and that and make sure that like the agent can't take that credential and go do something that it shouldn't be doing. It's just like literally a like literal infrastructure wall that says the agents like can't. can't access those credentials and can't do anything bad with them. So that was one thing that was really great. The other nice thing is like on that sandboxing infrastructure, we can make sure that we have really great egress controls. So we have like domain allow lists and things like that, or you just like totally shut off network access so that you can't say, okay, agent wrote untrusted code, that code executes in sandbox,
1:06:47 and that code can like reach out to the internet, right? Like now it only can reach out to where you say it can reach out to. So there's a lot of really great properties around all of this within the architecture and within the way that you can configure your sandboxes, make it so that you end up like secure by default. One of the things that's starting to happen is as we're talking to customers who are like, I want to run agents either for, you know, a product for my customers or internally. But I'm like, you know, hearing about incidents where agents are breaking out of sandboxes and bad things are happening. How do I think about these things? I think the two most important things are architecture so that it's like literally impossible for an agent to do something that isn't okay and the configuration you have on those sandboxes. And so one of the really, really nice things about Claude Managed Agents is you just like get that out of the box.
1:07:31 And you get something out of the box that like as we learn more and we continue to evolve the properties of those systems, you kind of get that for free. because I think all the words that just came out of my mouth, like brain and hands and credentials, injection and egress and all these sorts of things are just like, if you go back like nine months, like no one would be saying these words, right? Like these are all like relatively new problems that we're solving. And so we want our customers to be able to take advantage of the solutions to those problems as we're even learning about them and solving them ourselves within our infrastructure. Yeah. And internally, we're just upgrading everything to be basically secure by default. Yeah. but it's better. We also unlocked something that we covered in the direct pod which is the CloudBrain Local Hands which is projects.
1:08:15 Yeah. Is that the rough shape of what's going on? Yep. That seems right. Yeah. I feel like it's weird because obviously your famous or Claude Code is famous for being the super unsafe dangerously allowed permissions thing on your machine but now you're like finally evolving to where you probably should have started in the first place. Basically I think like all these sandbox leaks right? Are they a fundamental issue with our understanding of sandboxing or container tech, or are we just bad at this? Are we just not doing the allow list? It sounds like we're just not doing the allow list. Yeah, so maybe a distinction that I would make is in a lot of the incidents that people are hearing about and reading about, these are incidents that are happening to models, not just everybody's models, right,
1:09:01 that are in training, where the way that you're running these models is you put them in a box and you say, like solve impossible task. I'm going to stress you out. Ready, set, go. Right. And you like can only do what you can do within your environment. And the agent is basically incentivized to try to get out of his box and go solve the problem. When people are running production workloads on our API or on anybody else's API, you're running an environment where like there are safeguards that are running that are like not necessarily running in training where like the whole point is to actually train the model. Right. But in production workloads, first of all, you have those online safeguards is really great. Second of all, you have more of this architecture and infrastructure around what's happening. Like the agent isn't just in a box trying to get out, right? Like the harness is over here, the hands are over there. And it's just like not even a
1:09:47 problem that you would have to contemplate. And so I think that some of this is just like people having the right understanding that what's happening, some of these incidents that are happening in model training and otherwise are just things that like wouldn't happen in production workloads where a lot of work has been done to put the right guardrails in place so that those things like never really could happen. The second thing I would say is just like everybody's figuring all of this out like relatively newly because, you know, long-running agents is a relatively nascent thing that everybody is building and trying to deal with. And so everyone's figuring out some of these things on the fly and just racing to put the right, you know, like controls in place. And, you know, some of that is just happening as we go. So I would say it's not, you know, where people are bad at this, right? I think it's just more, it's a nascent field,
1:10:33 people are figuring it out. And I think when we talk about things like pacing the frontier, the way that we think about it is really specifically, we're doing all the work that we're talking about right here for all of our agents internally and making sure that all these things are accessible to all of our customers so that like by default, the right guardrails are just in place so that you don't end up having agents doing things that you don't want them to be doing. Fair enough. Because you mentioned pacing, we've got to go there. We also talked about this last time. It is superficially contradictory to advocate for pacing and then also release a new frontier model 11 days later. To me, it just means that it just passed your safety checks, right? Yeah. Everything we talked about earlier on how we launched the models,
1:11:19 it's like we are continuing to evolve more and more and more safety properties in place, again, across these, like, I kind of am starting to think about this in these three dimensions. It's like the actual, like, architecture and infrastructure security. Then it's the online safeguards that are running when a model is doing its work. And then it's the offline safeguards classification that's happening on data at rest. So across all those three dimensions, we're putting all the right work in place to make sure that we feel really good that we can put a model out there and it's going to be safe. And really, that's fundamentally what we mean. And so for Opus 5.5, It's an excellent model. It's also really, really great on all the dimensions that we care about across those three things. And therefore, we feel good about releasing that model.
1:12:01 So we went for what we thought, what we were hoping is the best possible user experience within this while we continue to hill climb on making those false positives better. But it's obviously like it's still a frustrating experience for people when you're trying to work with a model and then you fall back to a different model. And so it's just something we have to keep working on. I think people also understand it in the safety sense. Like you want more false positives, right? Like, it's a safety issue. We clearly see the whole invasive incident, and you're still giving access. To me, this is like a close cousin of the general model routing problem of do you want a smart router or dumb router? Does that make sense? Yes. Like, because as far as I can tell, the anthropic fallback router or detection thing is a separate model that's online.
1:12:46 Once it hits a classifier, there's just logic to what you just need to drop. So it is not the full fable. You're not running full fable at it. And that's going to cause classification issues because it's clearly not as smart as fable. Like, clearly. So then there's the question of, well, then when I have a classification issue, that's like an unjustified fallback. You never need to fall back. I'm just doing my bio homework. But I mentioned bio one time, and then it can fall back. So there's a question. Then this is very similar to the routing problem because your routing models, and how can a dumb model route to a smarter model if it doesn't even recognize this? That's a smart model problem. How do we solve this? It's a hard problem. I think in some super alignment sense,
1:13:32 models are good at classifying stuff, but not answering them, right? Not the smartest model can tell this is a dangerous query, even if it can't make any impact on that. I think the super simplifying thing to say would be like, basically you have the smarter model figured out over the one that it needs to detect. I think it's slower at X cost. There's trade-offs. There's trade-offs. I'm not saying it's like the right user experience, but it would probably be a slightly more effective route. I think one thing interesting is you also don't cut off immediately. I've seen cases where it will start answering, start reasoning, and then get hit by a safety filter. So my first example with Fable was throwing the Fable safety card. And it started, I was like, just break down anything interesting in here.
1:14:15 starts breaking it down five minutes in. I think it gets into cybersecurity and it's like, oh, we're cutting, we're rolling back to Opus. But it did a lot. There's a lot of context and I see it. It got to a point where it's all about cybersecurity, safety, and then I rolled back. And it's like, it wasn't rolling back my query. It was the combination of reasoning and the whole chain, right? Yeah. Do you have an idea of what's better? Yeah, let's brainstorm. What's better? I think the user experience and how we resolve that user experience is probably, you know, a separate question. Like maybe it's a super smart model to handle it or whatever. But I think that the more appropriate UX that I would imagine for a user is to actually have a more consistent, unified experience with Claude, where instead of getting you falling back and then you can double fall back,
1:15:00 there are like logical points in our tree that do do that for, again, like safety reasons and whatever. But I think that UX is just like really convoluted for a user. It's like you almost, you're trying to do something. And I would probably take the case of like a good user. And you're a good user, just trying to sell your biohomework, like assess the cybersecurity, like safety card, totally reasonable. And you get blocked and you fall back. And I think instead it would just be like, you are where our model should have gotten or classifiers or however we want to do this would be smart enough to detect that that is a situation that happens. And just write down the answer for you more concretely while dropping down the nature of the like negative use of that particular capability. So going back to that bio homework scenario, while we may have classifiers that have detected that it is possibly bio.
1:15:47 I'll also say like on the API, we went with a spectrum of solutions for this for customers. So first of all, like if you've built something on the API and you run into a block, like you don't have to like continue the conversation on a fallback. That's what we've done in our apps. And we've made that a feature of the API and you can do it like server side within our API. you can choose to like set, I want to do the fallbacks, right? And like, we'll do that. We also have it within our SDKs on the client side. There's helpers for if you want to like manage fallbacks in various ways, or you could choose to like reprompt differently in some way, right? And continue. with the same model. But I do think that there's some in-between interesting solutions that we'll
1:16:30 continue to experiment with to figure out how we unblock people and do so safely, but with a good user experience. Yeah. And then you brought up the bit that I was like very similar to routers. I think like, I totally agree with that. I think it has a similar UX problem as well. Like with the router you go through, it's like, let's say you want to do a cost router, right, for the task complexity that you have. Makes sense. Very hard to do. You don't know everything upfront about your task. So you can't like, even with perfect, you just don't actually have perfect information. Even if you could actually understand each model perfectly, which you don't, but even if you did, you also don't have perfect information about your task. And so there's a lot of error associated with your routing logic that you would have to create, whether no matter how good a classifier you produce. And yeah, maybe it's like a super big brain model type of problem, but regardless, it's I think a very difficult one. And in each one of those scenarios, if to find a way to route
1:17:17 that properly, it's very, very convoluted. You could expose all that logic to customers like, hey, you know, your task was to center a div, so I'm going to route you to something super cheap. And then there's other ones like detect vulnerabilities, so I'm going to route you to something like really expensive. If you expose all of that, I don't think that's like a great user experience ultimately either. And for that similar class of problem, I think the more idealized UX would be something along the lines of like dynamic effort or dynamic understanding of the level of complexity of your task, which you might actually evolve over time as you learn more and more information about the task. But in that world, if you're kind of like moving between a lot of different models, it actually becomes very, very disjointed. And so like maybe a more unified approach would be something like it's a consistent model,
1:18:01 but it's like very, very low effort level or something like that. It's actually very, very cheap and very, very affordable, but it can scale itself up very, very continuously. But you have like a very, very consistent persona towards that model. And obviously speaking about this in the context of like, you know, like our family of models, if you try to even do that across other family of models, other model providers, like the personality, the disjointedness, like starts becoming very, very complicated. I don't know how you solve it in that layer, but at least within like our family of stuff, like I'm more bullish on things that are just more consistent. And those might be ways to solve it more robustly for customers. Yeah, you're not responsible for anyone else, but within Cloud, yes. Yeah, I mean, this is your territory. Yeah. It's nice to see the way you guys think of these problems, right? Intent in and of itself is a hard problem. Like I feel like the models have gotten better,
1:18:46 but sometimes people don't do a good job at classifying what they want or they just slider all the way to one extreme or, you know, the model doesn't really understand. You're asking a simple question and it's like, oh, I have a whole HTML landing page now. I just expected a few line output, you know? So there's always a mesh around there. Yeah. I think we, in this conversation where we talked about a lot of safety, we talked about like launching the models, like all this kind of stuff, but it's obviously in pursuit of helping power the workloads for people. And like we discussed the kind of the earlier part of this conversation, we are seeing workloads change quite a bit. I think like in some workloads, intelligence does seem to be increasingly saturated, which is like a new situation. And it's getting to the place where I think there are some class of tasks that are still
1:19:32 very, very unsaturated. I actually think there are more than maybe people anticipate, but they're increasingly going into the direction of you get that alpha or that return by doing extremely long-running agentic tasks on things that historically you were not really able to brute force. but maybe you can with a lot more intelligence behind it. And those workloads are really, really fascinating to us, and we see a lot of value in that kind of area, both from businesses getting that value from themselves as well as, you know, like new companies or startups or however you want to frame it who are interested in building kind of like ejected products on top of it. I think if you look at the class of things today, a lot of it tends to be, it's obviously a lot of coding stuff. There's obviously a lot of like enterprise, innovation, acceleration kind of stuff, but they tend to take the shape of automating
1:20:15 a very distinct and specific process. And I think in some areas that's actually really starting to work, which is awesome. In some areas it still isn't, so there's still a lot of room to evolve and push the frontier for those models. And then there's this new class of workload, like the bio stuff that we talked about or some of the cyber stuff. It's just a very, very complicated set of hard engineering or hard science problem. And those workloads are increasingly showing up as well for us as a really interesting space to just deliver value to customers. You know, you are at one of the few spots in the world where you're discovering all these workloads and we're automating it. It's like... Yeah, it's pretty crazy. I mean, you know, that's very inspiring. You guys are having so much impact and I'm really grateful for that.
1:21:00 We're going to go into a few closing questions, which I thought would be fun to sort of bounce back and forth between the two of you. How do you fight Slop on your teams? So we actually, this has been an interesting debate within our team. We're no different than anybody else, right? I think plenty of teams are talking about this. And what's interesting is what we're trying to figure out is if you're producing a document, you're producing something that you want other people to consume, code, documents, whatever, right? If, like, you should use Claude to help you, of course, right? But if you use Claude to, like, totally generate a thing, you didn't spend any time on like actually reading it yourself and making sure that it was something of high quality then you're putting a whole extra burden on the consumer of that document or of that
1:21:45 code or whatever to spend a whole bunch of time trying to parse it and that's just like insane and totally unfair but what's funny is we you know we push back we push on our team like you can't do that right like if you're producing something use collage or whatever but like you have to make sure that it's a high quality thing yeah you as the human are still responsible for the quality right You're still responsible for the quality, but then you get into this really funny thing where because of the clodisms, even just like silly, like, I don't know, there's like an M dash in the middle of the thing, right? Like people's brains trigger on this like, oh, no, I'm reading something that was written by clod and not a human. And I'm like annoyed because I want to be like reading a thing that was like fully produced by not necessarily fully produced by a human, but like that has the quality bar that the human would hold.
1:22:30 Right. And so then we get into funny situations where maybe actually like the person did spend a lot of time making sure the thing was high quality, but they use Claude to help them. But there's those little hints of Claude and then the reader is like turned off, you know, like that's like unproductive as well. And so what we have kind of tried to do is like set a bar within our team that's very much like use Claude to help you because it would be really silly if you didn't use this hilariously powerful agent to speed you up in your job and in your life or to just like help you produce better things. But it has to like have a certain bar. And then for the consumer and the reader, if like it really actually is just slop, like send it back, right? Like just say no, just send it back. Like you're not going to waste your time on this. but also don't be like too nitpicky about the little quadisms, right?
1:23:17 Because like we have to find the right balance here. And so it's just really funny because we're, you know, we're going back and forth on this stuff within our teams. And just like, so is everybody else in the world right now. We're just not any different. But you have free tokens. Well, sure. But I mean, that doesn't tend to matter quite as much when it comes to life. So you have more than anyone else in the world. You probably see a lot. You guys use a lot. you see a lot more people doing a lot more. Yeah. Yeah, it's totally fair, but it's definitely, it's definitely. Heavily discouraged. Yeah. Engineering slope? Yeah, I mean, same thing, right? But I do think that where we've gotten to is a pretty good spot where like, you know, humans play a large role in making sure like designs of systems are good, right?
1:24:01 And like implementation tends to be clawed, right? And like, we're in a pretty good spot where for like a lot of the code that gets written, And like, all you really need is just like a quick stamp and you can keep going. And like, you don't necessarily have someone like deeply reviewing every single line of the code because you care more about like the overall plan, the overall like design is in good shape, less so than like the exact perfect implementation. And obviously rely on a whole bunch of verification to make sure the thing that you're going to ship is high quality. And so it's actually been like less of a conversation these days on like code quality being slop in part because collage has like gotten better, but in part because we have have a lot of the right verification in place to make sure that we're holding a high bar. I see. Trust your tests. Yeah.
1:24:45 Any product PMing slop, you can ship features a lot. You can put stuff out in a day. So he said this to me recently. Do you remember what he said to me? Tarek tweeted this. The right way to use model capabilities is not to ship 10x more features into prod. Spend more time understanding your users, trying experiments, building, whatnot. But basically, you could very easily just keep shipping random stuff, but you should actually think about it. You should spend more time kicking off that first prompt. I know now today he's like, kick off plan mode. We don't need it anymore. But outside of plan mode, you should think about what you're doing, right? It's very easy to put out a lot and you can get products solved. Yeah. I mean, I tend to kind of go on this rant about, there's a lot of just like fundamentals
1:25:30 about how software gets like, and products get planned and shipped and otherwise that like, doesn't need to change just because agents are like helping speed up certain parts of the process. But there's this inherent like almost laziness is starting to come out from a lot of people where it's like, oh, I don't have to like think about some part of the process at all because the agents are doing it and helping me or whatever. But like those are still like incredibly foundational parts of the process that like should be things that you're spending your time and energy on. And I think that's kind of the spirit of what he's getting at here. It's just like as a founder or creator, let's call it as well. It just feels like because the cost of experimentation or exploration is so low now that I should be doing more of that. And he's basically saying to not do
1:26:16 that, to like use it in service of a very intentional goal that I start from the start, which like obviously I'm coming around to. It's just hard. It's like you have this toy. does everything. It's just like, throw it at the wall. Yeah, there is scope too. So like the blog post of today was two weeks to make Cloud AI faster. There were 12 things. We hit, there were 13 things. We hit 12 of the 13 targets in three days, right? Well, you could just stay, okay, it's a two-week sprint. We'll do the 13. But instead, there's 20 things you push bound. This is not product slop. It's not new products. It's refactoring. But still, you guys do a very good job at outputting a lot but keeping high bar quality. Yeah, nice. Okay, part two or three. This is going to make Angela very uncomfortable.
1:27:00 This is Angela Tweet Corner. I will tell... Nice. I don't know. I will tell people nonstop to... And I'm pretty sure you've deleted stuff. Because I'm like, there's stuff in your deletions that I'm like... That you liked? Yeah, I know. It really altered my DNA. Oh, I appreciate that. What do you think about the most? what do you refer people to the most that you want to sort of bring up? And I can pull it out for you if you want. I actually, I don't think I have a favorite, honestly. Oh, come on. No, I really do. Okay, I guess maybe I like the one that you say where it's half doing something is an expensive way of not doing it. Maybe that's my favorite. That's very on topic for us today. Okay, nice. Okay, thank you. Love it. It's it, yeah.
1:27:45 I guess, you know, obviously you're in a different job now and you don't do this anymore. but like uh i think this is a power tweet this is like a naval robincon there's naval as you yeah that do this uh-huh and like what mode what mode of what like what framework of mind frame of mind are you in that's a good question yeah no this was a very long time ago um i went through a period of my life where i was like reading constantly actually i found myself like very bored um of the stuff that i was doing and i felt like i was just like not being like intellectually challenged. And so I actually went on this a bit of a bender where I think I read something like 200 or so books in like a year. And I was just curious about like, I just wanted
1:28:32 to like read everything. And I was missing a little bit of like the kind of like intellectual, like, I don't know, like muscle building you get when you're like in school, where they like, this is a new topic, you got to learn. It's like tough. It's like not super fun, actually, but you are really like stretching yourself. And I felt like after just like working for a couple of years, I just like stopped doing that. Like, yeah, the job's like interesting. And yes, it's like challenging, but it doesn't have like that like intellectual bit to it. So anyway, I went on this bit of a bender, a reading bender and I like read like 200 bucks in a year. It was great. I had like a really long commute. So it was like, it was a good use of my time. Very long like Caltrain ride. But I ended up coming out of that and being like, I was just like thinking a lot as a result of that. and at the time it really wasn't to build like a Twitter follower or anything.
1:29:17 I was just like tweeting into the like abyss. There was like, I have like no followers. These were like tweets for myself and I was like practicing a little bit of like, how would I try to compress the idea that I have in as few words as possible? It was kind of like the personal test I had for myself. And then I guess people just started liking it. And so I just kind of just kept going at it. And then I got too busy with work and I stopped doing it. I gotta ask after all the reading, any book recommendations, blogs, long articles? My favorite one still is probably The Black Swan by Nassim Taleb. That was like one of those, to me at least, it was like a bit of a life-changing philosophical book where I was like, that's a completely different way to look at the world.
1:30:01 You know, I was thinking of Black Swan when the fable thing happened, right? It's a thing that you didn't know could happen. Now that it happens, it permanently changed your framework of how things work. Exactly. And the idea is so simple, but I think he did a great job of just really hitting it home and articulating it and how it's a common property of so much of the world. So I really love that book, and that's probably my favorite. And for listeners, if you're bored with that one, you do Fool by Randomness, also by Taleb. Did you like Hinky, Fragile? Less so. The more famous he got, the more intolerable he became. but also question for kaylin my if you do have one do you have a similar like this is a book i recommend to everybody no that's a good question i need to think about it it is funny because i do
1:30:45 think we have very different styles on this front like she's no longer like in fortune cookie tweeting mode but i do think that like you stop that but i do think a big part of how you work and how you work with other people is like philosopher mode sometimes you know fortune cookies and slack oh i i do actually not intentionally i think it might just be somewhere i think that's his core success of succeeding in topic is like you have to be very good on slack yeah oh you have to be very good right um it is it's a pretty intense place but i think i'm a little so i'm kind of psycho about like inbox zero on both email and slack it's easier on email these days than slack um but i like pretty aggressively prune like here are the channels that i'm like actually in and paying attention to you versus the ones that are like muted below the line sort
1:31:30 of thing. And I'm like always making sure that I'm on top of the ones that I need to be on top of. But it is it's basically it feels like a full time job. Like there are days where I'm like, I could cancel all my meetings and write no documents, do no work. Right. And literally just sit there like on Slack the entire day. And I would have done what felt like an entire day's worth of work just by like engaging on Slack with all the things. It's pretty wild. No, but that's horrible. So that's exactly how I feel. I feel like you do all this. You put in all this effort. And yes, like you met the mark on like responding to people and getting certain things over the line. We didn't actually produce the output that you wanted to. And like, that's like a, that's like personally a very hard thing for me to deal with. So I try to be like, I need to like dedicate time to like actually thinking and actually like trying to produce something in order to feel like I'm like actually. And ignore and drop stuff, right?
1:32:15 You're going to drop stuff. Yes, I have gotten a lot of feedback. I'm a little hard to reach on Slack. Yeah, pretty terrible thing that happens now is I get a lot of Slacks saying, can you get Angela to respond to this? And I'm like really trying to write a doc here. So you guys don't have like a personal cloud assistant something? I don't know if it's going to help you. So why has no one written in a personal EA for each of you? Yeah, well, so we do have a human one also. We have plenty of cloud help in Slack for sure. But I do think actually the types of Slacks that I'm like when I'm pruning through and getting are often just like our team is like blocked on something because there's some hard decision that needs to happen or whatever it is, right?
1:33:00 And it's like, it is just like a form of, whether it's in Slack or some other way, right? Like it's a form of getting the team unblocked, like executing in high quality. That is my job anyway. And it like happens to happen a lot in Slack. But I do agree that it ends up feeling like, what did I even produce when you get through a whole day worth of literally just like going back and forth with people and trying to solve problems. You produced a functioning team. Yeah, exactly. That's unblocked. So I will give you a props for that as a former manager. That is, yeah, yeah, yeah. You don't feel like you produce anything, but like you produce the team. Yeah. Yeah. Speaking of your team, I was going to go to you next, Katelyn. DevRel Corner. Oh, nice. We are, I know you're really hiring DevRel, so I'm going to make a call offer for developer relations. Nice. You hired Addy Osmani recently.
1:33:45 Yeah. Great get. Lance, you know, you still don't have a team. what do you guys want to hire for? You know, this is it to talk about it. And I'm happy to trade notes. Yeah, well, props to you because I will say when- I'm the all-source Anthropic recruiting, Katelyn recruiting team. Literally, literally. It's fun. And it's actually not even just recruiting. Like I'm gonna toot your horn a little bit. So when I joined Anthropic, we, you know, we're a small team. We're like all things considered, we're an extremely small team. And so we run the platforms, the API business and all of our product infrastructure. And we had, like, a very nascent DevRel function within Anthropic that was, you know, like, not necessarily within the product and engineering org.
1:34:30 And when I joined, we were like, okay, we, like, need to grow up a little bit and need to figure out how to, like, engage with the community, engage with the world. And we need to, like, really invest in this DevRel function. And we ended up spinning up a DevRel team within Platform and a DevRel team within CloudCode, in part because it's like two pretty different like developer ecosystems that we're trying to engage with across the API business and Agenda coding, right? And so we ended up doing it as like two separate teams, but kind of like dotted line to each other and spend a ton of time together. but it was something that I was going to be responsible for like DevRel which I've spent plenty of time with DevRel before Stripe or otherwise but it was never something that I was responsible for and I was like I have no idea what I'm doing and you were like I got you
1:35:16 like here are the three pillars of DevRel like here's how you think about it which is really great across like product content community and now I can like rattle that off to people and they're like wow you really understand DevRel I'm like no so it's Tommy you're like I copied that that was not a ritual That post is apparently like the default reading for Google when they onboard new DevRel. Yes. It's really funny. Yes. It really like this really helped me because I had no idea what I was doing. But then on top of that, I don't have a manager for the DevRel team within Platform right now. And so that's one of the things that I'm hoping to hire. And our DevRel ICs report to me directly, in part because I think it's a really, really, really hard problem right now. but also in part because I find it really fun and I'm having a lot of fun working with the team.
1:36:03 But really specifically, like what's hard on platform is platform in some sometimes in our like public narrative, like our platform business is a really large business, but it can kind of get lost in between research and policy and all this work that we're obviously doing. That's like our most frontier important work. And then our applications like Claude Code and Cowork and all the things happening over here. When you think... about Anthropic and you think about our public narrative, those are some of the things that often come to mind and less so that we're running this like massive developer platform business that's really important and so many people are building on top of. And so a big goal that we have with our DevRel team within platform is figuring out not only like the really classic, like how do we better engage with like, you know, product, like
1:36:46 what people are building and how we get feedback back into the product and these sorts of things, but a lot of it is just like finding our voice and finding what our brand needs to be and what our narrative needs to be, and like who we even are going to be in the community and not kind of get lost in all of the things that are happening. And so that I think has been interesting because I think the brand that we've started to spin up for our DevRel team, in part because actually Lance joining our team was you connecting me with Lance, but Lance is highly technical in the way that he goes about DevRel is very much like teaching, right? Like he writes a lot about memory and managing costs and these sorts of things. And he goes really deep. He builds evals. He has a lot of really technical content that he puts together. And I really like that idea, that idea of our DevRel team being kind of like thought leaders for people within what is a really nascent, really hard, really evolving space.
1:37:36 Educators, thought leaders, explainers of things. There's another version of this I really like called the Master Builder, which is I will build the things with the platform to show you what's possible. And then you'll be like, oh, I didn't know that was possible with the Claude Platform. And then you just go. And this is a thing stolen from Lego. because Lego, how do they sell Legos? They have master builders. They build things with Legos and you're like, I want to do that. I want to be like this person. And then they do that. Nice. That's awesome. Yeah. And CJ, the other person on our team, who's really great as well, I think he also does a lot more of that sort of like, you know, writing cookbooks and like putting out examples and really engaging with the community on X.
1:38:16 Cookbooks is funny, right? Like when APIs launched in 2023, let's call it for LMs, very important. Now, I don't know. Yeah, well, it's interesting because you're less in the spot where you'd like copy paste the code and like use it, right? But I do think it's like it shows the art of the possible for people. And just like what even is the use case, right? And like how can you go about accomplishing it? But I hear you that like, you know, the code itself is maybe less. Like we for the longest time had this like there's an engineer on our team who wrote our cookbook on computer use. and it like haunts him to this day because it was like massively complex and like, you know, kind of a beast of a thing that I think, you know, a lot of people got use out of at a time
1:39:00 when it's like, I'm going to build a computer use implementation and I'm going to deal with all the screenshotting and all the things, right, that are happening between the messages API. Yeah, we're there for the hackathon that you guys launched in the office. Yeah, yeah. And like that was the era when you like needed to have that sort of thing. And now, you know, it's much more about We have a skill like the Cloud API skill. It's like really, really excellent at helping you either within Claude Code or any other coding agents to build a really high quality integration. And now like these sorts of things like I'm going to build a computer use integration. Like how do I go about doing that? Like very few people I think slash hope are reaching for the big gnarly cookbook and more so they're loading up the skill and encoding agent and working. Yeah, or they're just putting it to a reference architecture. Yeah, it actually does much better. like increasing or seeing that for a lot of the things
1:39:45 that you might want to have different implementations on, typically at the harness layer, but there could be other variants. You just point Cloud at it and you say, this is the reference architecture I want. Yeah, then you build it. Fun fact, the Cloud API skill that helps SQL build against the API is owned by our DevRel team. So that was built by Lance. As they should. Right, exactly. This is the most high leverage form of DevRel is to distill everything that is the best practices that's going to go into those agents. Yeah. One of the reasons, It's weird because I'm regarded as this DevRel person or authority. But there's some part of me that just wants to tell you you don't need DevRel. You get so good you don't need it. Right. Or you turn the engineers, the leaders, into the public faces.
1:40:30 Because all you really are trying to do is public faces and here's how we do things here. And that's kind of it. You're anthropic. You don't need people to hear about you. So I think to me, when Boris burst onto the scene, it seemed like a very like, hey, I'm Boris and the creator of Claude Code, blah, blah, blah. That's how we do things. Yes, he has the day job, but he's also doing that functionally. So why doesn't everyone just do that? Yeah, I mean, it's a really good question. And there are teams that have done this really well. I think the Cloudflare team is a really great example. They're all pumping out stuff. Non-stop. Yeah. And to me, that's actually a very visible sign of a good manager is that they're all happy at their jobs. They're all like publicly identifying. They're not quitting. Yeah, totally. It's interesting because I think
1:41:17 this is actually something we are trying to do more of with the platform team and with our team and folks who, you know, can kind of just get out there and like be part of the community and be speaking and be on X and be wherever they are, right? I think the problem for us is just like having time and kind of knowing the right way to do that stuff at high quality. So I see the DevRel team in some ways as just being like the experts in doing this sort of stuff at quality. They can do it all day, every day, and they can help enable the rest of the team to think about how to do this with the small amount of time that they are able to spend on this sort of stuff to do it at high quality, too. Yeah. So I call this kind of the unbundling of DevRel into a front office and a back office. So like a typical person who does this job does the whole thing.
1:42:02 Start to finish, they're kind of autonomous. But actually you can sort of build up this back office that lets your product leads and engineering leads actually take the spotlight with a simple contract of like, okay, you sit down with me for 30 to 60 minutes and we'll do the brain dump and then you're done. You go back to work. And then we'll like ghostwrite for you, whatever. But like that team of like production people, writing people, whatever is sort of provides the service to the rest of the people. and I think that to me that's like kind of the future of this stuff to be honest because people like don't actually really want to hear from DevRel they want to hear from Lance and like you know and you have like lots of Tariq you know and Lydia you got Lydia through Bun
1:42:45 you know exactly but like he he does the job he does the job and so like you want more of those because people people want to hear from people in the product not like who are like paid shows I paid spokesperson. Which I get a lot of. And that's fine. That's a job. Somebody has to do it. Reasonably, you can expect people who are working on engineering to not be good at it. So you should pay someone who specializes in it. Specialty is a skill. I think there is a back office, front office separation that can emerge. Yeah, that is really cool. Yeah. And my analogy would be like everyone hires, but you have an HR department. HR department enables you to hire. Indeed. You hire. Yep. Yeah. Makes a ton of sense. Cool. That was my soapbox.
1:43:31 Closing questions. You've been very generous over the time. Any parting thoughts or calls to action? What's something cool on Opus 5.5? What's something people should try to push the bounds with you, Opus 5.5? You guys have been using it for the longest. Yeah. I mean, it's really cost efficient. It's less verbose. All the things we mentioned, the vibes are really, really high. It's been fun. Yesterday was a really fun day for us because finally again, And I got like a whole slew of texts from friends and people who were just like, amazing model. Thank you. Like one of my old bosses messaged me and he was like, Opus 5-5 just saved our butts in an incident. Right. And it's like, OK, great. Like we're back is really the energy that we feel. And so I think things that like maybe you wanted to experiment with something and like cost was something that was front of mind for you.
1:44:18 Right. and token efficiency and these sorts of things, that kind of might have held you back from really firing it off and letting a model run. I think those are the sorts of problems you should return to now with Opus 5.5 because I think you'll be able to get a lot further than you maybe otherwise would have been able to with models that were less cost-effective. I think you should try something with a multi-agent setup. I think you will find it to be very good. Any other hints, by the way? I mean, multi-agent is very broad. Nope. I think we'd be very curious to hear what people build. But yes, it should be extra good. Yeah, including, let's say, roles that are not strictly defined, but they are assigned among themselves. Right? Which is, to me, the new thing.
1:45:00 You can assign roles. You can always assign roles. You can give tokens jobs. But this is like, they're giving themselves jobs. Yes. I guess, say more on multi-agent, right? Like, should we use sub-agents? What do you... How should people think about multi-agents? This is pretty good in a sense of like basically, generally, you want to have one lead and you want to like split up like a bunch of different stuff. And as long as you can have a task that you think could be generally paralyzable and they share uniform context across it, I think you will get a lot of gains. Now, of course, it depends on the problem that you're pushing at. But like increasingly, this is a very superior way for us to handle a lot of these things. And especially if every sub-agent is, or whatever you want to call these sub-leads, they are asynchronous and they're not blocking of each other.
1:45:47 That is, like, the only two bits I would say you should care about in your architecture. Other than that, like, let it rip and, like, see what Claude designs for you. And increasingly, I think a lot of this architecture stuff will fall into this direction. Like, Claude will get smarter and smarter. It's going to learn how to figure ways to, like, split itself, clone itself, adjust itself to the architectures that make sense. You just need to prevent it. You just need to make sure it can, like, parallel process. So it needs a shared state and it needs to like not block its sub agents. And as long as you contain those two principles, honestly, I think people should experiment and probably try some really crazy stuff. And I wouldn't be surprised to see some like really interesting things on top of that, that maybe they felt like there was some intractable problem that was really annoying and they'd keep pushing for. like this could actually probably just like crush it and maybe one shot or something. Excellent.
1:46:30 All right, everyone go build. Cool. Cool.
来源：Latent Space · latent.space