So we've spent, you know, the last 5 years building up this business. Today we launch two new car models every week. That's the rate at which the business is scaling. There is not really any automaker that is not deployed on our cockpit platforms. Most use our telematics. We are getting aggressively in the ADAS space and I want to give you the sense because we start to think about what we are providing also as a chassis. When I use the word chassis, what I mean is a predictable platform on top of which you can start to do development very quickly that is relevant to a very large number of vehicles that you will deploy. We've seen over the last and this is stats from the last 15-18 months, the time from first silicon to an automaker to SOP: 15 months. 15 months. This is not a simple SOC. This is highly complicated SOC. Obviously the level of risk that OEMs are taking is very different, but the rate at which things are moving is at a point where it is all about having a very deep understanding of the software that you're building, to where you are essentially bridging from one platform to the next platform. So if time is what you're using, that isn't really going to be your friend. And we are now starting to see just changes in our own planning where we planned to launch three OEMs in the first 6-9 months of a year. By the time you get to 6 months, you've launched 11. By the time you get to the end of the year, we might have launched 20. This is the rate at which this ecosystem is changing.
As you start to look at the numbers, I think what is important to keep in mind is that these are compounding in terms of the rate at which this is evolving. You know, we've all seen computer vision over the last, you know, 10 years. Ricky talked about our engagement back in 2012, 2013. I remember videos on computer vision and I think the name of the car was Bobby if I'm not mistaken. It was an autonomous driving vehicle on the lap. Computer vision has been around in the automotive industry for a long time. We've also seen natural language, you know, Nuance and other types of products that have been in the car. But what you are now starting to see is not the same. A vision language action model is actually a completely different type of AI. And if you start to think about these use cases on the right hand side, you know, when we use the word agentic, when we use the word and you've all used Gemini, you've all used Claude, when you use this term in the context of the car, which is agentic, which is you have a conversation with your car and the car is seeing the real world and then responding to you and this is actually normal. A couple of things come to mind. I think first of all the question is: is this the future? How far away is it? I think that's one question. I think the second question is: is it safe? Can we rely on it? What happens if something goes wrong? All of those typical questions that would come in. But I think the fundamental question that comes in is this is a different type of software development. This is actually you can't even call it rules-based. This is actually software development where you are running a very powerful model, its distilled version in the car. You are then providing it the necessary prompts through your sensors. You're providing it camera input. You're providing it information about who's inside the vehicle. It is connecting the dots. It is realizing who's in the driver's seat, the passenger seat. And then based upon the model's intelligence, it is creating an experience for you. Those experiences are not bounded by anything because they're really learned based upon habits. And we can think of this as: is this bringing in a massively complicated path to software development or we can actually think about it very differently.
which is this is actually fairly straightforward. If you start to do agentic development, I'll give you a sense as to how this is evolving in the platforms that we are deploying today. Everything that you are seeing here is commercial. This is not somewhere in the future. This is in cars deployed today. We talked last year, I recall about software-defined vehicle and the SDV stack. We've spent a lot of time on simplifying the infrastructure for an SOC for it to be able to connect to the application layer, right? We do QX, we do hypervisors, we do Linux, we work with Google to deploy containerized virtual machines with Android, we do all types of integration and the reason we can do that is because we have a very wide berth at the silicon level. We can think about how to preserve the investment that a very complicated OEM ecosystem makes such that when you go from one generation to the next generation you can preserve that investment. But now what we started to see 6 months ago with Open Claw coming out is that everybody wanted to run Claws on this same SOC. And so we broke that down. We said okay what does it mean to run a claw? And it's actually not as complex as you might think. The claw needs access to hardware. The hardware is a model, is an MCP server, a model context protocol server that is in the car which you have to secure. You have to make sure that you can control the access that you're providing it. On top of that it has to have access to some kind of a model. It's hybrid, part of the model will run in the edge, other part will run in the cloud. And so we said okay let's go figure out, and this is the benefit of working with a dozen OEMs who are all competing against each other to launch something in a very short window of time. So we built out actually the stack for what does it mean to do agentic development on our SOC. It's the same SOC. It's the same SV platform. This sits right on top.
Now what is the reason to show you all this? You know, when we got into this business, one of the thesis that I had, you know, I like Fian's comment about Bezos saying you know what are the things that will always be true. One thing that I think is always true about the automotive ecosystem is the OEM owns the customer. The OEM will always own the customer. The OEM will never relinquish the ownership of that customer, the association with the brand. And if you look at this, this really comes down to how does the OEM orchestrate the experience that it wants to provide to the customer. And so we are starting to see a tremendous amount of work happening in orchestration. How do you manage that relationship that the OEM is building with the customer? Where do you send the query? What model do you use? What is the cost of the model? What will you service in car? What will you send to the cloud? And on and on. And it requires you to have a framework within which you can go implement this. So we are spending a lot of time with a number of people in the ecosystem to make sure that this is once again a platform that we can provide that is open. We are not building our own models. We obviously have some proof of concept clues but we will use whatever is out there that is open source. But this framework, these guard rails, this template, this is super important to have in place because ultimately in my mind, the experience that AI can provide in a car is probably one of the richest experiences that you will see in any consumer device, more than what you can do with the phone, more than certainly what you can do with the PC, but you have to plan and prepare for it. The other thing to keep in mind is this isn't something that is in the future because at some level we've actually made it very simple to go do this because hosting a model inside an SOC means you have to be able to have a powerful NPU, a powerful accelerator, which we have been designing for, and making that model have access to context is something that is software that you can wire and beyond that is just one more experience. Experiences that you're seeing in your phone, in your PC can just be transported over. So both the opportunity and the threat are this is happening now. This is not 5 years out. This is happening right now. And you will see cars, certainly cars from competing OEMs, competing regions, that will have this capability built in because it is actually not all that hard to go build this in.
How are we able to do this over and over and over again? Because we keep the underlying foundation of the SOC the same. We don't change that too much. And when we go across tiers in the same generation or across generations, we maintain that compatibility. And we do that now more and more because we almost realize that we seldom have the silicon available when the OEM wants to start development. So the OEM has to start to do development on the previous generation and then port that development over. That almost has become a norm if you have to hit these 18 month, 20 month timelines between silicon and SOP. And this has allowed us to then take the same thought process also to ADAS. So what we decided five years ago, maybe a bit longer than that, was there is no point in automotive to design silicon for infotainment and then design separately silicon for ADAS. We will just design safety silicon. And when we made that decision, you know, we built all of the IP that we put into our chips is built inside the company. We don't license very little IP, so everything that we build we have to make sure that we can stand behind. So when we made the call to make all IP safety grade, that means everything has to be certified by us, tested by us, compliant to every single OEM standard. And we made that call 7 years ago. So we made that decision, it was the right decision to make because what we are now realizing is that there isn't really, if you think about AI, AI doesn't differentiate between whether this is a cockpit domain or if it's an ADAS domain. It's just data that you are processing with a model. And so the underlying infrastructure has to have tremendous optionality. Once you design the optionality in the hardware and in the software, it allows you to be very free in terms of the decisions that you can make. And I'll show you some examples as to how this is going.
We also took on about five years ago the challenge of building an ADAS stack. It's a very interesting, you know, if I over a beer I can share with you what the lessons were of getting into a new business that we as a silicon provider have not been in. But in hindsight I think it has actually been a fantastic learning experience for us because building an ADAS stack has taught us a lot of different things. We are entering into a space that is about safety, that is about homologation, that is about a global footprint, tearing of features, the ability to be able to keep these stacks relevant over a period of time. We certainly have tremendous benefit in having a very large silicon roadmap so that we can do a lot of code design. And when we started building the stack, there were no transformer architectures. So we started these stacks on a rules-based very conventional architecture and over time we have realized the complexity of that transition. How do you transition and redo the same work on a new architecture in parallel? We've seen how China has grown and evolved in this space. We also made the decision that we are not going to have an either strategy. If we are building our stack, we will not partner with other stacks. And that paid off very well for us also because we have partnered with a very large number of stack providers. And what it has done is it has allowed us to understand the architectures of next generation stacks and how they are relevant to our SOC. So when we think about that experience and we think about our own stack, we can start to understand what are some of the things that we have to plan as we think about the next generation, next generation silicon. But this experience is foundational because one thing that I can share with you is, you know, if you think about buzzwords like physical AI and the car is physical AI, there is not a better example of physical AI than the car. And you can't really build a car if you don't have familiarity with AI models, where you can't actually get AI to run in the car as the core feature of the car. And so when we made this bet, I feel fortunate that we did because it has given us so much optionality as we start to get into other types of physical AI spaces which I think all of you in this room are thinking about, certainly if not looking at already. Robotics is going to be a really big area that's going to have major needs to be able to have similar infrastructure that will be needed.
And I like this slide. It's a little technical, but I like this slide because it actually explains how the in-cabin experience and the ADAS experience are actually kind of the same because what you're basically saying is the car is a sensor that is mobile and it has a lot of different data that is coming in. That data can be visual data, can be radar data, can be LiDAR data, can be audio data, any kind of data. And that data is processed by different types of models. It can be processed by an ADAS model. It can be processed by a large language model for the cockpit. And what you extract out of it is the experience. It can be a driving experience. It can be a cockpit experience. And then when the user interacts with the vehicle, the vehicle simply reacts to the prompt and then executes to that prompt. This is how the car is actually starting to get designed. And so if I were to show you this slide 2 years ago or even a year ago, this wouldn't make any sense. But today, if you think about silicon architecture, this is exactly how the silicon is being architected because you really have to be able to figure out what is going to get processed where. And I'll connect this into the dots in terms of where silicon architecture is headed.
So I think you all know that we've been big proponents of mixed criticality. We've been pushing flex architectures. We now have flex architectures on the road. But this is literally what is now happening. You know, I think in the talk that Florian gave, one data point that came across very clearly was that the cost of silicon is not going down. Right? The cost of wafers are continuing to rise or stay flat even though you are getting some improvement on density. So what is happening is the bigger the piece of silicon that you make, the more you want to get out of that. Now we are on our third generation of SOC architectures with this flex strategy where we are building mixed critical architectures. So what that means is if you want guaranteed quality of service, guaranteed freedom from interference for a specific set of cores, for a hardware block, for a memory configuration, that is something that we guarantee in the system. And as you start to do that, you essentially can drive a significant amount of cost savings. So for systems that are running on discrete IVI systems, discrete cockpit systems, you can keep them separate. Obviously, you can also start to bring them together and we are starting to see a lot of that in our mixed criticality architectures.
And at this point in time, we don't really build silicon that is anything other than this architecture. Of course, our customers have the choice of using them only for cockpit or only for ADAS, and they do depending upon what they're trying to go do with it. But the flexibility allows us to be able to at a tiering level, at the lowest tier we can offer flex but you can choose to do cockpit or ADAS, and of course at the highest tier same thing, but in the middle you actually start to see a lot of OEMs think about hey, if I can actually take a stack that I'm sourcing from a certain supplier and run it as an application, and take my IVI run it as a separate application, can I actually consolidate? So we are starting to see significant change in the vehicle domain architecture. And by the way, from a cost savings perspective, this is actually significant savings because it brings down PCB cost, memory cost, overall hardware BOM, software BOM, and this is getting deployed with features, right? So every single type of feature you can think about, whether it is on the ADAS line or it's on the cockpit line, these are all getting deployed. And these are all examples of what various OEMs have started to go deploy. And it literally comes down to being able to decouple the hardware architecture, the sensor architecture from the stack that you will use. And I think you are very familiar with that now because you have so many different NOA type implementations. Similarly, you can decouple the cockpit architecture from the model. You can use an orchestrator and a model. They are not coupled with each other. And as you go to that level of abstraction, you can implement that on any kind of SOC architecture. That's a flex architecture. This is now the path that we are starting to go down. And it is very powerful because it changes the amount of investment that you have to make in software on a generation on generation basis. It allows you to be able to be very nimble and very agile. These are some of the OEMs that we have commercialized. But I can share with you without sharing too much more detail, in 2028 we will have global OEMs deploying flex in every region, right? So this is starting, this is here, and the next generation silicon that we are building relative to the previous generation is 5x more capable, so there is plenty of headroom to be able to actually take advantage of that capability. Okay.
So the other things that we start to see is now this idea of running more acceleration in the car. And, you know, if you had asked me again a couple of years ago, hey what does this mean? But some of this is from customers. The idea to be able to run federated AI inside the car because the hardware is there is the question that OEMs have asked us because they believe that at some point in time the currency that you can use is tokens. And so if you want to be able to use the car at a federated level as a token accelerator, is that something that you can deploy the car around? And while you might take a step back and say hmm that sounds really odd and farfetched, etc., actually it's not that odd because we are now running 30 billion parameter models in the car here in 2026. So by the time you get to 2030, the type of AI that you can run in the car is actually not all that different from what you might be able to run in your desktop PC. And if you have that, that is now an asset that belongs in every single vehicle. It has local memory. It has a tremendous amount of capability. The other piece of course is to add the accelerator to the SOC. So you know we have deliberately been very focused on the L2 plus part of the ADAS stack because we feel like we really have to get that at scale. We are now starting to see with more advances with the right type of redundancy with the right type of safety implementation, the need to be able to add an L3/L4 accelerator. But the approach that we are taking architecturally is simply to make that an add-on to the SOC as opposed to redo the complete architecture because we've invested so much, everybody's invested so much in getting the software story right, and this to me is super important because you don't want to break the amount of work that's been done in making sure that software stability is left intact.
Pivoting quickly to connectivity. So with Starlink now, satellite is actually becoming a really interesting opportunity and you will start to see both coverage and data rates expand very significantly. And we've started to see certainly for specific tiers of vehicles in the rescue space, in the commercial space, satellite connectivity becomes something that has been requested. So we are spending some time on that. And then the last topic that I would like to discuss is this idea of being able to run AI workloads, AI workflows in the car. This was a topic that came up with some colleagues in Germany actually where there is so much data that the car captures across so many different domains outside of the cockpit and outside of ADAS. If you look at battery management, if you look at powertrain, if you look at drivetrain, there is tremendous amount of data that needs to be processed that needs a model that does not need to go to the cloud. It can actually be processed locally. So what we've been working on in other parts of the business is machine learning models, not necessarily computer vision or transformer based, just simpler machine learning models, and run those models locally in the vehicle. We have plenty of NPU capacity to be able to run these models, but we've created a platform called Edge Impulse that allows us to be able to really take any kind of data from powertrain, engine, chassis and dynamics, of course, safety and ADAS, and then start to scale this to where you can actually now correlate information between driving behavior, what the car was seeing, what the battery consumption was. All of this data is super relevant, super important today. You're doing all of this by taking this information to the cloud. This can now actually be run locally in the vehicle. So, happy to go into more detail with this, but this is something that is yet another example. And here's a very quick video that kind of gives you a sense as to what that looks like.
