All right. I think we're ready to get started. Thank you everyone for joining us for the day. We've got Arvind Krishna, our Chairman, President, and CEO, and Jim Kavanaugh, our CFO. I know most of you saw Arvind's keynote this morning and had the opportunity to tour the forum floor. We're going to make this informal, and it's open to Q&A. We've got them for an hour before we go over to Jay Gambetta, who's going to talk about Quantum. I will open it up. Hi. Over here, Stefan Slowinski from BNP Paribas. Thanks for having us today and for answering our questions, taking the time. Appreciate it. I guess two questions for Jim just to start with. $4.5 billion of savings from AI and hybrid cloud. Can you maybe just take that down a level and tell us where is that coming from more granularly, and is there still potential to do more? A second question is just on M&A. I feel like we read in the paper every week about private equity looking to maybe get rid of software assets. Is that an opportunity for you? Do you think more opportunities arise coming out of private equity than in public markets? Thank you. I'm sure Arvind and I will both tag team all of these questions. Thank you for the question, Stefan. I really appreciate it. I actually think both of your questions kind of go hand in hand. It's the way we operate our business model inside IBM. We have what's called a value creation framework, where we drive productivity at our capital structure that gives us tremendous multiple leverage of financial flexibility that allows us then to go drive growth both organically and inorganically. These two go hand in hand. When we look at it, Arvind put in place a very disciplined productivity play about two and a half, three years ago, coming out of COVID. We had a lot of work to do when Arvind came in around portfolio optimization, operating model transformation. We started going down a maniacal focus on how we structurally improve the competitiveness of our business model over time. That was initiated. We have since been transparent with investors for two and a half years. We took out four and a half billion. By the way, if I go back for five years since he started, six years almost, it's about $7 billion. We're actually on an accelerated play overall. What is that built around? That's built around how we leverage data inside our company, how we fundamentally restructure intelligent workflows. Arvind talked on stage this morning, operating model. We have fundamentally changed the operating model of the company and then we have been deploying technology, digitization, AI, to reimagine the way we actually run the company. Where are we at? You asked as far as the journey. Arvind hit me up on this question last week. If you saw The Wall Street Journal article with Arvind that was out yesterday or this morning, I think he and I are directly aligned. When I look at digitization and AI and the way we've optimized our operating model, I would say we're moving from adoption to maturity. We're probably 60% of the way there on workflow optimization. We're only about a third of the way there on getting the extraction of value realization and ROI but it is on an accelerated path. This year we took the $4.5 billion up to now $5.5 billion, and I think we got a lot of headroom. Now to your second question, I'll let Arvind talk about M&A. What is our M&A playbook? Fundamentally different since this man has taken over the company. We're a very focused company, hybrid cloud and AI. Our criteria, we're very transparent around strategic focus, synergistic value about building platforms. As we invest inorganically or organically, we look for a multiple of a return and an attractive financial return overall. With the targeted areas that we're focused on, our playbook is around buying category leaders in technology, in structurally growing markets where we believe we can deliver differentiated value return through integration. I think that playbook has turned out quite well, and I think we've earned the credibility about being disciplined allocators. Let me pause there. Look, I'll just add a little bit to what Jim said, because I think you're all looking for a bit more color. We have looked at public companies, both HashiCorp and Confluent lay into that category. We have looked at equal-sized private companies. We took Apptio out from private equity. The whole question comes down to Jim's point about we are very disciplined in the return we want because the return can't all be in the price we pay. If effectively, I'll use the word, if multiples come down even inside private equity, that makes a lot more things potentially more attractive. The question is, does that happen and when will that happen? We have our long list of things that we keep because we are not going to get target-focused on only one or two things and stay there. We normally keep an eye on 12 things that are of extreme interest to us, and as time moves, if those become more attractive, then we will be, first, strategic and then after that, opportunistic in case the price is right. That's all I would say on that. Just a bit more color since you asked the details on the four and a half. The four and a half really came out about 1/3 of our total spend. That's not exactly fair, but it's roughly fair. There's 2/3 more by applying those same principles in other areas. We had a very tight process that Jim and his team ran, which is we looked at. That spend, we divided it up into an end-to-end process. There's about 200 of those. We have made significant progress in about 2/3 of them. Not in all of them. Some may not be possible to get a lot out of. About 140 of the 200 we have made progress on. The amount of return varies. Some of them resulted in 80% productivity, some of them resulted in 20%. That gives you about the 40% that we got out of those, to give you some idea of how we do it. Great. How about Ben? Hi. How you guys doing? Good. Ben Reitzes with Melius Research. I was wondering if you could give us an update on You guys stopped disclosing your AI book of business, which is fine, because AI should be the whole company. How do you want us to track how well you're doing in AI? What do you want us to take away? Is the data and AI segment going to soar now because of watsonx and the integration with Confluent, or is it everything? How do you want us to track you? How do you want us to grade you on how well you're doing with this AI transformation? I'll begin with a bit of a macro answer to that, Ben, and ask Jim to look, if you look at what I said on stage today, I said that AI is going to be enabled by how you unlock data. It's going to create a lot of opportunity for hybrid which means so for automation, and if we get our mainframe AI usage going, then it'll show up in TPS also. I kind of go to our software growth rate is probably the best proxy for how we are doing in AI. I then go a little bit tongue in cheek. We were having a conversation at the back corner of the room. If our portfolio is really being attacked by AI, that number should go into a negative territory. If we're getting a tailwind, that number should get acceleration over time. I really think that the software portfolio is probably the best proxy for how well we are doing for a long-term win in AI. Got it. I was talking to Jim about this, might as well just throw it in there. Multi-part questions? Yeah. Just really quick. I guess I should pass the mic. At the mainframe, are you seeing any benefits in the mainframe from the compute shortage going on, and the fact that some of the Linux workloads can actually be pretty quickly ported over, x86 servers are through the roof and whatnot. Is there any more sustainability to the mainframe as a play on this? What's going on with the rest of compute and making it relatively more attractive? A slightly longer answer to your question. We're definitely getting, because of the compute shortage out there, where people can't get CPUs and memory, which is causing the server shortage, we are absolutely seeing a benefit in our Unix, a.k.a. th e power business, and our storage business. Those two is direct in line of sight. It's not as simple as, oh, these guys have a better supply chain, or that they have better pricing. We have the same pricing for our components as other people. Both of those, in our case, are more efficient at memory utilization and at CPU utilization than alternates. Effectively, the client can do a lot more with it, and that is what we see there. On the mainframe, I don't think it's so much because of compute shortage. We do see the increase in capacity, but it's driven by workload, because mainframe, most people don't realize, mainframe hardware and software is priced by, in some sense, consumption, though you don't call it that. It's called capacity. Capacity will go according to what people want and need, not by some other metric. As people increase payments, as people increase retail banking transactions, as people increase claims across a variety of industries, both healthcare and insurance, it leads to mainframe capacity increase. The direct benefit on the Linux side of mainframe comes about because people are now wanting to also decrease power, not just the hardware shortage. If you have lightly loaded, I'll use that word, Linux workloads, the fact that we can compress 100,000 of them onto one mainframe system is attractive. That's not the compute-intensive Linux workload. That's more the sparse Linux workload. Unless there is an extreme data affinity to other data on the mainframe, then you absolutely get that benefit. I would not tie the mainframe right now to the shortage of hardware out there. I would tie the mainframe much more to the actual workload value that people are seeing. On Unix and storage, I think you can ascribe some of the wins there to current shortages. Ben, back to your first question because I think it's an important question overall about AI and book of business, because I got asked by at least three or four others in the audience here this morning and throughout the day. You dial back to the explosion, the event of ChatGPT at the end of 2022. We came out with our book of business concept. Why? We wanted to make sure our investors knew at the early phase of awareness and consideration that we were participating in being a strategic provider of choice in AI. We finished 2025 at what? Over $12.5 billion book of business. That was about a ten and a half book in consulting, which is always on the front end of that curve, and north of a $2 billion book of business on software overall. We said then in January, given we're at scale right now inside IBM, north of a $12.5 billion, we got to start turning this into what is the revenue realization and value we're seeing. Mainly because AI has permeated across our entire business, because we participate everything from the AI platforms, to the orchestration, to the data layer, to the agents and assistants, to the orchestration, to the consulting business, to AI is on the mainframe today. Even in that book of business that we were reporting on for about almost two years, it didn't include anything for what is AI doing to our infrastructure segment. Going forward, to Arvind's point, number one, what happens to the acceleration of our growth in software? It will play beyond data, right? Data in the first quarter, about five points of that growth of 16% was GenAI driven, right? It'll play across hybrid, it'll play across TP, and it'll play across automation overall. In consulting, I think I gave some statistics on our earnings call. It's over 40% of our book of business. By the way, that book of business, about 80% of that book is new clients. We're capturing new business in consulting overall, and it's 30% of our $31 billion, almost $32 billion backlog today, and it's north of 20% of our revenue in a quarter. That translates into over a $4 billion ARR with regards to GenAI in consulting. Finally, infrastructure. You saw we're capitalizing on GenAI demand in our distributed infrastructure. Very solid growth, mid-teens in storage and in power overall. You all have seen what we just completed, anniversarying our first year of mainframe z17. Program to program, we're at 135% of our most performant program ever, that being the z16. Put that in perspective, that is $1 billion more of revenue of hardware. That is a monetization foundation for us to get that three to four multiplier going forward. You're going to see AI play out across all facets of our business, and we'll be transparent each quarter. Maybe, Keith? Coming over here. Hi, thank you very much. Keith Bachman from Bank of Montreal. It's good to be back at Think. I wanted to, Arvind, to direct one, if I could, at you. It's interesting to hear you highlight Bob as a value proposition. I wanted to tease out what you think the value to IBM is and how it accrues. When I tease that out is, Bob is leveraging a lot of other technologies. You're drawing on other models, when I think about a software developer, why would he use Bob versus just going to Anthropic and using Claude Code and even had, you can do error correction and code checking and all those type of activities that are also captured in Bob. Maybe you could just elaborate on what the value proposition is to the audience I think you're trying to reach is the developer community and then how we should think about something like Bob accruing to what we as investors might notice in terms of the benefits. A few different points there, Keith. First, we want to have control of being model agnostic, because which model is allowed, which model is regulated, which model may be deemed unacceptable is one dimension, and the second dimension I want to add on is also cost of a model. If you let the developers go completely into the native tool before I get to the other enterprise abilities, you're going to have no control about which one they're using. You get fragmentation across the enterprise, where some teams will pick one, some teams will pick another. That means I lose fungibility of having people across projects and having common standards. Two, our handbook, which is an important point, which means a coding standard, what you need to document, how you need to patch because after 10 years, it'll be a different individual patching this. We are not making consumer apps. Some of our apps go into enterprises and then run for the next 20 years. We get control over all that because that is what we mean by handbook, because somebody else will come along seven years from now and need to maintain all of that code. The cost of models is something that people are not talking about. The cost of running a small model, let's call it 100 billion parameter, as opposed to a foundation model, is about 1%. Instead of being $30 for a million tokens, you're talking about cents for a million tokens. We decide inside. Inside Bob, we have a model router. We do not let the end user decide which model is being used. Right. I accept probably 70%-80% of the current tokens are being consumed by a foundation model. Actually, if we let all the tasks go to a foundation model, our token usage will also double. Effectively, we can put some controls around as long as the answer is good enough. Inside Bob, we have actually built the instrumentation that actually all 80,000 people inside may not be getting all the same model routing. We get two, we see if one is actually performing better, that is, people are more willing to take that, and then we'll go there. It's not that cost is the first optimization. Otherwise, you will just do everything on an open source tiny model. We say quality is the first, within that, we believe we can halve the cost. You can do all the things you're describing, I'm going to acknowledge that, but it's done in an ad hoc way. It's done on how good that developer is by doing all this. When you give a more curated experience, you don't have a choice. We are going to give you the secure coding experience. You have no choice, and the code will not get checked in until that is complete. Until documentation is complete, you can't check in code. This becomes much more of a place where an enterprise can be comfortable with how the product is built and then deployed. While we are not there in today's offering, we will give you deployment choice over time. That means in certain industries and in certain countries where they care deeply about it being in their own cloud, because today, if you're using a foundation model, you don't have a choice. It is going back to wherever they're hosting it. Over time, we will do that, but that is probably at the end of this year or early next year. Is it a monetization event for you also, you think, over time? I'll go tongue in cheek. In our $4.5 billion, we are not counting any savings from Bob right now. If I do the math, roughly, if we had to pay a third party, I think our bill would be somewhere around $80 million a year already. Let me park that to the side. If I walk up to a customer and show them, Here is a full experience of 80,000 people across all kinds of different roles, from writing firmware for a piece of hardware, to operating systems, to databases, to AI tools using this, I think that will be a pretty important function. Yes, over the next year and a half, this is a really important monetization event for organically homegrown product as well. Thank you. Great. How about Brent Thill? Thanks for having us. Brent Thill, Jefferies. Investors are watching this $40 billion Anthropic run rate and wondering where this is coming from. Most are just saying it's coming out of software budgets, and that's why software's getting crushed. Where is all the money coming from and where are you seeing this unlock? The other question I get a lot is, are there deals that are stalling because we're all investing in AI? Have you seen any signals of deals stalling in the first quarter, first half as we're doing investigative work and trying different models? Ultimately, hopefully, they come back to you, but has that been something you've seen or not? Let me start. I'm going to ask Jim, especially the second part of the question. To be blunt, we did not see any evidence of our deals slowing down or stalling because of money flowing into or because people are focused on which model they're using or how they're using the model and what they have to pay it. We did not see any evidence of that. I'll acknowledge the question that Ben asked, which is some deals did slow down because people just couldn't get the hardware. Why would they buy software if the hardware to run it on is not accessible? We think that's a somewhat short to medium term issue. I don't think that'll be a long-term issue. Supply will come up to service that side of it. On your first side, a lot of the money for people like Anthropic, we use the Anthropic models inside our Bob. You could imagine that $5 million-$10 million of their revenue comes from people like us. The same is true for a variety of enterprise customers. We are not yet seeing that come out of at least what we can see. We did print 11% growth in software in the first quarter. It was pretty even across the geographies. Where we didn't do well, I could tell you, was because of our own execution, not because of what clients were slowing down. We had great growth in Europe. We had great growth in North America. Those are good signals usually for, is there demand on these? A lot of that is because we are also enabling people to do their AI well. It's not like we are saying, Well, do it in an alternate way. That's not a fight that we pick. We say, Let's help you unlock your data for AI. If you're going to have an agent act on inside information, isn't Confluent the best way to open it up for that? Look, you need to go manage your infrastructure really well, be it on cloud or be it on premise. That's why we use the word hybrid. Hashi is going to give you the best way to go do that. You can now get your infrastructure deployed faster with fewer errors for AI workloads. Those are reasons why we play into it and why I believe, and our numbers so far back us up, that we are not going to get hit with it. I'll acknowledge your point. It will come out of some places. If it gets to hundreds of billions, that's not going to be just incremental. You have to ask, which things are done better this way, and is that the loser? On the deals slowing, I don't think so. Jim? No. We dial back 90 days ago, actually now 120 days ago. We entered the year and first quarter with probably the strongest software pipeline we've had in a long time. We look at the deal velocity and our yield rates on that pipeline, albeit first quarter for us, being we offer flexibility of how you purchase between subscription, perpetual licenses, et cetera, it's only about 10% of our quarter in a first quarter, unlike a fourth quarter, it's 30% of our software portfolio overall. We actually saw accelerated yields and accelerated velocity overall. Like I said to Ben's point, underneath our strongest growth in data, which was up 16%, you pull out closing Confluent early, which we're extremely excited about. We still grew very high single digits organically in data, and over half of that was GenAI driven. We had actually a strong start. When you look at consulting, our consulting book continues to accelerate. We're up like 70% year-over-year in bookings on GenAI. As far as pushing out enterprise-based spend, we don't see it happening across our portfolio. The only thing I would call out, and Arvind briefly touched on it on the call, just given the hardware supply chain dislocation and the commodity cost increases and what's happening with getting hardware right now, it is putting a little pressure on RHEL. On the flip side, I think it's driving higher utilization and density of current infrastructure, and our Red Hat OpenShift is exploding in growth. We're now north of a $2 billion ARR, up from about, what, when we acquired them, $50 million, something like that? Yes. Some. We're growing compoundedly 30+%. We're capitalizing in some areas. RHEL is going to go through it, but we think that'll be a short-term phenomenon that we can overcome. Great. How about Brian Essex? Where are you? Thank you. Brian Essex from J.P. Morgan. Thank you for doing this. I'll confess, I didn't go to the keynote. I was walking around the floor. Thank you as well for giving us that kind of access. I really appreciate it. One of the conversations I had was with HashiCorp, and what really resonated with me is the ability to expand outside your developer community and penetrate the C-suite. Maybe for Arvind, can you help me understand how much runway do you have left to penetrate the C-suite? Maybe for Jim, what does that do for you on the pricing environment as more users or more enterprises move up in enterprise class pricing? Thank you. So Brian, I'll tease you with part of what was going on when we looked at this about two years ago in our internal case. There's really two main products in Hashi. There is the Terraform side, and then there is the Vault side. I think Vault is making good progress, especially amongst larger clients, so I'll focus my comments more on the Terraform side. We think we monetize maybe 1% - 5% of the Terraform user base. You say, Why is that? Because I'll react with, they think that the pure open source with no support is good enough. You add what is going on right now in the cyberspace. You add what is going to go on with our integration of things like InfraGraph. You think about tying it more into being completely secure about how you deploy, not just the pure deployment of infrastructure. I would say that opens up the conversation to a place where the C-suite now begins to care. Certainly, the CIO, the CISO, and the CTO care deeply about those things. This is the same thing that happened in Linux, albeit 20 years ago. People initially deployed Fedora, the pure open source, and then you ask somebody the question, as you begin to grow and as the number of vulnerabilities increase, do you want somebody who supports it and is willing to stand by the quality of their team, who does all of the patching and all of the configuration management? Or do you want to hire your own 10, 20, 30, or in some cases, 100 people to go do that? I think that equation begins to close about now, and so we will be able to do that. The C-suite is interested because it has value, so we are never going to lose our familiarity with what the developers want and why they like it, and it makes their life easier. Then just like we did with OpenShift, you then say, in addition now, does this become your enterprise standard? Which is when the C-suite gets deeply motivated to say, This is a standard. I think this is going to play out certainly across all regulated industries and maybe in this case, because of ease, that I get a common environment in both public cloud and on premise across everybody who has that mix. Then you don't have to worry about the difference in those two environments. On your second question, I might surprise you a little. As a CFO, and I think I learned this from Arvind about a decade and a half ago, I don't look at our software portfolio and look at where we can get price optimization outside of potentially TP, which is on a very sticky stack. How do I look at the software portfolio? One of the things that we were talking about. By the way, we talked about HashiCorp the day after we closed Red Hat six years ago because of the synergistic value of what hybrid cloud, multi-cloud can be. The way we manage our software business is around capital investment allocation, innovation, and how do we drive a platform economic multiplier of dragging. The industry would know that as GRR, NRR. That, to me, is how you monetize value of software. Since we've closed HashiCorp, we've been operating in a 130, sometimes even 170 NRR space. What does that mean? To Arvind's point, when we brought in HashiCorp, the synergistic value of a IT infrastructure lifecycle management, a security lifecycle management. By the way, Terraform and Vault are on mainframe, so it plays the mainframe modernization, the FinOps synergy that it plays to. There's a synergistic value that we look at every time we land HashiCorp, whether it's Vault and/or Terraform, we can pull through an Apptio, a Turbonomic, an Instana in other parts of the portfolio. We're extremely excited, second time I said it, about Confluent overall. I look at it more from how do we get that economic multiplier? How do we get an NRR versus what is the price optimization opportunity? That's not long-term sustainable. How about Wamsi? Thank you so much. Wamsi Mohan, Bank of America. Thank you, Arvind, Jim, for doing this. Maybe if we step back, you had in the last four quarters, really strong infrastructure performance. Following that, you would think that TP should really start to perform really well. If you look at your through-cycle expectations of mid-single-digit over time. You got a kicker from AI as well, potentially starting to influence the percentage of AI MIPS. You also have Spyre Accelerator coming in this year, which is different from prior years, which should also be contributing. Just want to maybe get your sense of how we should think about calibrating transaction processing on a go-forward basis over the next few years. Yeah. First of all, for the people in the audience around, TP is our transaction processing software layer that runs all the mission-critical software on top of our mainframe stack, pretty much. We run that as a stack economic multiplier. Every time, why is it important? How do we monetize TP? Shipped MIPS mainframe. By the way, I think four quarters in a row, we've shipped over 100% growth year-over-year in z17. Shipped MIPS turn into installed MIPS. To Arvind's answer up front to Ben, it turns into workload consumption on the mainframe. That then gives us monetization opportunity for the software, potential price opportunity for the software, and value creation. If you take a look at it, last cycle, z16, which is our most successful cycle up until now is z17. If you map the TP performance, year one in z16, TP was flat. Year two, we grew six. Year three, the end of the cycle, we grew double digits. You take a look at z17, we just finished the 1st year. We grew low single digits. A little bit of an accelerator from the z16. Why? We've got 3.5x more installed MIPS out in the marketplace. We're bringing new innovation value to the platform. By the way, watsonx Code Assistant, we talked a lot with many of you around mainframe modernization, just given what came out with Anthropic throughout the quarter. We disrupted because we think that's a accretive value play to our mainframe in the long run. We came out with two years ago, watsonx Code Assistant for Z. Our watsonx Code Assistant for Z that sits on the platform is already a $300 million ARR book. That ultimately gets monetized in TP over time. We were flat, up 10 prior cycle. I don't see any difference this cycle as we move forward. Plus, you compound that with innovation value as we move forward. It's all going to depend on us getting more and more workloads on top of that mainframe, which I agree with Ben's thesis overall. I think the market's moved our way, both from a hardware infrastructure supply chain, but also from a sovereignty on-prem hybrid world. That's why mainframe is up 50%+ in the last four quarters in a row. I don't see any difference this year. We're excited about TP. I just add one part. Just as you go forward two more years, we will have ARM instruction set compatibility on the mainframe in addition to the current mainframe instruction set. Yeah. We can just pose the question that as people consolidate, then how many ARM binaries could also be run on the mainframe for those workloads? That adds workload into the mainframe that is different than the past. By the way, just on Spyre. Spyre is going to get monetized in mainframe. It's not in TP. As we get more and more consumption, more and more inferencing through that, it'll drag up the workload, which then we get a multiplier on top of it. Just so you know. How about Fatima? Good afternoon. Thank you so much for hosting us. Fatima Boolani from Citi. I wanted to ask you a question about the consulting business. It's been very clear that the Frontier Labs have taken very deliberate steps to build out their versions of forward deployed engineering organizations, for what is very obviously to me, standing up AI systems is complicated, heavy architectural work, and that is exactly your forte. I wanted to understand what the level of competitiveness is between IBM Consulting and the Frontier Labs and some of their initiatives and mandates that they're undertaking in real time. We saw the news and headlines the last couple of weeks. How are you sort of participating either competitively, cooperatively, or cooptatively, as this becomes a more meaningful opportunity to unlock real production AI implementations for organizations? Yeah, let me maybe start. Yeah. I'll go Yes. This morning, I think this morning was one of them. Last night was another one of them. I think at one level, if it's that important to any enterprise, it's going to be very hard for them to solely depend upon somebody else. They're going to want to have some control of it. That said, you then have to get into all the pragmatics of anybody who's run a large services organization of where are these people? How do you train them? How do you get them all on the same exact methodology? We've seen this happen, I'll leave them nameless, let's say at certain SaaS companies. They started first saying, We need to grow all this because people want the forward deploys, and then very quickly they back off, and they go somewhere else. That side of it, I think, will play out over the next couple of years in terms of does it all go there, or that is simply a way to accelerate? If I look at almost all software and technology companies over time, they often have a seeded small piece inside, but they almost use that to help their partners gain the skills, gain the methodologies, learn what works, learn what doesn't work. That is the way it has mostly played out. If I look at it, the approach that we've been taking with our clients is not so much to make them stand up their own models because these are all hosted models. We are taking the approach that we come to you, we help you optimize your finance function. We help you optimize your HR function. That is much more about deep integration of what is your internal system, what agent do you need to put in front of it? How do you make sure that there isn't data exfiltration going on? How do you do the workflow and change management that is needed inside to get the full value benefit of those pieces? As an example, you heard Elevance on stage this morning. We are a big part, not the only part, but we are a big part of what powers their mobile app, Sydney. Sydney was a mobile app, by the way. I don't think he quite said that. If you look at the conversational AI in it, yes, there is a lot of on-premise models, but there are also a lot of foundation models that are coming into it. How do you integrate that in such a way that they don't get a regulator looking at them to say, Are you letting out HIPAA information? Those kinds of things is where we succeed. If somebody just wants arms and legs to go play around with a copilot, I'm not sure that that's a place where we'll be able to make money in the long term. I think, Fatima, to your question, I think it's an instantiation of what we've been saying to our investors and our clients for the last couple of years of why is there synergistic value of having a consulting business inside IBM? We've been on this mission for multiple years about shifting the entire consulting business to a service as a software model. Arguably, quote-unquote, An FDE model that has been put in place. Palantir was the first years ago. Their model was right. We replicated that. To give Arvind a tremendous amount of credit, who runs our consulting business? He's not a consultant. He's ran our software businesses, and he's been a software CEO out in the marketplace. He is a technician. We have been doing a ton of work about realigning our offering portfolio, our operating model on how we capitalize on this moment. I always talk about the triangle, right? The triangle is a differentiated value inside IBM today, because why? We're the only company that brings an integrated tech stack. Yes, we have a parochial view of IBM, but also with Arvind, we have strategic partnerships that we bring to the table to our clients. Second, we have a consulting business at scale in 175 countries with C-suite incumbency and access. Third, I think a critical differentiator, and to Stefan's question up to lead this off, is we have our own client zero reference case inside IBM. When we come, I spent two sessions after the keynote today with CFOs, probably a table of almost 100 people, talking about the reinvention of IBM. That triangle is right at the core because deploying GenAI and getting value realization as a CFO, it depends on you realigning your operating model, but it also is heavy lifting. I think today, tech stack, integrated consulting company, and a client zero initiative is a tremendous value proposition, and you see that in our book of business. We finished last year at over $10.5 billion GenAI in consulting. I didn't give the number in first quarter, but you could do the backward math because I gave you the endpoints. I would put that book of business up against any consulting company in the marketplace today, even at our size. Right. How about Jim Schneider? Jim Schneider, Goldman Sachs. Thanks for taking the question and doing this event. Relative to the mainframe business, so it's been a year since the z17 launch, and maybe can you give us some data points as to what you are seeing, if you can see clients doing inference on their data stacks that sit on mainframe directly? In other words, consumer credit card data, things like that. It would make sense since they reside on mainframe to do inference, perhaps. Can you maybe give us some data points, some tangibility in terms of what you are seeing, how much of that is happening, or what you expect to happen over the next year or so? Thank you. I'll maybe begin with the macro and Jim, look, I got some numbers. Yeah Over a third of our clients have actually already either indicated a hard commit or physically purchased the AI inferencing hardware capability. That gives you some sense of the interest level. About 10% to 20% of them have now done the work to port their models onto the platform so they can begin to do, and you went right to fraud is the first, second, and third use case that people are deeply motivated to get done. We think that all of this begins to get monetized and turn into real revenue for us over the next 12 to 18 months. They've looked at it, they kicked the tires enough that they made a hard commit. They're now doing the work to port their models. Most of them are living in a highly regulated world. They want to be careful on how they port the model and make sure they're getting the right performance and the right outcome. In the months after that, we'll begin to get the revenue as that begins to scale up. That's kind of where you've seen it. We are probably more excited by the uptake of this one than in many other mainframe features other than the core of the platform itself over the last few years. When you take a look at mainframe, to Arvind's point where he ended, mainframe runs over 70% of the world's transaction volumes in terms of value across every industry. That's why 45 of the top 50 banks run mainframe, nine of the top 10 retailers, four of the five top airline companies, et cetera. We run 25 billion transactions per day on the mainframe. We run 450 billion inferencing transactions per day at 1 ms with 6 8 nines. Yes Overall at 100% utilization. We think this is a long-term growth factor for us as we capitalize on the Spyre side of the equation. It'll be consumption-based, it'll be inferencing based, which is a nice annuity stream over time. The reason I started with what is mainframe and how important it is, because there's millions and millions of installed MIPS that are out there running the world's transaction volumes that now we have innovation capability to actually do the inferencing where the data is located. Data gravity matters right now, I think that plays to our growth factor around AI as we move forward. That will play out over time, to Arvind's point. Paul. Thank you for your time today. Good afternoon. Paul Jackson, Pioneer Investments. There was a case in the paper about, I think it was April 26th, a company called PocketOS. They were working with an agent on Claude Opus 4.6. They tasked the agent with fixing a minor staging issue. The agent went rogue, deleted the whole production database and backups. How would Bob or Watsonx have prevented this? That is the whole point of putting guardrails and putting issues around it. First of all, if you were going to go delete it, we do not let BoB today be that autonomous. We actually put human touches in, so if it says, I want to go do this action, you have to go confirm it before it's going to go do that. When I didn't sort of expand on what I mean by enterprise, because then you have controls that you can put in. If you're in a regulated industry, that means you have the control of this was the human with their ID who agreed to that action. You can then also go back and verify on your training and is your controlled posture correct. BoB will suggest code to write, take that step. You must eye it before you commit it. Bob will say, I want to put in these secure coding guidelines because you were not so good here and here. Here is the whole suggestion. It'll show it to you in, I'll say green and red, so you can see where all the changes are being made. You accept it, then it'll go ahead and commit it, as opposed to I'm letting it run autonomously with no human checks and balances. By the way, I think that that was one who actually got into the press. My guess is there are hundreds of such incidents. Raimo. Hey, guys. You guys have done a pretty good job in terms of modernizing the hardware on the mainframe side. The additional applicational spaces that opens up with inference on the chip level, et cetera, all the use cases that you guys have talked about, and Jim Kavanaugh, you were mentioning some of the TCO advantages, et cetera. What would it take to sort of put more fuel on that fire, right, just to turbocharge some of the stuff that comes in? What are the primary bottlenecks in getting the mainframe users to start using some of these more enhanced capabilities? Is it sort of institutional inertia? Is it, you know Well, there could be a million different things, but love to kind of get your view in what you guys are doing to maybe turbocharge that a little bit. I'll take it from the positive side of what all we have to do. If you want to do AI today, either you're using an external model or your internal model. It's actually not as simple as having a model. You must then do all the work to make sure that you very efficiently use your underlying infrastructure. Today people talk about, are you talking about cache compression? Are you talking about technologies like vLLM? How do you optimize your model to run on a particular piece of hardware? If I take the Spyre analogy and go to the mainframe, they are not going to have all of that knowledge. We have to help them, back to the forward deployed engineers question, we have to help them with some engineering so we can work with them on what use case, which model, how do I optimize that model to run on the mainframe? What logging monitoring must I do to make sure that I'm watching what's happening, as opposed to having the lazy answer of a hosted model some other place. That is the piece of work that is going on, which is why I sort of said, this takes six, nine months to get done, and then you'll see the impact. What you can do, you can't get by any alternate route. Doing an inline model just takes 10 times the amount of time and 10 times the amount of compute energy if you don't do it on the mainframe itself. That's kind of what it is playing out at this time. Great. How about David Vogt? Great, thanks. David Vogt at UBS. Maybe Jim, on consulting, I think you mentioned that 80% of your book of orders or your backlog is from new customers or people new to IBM. What has to happen to get your existing customer base over the hill or over the hump to get them more engaged? Is it institutional inertia like the gentleman asked before? Is it ROI? What gets that existing IBM customer to adopt or embrace what you're doing in GenAI on a go-forward basis to accelerate growth? I think at the end of the day, GenAI, by definition, drives technology, productivity, innovation, and eventually, it's going to create competitive advantage for every enterprise client, that being new sources of revenue growth, new businesses, et cetera. I think the front end of the stage, because we're still very early in this cycle, are we moving from POCs, as Arvind said on stage, to beginnings of moving beyond experimentation to scale? Absolutely. All of the front-end work has been built around data transformation, governance structures, security protocols, et cetera. That is what I'll call, quote unquote, The foundation levers of GenAI around what we've been able to sell value. As enterprises, the one who are adopters and winners that are moved past this experimentation phase, now we're able to get scale. That's why you're seeing an inflection shift that we're calling in our consulting business. It's went from almost nothing to 30% of our backlog overall. It's actually that new client base is the reason why our net new penetration's up seven points year-to-year. Our backlog yields are up four points year-to-year. I think you start seeing an inflection where we've kind of hit the trough of ±0 over the last X number of quarters. We're pretty excited about the opportunity in front of us. I think coming at it from a client perspective, you've got to lay the foundation. Otherwise, every CFO that would be sitting in my chair up here, they'd be looking for show me the money. Where's the ROI? Where's the realization? If you haven't done that fundamental work, you're never going to see it. Great. We have time for one more. I see Matt's had his hand up for a while. Thanks, Matt Swanson from RBC. It seems like the word orchestration has kind of become a big buzzword a la software conference calls. Could you just talk a little bit about IBM's right to win in that space? In terms of what winning looks like, just where does value accrue in that orchestration layer? Where are the perimeters, the boundaries? Does it make sense that there's six domain-specific orchestrators within the enterprise or is there one big blue orchestration layer across the whole company? It's a great question, Matt. If an enterprise decides, and I'm going to overuse and misuse the word hybrid, that all of their AI comes from one hosted provider and all of the agents come from the same provider, there is very little value in our orchestration layer other than perhaps a little bit of governance and data exfiltration controls. I could argue those could go into the Confluent layer or an MCP server level, and then you don't need orchestration. You have to ask, is that the likely path or are most enterprises going to get agents from multiple sources? If you are, then you can go down the first path you described, okay, I'll put 1 orchestration layer for each one of those. That's a mess. You have to say, okay, is there somebody who's considered neutral enough? That's the reason why Salesforce, ServiceNow, SAP, Adobe are all agreeing to put their agents into our orchestration layer because then you can give one. If the hybrid, in this case across multiple SaaS and foundation models plays out, as we believe it is going to, then there is a lot of value in an orchestration layer as the place where you manage your agents, including those coming from other sources. If you believe that that's not the case, then you are going to fall back into it comes from only one place. I would go further. I would tell you that for the larger enterprises, they're probably going to have far more agents that they wrote themselves or had written for them than only from third parties. Why? A domain specialist has a lot of credibility in their particular application or domain. The value of agents is they cross domains, and they can do multiple things. The moment you do that's not going to be something you're getting from one third party. That's likely something that is unique to the way that you're doing things. Like how many agents are going to have to cross CRM systems and ERP systems and revenue recognition systems, and if you really want to take the work away, that should go impact how you do taxation and those things. Okay, who has credibility per se other than the enterprise itself if you're touching those things? I actually believe that's where the big ROI lies. The ROI is not in, Summarize my email for me. That should be part of Exchange, in our case. That should not be part of anything else, would be my view. Sorry, very long answer to your question. Great. I think we just finished up. Thank you, Jim. Thank you, Arvind. Now we'll welcome Jay Gambetta, Head of IBM Research. Pleasure to go a bit more deep into quantum than I have to this community before. I'm very much looking forward to the questions and things like that, and I hope I give you an overview of where we think the challenges are, where we are, and how we're going forward. Let me make sure it works. Just to give some numbers, if you take a BCG, and I saw there's a few more reports coming out, at the maturity of this market, the estimate is that it's going to make around about $1 trillion. This is across different industries from auto I've got a plot later that goes through these numbers in a lot more detail, over auto, materials, optimization, logistics, and things like that. This kind of gives us the end state, where we see this technology getting to, how we see it impacting. Think of this as a computer, which I'll make later on our roadmap as a Blue Jay system but at full scale. We've taken the view that the computers that we build today, if they're less than, say, 100 qubits, I can simulate them on my mobile phone or laptop, and they're useless. In 2023, we made the decision that we would switch to deploying only systems over 100 qubits. We are the only one deploying at that scale, and this is a scale where I can no longer simulate it, and in Arvind's keynote, this is where you can start to use it for scientific exploration. Since we made that decision, we've deployed over 30, and as Arvind said, there's around 90 that we've deployed since we put it on the cloud in 2016. We focus very much on developers in the quantum space, so Qiskit is our developer open source software package. In doing the annual survey, around 70% of developers using quantum actually prefer Qiskit. We've created an IBM Quantum Network. These are like-minded industries. It's a combination of academic and research partners, commercial startup partners, and other enterprises, and totals around 325 members. Since we started the program in about 2018, we've seen over $1 billion of signing since inception. I think when I presented to this community last time, we were just under $1 billion. We've crossed that, and we continue to see this growth. These are the numbers, but now I'll jump into some more of the details. I'm not going to go through the roadmap other than say we make our roadmap public. We're very proud of the fact that we've delivered on this roadmap. The dates haven't changed, it's our goal, as I said, to keep building larger and larger systems. I'll call out the Starling system in 2029 and the Blue Jay system in 2030. You can say 2034, slash, yeah, 2034. The Nighthawk systems are the current systems that our clients are using, and you see that, as I said, since Eagle demonstrated in 2022, but since then, reliably every device online, we've now, since 2023, been above the 100 qubit. I kind of want to give you a bit of milestones to keep in your head. Yesterday, it's 10 years since we first put the quantum computer on the cloud, in those 10 years, 10 years ago, on May the 4th, we decided that we would put a five qubit device on the cloud. Before then, I'd been doing quantum computing my whole life, but no one was even talking about quantum as an industry. To me, this signified the first time we took it from a lab and made it available. We made the plan, by 2023, we want to get to the point where a quantum computer running a quantum algorithm was beyond a classical computer running that quantum algorithm. We call that quantum utility. That doesn't mean that the quantum algorithm is the best algorithm for executing, say, the problem, but it means you can no longer simulate this with a classical computer, and we achieved that. This year, we talk about quantum advantage in various different ways. I think of this as quantum actually starting to be real. Scientists can use it, early adoption, and things like that, doing interesting scientific problems, and I'll show you some of that. Our goal is fault tolerance. By 2029, we want to demonstrate the first fault-tolerant quantum computer of order 200 qubits running over 100 million operations. We want to scale this to a larger system. My estimate is that we will be building systems that will be beyond cryptographic relevance in 2035. I would not take that the date to be quantum safe. I would say you should all be quantum safe today. If algorithms continue in their progress, there's no fundamentals that stop that date coming down to 2029. This is why companies, and you're seeing more and more governments saying, Get quantum safe before the end of the decade. My personal view is we should be switching the crypto right now. Here it puts it clear that we intend to build these systems larger and larger. Give a bit of a feel for the applications. At its heart, it's math. It's a math that is done different. I think a lot of people explain quantum computing as superposition, entanglement, and they use all these buzzwords. I think this confuses people. What it is it's a new primitive of math, different to addition, different to multiplication, that allows you to look at interesting problems. The most famous, obviously, as Richard Feynman pointed out, that we spend a lot of time simulating quantum properties with Boolean logic, so classical circuits, that simulation is exponentially heavy. We can't actually simulate, say, molecules that go into drug design or materials and things like this. A new method allows us to simulate quantum Hamiltonians directly, where the scaling is efficient, is one of the applications. Another one is in optimization problems. Classical computers are very good at solving optimization problems, generally, the optimization problem has not many constraints. As you put many constraints, you'll be surprised how fast classical computers fail. The interesting thing is, in quantum, as a function of those constraints, the algorithms don't show the same way of it degrading, you see this application of optimization problems. Differential equations, if you want to understand how energy diffuses or model, say, financial industries, modeling differential equations of scale are very, very hard. We've now shown many different algorithms as a community where you can actually model those differential equations efficiently using quantum algorithms. Machine learning is always my favorite, but also the one that worries me the most because if you ever say the word quantum and machine learning in one sentence, it makes people go to weird states. There are examples of data that you would have to put infinite data into a classical computer to be able to classify it, that I can provably show you with a quantum computer, I can classify it with exponentially less data. These are provable. Implementing these, I think, is going to take many years, and I think of this as the more longer term of these applications. The simple thing, if you take these applications and you do this sort of 2D plot and you see what this shows is, think of this as the quantum circuit. This is the object that runs on a quantum computer, that does this quantum math. If you're below around 100 qubits, 70 qubits is shown here, or less than 1,000 operations, honestly, go simulate it with a classical computer. They're the not interesting problems. I've shaded This is just a survey of all published algorithms from the quantum community showing Hamiltonian, showing optimization, machine learning, differential equations, and of course, cryptography. One of the applications of quantum computing is breaking different types of cryptography. If I say to you, What is our roadmap? Our roadmap is to build Starling in 2029, and you can kind of see it hits a point in this sort of space shown here, and then Blue Jay in 2033, sorry, 2034. You see it basically starts to solve these problems at this scale. You can kind of see that when you achieve this fault tolerant, the ones that you can prove with pen and paper become possible to solve on a quantum computer. In Arvind Krishna's keynote, he said, It's no longer science, it's engineering, and this is what we mean. We know how to get there. To show we have a roadmap to build these systems, I'm going to show a few slides and then I'm going to talk about interesting dynamics that we're seeing that is actually changing this landscape. The first is, if we want to build a system of this scale, it's a big system. It takes up a lot of floor space, but if you look at the power number there, 1.5 MW or 2 MW for the bigger systems, quantum computers do not use much power to actually solve these problems. Not only are we going to solve problems we couldn't solve, we're going to solve problems using very little power as we go forward. Why are we confident that we can build this? Well, first, we've done a lot of work creating new ways of doing error correction codes. I would say everyone in the field is now doing LDPC codes based on our recent paper in Nature. The whole field switched from surface codes to LDPC codes, that laid an architecture that made it no longer building a single bit of silicon, say, the size of a football field. You can make modular components, put it together, and then actually scale it up. We've demonstrated the first quantum Loon chip last year. This is the first LDPC code built inside a chip, showing that the technology is there to build the processor. We've got the plan for the processor. The next is, if you're going to put these systems together, you have to scale them. Connecting millikelvin environments is a non-trivial task. You are the first, actually, to ever see this photo. We have actually got up in Poughkeepsie, N.Y., we are working towards connecting these two fridges. As you saw in my original picture at the start, sorry. You can then imagine all these fridges connected in a line, we'll show the first demonstration of continually connecting modular fridges to scale in the next few months. This is a real photo of the real coupled modular cryogenics that is being cooled down right now in Poughkeepsie, N.Y. I hope I convinced you we've got a path to building these fault-tolerant quantum computers. You see there's a lot of white space in this sort of area where I can't prove by pen and paper a quantum algorithm, but I can't simulate it. What was an exceptional result led by, well, our thesis, sorry, is that by mixing CPUs, GPUs, and QPUs together, we can now think of quantum computing not as a replacement of classical computing, but as a subroutine, as something running in this heterogeneous accelerator framework, working and solving the different problems and allowing you to look at interesting problems of a bigger scale. Our partners in RIKEN showed exactly this. They showed that we could take an interesting chemistry molecule that would have required us building a quantum computer of the order approximately equal to Starling. By mixing a supercomputer, in this case, Fugaku, with our quantum computer, we were able to bring down a chemistry simulation all the way down to the systems that we can build today and run it, and this was shown last year. Of course, if you would've seen Arvind's keynote, those same ideas now have been extended by Cleveland Clinic, where you take a molecule and you break it into fragments, where those hard fragments are run on a quantum computer, then the other parts of the calculation are all mixed together so that you can actually start to do really, really big atoms. I'm excited by the fact that we are now simulating chemistry problems of the order of 10,000 atoms. When I talked to the scientist that did this, he said to me, I wish I went bigger and did 100,000 atoms. This methodology of mixing classical and quantum has made, in this case, molecules that matter, these are proteins, applicable much, much earlier than you would've thought. The same is true in this example. Here, the team of scientists across IBM, ETH, handmade a molecule. This molecule's a half Möbius. Completely irrelevant symmetry of a molecule, but you run around four times and you get back in the same place. It's a proposed symmetry that's exotic, never been seen, made by hand using an STM, basically placing atoms there. The STM image shows the actual molecule, to confirm it had the symmetry, we simulate it on a quantum computer using these classical plus quantum algorithms, and we were able to show that the results agreed. Another example to show that we're in this new regime where quantum computers are now not comparing against classical computers, we're comparing quantum computers against real data. If I want to understand materials, Oak Ridge, a large national lab, has a device where you can do neutral scattering and measure the cross-sections, right? This material is a trivial material, it's written down here. I forget where it is. I always get it wrong. It's a crystallized material. Sorry, I apologize. All right, I forgot what it is. It's a lithium high crystal. Basically, it allows you, and it's a one-dimensional crystal. You shoot the actual There it is, the KCuF3 crystal. You shoot the actual neutral atoms in there, and then you measure how it properties. You study this material physics. What the scientists were able to show is the actual physical observables, what they measured, is the same as what a quantum computer predicted. Now you actually start to see that the quantum computer is actually starting to be part of this scientific workload. There are many more examples of this. If you go into the Hamiltonians, obviously Cleveland Clinic with proteins. If you want to make strong materials that can make wings last longer, you want to do some composite packing, or you want to understand rare earth magnets, where you want to potentially, say, replace batteries, or you want to understand superconductors where you can trace energy, we have many of our partners looking at these algorithms and showing these type of examples. This is under the first case. Under the second case, optimization. As I said, optimization is about trying to find how you embed difficult constraint problems, usually when the constraints are changing with time. Example is Allstate. Looking at how you look at the mathematical problems, chance-constrained knapsack problem, but essentially the different constraints allow it to be a complicated problem that when you map it to classical computers, it's hard to do, but when you look on a quantum computer, you can start to look at it. Portfolio optimization by Vanguard is another example. There are other ones that have the similar type of behavior, high constraints, high optimal, where we're starting to look at these interesting problems. In quantum machine learning, as I said, there are exotic structures where you can rigorously prove that there are data where you can hide. In about 2024, we proved that we could determine whether an object is in a group or a coset, completely irrelevant mathematical problem. IonQ was able to map that to an interesting routing type of problem for looking at vehicle routing. Startups have now looked at different ways where they can embed the problem into allowing them to embed it into a Hamiltonian so you can put more data into the quantum computer, and you start to see these emerge. As I said before, think of machine learning kind of like 2012 when AI was starting with GPUs and we're looking at neural networks. This is kind of scientists seeing how these problems emerge. Differential equations, as I said, if we can do stochastic differential equations and we can map them, say, to Navier-Stokes, you can get to simulating interesting problems like weather or other exotic materials. At the moment, the team knows how to map them to what's known as compressed 2D. You can look at materials under pressure, flying through high nonlinearities. As an example, plasma inside a fusion is one of these, MIT working on this has looked at this type of applications. RL circuits recently actually just put on the archive. The teams have shown how you can look at designing RL circuits. It may sound like a simple thing, that's the first step to understanding complex graphs like logic design and things like this. Doing those type of problems exponentially faster will allow us to look at partial differential equations in the future. If you map this out, this is BCG's chart. You see these four categories, Hamiltonian simulation, machine learning, optimization, and PDs emerging. You start to see by working with different clients and partners, you start to see the connection of these four different key mathematics connecting to the use cases. I don't have time to go through them, but if you take pharma, you see that some of the pharma problems will be broken down to go on, say, some of the machine learning or the simulation type problems. You can start to see this mapping between these vertical use cases connecting to this mathematics. As we build these larger and larger systems with new algorithms, we start to see more of this emerge. BCG, I should say, also estimates that when this $1 trillion market is created, the hardware provider should be able to capture about 20% of it. Our strategy is pretty simple. Our strategy, written down from the start, is we are going to build quantum computers and provide them in a quantum platform with an open source software, Qiskit, built in a way that it can just connect into a hybrid cloud architecture as we scale forward. We are going to work with partners to create software on top. We're going to work on those use cases I pointed out, thinking about how we'd look at POCs or looking at problems that we can start to understand how we map them to quantum computers. We're also going to partner with many different companies on doing that. As we go forward, what matters for winning that platform layer? I like to think of it as broken into three key things. Obviously, you need quality of the systems. When you run these quantum circuits, if you get the wrong answer, they're useless. You need to get the right answer from it. You need to have scale. How many qubits can I put down? A topic that is often forgotten is speed. How fast can I run this quantum math determines the time to solution. If it takes me 10,000 times slower to run something, then it's not useful. If you look at these three dimensions, you can start to lay out a sort of a mind map of the different technologies. What I've shown here, and I agree there's a lot of data, and I apologize, is down the bottom, there's a 2D plot that shows the scale, the number of qubits, and the quality. You can see in blue is IBM. You can see a dotted line where I've gone around a quality enough to allow me to do 1,000 operations and a scale to be above 100 qubits. We're very proud of the fact that we are the dominant player in this space. You see that others emerging in that space is Google, China, and Quantinuum recently. You can think of that as a quality scale side. The speed side, no system except spin systems comes close to running operations like superconducting. If you really want to run operations really, really fast, you've got to build it on a CMOS architecture where you can engineer the interactions to have gate speeds at a point that allows you to execute them on speed. If you take the numbers that we can measure for speed and compare it to, say, spins or sorry, not to spins, to neutral atoms or ions, you find that we're about 10,000 times faster. When it comes to price to solution, this becomes most effective. We as a community are starting to see these things get benchmarked. I just put this as an example from a foundation that is trying to start to benchmark these systems, benchmarking over all available processes. You can see for the IBM systems, clearly our numbers at the moment are the best. You see Quantinuum coming in second because they have very high-quality gates. You can kind of see if you compare the CLOPS metrics. The ion systems do not measure a number because they're very, very slow and only the superconducting based systems can measure it. You can see other competitors like IQM, Rigetti, and some of the systems designed in China. Coming to systems, if we're going to also build a community, we want to build an ecosystem. From day one of putting it on the cloud, it has been our goal to make sure that we are always continuously updating and showing that we can build both data centers where our cloud users can operate. We, from the start, knew that we need to have a data center in Europe as well as a data center in the U.S. so that any sovereignty concerns can be eliminated, as well as install quantum computers in a variety of universities, national labs, and Cleveland Clinic as an example of the first enterprise partner that is working towards those type of applications. To date, we've deployed, as I said, 91 systems, with 30 of them above 100, and the only other competitor close to 100 is Google. In terms of software, if you want the analogy to GPUs, what mattered for GPUs to be adopted was performance software. Performance software allowed me and my colleagues when we were younger to write physics problems, whether it was machine learning or simulating physics on GPUs, we all were writing on this language called CUDA. CUDA was the most performant software to allow us to look at interesting problems. We've taken that analogy with Qiskit and said, We will make sure Qiskit is the most performant and easy to use software for executing quantum circuits. I'm very proud of the fact that when we benchmark it is 100 times faster than everyone else, but it is also shown by various different metrics to be the most adopted. You've got hardware, you've got systems, you've got software, and of course, you've got the ecosystem. If you want to grow a large ecosystem, you need to have a lot of academic and national lab partners that want to do this algorithm research with you, but you also need to have startup and commercial partners that want to integrate, build upon you, and eventually industry clients that want to be the clients that use this. Since we put the IBM network together, we've been growing this year-over-year. I'm very proud of the fact that we're over 325 members using our quantum computers. On that, I think I'm going to end and open it up for questions. Yep. How about over here? Mark. Thanks very much for doing this. Really very interesting, very helpful. Could you talk a bit more about the other modalities, other approaches to quantum? Yep. Why IBM's approach, superconducting qubits, is the approach that's going to win? You touched on it a little bit there. Yep. Of course, some of the others like Quantinuum, Trapped IonQ, Neutral Atom, some of the other approaches, some of the other competitors out there. I'm going to stay factual based on modularities. Superconducting qubits is actually the newest technology. It is the newest from the history. I think photons is the oldest. When I was in Australia, I worked on photons. Okay. First, it's the newest, and it has allowed it to scale fast because of one reason, and that one reason is it's built on CMOS. When you build something on silicon, you can get iterative cycles of learning that once we showed the two-qubit when I was at Yale in 2007, we then showed how we could get a gate. You could scale it and run it. For everyone else, they think, Oh, superconducting is the oldest. No. It is the one scaling really, really fast because it's built on the CMOS technology. I've always wanted to have a technology built on a foundation that you can define effective cycles of learning so that you can iterate and you can iterate really, really fast to have a predictable roadmap that we can stay on it. It's built on CMOS is why we have stayed to the roadmap. Other technologies that have put out roadmaps, if you go look at them, they change all over the place. Number one, build on a foundation. If you want to build a quantum computer, if it takes me 100 years to run an application, it is not useful. You need it to be fast. The only systems that allow us to get to nanosecond operation gates are spin-based systems and superconducting systems. The physics of it is you come in and you can basically engineer a very strong electric field and then decouple it from the environment. The weakness of these systems, and in particular spin systems and why they're not anywhere near superconducting, is because you can engineer that strong environment, they decohere more. Ions have always had the best two qubit photons. If you make a polarization photon, you look it through a glass, it stays H and V polarization as long as light exists. They had very good qubits, engineering them to have fast operations has made them almost impossible to do. Okay? That is why even photons, since the first two qubit gate in 2003, they have not made really progress. Okay? They talk a big game. Fundamentally, it is very hard to do it. You have to engineer a really exotic coupling that honestly, if you could do it, you could make a lot more money in optical interconnects than classical, but it's really, really hard to actually get that to offer the strength to do it. Once you start to go, I want speed, I'm willing to sacrifice quality if I can show a path through engineering, I can make progress. That has always been the challenge of superconducting qubits. When I was a postdoc at Yale, and we first put the transmon online, it had a coherence time of 100 nanoseconds. We, through understanding materials, material processes, cleaning up the material, we're now at three milliseconds in our isolated qubits. In our 100 qubit devices, when we have more layers of metal, it comes down to about 300 microseconds. I want another factor of 10. At around a factor somewhere between 300 microseconds and 3 ms, you get a error rate that is enough for error correction to work. I want maybe a factor 2- 5 more in coherence time, which I've already proven in isolated devices in my more complicated ones. That is the big challenge for the superconducting. When you look at these different modalities, I really advise you to ask this question: What is your plan to have fast operations? If you have no plan, honestly, you're building a scientific experiment, not a business. What is your plan to get quality? This is where superconducting and spins will be hit the hardest. Spins still suffering, because electrons 1/f noise is harder. Superconducting, as I said, we're now in hundreds of milliseconds, sorry, hundreds of microseconds. I want another factor of five to 10. Scale, if it's built on technology that doesn't allow you to show cycles of learning like CMOS, I question the ability of scaling and dealing with all of it. Could be wrong, we have chosen one based on a platform that the classical industry has shown, like it's all silicon with metal. Superconducting is silicon and superconducting metal. Rather than silicon and copper and other types of metal, spins are superconductors, you basically artificially create dots inside it. It's still built on silicon. If you want to scale, you want to have a material that you basically can get that engine going. Iterate. We transitioned from, let's call it our research, 200 millimeter fab to our 300 millimeter fab, which is equivalent to the tools that you have like TSMC and the standard foundries about two years ago. Since then, I've seen a factor of 30 improvement in my cycle time by that transition. That transition was a big one. We had to go from our internal 200 millimeter, I want to call it university-grade fab to commercial-grade fab. You can get into arguments, throughput, and exactly what university. That made a 30 times improvement, and that's the beast that goes. When you're asking those questions of other modalities, that's how I would ask it. If you were asking me and saying, Jay, you can't do superconducting, I would actually choose spins and deal with the fact of making noise better because it's built on a technology that scales. Right. Hey, Jay. It's Rathan. My question's not going to be on the hardware-based modality as the previous question, there seems to me that the research that's coming on the algorithmic side at this point, the developments there seem to be more standardized based on the modality. As an example, I'm sure you saw the Preskill paper right on coming out of Caltech and Oratomic and in terms of what they're doing with solving Shor's at 10,000-11,000, that's going to be on neutral- Yep atom, QNTT, the JVG algorithms, other stuff like that, which seem to be very specific to their individual modalities. For the most part, that's not whereas on the QLDPC side, I guess that could be applicable to everything. My question is, a lot of the engineering, the hardware-based engineering progress is incremental, right? Let's just assume all the hardware-based modalities get there. These types of innovations are more kind of these zero to one jumps, right? Yep. In terms of theoretical insights that one has to have. How do you approach that? It seems like there's a forking going on in terms of the algorithmic research. Algorithmic research we need more of. I agree completely. To pick on the papers you did, we were stuck as a community in this thing known as the surface code, and if you look at old roadmaps, even though I was hiring every error correction grad student that graduated, we did not put error correction on because I did not believe in the surface code. This LDPC code, if you look at the one by Preskill, it is extensions of the LDPC code. How we extend these ideas of LDPC codes, we will make huge jumps in the algorithms and by having the ingredients that we've shown in Loon to be able to engineer in a silicon-based and arbitrary LDPC code. What are the advantages of neutral atoms? I don't need to use CMOS to engineer it. I can do a change my laser and do it. I can show the primitives and it's worthwhile, I can now build this on an architecture that I can iterate strongly. I would say the first jump was this paper. Since then, they're actually better LDPC. I didn't have time to go into how we're improving LDPC. On that particular paper, the 10,000 was associated with 100 years because there's routing and things like this, but the high-level macroscopic is the invention of LDPC codes has changed the game. Being able to build LDPC codes is a must. Is it easier to do proof of principle demonstrations of LDPC codes with neutral atoms? 100%. If you want to build a scalable, fast architecture, you need to show this Loon type chip, and the details of this Loon chip is it has 10 levels of metal. It's metal, dielectric, metal, dielectric, metal, dielectric, 10 times. Three for input output, three for the different types of connections, one for the qubit, one for the readout, and then two grounding. Sorry, I think 3+ 3+ 2+2. Yes, I got 10. That type of stack was needed to give us the ability. Once you can have three for the routing, I can connect any. All LDPCs have a low weight graph, but they have arbitrary connections. Once I have three, think of it as a highway. You've got bridges, I can connect it. I kind of said this with the comment on crypto relevance. My expectation with LDPC codes is all numbers you ever heard, like three million physical qubits, 10 million just throw them out. We knew this was the case. The person that invented the surface code, Sergey Bravyi, is the lead author of this. Well, sorry, the person that co-invented the surface code with Alexei Kitaev at Caltech when he was a postdoc, he is now an IBM fellow. He's the lead author of this paper. It's always amazing that it's a single person creating, basically changing error correction continuously. How this error correction changes, take all those numbers that you've heard, like 10 million, three million, throw them away and ask for the fault tolerance, do you have a viable path to get these LDPC codes working? Then I think there'll be algorithm innovation. There's another one on Shor's algorithm where you replace the multiplication with classical, and that has not been worked out yet. Yeah. Hey, thanks. This follows up a little bit on one you were just discussing, but totally understand that IBM has taken the superconducting approach because that lets you solve scale, and you've worked towards quality, fidelity, error correction from there. At the same time, if you take some of the competitors, trapped ion, I don't do quantum, but I know there's a lot of smart money and a lot of smart people where the funding is going to some of these other approaches. My question is, do you see a path down the line where people who are taking the trapped ion or those competing approaches resolve the scaling issues, and eventually there could be two architectures or two approaches that get you to the top right of that quadrant? Do you guys feel pretty firmly that you have the right approach and eventually the competing alternatives out there are going to converge to the superconducting approach? As a scientist, I'm never going to say it's fully solved. As a scientist, we always have to explore. Photons are beautiful ways of creating superpositions that last for a long time. Trapped ions are natural qubits. You can have a trapped ion, and it can be a natural qubit. When I've worked in different modularities and when people in the team have worked in different modularities, Well, to answer your high-level question, if there's multiple modularities up there, it's good for everyone, and we'll get more algorithms, and we'll go faster. I think the probability of that happening is low, to just answer it. I think it's going to depend on technology built on CMOS, silicon. Many of those other modularities, if you're honest and you ask, they are trying to solve their issues by going to silicon. Trapped ions are building new traps based on silicon, where they can engineer the magnetic fields to be closer, so they can solve some of their scaling issues. Photons are building waveguides to have stronger non-linearities so they can couple. When you think of it, that's the path they're going, but I still worry about all the other technology like lasers and things like this to keep it. Science is science. We have to go fast in the end. It's going to matter who gets there first and who can build a quantum computer that executes circuits on speed. Great. I think we have time for one more with Wamsi. Thank you, Jay. Maybe just a simplistic question here, but if you think about the announcement that Arvind made on stage around the simulation of 10,000 atoms, and frankly, there was a comment about why not have that have been 100,000. What is it going to take to, A, go from 10 to 100,000? Is that technology sort of already there? What was the scaling jump that enabled the simulation of this 10,000? Was it the coupling of the supercomputing capability with the quantum, or was there something in quantum itself that kind of made a jump that allowed for this to happen? Yeah. All of the above. It's on our new processor, it's a little bit better on our latest R3 Heron. It's an architecture that brings GPUs, CPUs, and QPUs together. They used Fugaku, which is mainly CPU based, and I cannot say the one in Japan. The supercomputer at Tokyo. Cleveland Clinic has a partnership with RIKEN where they were doing it. That was GPU based. Yes, better hardware. Yes, better integration with the classical compute. Also Cleveland Clinic designed a new algorithm they called a TRIPWF that gave them the ability to fragment a problem into interesting things. I would say better hardware, better integration, better algorithm, and now they feel that they can scale it. The real question is going to be how big is the biggest fragment that needs quantum simulation? That's where it's not the number of atoms. If you're going to a really big fragment, you need a better algorithm to tell you, Do this part quantum, this part classical, this part quantum. How big is that quantum part is where the limitation's going to be until we build bigger ones. Many of the interesting sort of fragments, and now I'm out of my depth, I'm just going to repeat what the chemists told me because they are better than me at this. They tell me that the interesting fragment size is around 100 to 200 qubits. Which is of the order of the systems we're doing. I don't know if that's just because they've never really been able to take a classical computer of fragments above 50 and that you need to go to really big, they say in this sort of 100-200, there's a sweet spot of having quantum fragments that we can join together. I'm totally out of my depth answering that as the chemist. All right. Thank you, Jay. Thank you.