How Anthropic ships the #1 LLM in the World — with Katelyn Lesse and Angela Jiang
Summary
- The opening’s IPO case rests on a sharp improvement in employee and capital efficiency. Citing Anthropic’s S-1, the host reports $6.6 million in trailing-12-month revenue per employee versus $1.4 million a year earlier, and a first profitable quarter at 19% on a GAAP basis versus a loss equal to 129% of revenue. The opening also puts lifetime fundraising above $100 billion and burn below $10 billion, with an IPO expected “in two weeks at a $2 trillion valuation.”
- Claude Platform gives Anthropic a business that extends beyond selling access to model intelligence. The opening says more than 50% of customers with at least $100,000 in trailing-12-month revenue use the platform, whose primitives also underpin Claude Code and Cowork. Managed Agents adds infrastructure and harness management, complementing the host’s framing of Anthropic as a cloud platform.
- Opus 5.5’s pitch combines stronger economics with a more usable model. Katelyn Lesse highlights price cuts, less convoluted writing than Opus 5, and demand for “good intelligence per dollar.” The guests qualify the host’s “top model” description with “depends who you ask”; the opening’s prediction that Fable 5.5 will probably follow within two weeks comes with an explicit “I don’t have insider information.”
- Safety engineering has become a major component of the model-release workload. Releases now require decisions about retention, online safeguards, offline review, verification programs, and authorization throughout the stack. Anti-distillation measures preserve thinking blocks while accommodating legitimate compaction. Katelyn explains the safety rationale; the host says safety, rather than commercial impact, is the main concern and notes that distillation usage pays Anthropic.
- CPU availability is becoming a material constraint alongside accelerator supply. The guests describe APIs, sandboxes, research, and growing CI activity competing for Anthropic’s allocation. A Claude-assisted port of the Messages API from Python to Rust delivered roughly 40–50% CPU savings and a 10–20% improvement in time to first token; the critical human contributions were “the plan” and “the verification.”
- Separating the agent’s brain from its hands turns security into an infrastructure property. Managed Agents keeps the harness durable, execution isolated, and credentials in a separate vault, with an egress proxy injecting secrets the agent never sees. That architecture also improves startup latency and resilience when sandboxes fail; a guest says a colleague who prioritized security was vindicated.
- Evaluation and personalization remain unresolved constraints on product quality. Different customers want conflicting levels of initiative, and the guests admit, “We don’t do a great job of it.” Their response combines broader eval suites, adjustable effort, and managed harnesses; Angela Jiang is more bullish on a consistent Claude that dynamically changes effort than on visibly switching users between models.
- The next workload opportunity is longer autonomous work with stronger verification. Angela sees some tasks approaching intelligence saturation, while difficult engineering and science problems remain open. The closing multi-agent advice is one lead, shared state, and asynchronous workers that do not block each other; throughout, humans retain responsibility for quality, because faster implementation is no excuse to ship “10X more features into prod.”
Deep dive
1. The IPO framing centers on efficiency and a broader platform business
The opening host says Anthropic filed its S-1 that day and frames an IPO expected “in two weeks at a $2 trillion valuation.” He contrasts reported lifetime fundraising above $100 billion with lifetime burn below $10 billion. These figures establish the episode’s opening question: how is Anthropic shipping what he regards as the strongest models while building its business unusually efficiently?
The cited operating figures describe a sharp reversal: trailing-12-month revenue per employee rises from $1.4 million to $6.6 million, almost fivefold. The host says Anthropic was “losing half a dollar for every dollar of revenue” in Q2 2025 and now generates $2 of revenue per $1 of cost. Its first profitable quarter shows 19% GAAP profit, versus a prior loss equal to 129% of revenue.
The host explains the improvement through two reinforcing loops. Better Claude models unlock use cases, adoption produces feedback, and feedback improves Claude; separately, adoption increases revenue and growth, attracting investment that funds more capability. He presents these as the S-1’s “improvement loop” and “investment loop,” linking product performance with the resources available to keep improving it.
More than 50% of customers with at least $100,000 in trailing-12-month revenue reportedly use Claude Platform. The host emphasizes that Claude Code and Cowork use the same exposed primitives. He interprets Anthropic’s positioning as moving from chatbots and copilots toward “virtual collaborators”: systems that own goals, use tools, self-correct, and work alongside people across longer tasks.
2. Opus 5.5 targets intelligence per dollar and clearer communication
Asked to celebrate the “top model in the world,” the guests immediately qualify it: “Depends who you ask.” Katelyn is particularly pleased that feedback about Opus 5’s convoluted writing translated into a cleaner successor. Price cuts address a separate demand: customers increasingly care about “good intelligence per dollar,” so the team must improve both intelligence and its cost.
The opening was recorded around the Opus 5.5 launch and describes strong reactions from the host’s testers. His additional prediction that Anthropic is sitting on Fable 5.5 and will “probably” release it within two weeks is explicitly speculation: “I don’t have insider information.” He connects that timing to the anticipated IPO rather than presenting a confirmed release schedule.
Katelyn describes product’s role as balancing intelligence, safety, cost, and commercial impact; she says engineering emphasizes integration and developer experience. Their technical product managers and product-minded engineers deliberately overlap. Asked whether software engineering being “solved” will merge the roles, Katelyn rejects that strength of language: “Ambitions will continue to elevate,” leaving substantial operating and design work for humans.
3. Anti-distillation changes protect safeguards while preserving legitimate uses
The discussion of “Stealing Reasoning Traces from Proprietary LLMs” starts with responsible disclosure, which both guests welcome. Katelyn says the paper exposed a gap Anthropic already understood: extracting chain of thought is “one of the most powerful ways that you can distill models.” The engineering question was how to close that avenue without making useful API integrations substantially worse.
Katelyn’s rationale centers on safeguards: Anthropic classifies generated tokens to reduce harmful outcomes, while a distilled model could run without those protections. The host, not Angela, says the primary concern is safety rather than commercialization and notes that “if you distill from us, you actually pay us.” His concern is a derivative of Claude being used negatively without the surrounding safety systems. Angela separately says distillation has become significantly harder in the areas Anthropic can measure.
The team distinguishes two kinds of user-experience damage: an annoying integration migration that preserves capabilities, and a change that makes previously possible work impossible. They especially want to avoid the latter. Preserving thinking blocks across turns, and tightening their treatment across accounts, required separating legitimate workflows from extraction techniques rather than simply banning every manipulation of reasoning traces.
Compaction supplied the concrete test. Some customers’ existing strategies would break under preserved-thinking requirements, so Anthropic worked with customers and open-source harness maintainers and shipped an API compaction feature compatible with them. Angela does not claim complete visibility or that extraction has been eliminated.
4. Every model now needs its own safety deployment policy
The guest discussing release safety frames it across three dimensions: architecture and infrastructure security, online safeguards operating during generation, and offline classification of stored data. Capability determines the work required. Katelyn adds that specific spikes in biology or cybersecurity can demand different treatment depending on whether capabilities appear offense-dominant or defense-dominant, rather than treating all intelligence improvements as equivalent.
Retention addresses behavior that may not be recognized while an individual request streams. Networks of accounts may collectively reveal malicious use or distillation, requiring automated or human review. Angela explicitly distinguishes models: Opus 5.5 does not carry the data-retention requirements Fable has. Those requirements are decisions made for individual releases, with engineering needed to enforce them.
Cyber verification and the newer life-science verification program let approved users access dual-use capabilities with reduced safeguards for specified purposes. Legitimate vulnerability research and biological research are the examples. Authorization must follow the request throughout the system; Angela contrasts that with casually issuing a key and flipping a feature flag. Launching these programs is now part of launching the model itself.
5. Generic trust grants make uncertain deployment scenarios manageable
Fable’s rollback becomes Angela’s example of a roadmap that cannot rely on confidently forecasting use cases. Something the team would not have predicted nevertheless happened, establishing a nonzero probability. Her response is “deeply probabilistic” product management: build “a portfolio of bets,” including controls that may never be needed but provide options if an unusual situation returns.
The access system began with granting particular users particular capabilities, but the team chose more generic primitives than conventional product scoping might favor. Those primitives proved useful for broader model access, trusted programs, and model deployments. Work toward a single-button rollback extends that same foundation. Angela says this generic approach has repeatedly paid dividends, while leaving the value of any particular hedge uncertain.
A “trust grant” is ordinary authorization expressed through Anthropic’s own data model, not a fundamentally different security concept. For Fable 5.1’s preserved-thinking rollout, existing customers received a grace period to update integrations; grants tracked those exceptions. A service on the request’s hot path checks whether the requester holds the relevant permission, allowing the same mechanism to support multiple policies.
6. Model feedback is most valuable when external harnesses expose failures
Model launches move through candidate versions, evaluation, internal dogfooding, and selected external testing. Customers such as Cognition provide a different harness from Anthropic’s own products, which matters because Claude is intended to generalize. Angela wants both formal results and subjective reactions: “Do you like it? What don’t you like?” Negative feedback is often the most useful input for further improvement.
The host’s pushback is that feedback still resembles a Slack channel saying, “Hey, this thing seems weird.” Angela agrees the process can be informal, partly because the team is “racing” to minimize the interval between a testable model and broad availability. Early-access customers therefore tend to have robust eval suites capable of producing actionable evidence quickly, alongside subjective impressions.
Laziness versus initiative illustrates why outside testing matters. One customer wants Claude to “just finish my task”; another is still planning when Claude unexpectedly writes code. Katelyn says getting that spectrum exactly right for everyone is “literally impossible.” In one case, excessive laziness led the team to put a candidate “back in the oven,” a problem internal product usage might have missed.
7. Personalization exceeds what today’s parameters can express
The host uses a code benchmark to challenge model evaluation: a benchmark can penalize excessive activity or file creation even when a user’s CLAUDE.md instructions could suppress that behavior. Is the benchmark then unfairly penalizing the model? The guests’ candid answer on evaluating personalization is, “We don’t do a great job of it.” A constitution can help, Katelyn says, but does not resolve conflicting preferences about how assistance should behave.
Effort provides a limited customization mechanism. The conversation specifically identifies Claude Code’s default as medium, while Katelyn says defaults can differ across free users, prosumers, enterprise, Cowork, and API use. The preference is for “gentle defaults” with user control. Some users want maximum intelligence; others benefit from lower effort and faster responses, making a single aggressive default difficult to justify.
Katelyn describes a “funny mishmash” of effort, budgets, and other parameters, with no obvious combination for every task. Choices include whether to expose low/medium/high or a 1-to-100 scale, and which controls to retire. As the number of customers grows, she says relying on judgment calls about conflicting preferences will not scale indefinitely; richer ways for Claude to absorb personalization will be needed, but are not solved today.
8. Managed Agents packages the harness while leaving room for experimentation
Angela distinguishes the Messages API’s “raw token access” from Claude Managed Agents, a higher abstraction that lets developers define an agent and start a session. Anthropic supplies infrastructure and a harness, including work to accommodate new model parameters and breaking changes. The value is programmatic access without requiring every customer to repeatedly rediscover how to get the best behavior from each release.
Managed Agents shares substantial infrastructure with first-party products, including the sandbox fleet, although shared infrastructure does not mean identical harnesses. Angela says the provided harness is “intentionally simple”: it incorporates useful practices and handles difficult but undifferentiated parts of the agent loop. More opinionated strategies can then sit above that foundation instead of being imposed on every developer.
Asked whether memory and dreaming have stalled, Angela acknowledges that some feature work has slowed relative to earlier in the year as safety consumes more attention. That is not an abandonment: “We love skills.” Memory and dreaming still address continuous improvement, while the team increasingly wants developers to extend existing primitives and Anthropic to concentrate on providing safe access to model capabilities.
Dreaming is itself a multi-agent construction: another managed agent examines the previous agent and writes memories for it. “It’s managed agents all the way down.” Angela also names best-of-N and verifier agents as possible strategies. An update expected “relatively soon” would expose underlying primitives and templates so developers could construct their own variants, rather than only consuming Anthropic’s particular dreaming implementation.
9. Agent engineering increasingly resembles experimental research
Angela’s eval advice is breadth: “You probably need more rather than less.” Static deterministic checks and LLM judges serve different purposes; a small supposedly perfect suite will not answer every question. She also recommends starting simply. Debating an elaborate menu of evaluation methods while having zero actual evals is worse than implementing a basic useful check and improving it.
The host proposes treating engineering like research: define the goal, formalize an eval, label results, prototype, and scale runs. Failure diagnosis must consider at least three possibilities: the eval is wrong, the environment is wrong, or the model is wrong. Katelyn agrees that “a lot of the time your eval is wrong.” This imports habits familiar to model researchers into application engineering, where satisfying a conventional product requirements document previously dominated.
Claude can help build both evals and the interface for grading them. The hosts contrast intimidating JSONL files with a usable left/right comparison UI, where people add ratings and comments. Those judgments become feedback Claude can consume to improve the system. Katelyn anticipates Managed Agents tooling that feels like working with Claude to create evaluations, rather than requiring a separate unfamiliar workflow.
A performance blog supplies an example, but the transcript gives differing figures: the host first says 9 of 12 targets were done in about three days, then later says 12 of 13 targets were hit in three days during a two-week effort. The discussion considers expanding the improvement list rather than treating faster implementation as a reason to invent unrelated products. The guests also enjoy publishing actual prompts because the method is often less exotic than imagined: sometimes it is simply, “Try harder, Claude.”
10. CPU demand now requires the planning once associated with accelerators
Katelyn says CPU scarcity is “as much of a problem today as the accelerator layer.” Capacity that teams once expected to obtain on demand, provided they had budget, now requires advance planning. VMs and sandboxes are part of the constraint. Her account is not confined to Anthropic: she says other people she talks to across the industry are encountering similar shortages.
Product services, APIs, applications, sandbox execution, research, and CI all draw on CPU. More generated code means more CI runs, adding demand beyond the agents’ immediate work. Research and product sandboxing do not commingle, but CPU allocation across the company remains “a zero-sum game”: Anthropic secures capacity from cloud providers and must divide that supply among competing internal needs.
The response combines procurement, more efficient sandbox infrastructure, and application efficiency without compromising tenant isolation or security. Scale and quality determine whether another supplier is worth integrating. Anthropic also runs across all three clouds, limiting reliance on a single provider’s specialized compute shape; the guest says the common foundation often has to be the most vanilla capabilities available across environments.
11. A Claude-assisted Rust port cuts the Messages API’s resource cost
Katelyn says that when she joined a little over a year earlier, the Messages API was a Python monolith in one GCP region. The team has since expanded across regions and confronted a CPU wall. It chose Rust despite initially having no Rust developer in the room. Claude would write implementation code; humans would design the distributed system and learn what they needed to operate it.
The crucial work was “the plan to do the thing, and then the verification of the thing.” The team built an entire Rust counterpart and sent shadow traffic through it, comparing outputs against Python before gradually enabling production traffic. The conversation contrasts that with the incremental, multi-year migration previously expected. A few more experienced Rust developers were hired along the way.
The guest describing the port says the Rust Messages API had fully rolled out the previous week. The reported ballpark savings are roughly 40–50% on CPU and approximately 10–20% improvement in time to first token, with greater improvements on longer-running workloads. These are operating results from the port, distinct from the separate blog example about making Claude.ai faster in a few days.
Scope discipline mattered: it was a port, while the rest of the organization kept adding API features. The migration team used static analysis and coordination to maintain parity, resisting redesign. Later opportunities include storing conversation state so clients need not repeatedly send the entire history. Prompt caching alone does not remove that transfer; long conversations may be few by user count but substantial by token volume.
12. Separating brain and hands improves durability before it improves security
A guest explains that Managed Agents could initially have been Claude Code placed inside a sandbox with an API attached. That was insufficient: callers wait for both sandbox and agent startup before receiving tokens, and a dead sandbox can kill the agent. The eventual design puts the harness on a durable server, keeps state separately, and spawns execution environments when needed.
Reliability and latency initially dominated the team’s explanation. A product manager kept insisting, “The most important property of this architecture is security.” The guest says they apologized to that colleague the previous day. The change of mind matters: separating orchestration from execution supplies security properties that were less obvious when the team primarily evaluated the architecture through product performance.
Credentials live in a separate vault. The agent sees a placeholder; when it calls a service, an egress proxy retrieves and injects the appropriate secret. This avoids putting raw credentials inside the agent’s execution environment and then trying to scrub or conceal them afterward. The guest calls the separation a “literal infrastructure wall” between the agent and those credentials.
Sandboxes add domain allowlists or completely disabled network access, constraining what agent-written code can contact. The guest emphasizes both architecture and configuration when customers ask about containment. Managed Agents packages those controls and subsequent improvements: customers receive evolving protections as Anthropic learns, rather than having to independently reconstruct every credential-handling, networking, and execution decision as the field changes.
13. Training breakouts and production deployments have different conditions
Challenged on whether sandbox escapes indicate defective technology or poor implementation, a guest distinguishes training incidents from deployed systems. Training may effectively tell a boxed-in model, “Solve an impossible task. I’m going to stress you out. Ready, set, go,” incentivizing escape attempts. Production can include online safeguards and separated infrastructure absent from that setup. The guest cautions against treating those environments as interchangeable.
The host also questions advocating “pacing” while releasing a frontier model 11 days later. The response is that pacing means doing the security and safeguards work needed to feel comfortable releasing; Opus 5.5 met those requirements. The guest still describes long-running agents as nascent, with teams figuring things out and racing to install controls, rather than presenting the surrounding engineering as finished.
14. Safety fallbacks expose the same unresolved problem as model routing
False positives can interrupt benign work. The host describes asking Fable to analyze its safety card: it reasoned for about five minutes, reached cybersecurity material, then fell back to Opus. The trigger appeared to involve the evolving reasoning and context rather than just the initial request. A user doing biology homework could likewise encounter a block despite a legitimate purpose.
The host’s objection is that a less capable classifier may misjudge work performed by a smarter model. A guest responds that classification and answering are different capabilities: recognizing danger need not require being able to carry it out. A smarter judge could help, but introduces cost and latency. The guests acknowledge the problem without claiming a definitive solution.
Angela explains that the API exposes several choices. Customers can opt into server-side fallbacks, use client-side SDK helpers to manage them, or re-prompt and continue with the same model. The apps’ fallback behavior therefore is not the only available integration. Angela would prefer a more unified experience that answers the benign part appropriately while reducing access to the problematic capability.
Angela connects this to ordinary cost routing: neither the task nor the model is perfectly understood upfront, and new complexity emerges during execution. Visible switches can make the experience convoluted and personalities inconsistent. She is more bullish on a consistent model that starts cheaply at low effort and scales effort continuously as needed. Across different providers, she says she does not know how to solve that discontinuity.
15. Long-running tasks remain an important source of unsaturated demand
Angela says intelligence appears increasingly saturated for some workloads, while other classes remain “very unsaturated”—more than people may anticipate. The emerging return comes from “extremely long-running agentic tasks” on problems that historically resisted brute force but might yield to more intelligence. She sees value both for businesses doing the work themselves and startups building agentic products around it.
Existing demand includes coding and enterprise products automating distinct processes. Some of those applications are starting to work; others still are not. Biology and cybersecurity introduce another category of hard science and engineering work, beyond straightforward process automation. Angela describes these as increasingly interesting workloads showing up on the platform, without claiming that capability or reliable execution has become universal.
16. Faster implementation leaves humans responsible for judgment and quality
Angela says that for documents and code, people should use Claude but ensure the result is high quality; passing along an unread generated artifact transfers the author’s work to the reader, which she calls unfair. Katelyn emphasizes that humans remain responsible for the quality. Consumers should send actual slop back, but avoid reflexively rejecting good work because an em dash or another “Claude-ism” reveals AI assistance. Quality and stylistic telltales are different questions.
In engineering, humans ensure system designs and plans are sound; Claude writes much of the code; verification establishes whether the result meets the bar. Katelyn says some changes need only a quick approval. That does not mean handing the production system to Claude with “Good luck”: operating and evolving large systems still requires human expertise.
The host cites the warning that new capabilities should not simply produce “10X more features into prod.” Katelyn argues that foundational product planning does not disappear because agents accelerate part of the process. The host admits the tension: when experimentation is cheap, trying everything feels attractive. The counterargument is to use that speed in service of an intentional goal and better understanding of users.
The same tension appears in management. Katelyn can spend an entire day unblocking decisions in Slack and feel she produced nothing; Angela protects time for thinking and writing, at the cost of being harder to reach. The host’s correction is that resolving those problems produces “a functioning team” that is unblocked. Claude assistance does not remove every difficult decision that reaches their inboxes.
17. Developer relations is shifting toward teaching people and their agents
Katelyn says the platform business can disappear from Anthropic’s public narrative between research, policy, Claude Code, and Cowork. Separate platform and Claude Code DevRel teams address different developer ecosystems. Platform still needs a manager, with individual contributors reporting directly to her. Its challenge includes finding a voice and identity, alongside the familiar responsibilities of product feedback, content, and community.
Lance’s deep technical teaching on memory, costs, and evals exemplifies the approach Katelyn wants; CJ contributes examples and community work. The host adds the “master builder” model, borrowed from Lego: demonstrate something impressive with the platform so developers understand what they could build. The work helps reveal possible applications, rather than merely announcing that another capability exists.
Cookbooks increasingly illustrate possibilities rather than serving as code people copy. Katelyn contrasts an elaborate older computer-use implementation with the Claude API skill, built by Lance and owned by DevRel, which helps coding agents create integrations. Angela adds that developers can point Claude at a reference architecture. Best practices increasingly reach users through the agents helping them build.
The host challenges whether engineers and product leaders should themselves be the public faces, as Boris is for Claude Code. His proposed separation is a public-facing expert supported by production staff: spend 30–60 minutes on a brain dump, then return to work while others help publish it. Katelyn sees DevRel enabling colleagues to communicate well; the host compares that support to HR helping everyone hire.
18. Multi-agent gains depend on shared state and workers that can progress independently
Angela’s closing recommendation is to revisit experiments previously constrained by cost or token efficiency. Opus 5.5’s economics and reduced verbosity might let developers get further by letting it run. She specifically recommends trying a multi-agent setup, while declining to supply a narrow recipe for the most promising application. She wants to see what people build with the additional capability.
The closing advice is to have one lead coordinate work that can be parallelized, with shared context and asynchronous sub-agents that do not block each other. The guests’ two architectural priorities are shared state and independent progress. Subject to the problem being suitable, they expect gains; beyond those constraints, the advice is to experiment and “let it rip” rather than overprescribe every role.
The hosts distinguish assigning agents fixed jobs from agents assigning work among themselves. A guest expects smarter Claude models to improve at splitting, cloning, and adapting their own arrangements. The guest “wouldn’t be surprised” if experimentation yielded interesting results on problems that previously seemed intractable—perhaps solving something “in maybe one shot or something.” The language remains an invitation to test, not a performance guarantee.