The LMSYS Chatbot Arena ranks models by blind tests, and the Gemini family is all over it. The small Gemma models. Flash, which is fast and cheap. Pro at the top end. At every tier the pattern holds: Google’s models cost less than comparable alternatives. The whole lineup is laid out that way.

The obvious question is how. The answer sits underneath the models, in the chips they run on.

Run AI at any serious scale and you pay a tax to NVIDIA, because their GPUs are the only realistic option and they are priced accordingly. Their hardware is excellent. That’s exactly why the tax sticks.

Google chose a different route more than a decade ago: build its own chips. The Tensor Processing Units are vertical integration in the mold of Apple, where the people who design the hardware also design the software running on it. Google didn’t rent a factory, it built one, and it designed every machine inside.

A GPU is a general-purpose engine. Graphics, scientific computing, AI. A TPU does one thing: run neural networks. Neural networks at heart are a long series of matrix multiplications, tensors getting multiplied together over and over. Google’s TPUs strip out everything that isn’t that one operation and perfect the Matrix Multiply Unit at the center of the chip. It’s the difference between a sedan that hauls anything and a dedicated race car built for one track.

The specialization goes further. Modern models handle sparse tensors. Pull one user’s viewing history from billions of hours of YouTube and you get an enormous array where nearly every entry is zero, because they haven’t watched that video. A general-purpose chip multiplies those zeros anyway, wasting power and time. Google’s SparseCores are built to skip the zeros and compute only the non-zero entries. That efficiency is the reason Google Search and Ads can run at planetary scale without the compute bill eating the company.

The newer TPU generations, Trillium and Ironwood, push the same direction: more memory, more efficiency at the exact workloads that are becoming AI’s biggest bottleneck. They’re getting faster, and they’re also getting cheaper per unit of useful work, which is the number that decides what AI products can cost.

So while the world argues about which chatbot writes the better poem, the contest underneath is about economics. Most companies in the AI race buy their fuel from a single supplier. Google owns the 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. 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. 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. 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. 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 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 doesn’t replace historians. It gives 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.

As soon as you decide to build one, you face a choice. The choice is between something like Microsoft’s Semantic Kernel and OpenAI’s 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. 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, a quiet promise of stability. It says, “build your business on this; we won’t change everything next month.” That matters for a large organization. Semantic Kernel is designed for a world where systems are complex, security is paramount, and downtime is expensive. The freight train: powerful, reliable, and built 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. A small, AI-focused team will find that a simplification. It’s also described as “evolving.” For an enterprise, that’s a red flag. 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 a direct line to the model architects. It aims to be the fastest and most direct way to build with OpenAI’s technology. The Formula 1 car: unbelievably fast, highly specialized, and not intended for hauling groceries.

It’s a Choice of Philosophy

So the choice comes down to what kind of team you are.

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

OpenAI builds for the frontier. They’re 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.

Broad and stable, or sharp and fast. For building AI agents today, the choice of scaffolding depends entirely on the shape of what you’re building. Choose the one that fits.

This is a sign of a bigger shift happening right now. Large language models are powerful agents of consolidation. Trained on a vast snapshot of the world, they reflect it back to us and amplify its most dominant ideas and habits. They freeze 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, the stories we tell. Ask one to write a casual email and it might throw in an “LOL” or a phrase that feels distinctly like Twitter in 2022. It captured the linguistic fashion of a specific moment.

On the surface this seems harmless. But most of the internet is in English, and much of its cultural gravity is American. Ask an LLM an abstract question about “freedom” and its answer will be shaped by Western philosophy, particularly American. Getting a perspective from an Indigenous tribe in the Amazon takes real work. The model presents a default view, and that default is whatever is most common in its training data. Globalization in overdrive, smoothing out the weird and wonderful edges of culture into a single global dialect.

The same thing happens with code. Copilot suggests pandas because most public code uses pandas. It suggests React because React is all over GitHub. This creates a feedback loop: the most popular tools get suggested, which makes them more popular, which ensures they dominate the next model’s training data.

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

Are we all doomed to use React and say “yeet” forever? Probably not. Culture moves too fast. By the time a massive model is trained and deployed, the slang it knows already sounds dated. New ideas, memes, and ways of speaking bubble 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. Rust happened because developers wanted something better and safer than C++ and pushed for it. A good programmer can ignore Copilot’s suggestion and 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. Ask, and 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 push for centralization, for a shared standard. On the other, human creativity pushes for decentralization, for variety, for change. The future probably won’t be a bland monoculture. It will be a landscape with a huge six-lane superhighway running through it, built by AI, and thousands of smaller, more interesting dirt roads built and explored by people.

The most interesting thing about these models might be 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.