A Clear Lead in Performance-for-Value

This dominance isn’t just theoretical; it’s visible in plain sight on leaderboards like the LMSYS Chatbot Arena, which pits models against each other in blind tests. Across the entire spectrum, Google’s Gemini family is establishing an undeniable pattern. Whether it’s the small and versatile Gemma, lightning fast and inexpensive Gemini Flash, or the top-tier and powerful Gemini Pro, each model consistently delivers performance that punches far above its price point. This isn’t just winning one category; it’s a strategic placement across all tiers, offering remarkable performance for value no matter the use case.

This consistent lead begs the question: how are they doing it? This isn’t a temporary sale or a minor lead. It’s a structural advantage. The answer has less to do with the models themselves and more to do with the custom engines they run on.

The NVIDIA Tax and the TPU Gambit

For most companies, the AI boom comes with a hefty tax. It’s paid to NVIDIA. To build or run any serious AI at scale, you need to buy or rent their GPUs, and you pay the price for their market dominance. This isn’t a criticism of NVIDIA; they make exceptional hardware. It’s just a statement of fact about the economics of the industry.

Google decided to play a different game. Over a decade ago, they started building their own chips: the Tensor Processing Units (TPUs). This is fundamentally an argument about vertical integration, which is not dissimilar to how Apple sees its Hardware and Software going hand-in-hand. Instead of renting a factory, they built their own. But more importantly, they got to design every machine inside it.

A GPU is a powerful, general-purpose engine. We use it for graphics, scientific computing, or AI. A TPU is different. It’s a custom-built engine designed for exactly one purpose: running neural networks. At their core, neural networks process information by performing a staggering number of matrix multiplications. Data is represented in large, multi-dimensional arrays in the form of “tensors,” and training or running a model is essentially a marathon of multiplying these tensors together. A TPU strips away unnecessary components and perfects this one operation. Its architecture, built around a dedicated Matrix Multiply Unit (MXU), is like a hyper-efficient assembly line designed for this single mathematical task. It’s less like a car engine that can do anything and more like a Formula 1 engine designed for pure, unadulterated speed on a specific track.

This specialization goes even deeper. Modern AI often deals with “sparse” tensors. Imagine looking up a single user’s viewing history from the billions of hours on YouTube. The resulting data tensor would be enormous, but nearly every value in it would be zero, representing a video the user hasn’t watched. A general-purpose chip wastes immense effort and energy multiplying by zero over and over again, which is a computationally useless task. Google’s TPUs have specialized hardware called SparseCores that are built to handle this exact problem. They are engineered to identify and skip these zero-value entries, only performing calculations on the meaningful, non-zero data. This isn’t a theoretical edge; it’s what makes products like Google Search and Ads run efficiently at planetary scale.

When you see the results of this strategy, like the prices for Gemini, you’re not seeing a marketing gimmick. You’re seeing the economic output of a more efficient machine. Google can afford to charge less because it costs them less to get the answer. And this advantage is compounding. Their newer TPU generations, Trillium and Ironwood, show an obsessive focus on widening this lead by dramatically increasing memory and improving an already specialized architecture. They aren’t just getting faster; they’re getting more efficient at the exact workloads that are becoming AI’s biggest bottlenecks.

So while we obsess over which chatbot is more clever, the real moat in AI may be forming at a much deeper level. It might not be the model’s intelligence, which can be fleeting, but the brutal economics of running it at scale. Other companies are in a race where the cost of fuel is set by a single supplier. Google is quietly showing everyone what happens when you own the oil refinery.

A while ago, I stumbled upon one. It started with an old piece of military memorabilia, a small metal artifact stamped with just three words: “Cheung Po 1899.” This was posted in a reddit post.

The person who found it was asking for help. Where was Cheung Po? No one knew. It’s not on any modern map of Hong Kong or Shenzhen. It seemed to be a ghost, a place that existed for a moment and then vanished. It was a dangling pointer. A bug in the historical record. And like any good bug, it hinted that the underlying system was more complex than the documentation suggested.

As so often happens, the bug wasn’t in the history itself, but in the data entry. “Cheung Po” was almost certainly a Brit’s attempt at writing down a Cantonese name. The most likely candidate was 軍陂 (pronounced roughly Gwan Po), a small area just west of the old Shenzhen market—Sham Chun Hui. An 1866 map, drawn by an industrious Italian missionary, confirmed it. There, right next to “Sham Chun,” was a place he’d labeled “Sheung Po.” We were getting closer. The map can be found in CUHK’s archive.

