# Jake Quist

> Jake Quist's blog about software engineering, AI, and technology.

---

# 'Cheap Chinese Models' Aren't Cheap

Motivation I have a small side project in the works: Kanjiland. It’s a reading comprehension engine for Japanese language learners. It’s a model trained to help identify the structure of Japanese text. Raw Japanese goes in, structured grammar and annotated furigana comes out. If you’re an intermediate or advanced Japanese language learner, this model is for you™.
To train this model, I need more data than just English ⇔ Japanese translations. What I really need is the annotated grammar and furigana (i.e. the readings of the individual characters). That kind of data doesn’t really exist on the open web. So I decided to distill the training data from the big labs. In other words, I’m going to pay the big labs some amount of money and have their models produce a large dataset that I can use to train my own model.
It’s likely that I’ll need to build a training set of around 300k samples. That’s a lot cost-wise, especially for a side project that won’t make any money. So consider me a prime target for the “Cheap Chinese Models”. Thought I, “I hear the Chinese models are a fraction of OpenAI/Anthropic! I’ll be so smart to use them for this project.”
In an uncanny moment of clarity, I decided to be a little more empirical and get a data-driven sense of the cost / quality curve. So I decided to stage a “bake off” between OpenAI, Anthropic, and the Chinese Models.
The method For this experiment, I used 150 sentences from the KFTT corpus. The idea is to give these models a prompt like so:
SYSTEM: You annotate Japanese sentences for a reading-comprehension dataset. You are given a sentence already segmented into morpheme TOKENS (with ids, surface, POS, dictionary form). Do NOT re-segment. Produce ONLY a JSON object: { "tokens": [{"id": <int>, "gloss": "<contextual English meaning HERE>"}, ...], "words": [{"span": [start,end], "dict": "<dictionary form>", "gloss": "<meaning>"}], "sentences": [{"span": [start,end], "translation": "<natural English>"}], "grammar": [{"rule": "<RULE_ID>", "roles": {"<role>": <target>, ...}}] } Rules: gloss EVERY token exactly once (punctuation = ""); sentence spans must tile the whole paragraph; grammar rules come from a closed 120-rule inventory (TOPIC_WA, GENITIVE_NO, PASSIVE, COND_BA, ...) with required roles per rule. USER: Sentence: 正室は松平正和の娘。 Tokens: 0: 正室 [NOUN] dict=正室 1: は [PART] dict=は 2: 松平 [NOUN] dict=松平 3: 正和 [NOUN] dict=正和 4: の [PART] dict=の 5: 娘 [NOUN] dict=娘 6: 。 [PUNCT] dict=。 And then the expected output would look something like this:
{ "tokens": [ {"id": 0, "gloss": "legal wife / official consort"}, {"id": 1, "gloss": "(topic marker)"}, {"id": 2, "gloss": "Matsudaira (surname)"}, {"id": 3, "gloss": "Masakazu (given name)"}, {"id": 4, "gloss": "of"}, {"id": 5, "gloss": "daughter"}, {"id": 6, "gloss": ""} ], "words": [ {"span": [2, 4], "dict": "松平正和", "gloss": "Matsudaira Masakazu (person)"} ], "sentences": [ {"span": [0, 7], "translation": "His legal wife was a daughter of Matsudaira Masakazu."} ], "grammar": [ {"rule": "TOPIC_WA", "roles": {"topic": [0, 1], "marker": 1}}, {"rule": "GENITIVE_NO", "roles": {"modifier": [2, 4], "marker": 4, "head": [5, 6]}} ] } And then evaluate that output for correctness. The model that has the most amount of correct outputs wins the bake off.
The results I entered the following models into this bake off: gpt-5.6-luna, deepseek-v4-flash, qwen3.6-plus, kimi-k2.6, and Claude Opus 4.8[1]
This Experiment:
teacher e2e yield empty-gloss rate $/valid item p50 latency Cost Claude Opus 4.8 92.0% (138/150) 0% ~$0.032 (est.) n/a (harness) $4.46 gpt-5.6-luna 81.3% (122/150) 15.3% $0.0012 3.0s $0.15 qwen3.6-plus 74.0% (111/150) 11.6% $0.035 144s $3.90 deepseek-v4-flash 42.0% (63/150) 36.4% $0.0052 51s $0.52 kimi-k2.6 blocked — — — - The yield and gloss-rate columns are important. They’re basically telling us: “how many extra queries do you need to send the model to reach your (300k) target”. That’s the key piece when working with cheap models – you need to hit them multiple times to get the desired results.
Total Cost (i.e the estimated total cost of generating 300k samples based on the above data)
teacher Cost Claude Opus 4.8 ~$9,700 gpt-5.6-luna ~$360 qwen3.6-plus ~$10,500 deepseek-v4-flash ~$1,600 kimi-k2.6 n/a Surprise #1: the cheap models billed like expensive ones So were the “cheap models” cheap? No. The premise died on contact with the invoice. qwen3.6-plus and deepseek-v4-flash billed 8–13× the completion tokens luna did for the same task (qwen ~8k billed tokens per call vs luna’s ~640). Result: qwen cost 27× more per valid item than luna and ran 48× slower. My $2.50 cost projection came in at $5.68 — the overage entirely reasoning tokens. Meanwhile luna costs $1 per thousand sentences. At my scale, the entire data expansion costs ~$360 with the luna.
Surprise #2: the cheapest option was the worst teacher DeepSeek-V4-Flash turned out to actually be cheaper (especially with its $0.03/M cached-input pricing). But it produced the dirtiest data by a wide margin: 42% yield, 36% of tokens left unglossed, and 39/150 responses truncated (even at max_tokens 8000) because it couldn’t stop deliberating.
Surprise #3: Kimi never got to compete kimi-k2.6 hit three account-level walls: it rejects any temperature≠1, my account has a 3-concurrent / 20-RPM cap, and a 1.5M token/day ceiling — which the first (truncation-plagued) run exhausted, burning $1.12 for zero clean samples. Whatever the model’s quality, those limits disqualify it as a 300k-sentence batch teacher. A more patient person would have persevered, but I had to cut my losses here.
Surprise #4: Anthropic is really, really good Claude Opus 4.8 (run as 10 parallel subagents in Claude Code, 15 sentences each) posted the best funnel: 92% yield, zero empty glosses, zero JSON failures, and the strongest grammar agreement with every peer. It also handled the proper-noun minefield well — 島津貞久 read correctly as “Sadahisa” where DeepSeek invented “Sadaisa.”
Takeaways OpenAI’s luna was the clear winner in terms of performance per dollar. It was the best value by 27×, fastest, and its one systematic defect (lazy particle glosses) is fixable with one prompt line, per the Anthropic result.
Fine print This post should be considered amateur and nobody should be making budgetary decisions based off it. I’m literally running these experiments in my garage. Second, the eval domain (KFTT/Wikipedia-history) is pretty brutal for machine translation. That’s both a blessing and a curse for my use case, but it’s pretty orthogonal to the primary use-case these models are intended to tackle.
Prices are July-2026 list; the luna cost is measured actuals, the Opus cost is a stated-assumptions estimate. Total spend for everything in this post: $5.68 of API money plus ~1.06M Claude-plan tokens.
[1] Opus was tested in-harness (via Claude Code) via my subscription account. So cost is just an estimate.


