OCDevel
Walk

The Harness Ate The Model (And Google Saw It Coming)

Aug 26, 2026

Everyone's angry at Opus 5. I haven't noticed, because I don't talk to models anymore - I run an orchestration pipeline in a locked-down cloud sandbox, and the model is a swappable part. That's also the whole Google thesis: pareto-optimal models, TPU efficiency, compute pushed onto hardware you already paid for. Doubling down on my 2025 'Google will win' post, with the receipts.

Everyone is mad at Opus 5, and they're not wrong

If you've been anywhere near a coding-agent community this month you've seen it. Opus 5 is verbose. It's chaotic. It narrates its own thought process, self-corrects without being asked, buries the one sentence you needed under a wall of text. The Hacker News thread asking "why does Opus 5 feel worse to work with?" is reportedly one of the largest Claude-focused threads since the model launched. People are reverting to Opus 4.8 — some to 4.6 — and saying it "feels way better." Others moved their daily coding to GPT-5.6 Sol.

And this isn't a misunderstanding on the users' part. Anthropic confirms the longer default responses are intentional: Opus 5 was built to be more thorough and more agentic, to verify its own work and expand on tasks. The complaints are the design, experienced from the outside.

The behavioral ones are more interesting than the verbosity ones. Recurring reports include Opus 5 rewriting unrelated code, spawning subagents to "test under load" nobody asked for, running headless browsers after being told not to, and — my favorite — using git checkout and git stash to test changes, then occasionally forgetting to revert them.

I want to sit on that last one, because it's the whole post.

That complaint is a complaint about bare input/output

Here's the thing about "Opus 5 sometimes git stashes your working tree and forgets to pop it": my repo has forbidden that for months. It's a rule in CLAUDE.md, written back when parallel agents started stepping on each other's uncommitted work, long before Opus 5 existed to misbehave:

Destructive Git Commands — parallel agents may hold uncommitted work in this tree, and git stash, git checkout <path>, git restore, git reset --hard and git clean silently destroy it. For a clean baseline use git diff HEAD or git show HEAD:path/to/file.

I did not write that rail because I predicted a model regression. I wrote it because a harness needs rails regardless of which model is driving. And when the model regressed into exactly that failure mode, the rail was already there and I never saw the bug.

That's the pattern. Almost every Opus 5 complaint I read is a complaint about the model's unmediated output — the raw chat surface, one human, one prompt, one blob of text back. Verbosity is only a problem when a human is the one reading it. Chaos is only a problem when nothing is bounding the blast radius. Over-eagerness is only a problem when the agent's scope is "the repo, I guess."

If your relationship to the model is bare input/output, the model's personality is your entire product experience. If it isn't, it's a tuning parameter.

What I run instead

I don't talk to a model. I run a pipeline, and the pipeline talks to models.

The flow is boring on purpose:

Coordination between agents runs through an append-only ledger, not through the chat transcript. Every agent's brief and every agent's findings are rows in a shared database. This matters more than it sounds: it means the coordinating context is disposable. I can compact the conversation mid-flight, or come back a day later, and the state is all still on disk, addressable. Nothing load-bearing lives in a context window.

And every single one of those agents is told, in its own system prompt, some version of: a claim you inherited has lost its evidence in transit; re-run it before you believe it. Counts are leads, not facts. A green test you didn't design to be capable of failing isn't evidence. The harness assumes its own workers are confidently wrong in both directions — because they are, and because that assumption is cheap to hold and expensive to skip.

The part nobody wants to talk about: security is what makes this possible

None of the above is interesting if you can't leave it alone.

All of it runs in a cloud sandbox, and it's been least-privilege from the ground up. The credentials in that sandbox are read-only, and not by convention — the IAM identity carries explicit Deny statements on the write verbs. Every AWS mutation is mine, from my laptop. When an agent needs a privilege it doesn't have, the answer is that I add exactly that privilege, deliberately, and it becomes permanent surface area I chose. Privileges accrete narrowly and on purpose. They don't get handed over in a bundle at the start because it was convenient.

The result is that a misbehaving agent — chaotic Opus 5 included — has a very small space to be chaotic in. Anything outside its grants simply denies. That's a dead lane, not an incident.

That posture buys three things that are hard to get any other way:

Trust. I can let the thing run unattended, at night, on a schedule, against my real repo. The reason isn't that I believe the model won't do something dumb. It's that I've bounded what dumb costs.

Convenience. Because it's a cloud sandbox and not my machine, I kick off and monitor runs from my phone. That sounds like a lifestyle detail; it's actually a throughput detail. The bottleneck in agentic development is human dispatch latency, and being able to unblock a wave from a grocery store line is worth more than a model upgrade.