The date, 1899, was the real key. In 1898, Britain had leased a huge tract of land from Qing China, which would become Hong Kong’s New Territories. But the local clans living there hadn’t been consulted, and they weren’t happy about it. When British troops arrived in 1899 to hoist the Union Jack, they were met with armed resistance.

The official story is of a short conflict, after which the new border was established at the Shenzhen River. But the reality on the ground was far messier. To quell the resistance, British-led troops pushed north of the agreed-upon border and occupied the market town of Sham Chun. And it was here they set up camp. One of those camps was at Cheung Po.

The final piece of the puzzle came from a historical journal, quoting a letter from a Major Prendergast, R.E., dated July 1899. Its location? “Cheung Po Camp, Shum Chun.” This was our smoking gun. The camp was real. It was a temporary, unauthorized footprint on what was technically still Chinese soil, a product of military necessity that politics would soon erase. The Prime Minister back in London got nervous about the overreach, and the colonial government didn’t want the expense of securing more land. The troops were pulled back, the camp was dismantled, and the name “Cheung Po” vanished, surviving only on a few soldiers’ souvenirs. The bug was patched.

The quotation reads:

“The regiment took an active part in the occupation of the New Territories in 1898/1899. Detachments were present at the occupation of Tai Po, and the “battle” of Kam Tin. They also provided the garrison for Shum Chun (north of the present frontier) which was initially occupied for some months. An interesting letter dated 14th July 1899 from Major Prendergast, R.E. in command of the troops at Cheung Po Camp, Shum Chun, comments indirectly on the good discipline of these soldiers and advises against their relief by British soldiers.”

Solving this puzzle felt satisfying. But it also felt artisanal. It required one person’s curiosity, hours of digging, and a lucky break finding that one journal article. And this is where the story gets really interesting. Because that whole process is about to change.

Imagine training an AI on the millions of pages in the British colonial archives. On every map, hand-drawn or printed. On every ship’s log and soldier’s letter. You could then treat history not as a story, but as a massive, messy dataset.

You could ask it questions that are currently impossible to answer. “List all place names that appear in 1899 military correspondence but don’t appear on official 1900 maps.” Cheung Po would pop right out. So would many others, I suspect. You could cross-reference phonetically similar place names across documents written in English, Cantonese, and Hakka, instantly resolving thousands of “Cheung Po” style transliteration errors.

This isn’t about replacing historians. It’s about giving them a superpower. It automates the most grueling part of their work—the search—and frees them to do what humans do best: ask questions, see patterns, and tell stories.

The story of “Cheung Po” is more than a historical curiosity. It’s a reminder that the past isn’t a fixed narrative, but a vast, largely un-queried database. There are thousands of forgotten stories, contradictions, and bugs lying dormant in the archives. We’re finally building the tools to go find them.

And as soon as you decide to build one, you face a choice. It’s a choice that says a lot about what you’re building and who you are. The choice is between something like Microsoft’s Semantic Kernel and OpenAI’s own Agent SDK.

Looking at them, you might think they’re direct competitors. They both help you build agents. But that’s like saying a freight train and a Formula 1 car are competitors because they both have engines. They’re engineered for fundamentally different jobs.

Semantic Kernel: The Freight Train

Semantic Kernel is Microsoft’s answer to building agents. And it’s exactly what you’d expect from a company that has powered large enterprises for decades.

It’s built to be robust and to work everywhere. It supports C#, Python, and Java. Why? Because if you’re a big company, you don’t have the luxury of everyone using the same language. You have teams in different decades of technology. A tool has to meet you where you are.

It’s also mature. It’s past version 1.0, which is a quiet promise of stability. It says, “build your business on this; we won’t change everything next month.” For a large organization, predictability isn’t boring; it’s a critical feature. Semantic Kernel is designed for a world where systems are complex, security is paramount, and downtime is expensive. It’s the freight train: powerful, reliable, and designed to haul serious cargo across a vast network.

OpenAI Agent SDK: The Formula 1 Car

Then there’s the OpenAI Agent SDK. It’s built for one thing: speed.

It’s Python-only. For a small, AI-focused team, this isn’t a limitation; it’s a simplification. It’s also described as “evolving.” For an enterprise, that’s a red flag. But for a startup trying to build with the absolute latest OpenAI tech, it’s exactly what you want. You get the newest features—the improved function calling, the built-in search—the moment they are ready, straight from the source.