---

# Where Do IDEs Go From Here?

Remember the time when TUIs and terminal-based apps seemed like silly gimmicks? I would have chortled (yes, chortled) at the thought. Yet, here we are now. TUIs now seem like one of the smartest product decisions Anthropic could have made.
It’s interesting to relect on Cursor vs Anthropic’s approach to the coding interface problem. Because 6 months ago, it sure seemed like Cursor was making the right decisions and Anthropic wasn’t take AI coding very seriously.
Yet, here we are. The above chart is Google Trends for “Cursor” vs “Claude Code”. Claude Code went from essentially zero to overtaking Cursor in about twelve months.
This is the source of much anxiety amongst founders in Silicon Valley right now. You spend years building a product, and then a big lab walks into your market and eats your lunch. The CC vs Cursor story seems to validate that fear perfectly. Anthropic decided to compete, perhaps as an afterthought, and now they’re winning.
But it dawns on me: Claude Code isn’t winning because they have a secret LLM. Cursor uses the same Claude models through the same API. The raw intelligence powering both tools is basically identical. Anthropic does have some structural advantages here: they can fine-tune for their own agentic loops and whatnot, but I don’t think it’s sufficient to explain what’s happening. Cursor is a company laser-focused on developer tools, and you would think they’d be better at building the last mile of polish that would make them win. For example, I’m sure Cursor has some really smart people who think all day about the right system prompt for a coding agent. I’m not sure Anthropic had those resources to spare 6-12 months ago. Cursor is the specialist, Anthropic is the generalist. You’d expect the specialist to win.
And yet I think Claude Code is winning not because of its access to better models, but because of UX. The TUI.
When I first used CC, I thought the minimal interface was a limitation. Now I realize it’s the superpower. Working in CC doesn’t feel like programming. It feels like delegating. I describe what I want at a high level, and the agent executes. I regularly run five CC sessions in parallel across different parts of a codebase. I don’t write code. I provide vision and milestones to the team.
Cursor, for all its polish, still puts me in the programmer’s seat. I’m watching diffs, approving line-by-line changes, tabbing through suggestions. It’s pair programming with a very fast partner. That’s useful, but it’s a fundamentally different mode of work. The IDE, by its nature, keeps you in the weeds. You’re a micromanager with a really good assistant.
The TUI removes all of that. There are no diffs to review inline, no gutters full of suggestions, no tabs competing for your attention. There’s just a conversation and a codebase. That spareness, which I mistook for laziness, actually pushed me into a completely different relationship with my code. I went from line-level thinking to system-level thinking.
This matters for founders because it inverts the conventional fear. The worry is that the big labs will crush startups because they have better models. But CC isn’t winning on models. It’s winning on DevEx. Specifically, it’s winning because someone (perhaps accidentally) discovered that removing features could be more powerful than adding them. The best developer experience innovation of the past year wasn’t some space-age way to navigate your code. It was the revival of a text-based interface that frees you up to think at a higher level.
This suggests the defensible ground for startups isn’t where most founders think it is. If you’re building on top of LLMs and your moat is “we have better prompts” or “we fine-tuned on more data,” you’re competing on the same axis as the labs. They will eventually do it better than you and will crush your soul in the process.
But the labs are big, bureaucratic machines. They are structurally hindered from taking big risks on dimensions like interaction paradigms. They’re not thinking about the weird, counterintuitive product decision that changes how people relate to their tools. Anthropic stumbled (I believe) into this one and I think it’s going to be really hard for them to do it again (innovators dilemma, if you will). The next version of this insight is sitting there waiting for someone to find it.
I think the founders who survive the age of AI labs won’t be the ones with the best model access. It will be the ones with crazy-enough ideas that win on the non-obvious dimensions.