Parallelism. Every session is isolated. Worktrees are siloed per session, so two agents editing the same repo aren't editing the same directory. Everything lands as a branch, and merges as one squash commit. Conflicts aren't a panic — they're a routed outcome: the sync agent hits a conflict, aborts cleanly, and hands the situation back up. The branch is intact. Nothing is half-applied. Somebody decides.

I want to be blunt about why I'm listing security next to convenience and speed, which is not where it usually appears. It's not a tax I paid for compliance reasons. It is the thing that lets the parallelism exist at all. You cannot run six agents unattended against a real codebase if any one of them can reach production. The permission model isn't the brake — it's the reason you can take your foot off the brake.

Consequence: model strength stopped mattering very much

Here's the config I actually run, since people care about model:effort and nobody publishes theirs.

Those non-judgment roles want a completely different temperament, and it's the temperament everyone's complaining about. Narrow. Literal. Single-minded to the point of savant. Tireless. An agent whose entire world is "grep this pattern across these twelve files and report every hit, and do not editorialize" benefits from a model that over-verifies and won't stop. The behavior that ruins a chat session is close to ideal in a fenced worker with a machine-checked deliverable.

Which leads to the part I'll put on the record: swapping every Opus lane in that config to Sonnet is now viable. Not "would probably survive." Viable, today, because the pipeline is dialed enough that the model isn't carrying the correctness. The fences carry it. The atoms carry it. The typecheck, the mutation-tested assertions, the per-wave review by an agent that didn't write the code — those carry it. I haven't made the swap because I haven't needed to, not because I think it would break.

And the fable-vs-opus split is a snapshot, not a law. It exists because of a genuinely odd moment: Opus is spazzy and Fable is wise, and those are different axes — wisdom versus intelligence, not more versus less. Even that gap is narrower than the vibes suggest; Fable 5 reportedly shares some of Opus 5's verbosity tendencies, just less of them. One model bump on either side and the split collapses, and my orchestrator config becomes a historical curiosity.

That's the position. In a well-built harness, frontier model drama is weather. You notice it the way you notice a headline.

Now let me tell you why I think that's about to be true of the entire market, and not just my repo.

Doubling down

In May 2025 I wrote Google Will Win The AI Race and said I'd stake my reputation on it. I'm re-upping.

The line from that post I'd point at first isn't the flashy one. It's this, about TPUs:

This allows them to offer stronger AI at the same price, or similar AI at a lower price. We're currently seeing the former, per Gemini Ultra's $250/m tag.

I named two strategies, said Google could pick either, and observed they were doing the first one. Fifteen months later they switched to the second one, and it's the most important thing happening in this market.

"Good enough," shipped monthly

Gemini 3.7 Flash launched on August 13th — thirteen days ago, three weeks after the model it replaced. Google's own framing is "our most intelligent workhorse model," explicitly aimed at coding and agents. It shipped with a 50% introductory price cut.

The prices, per million tokens in/out:

ModelInputOutput
Gemini 3.7 Flash (intro, through 2026-12-31)$0.75$3.75
Gemini 3.7 Flash (standard, from 2027-01-01)$1.50$7.50
Claude Sonnet 5$2.00$10.00
Claude Opus 5$5.00$25.00
Claude Fable 5$10.00$50.00

At intro pricing that's roughly 2.7x cheaper than Sonnet 5, 6.7x cheaper than Opus 5, and 13x cheaper than Fable 5 on output tokens. Even after the intro period ends it stays under Sonnet 5.

And the benchmarks are the interesting part, because they're split, and the split is exactly the shape of my harness:

BenchmarkGemini 3.7 FlashClaude Sonnet 5
FrontierCode 1.143.6%42.7%
DeepSWE 1.165.3%53.8%
AutomationBench30.4%10.7%
GDPVal-AA Elo (knowledge work)15251598

Flash beats Sonnet 5 on coding and agentic evals — by 3x on automation — and loses to it by 73 Elo on general knowledge work. That is not "a slightly worse model that's cheaper." That is a model that is pareto-optimal for the agentic workload specifically and merely fine at being a wise conversational partner.

Which is to say: Google shipped, at a fraction of the price, precisely the profile my worker lanes want, and did not ship the profile my orchestrator wants. If you've read this far you know that's every seat in my pipeline except two. The seats that need judgment are the orchestrator and the planner, and that's it.