Using it feels like you’re working with a direct line to the model architects. The goal isn’t to be everything to everyone. The goal is to be the fastest and most direct way to build with OpenAI’s technology. It’s the Formula 1 car: unbelievably fast, highly specialized, and not intended for hauling groceries.

It’s a Choice of Philosophy

So the question isn’t “which framework is better?” The real question is “what kind of team are you?”

Microsoft’s philosophy is to build for organizational complexity. They build for the Fortune 500. Their tools are designed to be integrated, not to stand alone.

OpenAI’s philosophy is to build for the frontier. They are a research lab at heart, and their tools are for others who want to live on that frontier with them. They accept the churn in exchange for being at the bleeding edge.

If you work in a large organization, especially one with a heavy .NET presence, your choice is practically made for you. You need the stability and breadth of Semantic Kernel.

If you’re a small team building an AI-native product, and you’ve bet your future on OpenAI’s models, you’d be crazy not to use the tools they built for you. You take the speed and agility of the Agent SDK.

You see this fork in the road everywhere in technology. The broad, stable tool versus the sharp, fast one. When it comes to building AI agents today, your choice of scaffolding depends entirely on the shape of what you’re building. Choose the one that fits.

.

This isn’t just a quirk. It’s a sign of a much bigger shift that’s happening right now. Large language models, the tech behind tools like ChatGPT and Copilot, are powerful agents of consolidation. They are trained on a vast snapshot of our current world, and by reflecting that world back to us, they amplify its most dominant ideas and habits. They are, in a sense, freezing our culture in digital amber.

You see this most clearly with language. LLMs learn from the internet, books, and articles. So they learn the slang we use, the way we argue, and the stories we tell. When you ask one to write a casual email, it might throw in an “LOL” or use a phrase that feels distinctly like it came from Twitter in 2022. It has captured the linguistic fashion of a specific moment in time.

On the surface, this seems harmless. But it has deeper implications. Most of the internet is in English, and a lot of its cultural gravity is American. So if you ask an LLM an abstract question about “freedom,” its answer will likely be shaped by Western, and particularly American, philosophy. It’s not going to give you a perspective from, say, an Indigenous tribe in the Amazon unless you work hard to ask for it. The model presents a default view, and that default is whatever is most common in its training data. It’s globalization in overdrive, smoothing out the weird and wonderful edges of culture into a single, global dialect.

The same thing is happening with code. Copilot suggests pandas because most of the public code it was trained on uses pandas. It suggests React for building a web app because React is all over GitHub. This creates a powerful feedback loop. The most popular tools get suggested by the AI, which makes them even more popular, which ensures they’ll dominate the training data for the next AI.

This could make it harder for new ideas to spread. A breakthrough new programming language or a brilliantly efficient web framework might struggle to get noticed, because the AI assistant that millions of developers use every day never mentions it. It’s like trying to find a new restaurant when your map app only shows you McDonald’s.

So, are we all doomed to use React and say “yeet” forever? I don’t think so. That’s not the whole story.

For one thing, culture moves too fast. By the time a massive model is trained and deployed, the slang it knows is already starting to sound a little dated. New ideas, new memes, and new ways of speaking are always bubbling up from the edges. An LLM is a lagging indicator of culture, not its source.

The same is true for programming. Programmers are restless innovators. The rise of Rust happened because developers were actively looking for something better and safer than C++, and they pushed for it. A good programmer can always ignore Copilot’s suggestion and decide to try that new, experimental library. Human curiosity is a powerful antidote to consolidation.

And the models themselves aren’t perfect monoliths. Their training data is huge and contains multitudes. If you ask, they can often write in a rare dialect or generate code in a niche language like Haskell. The seeds of diversity are in there, even if the main path is paved with whatever is most popular.

What we’re seeing is a new tension. On one side, LLMs are a powerful force for centralization, for creating a shared standard. On the other, human creativity is a constant force for decentralization, for variety, and for change. The future probably won’t be a bland monoculture. It will be more like a landscape with a huge, six-lane superhighway running through it, built by AI. But alongside it, there will still be thousands of smaller, more interesting dirt roads, built and explored by people.

Perhaps the most interesting thing about these models isn’t what they tell us about the future of AI, but what they tell us about ourselves. They are a mirror. What they choose to consolidate is simply what we, collectively, are already doing the most. If we don’t like the reflection, we’re the only ones who can change it.