---

# What Happens To Developer Tools After Claude Code?

If you’re building a developer tool right now, you probably have a launch plan: Post it on Show HN. Grind for GitHub stars. Maybe host a hackathon or two. You know, the standard playbook.
I suspect this playbook will soon become obsolete. Not because it doesn’t work on humans, but because humans are no longer the ones choosing the tools.
It’s not that humans have left the loop. A human still decides which tools end up in a project. But increasingly, that decision gets mediated by an AI coding agent.
Watch how software actually gets built now. A developer doesn’t read your README and evaluate your API. They tell Claude Code “I need to transform this dataset” and Claude Code either reaches for your tool or it doesn’t.
This changes the distribution game in ways I don’t think most developer-tool founders have internalized yet.
The old funnel was: awareness → landing page → docs → adoption. A human saw your Show HN post, clicked through, skimmed the README, and maybe tried it out. Every step was optimized for human attention and human decision-making.
The new funnel looks different. The human says “do X.” The AI agent decides how to do X. If the agent knows your tool exists and understands how to use it, you win. If it doesn’t, you don’t. The human never even saw your name.
So the question becomes: how does an AI agent come to know about your tool?
There are really two distinct things happening here:
The first is training data. If an LLM has seen enough examples of your tool being used — in blog posts, tutorials, Stack Overflow answers, GitHub repos — it develops an intuition for when and how to reach for it. This is the passive channel. You can’t directly control it, but you can influence it.
The second is tool integration. MCP servers, CLI interfaces, well-structured APIs — the mechanisms by which an AI agent can actually invoke your tool at runtime. This is the active channel. You control it completely.
Most people fixate on the first one because it feels more mysterious. But I think the second one is where the real leverage is, at least right now. If your tool has a clean MCP integration and good structured documentation, an AI coding agent can use it today regardless of whether it appeared in the training data. The training data question matters more for discovery — whether the agent thinks to use your tool unprompted.
This leads to what I think is the most interesting question in developer-tool distribution right now: is there such a thing as SEO for LLMs?
The cynical framing is: do I need to manufacture social proof? Do I need to convince fifty friends to write blog posts about my tool so that Anthropic’s next training run picks them up?
The honest answer is: kind of, but it’s not as sinister as it sounds. LLMs learn from the public web. If nobody writes about your tool, it functionally doesn’t exist to the model. That’s not some opaque ranking algorithm punishing you. It’s just the physics of how these systems work. A tool with a thousand tutorials will be better understood by the model than a tool with three. This was always true for humans too — it’s just that now the “reader” processing all that content is a neural network instead of a person scanning Hacker News.
What worries me is the second-order effect. Well-known tools generate more public content. More content means better model understanding. Better model understanding means AI agents recommend those tools more often. Which makes them more well-known. This is a rich-get-richer dynamic, and it creates a brutal cold-start problem for new tools.
If you’re an established project with years of blog posts and Stack Overflow threads, the AI era is a tailwind. If you’re launching something new, you face a bootstrapping challenge that didn’t exist before: you need to get into the models, and the models won’t find you until you’re already popular.
So what should a developer-tool founder actually do about this?
First, we need to treat documentation as our primary marketing channel. Not documentation in the traditional sense — a dry API reference that exists to serve existing users. Documentation as content. Rich examples, explained end-to-end. Common workflows, spelled out verbosely. The kind of writing that a human might find tediously thorough but that an LLM will absorb perfectly. Your docs need to be optimized for a reader with infinite patience and zero intuition.
Second, prioritize an MCP server. If a developer’s Claude Code instance can invoke your tool directly, that’s worth more than a thousand GitHub stars. Stars are a vanity metric for humans. Tool integration is a distribution metric for agents.
Third, rethink what “content marketing” means. It used to mean writing blog posts to build an audience. Now it means producing the training data you want future models to learn from. Every tutorial you write, every example you publish, every answer you post — it’s all input to the next training run. The audience for your content is partly human and partly statistical.
I don’t know if this is the right framework. It’s possible that six months from now, tool discovery will look completely different — maybe there will be an app store for MCP servers, or Anthropic will launch some kind of tool registry, and none of this grassroots optimization will matter.
But I suspect the core insight will hold: if you’re building a developer tool in the AI era, your most important user can’t attend your hackathon, doesn’t care about your logo, and will never star your repo. It just needs to understand what your tool does and how to call it. Everything else is noise.


