Invest Like the Best with Patrick O'Shaughnessy
· Krishna Rao
[00:00:00] S1: The company is only a little over five years old. This past March was the third anniversary of the first dollar of revenue into the business, and we only had a frontier model for real, for the first time, in March of 2024. The timescale of these things is an important backdrop as I think about it. Our pricing has been relatively stable across Haiku, Sonnet, and Opus, and now Mythos is obviously newer. We made very few pricing changes. The biggest pricing change we made was to bring down the price of the Opus family when we launched Opus 4.5. Why did we do that? It's because we found that Opus-class models were underutilized relative to their capability. People were trying to often fit an Opus problem into a Sonnet. We were able to serve that very efficiently from our perspective, but actually bring down the price, which made it more accessible to customers. We want our customers to generate a lot of value from it. They're generating a ton of ROI from our models today. We want that to continue, because our goal is to proliferate this throughout the ecosystem. We think we're in the very, very early innings on all of these use cases. The best way to do that is get this intelligence in the hands of as many businesses, from startups to digitally native businesses to the largest companies in the world. Some of that means you have to make it at a price point that's accessible, and that allows them to get a lot of value from it. In changing the pricing for Opus, you see this Jevons paradox. We lowered the price of it, but the consumption went up way, way more than what you would have expected. Because we hit that sweet spot for customers, they were able to use it a lot more. We had the efficiency to be able to serve it to customers at scale. And they were able to build that into their workload, such that when we released Opus 4.6, which is a model improvement — they can slot it in. We didn't change the price. We think pricing stability is important, and we also think that pricing to get that value and to see that Jevons paradox happen is really important.
· Patrick O'Shaughnessy
[00:00:00] S0: The other component of this is margins and how you think about margins as a business. Again, because this is unbelievably capital-intensive to build these frontier labs, you've got the levers we talked about, which is efficiency, price — both of those relate to margin. Given how much capital you need, why not just say we want to have a healthy margin and set the price accordingly, and maybe that price can come down if efficiency is better or whatever? I'm just curious how you think about margins as it relates to pricing in the business.
· Krishna Rao
[00:00:00] S1: We think about what is the return on our compute spend writ large. That is all of the different workloads that we've talked about, whether it's serving customers. All of those are kind of in support of revenue over different timescales. If I serve inference, it's in support of revenue today. If I do model development, it might help for a capability that unlocks TAM that drives revenue six months from now. And everything in between. If I do internal acceleration to launch a new product — all of these things are in support of that. Our returns on that compute expense today are robust. We think of it as, what is the return on that full envelope of compute? We feel really good about where we are from that perspective, and we're balancing delivering value to customers with also seeing a really strong return on that compute ourselves. When revenue grows, as we mentioned in Q1 — it's not like we onboarded a bunch of new compute in that time period. Compute comes based on a ramp that might have been determined 12 months ago. This idea of a variable cost that's on the incremental to serve a customer doesn't really fit our business. It tries to fit our business into a software paradigm. That's not the case. In actuality, compute is supporting all of these activities. We're really generating a robust return on that compute, and that's our measuring stick. We think of the compute envelope that we have as the thing able to govern how much we can drive revenue, both over the short term and the long term.
· Patrick O'Shaughnessy, Krishna Rao
[00:00:00] S0: If you're this great customer of the compute providers, what does that group need to do to be a great provider to you to help you drive that return? [00:00:00] S1: We're fortunate iwn that we have really great partners in Amazon, Google, and Microsoft, but also with Broadcom and NVIDIA as well. We are the only model on all three clouds today. We're the only large language lab using all three of these chip platforms. These collaborations are much deeper than just procurement. I think that's something that's often lost. If you think about our relationship with Amazon, our teams are deeply embedded with the Annapurna Labs team. We are good users of Trainium. We've spent a lot of time and energy and worked closely with the team internally, and we plan capacity together. We do that with the other hyperscalers as well. If you think about the three clouds, they're great distribution engines for us too. We have a really, really robust first-party business as well, but these are multifaceted partnerships, whether it be on developing the chips themselves, landing that capacity, serving it, and then ultimately distributing it to the customers. Each one of them has that element to it. They're different, and each has relative strengths, but we've been able to work really well across those clouds and obviously across Broadcom and NVIDIA as well.
· Krishna Rao, Patrick O'Shaughnessy
[00:00:00] S1: We're fortunate iwn that we have really great partners in Amazon, Google, and Microsoft, but also with Broadcom and NVIDIA as well. We are the only model on all three clouds today. We're the only large language lab using all three of these chip platforms. These collaborations are much deeper than just procurement. I think that's something that's often lost. If you think about our relationship with Amazon, our teams are deeply embedded with the Annapurna Labs team. We are good users of Trainium. We've spent a lot of time and energy and worked closely with the team internally, and we plan capacity together. We do that with the other hyperscalers as well. If you think about the three clouds, they're great distribution engines for us too. We have a really, really robust first-party business as well, but these are multifaceted partnerships, whether it be on developing the chips themselves, landing that capacity, serving it, and then ultimately distributing it to the customers. Each one of them has that element to it. They're different, and each has relative strengths, but we've been able to work really well across those clouds and obviously across Broadcom and NVIDIA as well. [00:00:00] S0: I'm thinking about your function — the finance team. I'm picturing this ROI-on-compute thing on different horizons with all these complex variables. Which makes me wonder, how do you use these powerful tools yourself internally to run your group and the business? What is the deployment of Claude Code and Claude in general on the finance team at Anthropic?
· Krishna Rao
[00:00:00] S1: This is really interesting. We were using Claude Code about a year ago, and I started asking people, "Is everyone just taking up vibe coding, or what is it?" We started to use Claude Code as almost like an assistant, a digital coworker — not just for coding tasks. That was early in what eventually became Cowork. That was an extension of Claude Code — to say, what it's done for agentic software development, it should do for all of knowledge work. Then we started to productionize that, and I'm actually really proud. We spend a lot of time with our product team too, they see how we use it and get input and feedback from that. Today, all of our legal entities — we can produce the statutory financial statements using Claude. Yes, a human checks it, but all of those financial statements are produced with Claude. We also have a more real-time platform called Ant Stats. It used to take a lot of time to sift through all the data, get to conclusions, write a memo about it, or publish a regular report on what's happening over the course of the day, what's driving it. We now have a library of skills for Claude that are specific to finance. Last I checked, there were over 70 of them that everyone can access through this common repository. On top of that, we built an MFR — a monthly financial review — skill. It can produce our monthly financial review. It's 90 to 95% ready. And then all of our discussion becomes about — what do we do? What are the implications? Not what exactly happened, because Claude is not just reporting the weather. It's also helping to think about drivers. Why did the number change in the way it did? That gives you tremendous insight into the business, both in terms of this MFR that we do, but also on a daily basis. What used to take hours to produce a weekly report for what's driving revenue or what's driving our compute utilization now comes down to 30 minutes, and then we can spend our time on the actual strategic implications of the business. We can also get it in the hands of business leaders much more quickly. The insight engine is a lot faster. I have a dashboard, I look at token usage.