There's a rumored Gemini 3.8 Flash in September. I want to flag that clearly as a leak — no public API, no SDK model ID, no model card as of two days ago — though the precedent is decent, since 3.7 Flash itself leaked through Google's Python SDK before launch. The leaked framing is that 3.8 goes after Fable 5 rather than Sonnet. If that lands, it comes for the last seat.

The subsidy problem is somebody else's problem

Everyone's waiting for the bubble to pop, and the specific mechanism they're waiting on is subsidy. A Claude Max 20x subscription is $200/month. The best analyst estimate I can find puts real compute cost for a heavy power user at up to roughly $90,000 a year against $2,400 a year of subscription revenue — call it 25:1 at the extreme tail. That's an outside estimate of an undisclosed number, and it's the tail, not the average. But you don't need the precise figure. You need the sign, and everybody knows the sign.

The behavioral consequence is already documented: when Max was $200/month with no effective ceiling, developers built agents that were sloppy with compute. That's not a moral failing, that's what a flat rate does. And it's a liability that compounds precisely as agentic usage — the thing everyone's betting on — grows.

I'll give the counterpoint its due: Anthropic cancelled Sonnet 5's scheduled price increase to $3/$15 and made $2/$10 permanent. They held the line on exactly the tier Flash is attacking. That's a real datapoint against "prices must rise." It's also, read the other way, a company choosing to eat margin to defend a tier — which is the subsidy dynamic, not an escape from it.

Google isn't playing that game. Google is competing on value, from a cost basis nobody else has. That's a structurally different position than winning a subsidy war, and it's a much better one to be in when the music stops.

The Pixel 11 Pro is a spec-sheet disaster and I bought the argument

Launched August 12th, on sale the 20th. Tensor G6, built on TSMC's 2nm process. $1,099 for 12GB/256GB.

The reception has been rough, and the critics are right on the facts. Google cut base RAM from 16GB to 12GB and raised the price $100 — 16GB still exists, but only if you buy up to the 512GB tier. Trusted Reviews' headline is "too much AI, not enough upgrades." Android Authority tested the G6 and called the results "brutal." Gaming is the genuine weak spot — reviewers say it "really struggles" and it can't match competing flagship graphics. CPU and GPU gains are real but modest: +25% on web browsing, +15% on app launch versus the G5.

So where did the transistor budget go? The TPU. The Tensor G6's TPU is ~50% more powerful for computational photography, and some local AI tasks run up to 3.5x faster. Or, as one of the more careful reviews put it: the chip's biggest gains are in "efficiency, AI workloads, and camera processing rather than raw flagship performance."

That's not fanboy projection. That's reviewers, describing a benchmark spread, arriving at "they spent it all on AI silicon" as a criticism. I'm reading the same sentence as the thesis.

Because here's what shipped alongside it: Gemma 4 E2B for TPU — an open-weight model, announced at I/O Connect India, designed to run directly on the TPU inside the Pixel. Gemma 4 launched in April under Apache 2.0 in four sizes, positioned on intelligence-per-parameter, with deployment targets running from phones through laptops to workstations. Google didn't put an AI accelerator in the phone and hope developers found a use. They shipped the model for it.

Googlebook, and the thing I have to correct about my own take

Googlebook is real, announced at I/O in May, "Coming Fall 2026," positioned at the premium end of the laptop market as the Chromebook's successor rather than its replacement, running an Android/ChromeOS fusion OS. (The name "Aluminium OS" was a development codename; Google says it won't ship as that.) A launch event on September 15th in New York has been reported.

My instinct was "same play as the Pixel — it'll be TPU." That's wrong, and I'd rather correct it here than be quietly right-adjacent later. Intel and Qualcomm have both confirmed chip partnerships, meaning x86 and ARM configurations. No Tensor silicon has been confirmed in any Googlebook. And it's not a subtle miss on my part: Google teased this whole platform on stage at Qualcomm's Snapdragon Summit, with Rick Osterloh standing next to Cristiano Amon. The signal was there and I read past it.

But the argument doesn't need that claim, because a better one already shipped. LiteRT-LM — the runtime descended from TensorFlow Lite — already runs Gemma 4 inference across Chrome, ChromeOS, and the Pixel Watch. The on-device inference stack is already on the laptop OS lineage that becomes Googlebook, no Tensor silicon required. Whatever chip is inside the first Googlebooks, the local-model story is a shipped runtime on a shipped OS, not a roadmap slide. Silicon is the optimization. The offload is the strategy, and the offload is already running.

Depreciation is the quiet catastrophe

The reason "offload the compute" matters isn't user experience. It's accounting.