---

# What Happens When AI Can Write All Your Software?

 A few weeks ago, while refactoring some of my old code, I asked an LLM to write a RingBuffer implementation in TypeScript. I’ve written these before in other languages. I know the tricky edge cases, especially around concurrency. To my surprise — and mild horror — the LLM wrote it flawlessly. Better than I could have. No feedback necessary. No vibing at all.
Then I asked it to build something slightly more ambitious: a personal CRM.
It fell apart. Buttons didn’t work. When they did work, the backend threw exceptions. I eventually vibe-coded the fixes and got it running. But when I looked at the backend code, it read like something an undergraduate might write — technically correct in places, but with no sense of how the pieces should fit together.
How can this be? The same system that writes better low-level code than me produces amateur work on what should be a straightforward application?
I think the answer is complexity.
Note that both prompts were equally vague. “Create a RingBuffer” isn’t much more specific than “Create a personal CRM.” The difference isn’t in the specification — it’s in the internal complexity of the task itself.
A RingBuffer is self-contained. It has a few moving parts, clear boundaries, well-defined behavior. A CRM, even a “simple” one, is a web of interconnected concerns: data models, API design, state management, UI flows, error handling, validation — all of which need to work together coherently.
My hypothesis: humans are remarkably good at context-switching. When I’m looking at a React component, my attention is tuned to one set of concerns. When I jump to database code, I activate a different mental mode. I can hold the big picture while zooming into specifics, and I can do this dozens of times per hour without losing the thread.
Current LLM architectures seem to struggle with this. Maybe it’s a training issue. Maybe it’s architectural. I don’t know. But the pattern is consistent: small, contained tasks get done brilliantly. Complex, interconnected systems fall apart.
If this is true, what does it mean for the future of software?
LLMs will commoditize the parts of software development that have lower complexity. They’ll continue to struggle with the parts that have high complexity.
At first glance, I’m tempted to frame this as a frontend vs. backend issue — frontend code is often considered less complex than backend code. But I don’t think that’s actually right. There are plenty of frontends that are extremely complex with lots of interconnected parts, while the backend is a simple CRUD database. The principle is simpler: humans will own whatever is complex; LLMs will handle whatever isn’t.
This suggests an interesting development pattern. Imagine your team builds a super-complex-accounting-rules internal package — all the gnarly domain logic, validated and tested by humans who understand the stakes. Then you hand that package to an LLM and say: “Build me an iOS app that uses this.” The LLM treats the complexity like a black box; it doesn’t have to understand it. It just needs to wire up a relatively simple interface.
What might this look like in five years?
I suspect most human developers will be working on complexity — wherever it lives in their stack. Business logic. Integrations. The parts where mistakes are expensive and domain knowledge matters.
Meanwhile, LLMs will be printing out interfaces. Your company’s ERP system will have a human-built core with predictable, accountable logic. But the accounting department might generate their own Windows desktop client while the sales team gets a native iPad app. Because it’s “just” presentation code and minor bugs are acceptable. The bugs are annoyances, not disasters. And when bugs do appear, users can ask the LLM to fix them — without ever touching the core logic owned by human developers.
Counterintuitively, this might be good news for the SaaS giants. If LLMs can’t reliably rewrite Salesforce’s backend — all that accumulated domain logic and integration complexity — then Salesforce’s moat is intact. But now users can print their own interfaces on top of it. The plugin ecosystem might die, but Salesforce would probably make that trade.
Picture what this world actually looks like. Salesforce is still around. Your company still runs on its ERP system. But now you get to choose how you interact with it. Maybe you’re a sales manager who wants a podcast-style summary of yesterday’s numbers to listen to on your commute. Maybe you’re a developer that prefers a CLI to submit your expenses. Maybe you have a visual impairment and need a high-contrast, screen-reader-optimized interface that the vendor never bothered to build.
The complex parts of the stack remain first-class human concerns. But everyone gets to customize their last mile.
I hope I’m right about this. I think this vision is genuinely exciting. I’d love to customize how I interact with the big software systems I’m stuck using.
But maybe I’m wrong. Maybe the big vendors will try to block LLM-based integrations — that seems like the obvious knee-jerk reaction. Or maybe LLMs will keep advancing until they can handle the complex parts too, and actually put Salesforce out of business.
Who knows. I just have a guess about what the next few years look like. And my guess is that complexity is the bottleneck — for now.


---

# Big Tech vs. OpenClaw

 OpenClaw launched last week. If you haven’t tried it yet, it’s essentially a way for AI to control your computer on your behalf. You describe what you want done, and it does it—clicking, typing, navigating, the whole thing.
It’s impressive technology. But the most interesting thing about OpenClaw isn’t what it can do. It’s what it means for the companies that have spent the last fifteen years figuring out how to capture and hold our attention.
Here’s the thing about social media that nobody at these companies will say out loud: the product only works if you’re using it badly. Facebook and LinkedIn don’t make money when you efficiently check your messages and leave. They make money when you intended to check your messages but somehow ended up scrolling for forty-five minutes through engagement-optimized content you never asked for.
OpenClaw breaks this model. I can now say “notify me when someone sends me a LinkedIn message, but filter out the recruiters and the people trying to sell me marketing services.” That’s it. I never have to open LinkedIn again. I get the utility of the network without the tax of the feed.
This might sound minor, but I think it’s actually a very big deal.
Consider what LinkedIn has really become. Ostensibly it’s a professional network. In practice, it’s one of the most valuable proprietary datasets on the planet. Most VC firms I know are scraping it, one way or another. It’s one of those open secrets in the industry—a lot of people are doing it, nobody talks about it publicly, and LinkedIn seems to look the other way as long as you’re not too blatant about it.
Before OpenClaw, getting useful data out of LinkedIn required either paying a fortune for their official APIs (which are deliberately hobbled), or building and maintaining sophisticated scraping infrastructure that played an endless cat-and-mouse game with their bot detection. Only well-funded companies could do it effectively.
Now? Any VC with a spare Mac Mini can fully automate their deal sourcing. OpenClaw will just log in as you, browse around, and extract whatever you need. It’s not even really “scraping” in the traditional sense—it’s just using the site the way a human would, except the human is an AI following your instructions.
The obvious question is: how will these companies respond?
The first line of defense is CAPTCHAs. LinkedIn and Facebook already have state-of-the-art bot detection. They could turn up those knobs. But there’s a limit to how far they can push this without alienating legitimate human users. Make the friction too high and people stop using your product. And crucially, OpenClaw isn’t really distinguishable from a slow, methodical human user. The patterns are the same. The pixels are the same.
My hunch is that we’re going to see a hard push toward native apps.
If you’re running a hypothetical native LinkedIn app on your Mac, that app can inspect your machine. It can see what processes are running. It can detect screen recording. It can phone home and report suspicious activity. A native app has capabilities that a website in a browser simply doesn’t have.
Why do these companies push their native apps so aggressively? Why does Reddit constantly nag you to install their native app? I always assumed it was just about engagement metrics or notification permissions. But now I wonder if part of the reason is that native apps are defensible in ways that websites aren’t.
Longer term, I wonder if we’re going to see something even more aggressive: computer-use DRM.
OpenClaw is currently the most popular tool in this space, but it’s really just part of a broader “computer-use” category that’s emerging. Anthropic, Google, and several startups are all building AI that can operate a computer the way a human does. This isn’t going away. If anything, it’s going to get much better very quickly. The question isn’t whether computer-use AI will become ubiquitous—it’s whether platforms will find ways to lock it out.
And this isn’t as far-fetched as it sounds. We already have precedent. Try taking a screenshot of Netflix content in your browser. On most systems, you’ll get a black rectangle. The browser, working with the operating system, actively prevents you from capturing DRM-protected video content. This isn’t a bug—it’s a feature, negotiated between content companies and platform vendors.
Imagine the same technology applied to social media. Your operating system could expose an API that tells apps whether any automation software is running. LinkedIn’s website could simply refuse to render if it detects OpenClaw. Apple and Microsoft, under pressure from major advertisers, might be convinced to build these capabilities directly into their platforms.
Would this happen? A year ago I would have said no. Platform vendors have historically positioned themselves as neutral—they provide the infrastructure, they don’t pick sides in fights between applications. But the pressure from big tech is enormous, and the advertising dollars are real.
The optimistic case is that this is the beginning of the end for attention-harvesting as a business model. If users can finally automate away the junk and extract just the value from these networks, maybe the networks will have to evolve. Maybe LinkedIn becomes a pure utility—a directory and messaging service—and finds some other way to make money. Maybe Facebook finally has to compete on actual value rather than addictiveness.
The pessimistic case is that we get a new kind of platform lock-in. Not just network effects keeping you on a platform, but actual technical barriers preventing you from using that platform in any way other than what the company intended. An internet where the sites you visit can veto the software you run.
I don’t know which way this goes. But it does seem like OpenClaw and tools like it represent something new in the balance of power between users and platforms. For the first time in a long time, users have a tool that lets them interact with these services on their own terms.
Big Tech has gotten very good at capturing human attention. Now they may have to figure out how to capture attention from robots. That’s a different game, and I’m genuinely curious to see how they’ll play it.