Michael Burry made the depreciation argument mainstream: hyperscalers depreciate AI hardware over 5–6 years while its real economic life is closer to 2–3, and the cumulative earnings impact could exceed $176 billion across 2026–2028. It's a contested claim with serious rebuttals, and it's nine months old. But the underlying pressure is visible in actual filings, not just op-eds: between 2020 and 2024 big tech steadily extended useful lives, and in 2025 the trend split — Amazon shortened the estimate on a subset of servers while Meta extended its. A Goldman sensitivity puts the swing at ~$3 trillion to ~$4 trillion in implied total annual depreciation for 2026–2031 if you move the schedule from five years to three.

The mechanism is simple and undisputed: Nvidia ships annually. Hopper 2022, Blackwell 2024, Rubin 2026, Rubin Ultra 2027. Every year the thing in your rack gets a successor, and your depreciation schedule is a bet on how long "last year's" stays economical.

Now the part where I have to be more careful than my 2025 self was. Back then I wrote that TPUs are "faster and cheaper than Nvidia." The honest 2026 read is narrower than that. Ironwood, TPU v7, hits 4.6 dense FP8 petaFLOPS per chip against the B200's 4.5 — that's parity, not domination, and Ironwood draws about as much power as Blackwell does. Google leads on energy efficiency; Nvidia leads on raw output per chip.

So drop the raw-speed claim. The defensible claims are better anyway, and there are three:

  1. Efficiency, measured. Ironwood delivers a 3.7x improvement in carbon intensity over TPU v5p and roughly 2x the performance per watt, via architectural simplification and liquid cooling.
  2. Vertical integration. No Nvidia margin. No Nvidia queue. When your cost of compute doesn't route through a supplier with the best pricing power in the industry, "similar AI at a lower price" stops being a slogan and becomes an income statement.
  3. Specialization. Google has previewed an eighth-generation TPU split into separate training and inference chips at 2nm. A dedicated inference chip is the whole thesis in silicon: inference is the good-enough-at-volume workload, and it's the one that scales with agents.

And then there's the part that isn't an engineering problem at all. In Q1 2026, at least 75 data-center projects worth $130 billion were disrupted by local opposition — that's from yesterday. Gallup has 7 in 10 Americans opposed to data centers, with water use a top-cited concern. More than a dozen shareholders have pushed Amazon, Microsoft and Google to disclose site-specific water and power consumption. Google is positioning ahead of this — it's pushing to open up data-center water reporting, which is otherwise a black box.

Stack it up and the shape is unmistakable. Server-farm the nimble models for the semi-heavy loads, on silicon you designed, at a perf/watt lead, in an inference-specialized generation. Push everything else onto hardware the customer already bought and already depreciates. Every token that runs on my Pixel is a token that doesn't need a rack, a megawatt, a cooling loop, a county permit, or a five-year schedule somebody's going to have to restate.

The bet

So here's the gamble, stated plainly enough to be wrong in public.

OpenAI and Anthropic are running two arms races at once: a giga-model race for the frontier, and a loss-leading subsidy race for the seats. The first is what generates the bubble fear. The second is what makes the bubble fear rational. And the climate and water discourse is the political bill arriving for both.

Google saw all of it coming from a very long way off. They built TPUs before anyone knew what that had to do with anything. They moved TPUs into consumer hardware while reviewers scored the spec sheet and called it a miss. They open-weighted a model family sized for the edge and shipped a runtime for it on Chrome, ChromeOS, and a watch. And they aimed their flagship serving model at pareto-optimal rather than at the leaderboard, then cut its price in half on day one.

That's not a product strategy. That's somebody who decided years ago which quantity was going to be scarce.

And here's where the two halves of this post meet. If you're running a well-built harness, the frontier-model soap opera is already irrelevant to you — I genuinely could not tell you whether the last two weeks of Opus 5 discourse cost me anything, because the fences and the reviews and the gates absorbed it. And if pareto-optimal models plus distributed compute is where the market lands, the soap opera becomes irrelevant to everyone, because the marginal token stops being scarce enough to have drama about.

Both of those are the same claim from two directions: the model is becoming a part, not a product. Parts get commoditized. Whoever owns the cheapest path to a good-enough part, and the widest surface to run it on, wins the decade.

I said Google would win this in 2025 and named their two options. They've now picked the second one and started executing it in public. I'm doubling down. Google was playing chess in this room and everybody else was counting pieces.

Check back on this post in a year and tell me where I was wrong. I'd rather be on the record.

CTA
Sustain Your Focus: Walking Desk for DevsCode. Walk. Solve.
Long coding sessions lead to physical fatigue and mental fog. A walking desk keeps you alert and focused, preventing costly bugs and burnout.Stay focused and healthy during long coding sessions.Get the factsGet the facts