---

# OpenClaw is What Apple Intelligence Should Have Been

Something strange is happening with Mac Minis. They’re selling out everywhere, and it’s not because people suddenly need more coffee table computers.
If you browse Reddit or HN, you’ll see the same pattern: people are buying Mac Minis specifically to run AI agents with computer use. They’re setting up headless machines whose sole job is to automate their workflows. OpenClaw—the open-source framework that lets you run Claude, GPT-5, or whatever model you want to actually control your computer—has become the killer app for Mac hardware. Not Final Cut. Not Logic. An AI agent that clicks buttons.
This is exactly what Apple Intelligence should have been.
Apple had everything: the hardware, the ecosystem, the reputation for “it just works.” They could have shipped an agentic AI that actually automated your computer instead of summarizing your notifications. Imagine if Siri could genuinely file your taxes, respond to emails, or manage your calendar by actually using your apps, not through some brittle API layer that breaks every update.
They could have charged $500 more per device and people would have paid it. The margins would have been obscene. And they would have won the AI race not by building the best model, but by being the only company that could ship an AI you’d actually trust with root access to your computer. That trust—built over decades—was their moat.
So why didn’t they?
Maybe they just didn’t see it. That sounds mundane, but it’s probably the most common reason companies miss opportunities. When you’re Apple, you’re thinking about chip design, manufacturing scale, and retail strategy. An open-source project letting AI agents control computers might not ping your radar until it’s already happening.
Or maybe they saw it and decided the risk wasn’t worth it. If you’re Apple, you don’t want your AI agent automatically buying things, posting on social media, or making irreversible decisions. The liability exposure would be enormous. Better to ship something safe and limited than something powerful and unpredictable.
But there’s another dynamic at play. Look at who’s about to get angry about OpenClaw-style automation: LinkedIn, Facebook, anyone with a walled garden and a careful API strategy. These services depend on friction. They want you to use their app, see their ads, stay in their ecosystem. An AI that can automate away that friction is an existential threat.
If Apple had built this, they’d be fighting Instagram over ToS violations by Tuesday. They’d be testifying in front of Congress about AI agents committing fraud. Every tech platform would be updating their terms to explicitly ban Apple Intelligence.
By letting some third party do it, Apple gets plausible deniability. They’re just selling hardware. Not their fault what people run on it. It’s the same strategy that made them billions in the App Store while maintaining they’re “not responsible for what developers do.”
But I think this is short-term thinking.
Here’s what people miss about moats: they compound. The reason Microsoft dominated PCs wasn’t just that they had the best OS. It’s that everyone built for Windows, which made Windows more valuable, which made more people build for Windows. Network effects.
If Apple owned the agent layer, they could have created the most defensible moat in tech. Because an AI agent gets better the more it knows about you. And Apple already has all your data, all your apps, all your devices. They could have built an agent that works across your iPhone, Mac, iPad, and Watch seamlessly—something no one else can do.
More importantly, they could have owned the API. Want your service to work with Apple Agent? You play by Apple’s rules. Suddenly Apple isn’t fighting with platforms—they’re the platform that platforms need to integrate with. It’s the App Store playbook all over again, but for the AI era.
The Mac Mini rush is a preview of this future. People want agents. They want automation. They want to pay for it. They’re literally buying extra computers just to run someone else’s AI on Apple’s hardware.
Apple is getting the hardware revenue but missing the platform revenue. That might look smart this quarter. But platform revenue is what built Apple into a $3 trillion company. And platforms are what create trillion-dollar moats.
I suspect ten years from now, people will look back at 2024-2025 as the moment Apple had a clear shot at owning the agent layer and chose not to take it. Not because they couldn’t build it—they obviously could—but because they were optimizing for this year’s legal risk instead of next decade’s platform power.
The people buying Mac Minis to run AI agents aren’t just early adopters. They’re showing Apple exactly what product they should have built. Whether Apple is paying attention is another question entirely.