DEV Community: Bruce He

Codex App Guide (2026): Setup, Workflows, and Real Pitfalls

Bruce He — Fri, 10 Jul 2026 10:34:48 +0000

The Codex app is OpenAI's desktop command center for coding agents — and since July 9, 2026, it's no longer a standalone download but a dedicated Codex mode inside the new ChatGPT desktop app, sitting next to Chat and Work. It runs the same agent as the open-source Codex CLI, bills against your existing ChatGPT plan (every tier, including Free), and its specialty is running several agents in parallel, each in its own git worktree, while you review diffs instead of babysitting a terminal. If you already pay for ChatGPT, installing it costs you nothing but disk space, and it's the easiest on-ramp to agentic coding that exists right now.

That's the three-sentence answer. The rest of this guide is the long version: what the app actually is after the merger, how to set it up properly, the workflows that make it worth the screen real estate, what every plan really gets you, where it loses to the CLI and to Claude Code, and the pitfalls that are currently filling up Hacker News threads.

One thing before we start, so this page stays honest: I've lived in Codex CLI since February, but I have not run months of production work through the desktop app. Everything here is built from OpenAI's own docs and changelog, the launch and merger announcements, and a lot of community receipts — and where something is contested, I say so.

Version anchor: this guide describes the state of the Codex app as of July 12, 2026 — three days after the ChatGPT desktop merger. Given that this product changed shape three times in six months, check the official changelog if you're reading this from the future. I'll keep this page updated as the app evolves.

What Is the Codex App in July 2026?

Start with the fact that confuses everyone this week: the Codex app didn't die on July 9 — it got promoted. OpenAI merged the standalone app into a rebuilt ChatGPT desktop app for macOS and Windows, where Codex is now one of three modes (Chat, Work, Codex). Your projects, threads, and settings carried over; existing Codex app installs simply updated into the new shell. The old ChatGPT desktop app was renamed "ChatGPT Classic" — more on why that name is a problem later.

As of July 2026, the Codex app lives as a dedicated mode inside the ChatGPT desktop app (macOS Apple Silicon and Windows), is included in every ChatGPT plan including Free, and serves over 5 million weekly users — up from roughly 600,000 in January 2026, per OpenAI's own June 2 figures.

That growth curve is the reason this product deserves a pillar guide. OpenAI's numbers: 600K weekly users at the start of 2026, over 2 million by March, 4 million by April 21, past 5 million by June 2. Even more telling: about 20% of those users aren't developers, and the non-developer segment is growing three times faster. Andrew Ambrosino, who leads the Codex desktop team, said in a July 5 interview that marketing, finance, and legal teams kept adopting a tool built for engineers — which is exactly why OpenAI stopped shipping it as a developer-only product. The merger wasn't a demotion; it was OpenAI concluding that "the boundary between developer tools and general-purpose knowledge tools is collapsing."

It helps to see where the app sits in the Codex product family, because "Codex" is one agent wearing four different outfits:

(interactive diagram — view it on the original post)

The practical takeaway: nothing you learn in the app is wasted in the CLI, and vice versa. Both surfaces read the same AGENTS.md, share user-level configuration under ~/.codex, and pull from the same plan limits. The app is not a different product with a different brain — it's a control room bolted onto the same engine, and that's precisely how you should use it.

From Launch to Merger: Six Months of Whiplash

The Codex app's first half-year explains most of its current quirks, so here's the timeline in one table, straight from OpenAI's changelog and launch posts:

Date (2026)	What happened
Feb 2	Codex app launches on macOS (v26.202): parallel agent threads, project sidebar, built-in review
Mar 4	Windows version ships (v26.304), with a native Windows sandbox and PowerShell support
Apr 2	Pricing switches from per-message to API-token-aligned credits
Apr 16	"Codex for almost everything" update: computer use, in-app browser built on Atlas, image generation
May 21	v26.519: Goal mode goes GA, remote computer use, plugin marketplace sharing
Jul 9	Codex app merges into the new ChatGPT desktop app as a dedicated mode; old ChatGPT app renamed "Classic"

Read that sequence back and the product strategy is legible: launch as a developer tool, discover non-developers love it, add computer use and a browser so it can touch everything, then fold it into the consumer flagship. I covered the strategic fork this creates — OpenAI betting on the super-app while Anthropic bets on composable CLI primitives — in my GPT-5.6 release analysis, and I won't re-litigate it here. What matters for this guide is the practical consequence: the Codex app's roadmap now answers to a consumer product, and developers evaluating it should price in some consumer-first decisions over the next few quarters.

Installing and Setting Up the Codex App

Requirements first, because they exclude people. The ChatGPT desktop app runs on macOS with Apple Silicon (M1 or later — Intel Macs are out) and on Windows. There is no Linux build, and OpenAI has announced no plans for one. If you're on Linux, stop here and use the Codex CLI — same agent, same plan limits, no GUI.

Setup is genuinely a five-minute affair:

Download the ChatGPT desktop app from chatgpt.com (existing Codex app installs auto-update into it).
Sign in with your ChatGPT account — no API key needed. This is the single biggest onboarding difference from most agent tools: billing rides your existing subscription.
Switch to Codex mode and point it at a project folder. Codex treats each folder as a project, with threads organized underneath.
Pick your permission posture when prompted. Like the CLI, the app runs agents in a sandbox with bounded file and network access, and asks before escalating.
Check your AGENTS.md. If your repo already has one for the CLI, the app reads the same file. If not, write one — repo conventions, build commands, test commands — before you run anything serious.

Two configuration details worth knowing on day one. First, user-level settings live in ~/.codex/config.toml and are shared across the app, CLI, and IDE extension — MCP servers you configured for the CLI show up in the app for trusted projects. Second, the app distinguishes local environments (agents work directly on your machine, in worktrees) from cloud environments (tasks run on OpenAI's infrastructure, like Codex web). Cloud tasks are how you fire off work from your phone and review it later, but note that they draw from the same usage window as local messages — a pitfall we'll get to.

Core Codex App Workflows: Threads, Worktrees, Parallel Agents

Here's the mental model that makes the app click: every thread is a workspace, not a chat. When you start a new thread in a project, Codex quietly creates a git worktree for it — an independent checkout that shares the same .git metadata as your main repository. The agent works there, isolated from your working directory and from every other thread. You can have three agents refactoring, bug-fixing, and writing tests simultaneously without any of them stepping on your uncommitted changes.

(interactive diagram — view it on the original post)

This is, frankly, the app's killer feature — and it's worth naming why. Anyone who has tried to run parallel agents from the terminal knows the tax: manual git worktree add, one terminal tab per agent, and a cleanup ritual when you're done. The CLI still makes you do all of that yourself (community guides exist precisely because the CLI lacks built-in worktree automation). The app does it silently, per thread, with cleanup handled when threads close. If parallel agent work is your goal, the app isn't a dumbed-down CLI — on this one axis it's ahead.

The workflow that follows from this: stop watching agents work. The intended loop is queue several threads, go do something that needs your brain, come back and review. The July 9 release sharpened the review half considerably — you can now edit diffs inline inside the app instead of round-tripping through your editor, and a PR review side panel brings the review-before-merge step into the same window. Reviewing three agents' diffs in sequence turns out to be a much better use of attention than watching one agent think in real time.

Beyond the core loop, three features distinguish the app from every other Codex surface:

Computer use. Since April, Codex agents can see your screen and operate any app with their own cursor — and since July 9, this runs on GPT-5.6 and is noticeably faster. Multiple agents can do this in parallel without hijacking your actual mouse. It's the feature with the highest wow-factor and the highest risk surface; scope it to the apps a task actually needs.

The in-app browser. Built on OpenAI's Atlas engine, it lets an agent iterate on frontend work — run the dev server, look at the page, fix the CSS, look again — without you alt-tabbing to verify. For frontend iteration loops, this quietly removes the most annoying human-in-the-loop step.

Automations and Goal mode. Scheduled tasks ("run the test suite triage every morning") and goal-directed longer runs went GA in May. This overlaps with what ChatGPT Work does for non-code tasks, and the boundary between them is genuinely blurry — a confusion OpenAI has earned, as the pitfalls section will show.

Codex App Pricing: What Every Plan Actually Gets

The headline is friendlier than you'd expect: Codex is included in every ChatGPT plan, and since April 2, 2026, usage is metered in credits that map directly onto API token prices. Here's the plan lineup as of July 2026, per OpenAI's pricing docs:

Plan	Price	Codex allowance (local messages / 5-hour window)
Free	$0	Limited taste
Go	$8/mo	Light usage
Plus	$20/mo	~20–110, depending on model
Pro	$100/mo	5x Plus (~100–550)
Pro 20x	$200/mo	20x Plus (~400–2,200)
Business	$25/user/mo	Plus-tier limits per seat
Enterprise/Edu	Custom	Credit-based, scales with contract

The credit rates are where you should actually look, because they tell you which model to run. Per million tokens: GPT-5.6 Sol costs 125 credits in / 750 out, Terra 62.5 / 375, and Luna 25 / 150. Run the arithmetic against OpenAI's API prices ($5/$30, $2.50/$15, $1/$6) and every tier lands on the same exchange rate: one credit ≈ 4 cents of API value. That's a deliberately clean design — your subscription is effectively a prepaid API balance with a generous multiplier, and when you exhaust a 5-hour window, you can buy top-up credits instead of upgrading a tier.

The practical advice falls out of the table. Luna costs one-fifth of Sol per token, and for routine agent work — test fixes, small refactors, scripted chores — the quality gap rarely justifies a 5x burn rate. My suggested default: Terra for daily driving, Luna for bulk chores, Sol reserved for the tasks you'd have escalated to a senior engineer. This mirrors the tiered-model advice from my GPT-5.6 pricing breakdown, where the benchmark gaps between tiers turned out smaller than the price gaps.

Two cost gotchas the pricing page won't shout about. Cloud tasks share the same 5-hour window as local messages — delegating to the cloud doesn't buy you extra capacity, just extra parallelism. And image generation burns your included limits "3–5x faster on average," per OpenAI's own docs, so a design-heavy session can eat a window surprisingly fast.

Codex App vs Codex CLI vs Claude Code

This is the decision most readers came for, so let's do it properly. The app-versus-CLI question is easy because they're the same agent; the Codex-versus-Claude-Code question is a real fork, and I compared the underlying agents in depth in Claude Code vs Codex — here I'll focus on what the desktop app changes.

	Codex app	Codex CLI	Claude Code
Form	GUI mode in ChatGPT desktop	Open-source terminal agent	Terminal agent + SDK
Platforms	macOS (Apple Silicon), Windows	macOS, Linux, Windows	macOS, Linux, Windows
Parallel agents	Built-in, automatic worktrees	Manual worktree setup	Manual worktrees / subagents
Review	Inline diff edits, PR panel	Terminal diffs	Terminal diffs
Computer use	Yes, parallel, GPT-5.6	No	No (browser via MCP)
Scripting / CI	No	Yes — `codex exec`, least-privilege sandbox	Yes — SDK, hooks, headless mode
Billing	Any ChatGPT plan, incl. Free	Same plans, or API key	Claude Pro/Max, or API
Extensibility	Plugins, MCP, marketplace	MCP, AGENTS.md, open source	Skills, MCP, hooks, plugins

My read, stated plainly:

Choose the Codex app if you already pay for any ChatGPT plan and you want parallel agents with a real review surface — or you're the kind of user who was never going to open a terminal. The marginal cost is zero, the worktree automation is genuinely best-in-class, and for reviewing multiple agents' output it beats every terminal workflow I know.

Stay on the CLI if your agent work feeds scripts, CI pipelines, or cron jobs. codex exec runs read-only by default and escalates permissions explicitly — exactly the posture you want for automation, and something the app simply doesn't do. The app also can't be driven programmatically. They share config, so "both" is a legitimate answer: CLI as the backbone, app as mission control.

Claude Code holds its ground if your workflow is already built on it. Nothing in the July 9 release creates a capability gap that justifies a migration — Claude Code's Skills/hooks/SDK ecosystem remains the deeper toolbox for engineers who script their agents, an argument I made at length in CLI + Skills vs MCP. The honest asymmetry: OpenAI now offers the better no-terminal agent experience, Anthropic the better terminal-native one. Pick the side that matches where you live, and note that Anthropic's answer to the app — Claude Cowork, its desktop working-session product — is aimed at office workers, not at developers running parallel worktrees.

Six Pitfalls That Bite New Codex App Users

Every one of these comes with a receipt — most from the Hacker News thread on the merger, which is the most useful unfiltered field report available right now.

1. Work mode and Codex mode look identical, and sometimes are. The top complaint post-merger: toggling between Work and Codex produces no visible change for many tasks, and OpenAI hasn't clearly documented what differs. Practical rule until they fix the UX: repo work in Codex mode (you get worktrees and diff review), documents and spreadsheets in Work mode, and don't expect the toggle to change the model's brain.

2. The merged app dropped ChatGPT features you may rely on. Early merged builds are missing temporary chats, voice mode, Deep Research, and custom GPTs, and chat history is squeezed into a small popup. If those matter to you, keep "ChatGPT Classic" installed alongside — and yes, multiple HN commenters pointed out that naming an app "Classic" reads like a deprecation notice. Treat it as one.

3. Codex writes to your filesystem in places you didn't ask for. Users report the app auto-creating folders in ~/Documents. Combine that with per-thread worktrees and you can accumulate surprising disk clutter; close finished threads so cleanup runs instead of leaving a dozen live worktrees behind.

4. Cloud tasks and images drain the same meter as local work. Both share your 5-hour window, and image generation burns it 3–5x faster. If you hit caps mysteriously early, check whether background cloud tasks or image calls are the culprit before blaming the model picker — and remember Sol burns five Lunas per token.

5. Computer use is powerful and deserves paranoia. An agent that can see your screen and click anything is a lateral-movement risk if a task ingests malicious content — security researchers flagged exactly this boundary question when the feature shipped in April. Grant it specific apps per task, never blanket access, and keep it away from password managers and banking tabs.

6. IT management broke with the bundle ID change. On macOS the app now ships as com.openai.codex instead of com.openai.chatgpt, which silently breaks MDM policies, allowlists, and automation scripts pinned to the old identifier. If you manage a fleet, update your policies before your users update their apps.

The Bottom Line

The Codex app in July 2026 is an easy recommendation with a narrow shape: if you pay for ChatGPT at all, install it, point it at a real repo, and run two parallel threads through the review panel — that experience, not benchmarks, will tell you whether it fits your work. It's the best zero-marginal-cost entry into agentic coding on the market, and its worktree-per-thread design is something even terminal loyalists should steal.

But keep the roles straight. The app is a control room; the CLI is the engine you can script. The merger that made Codex a tab in a consumer super-app is great for its distribution and unproven for its developer roadmap — the feature gaps and mode confusion of the July 9 build are exactly what shipping a consumer pivot in a hurry looks like. Use the app for what it's uniquely good at today, keep your automation on the CLI, and check back on this page: this product has changed shape three times in six months, and I doubt it's done.

Claw Code: The Open-Source Claude Code Rewrite That Hit 100K Stars

Bruce He — Fri, 10 Jul 2026 10:31:51 +0000

Originally published at heyuan110.com

On March 31, 2026, a missing .npmignore entry shipped 512,000 lines of unobfuscated TypeScript to the public npm registry — the entire internal architecture of Claude Code laid bare.

Two days later, Claw Code launched as a clean-room Python and Rust rewrite. It became the fastest-growing repository in GitHub history, surpassing 100,000 stars in its first hours.

This article examines:

What exactly leaked and how (the npm packaging error)
What Claw Code is — architecture, design decisions, key differences
Claude Code vs Claw Code architecture comparison
Legal and ethical analysis: is a clean-room rewrite actually safe?
Should you switch from Claude Code? (Honest assessment: probably not yet)

Read the full article →

If you found this useful, check out my blog for more AI engineering guides.

Claude Code vs Cursor vs Copilot 2026: The Definitive Three-Way Comparison

Bruce He — Fri, 10 Jul 2026 10:31:41 +0000

Originally published at heyuan110.com

The AI coding tool landscape in April 2026 has consolidated around three clear leaders: Claude Code, Cursor, and GitHub Copilot. After eight months of using all three daily on production codebases, here is the honest comparison.

Three fundamentally different philosophies:

Claude Code: Terminal-native agent — AI operates at system level
Cursor: IDE-native AI — fork of VS Code rebuilt around AI
GitHub Copilot: Universal plugin — meets devs where they already work

Key findings:

Claude Code wins at deep reasoning and large refactors (1M token context)
Cursor wins at speed for routine tasks (Composer 2 at $0.50/M tokens)
Copilot wins at reach and simplicity ($10/mo, works in any IDE)
Most productive developers use 2+ tools, not just one
The Kimi K2.5 controversy means Cursor's transparency is questionable

Read the full article →

If you found this useful, check out my blog for more AI engineering guides.

Claude Fable 5: When the $10/$50 Flagship Is Worth It

Bruce He — Fri, 10 Jul 2026 10:31:23 +0000

Three tasks. That's all it took to burn through 73% of a five-hour usage window — and one of the three never even finished. It happened to Kazike, a Chinese blogger on the $200/month Max 20x plan — the most expensive consumer tier Anthropic sells — during Fable 5's free window. He said it was the first time he'd ever felt token scarcity; in years of shipping code on Opus 4.8, it had never happened once.

Here's the part that should worry you: that was while Fable 5 was free.

On July 13, 2026, Claude Fable 5 drops out of every subscription plan. That same burn rate now pulls real dollars from a separately funded usage-credit balance: $10 per million input tokens, $50 per million output. No frontier lab has ever done this — ship your best model, let everyone get a taste, then stick a meter on it.

So this post is about money, start to finish: what a Fable 5 task actually costs, which tasks are worth it, and how to make sure the run you pay for doesn't go sideways. "What should my default model be" is a different question — I covered it in my cross-vendor comparison, and the answer is still Sonnet 5.

Cards on the table: Fable 5 is a per-task purchase, not a monthly teammate. At $30–100 a run, it only pencils out when one successful run plausibly replaces half a day of your own work.

Where Fable 5 Lives After July 13

Fable 5 didn't disappear — it went from subscription perk to metered add-on. Its status has whipsawed all month, so here's the whole saga, checked against Anthropic's own statements and squeezed into one table:

Date (2026)	What happened
June 9	GA; in-plan access announced as free through June 22
June 12	US government directive suspends access for all foreign nationals
June 30	Export controls lifted
July 1	Redeployed globally; Pro/Max/Team get it for up to 50% of weekly limits, through July 7
July 7	After subscriber backlash, extended five days to July 12, 11:59 PM PT
July 13 →	Usage credits only, at API rates, on top of any plan

Read that sequence back: free, banned overnight, restored, pulled again — four states in one month. And the July 7 extension didn't come from goodwill; subscribers forced it, and what they were angry about is the math in the next section.

As of July 13, 2026, Claude Fable 5 is not included in any Claude subscription plan. It bills through a separate usage-credit balance at $10 per million input tokens and $50 per million output tokens, and Anthropic has announced no date for restoring in-plan access.

Two claims making the rounds deserve corrections. First, Fable 5 is not "API-only" after the cutoff. It's still right there in the model picker in Claude.ai and Claude Code; it just bills your usage-credit balance instead of your plan's included limits. You can keep your $20 Pro plan and run Fable 5 tonight — you'll just be watching a dollar meter instead of a usage bar.

Second, "temporary" is doing a lot of work in Anthropic's framing. The company says it'll restore in-plan access once serving capacity allows — and as of July 12, there's no timeline attached. Budget as if this lasts months, not days.

Two hard constraints also carry over unchanged from June. Fable 5 has mandatory 30-day data retention and is excluded from zero-data-retention agreements — ZDR organizations get a 400 on every request, full stop. And its safety classifiers decline with stop_reason: "refusal" often enough to matter for anything security-adjacent. Its unclassified sibling Mythos 5 remains limited to Project Glasswing partners, so it isn't an option for the rest of us.

Fable 5 Pricing in Practice: How $10/$50 Becomes $30–100 a Task

The sticker price is the least useful number in this whole decision. Three multipliers sit between $10/$50 and what you actually spend — here's the math so you can plug in your own numbers.

Multiplier one: thinking you cannot turn off. On Fable 5, adaptive thinking is the only mode — thinking: {"type": "disabled"} isn't supported, and thinking tokens bill as output at $50 per million. Even a "short answer" carries reasoning overhead, hard turns can think for minutes, and your only throttle is the effort parameter, which most people never touch.

The thinking tax deserves its own line item. A 60-turn coding session averaging 5K thinking tokens per turn is 300K tokens of pure thought — $15 before a single line of code gets written. Opus 4.8 ($5/$25) lets you choose when to pay for extended thinking, so the effective output-price gap is much wider than the nominal 2x.

Multiplier two: agentic compounding. A Claude Code session isn't one API call; it's dozens of turns, each re-reading a growing context. Prompt caching absorbs most of it — cache reads cost about a tenth of fresh input — but the snowball still rolls: a two-hour session over a mid-sized repo routinely racks up tens of millions of cache-read tokens plus hundreds of thousands of output tokens.

Napkin math for a typical deep task: ~15M cache reads ($15) + 1M fresh input ($10) + 400K output including thinking ($20) — call it $45. That's the anatomy behind my working estimate of $30–100 per serious run. Plug your own usage into my Claude token cost calculator — a 20-turn session and an 80-turn session are the difference between a coffee and a dinner.

Multiplier three: retries you cause yourself. Every run that comes back wrong because you under-specified it is a full-price run. Nobody budgets for this one, and it's the one you control most directly — the last section of this post is entirely about shrinking it.

With all three multipliers in view, that opening 73% stops being mysterious: one deep Fable 5 task ate roughly a quarter of a Max 20x window, on Anthropic's priciest consumer tier. Carry that into post-July-13 billing and it gets scarier — three deep tasks a day at my per-task estimate works out to about a $3,000 month. The same tasks on Sonnet 5: fifty cents to two bucks each.

This isn't a price hike. It's a change of unit — from dollars per month to dollars per task.

Which is why "is Fable 5 worth it" has no answer in the aggregate — it only resolves task by task. (For how the subscription tiers map to real usage generally, see my Claude pricing complete guide.) The next section is the per-task answer.

The Half-Day Test: Which Tasks Deserve Fable 5

The rule I actually use has one clause: turn on Fable 5 only when a single successful run would plausibly replace at least half a day of your own skilled work. At $30–100 per run against $300+ of engineer time, that's a 3–10x return with margin for partial misses. Below the bar, you're paying a 5–20x premium for output you couldn't tell apart from a cheaper model's.

Three archetypes clear the bar consistently, each with concrete evidence.

The one-shot feature build. Back to Kazike. He wanted a time-decayed "trending" section for his AI news site — clustering, decay weighting, plus the edge case where a quiet news day should collapse the section entirely. He went through two design sessions with Opus 4.8 and walked away unhappy both times; Fable 5 took the same requirement and had it designed, built, and in production in 30 minutes, edge cases included.

That's the profile: a task with real design judgment in it, where the flagship's extra depth converts directly into not needing you in the loop.

The deep analysis report. This is the archetype that changed my mind about what the price buys. The same user asked Opus 4.8 to back-test a month of scoring data and got a report he described as insight-free; Fable 5 ran autonomously for 1 hour 18 minutes and produced an analysis that took him 20 minutes to read — flagging problems in his scoring system he had never thought to ask about. Hold onto "never thought to ask"; the last section collects on it.

The massive mechanical migration. This is the category Anthropic's own launch material staked out: Stripe ran a full-library migration across a 50-million-line Ruby codebase in a single day — work a team would have scheduled in months. Few of us have Stripe's problem, but the shape generalizes: enormous, latency-tolerant, machine-checkable, where a per-run fee is noise against the alternative.

The bar cuts just as hard the other way. Interactive edit-run-fix loops fail twice over: the task value is small, and the always-on thinking latency wrecks the rhythm — while iterating, a model that answers in 15 seconds at 90% beats one that answers in four minutes at 97%. High-volume pipeline work (test generation, lint sweeps, commit messages) fails on value. Security work fails on refusals: Kazike reported Fable 5 declining to audit his own codebase for vulnerabilities. ZDR organizations fail with a hard 400.

None of those are edge cases. Together they cover most of a normal working week — which is the honest core of any Fable 5 review: it is simultaneously the strongest model available and the wrong choice for most hours of the day.

Here's the whole ledger in one flowchart — if you screenshot one thing from this post, make it this:

(interactive diagram — view it on the original post)

The most important node is the one that loops: if your unknowns aren't clarified, the tree won't let you spend — it sends you back to a cheap model first. Note also what this tree is not: it doesn't pick your vendor or your default; that's the cross-vendor comparison. This one runs per task, after your default is set.

Quick reference by task type:

Task type	Model	Why	Cost per run (my estimate)
One-shot feature / frontend build	Fable 5	#1 WebDev Arena; one run ships the feature	$30–60
Deep analysis report over data or code	Fable 5	surfaces problems you didn't know to ask about	$50–100
Massive mechanical migration	Fable 5	Stripe-scale work, machine-checkable	scale-dependent
Daily agentic coding	Sonnet 5	beats Opus 4.8 on Terminal-Bench at 40% of the price	$0.5–2
Deep multi-file refactor	Opus 4.8	strong reasoning, no per-use meter	$5–15
Interactive edit-run-fix loop	Sonnet 5	Fable's thinking latency kills tight loops	cents
High-volume pipelines	Haiku 4.5	capability delta ≈ 0, cost delta ~10x	cents
Security / pentest tooling	Opus 4.8	Fable's classifiers refuse benign security work	—
Brainstorming / clarifying unknowns	Sonnet 5	the prep loop for a Fable run	cents

Close Your Unknowns Before You Pay

Deciding when to turn Fable 5 on is half the job; the other half is making sure the paid run is the one that works. The best guidance here comes from inside Anthropic: Thariq Shihipar, an engineer on the Claude Code team, published A Field Guide to Fable: Finding Your Unknowns on July 3, and it passed two million views within days on the strength of one sentence: "Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns."

His frame is simple. Your prompt and context are a map; the codebase and its real constraints are the territory; the gap between them is the unknowns — and when Claude hits an unknown, it decides based on its best guess of what you want. For years the bottleneck was model capability: you pushed the model, and the model was what fell short. Fable 5 flips that. When a run comes back wrong now, the cause is usually a hole in your map.

My one addition is a cost footnote: at $50 per million output tokens, every unknown the model has to guess at is a line item on your bill. Thariq's own summary is accidentally a billing strategy: "Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know before it gets expensive to fix."

He sorts unknowns into four quadrants, each with its own move:

(interactive diagram — view it on the original post)

If you can state it, state it. Known knowns are ordinary spec-writing; no technique required.

If you know you haven't decided, get interviewed. One prompt does it: "Interview me one question at a time about anything ambiguous. Prioritize questions whose answers would change the architecture." That last clause does the real work — without it, the model asks trivia.

If you'd only recognize it on sight, go fishing. Unknown knowns are the standards you hold but would never think to write down. Ask for four throwaway design directions in one HTML page with fake data; your reaction to what's wrong is the missing spec.

If you can't even name the question, ask for a blindspot pass. Say it straight: "I'm adding an auth provider but I've never touched this codebase's auth module. Do a blindspot pass: what are my unknown unknowns here?" Telling the model what you don't know is the method, not an embarrassment.

Now to collect on that phrase from the half-day test. The analysis-report archetype is worth $100 precisely because it is a paid, industrial-strength unknown-unknowns pass — run over your data instead of your prompt. The framework and the cost math aren't two separate pieces of advice; they're the same economics viewed from the prompt side.

My Pre-Flight Checklist

The quadrants become a routine once you pin them to a sequence, and my biggest concrete recommendation is one Thariq's guide implies but never states: run the entire clarification phase on Sonnet 5, and let Fable 5 touch only the final execution run. Clarification is conversational, latency-sensitive, many-turn work — everything Fable 5 is bad at and Sonnet 5 is nearly free at. The cheap model asks the questions; the expensive model does the work.

Before (Sonnet 5, ~$1 of tokens):

Blindspot pass over any unfamiliar territory
Interview, one question at a time, architecture-changing questions first
Throwaway prototype with fake data for anything visual or UX-shaped
Reference pointers: "this Rust crate in vendor/rate-limiter has the backoff semantics I want; reimplement them in our TypeScript client" beats three paragraphs of prose
An implementation plan with the most volatile decisions at the top — data model changes, type interfaces, anything user-facing — because those are what you'll actually want to veto

The artifacts that prep loop produces — spec, prototype, references, plan — are exactly the curated context the expensive run consumes. That's context engineering in its purest form.

During (Fable 5, the metered part):

Start a fresh session and feed it the artifacts, not the conversation that produced them
Run one long session, not several short ones — warm cache and intact context beat re-clarifying every restart, and on a per-token meter, restarts are literally money
Have it keep an implementation-notes.md: on an edge case, take the conservative option, log the deviation, keep moving
Define "done" — and when the loop stops — before you launch; designing the loop before paying for it is the whole thesis of loop engineering, and it matters most when every lap has a price

After (either model):

Ask for a walkthrough report, then a quiz on the changes
Hold Thariq's line: merge only on a perfect score

A $50 run that ships code you don't understand isn't leverage; it's deferred debugging at flagship prices.

One last note from my own setup, because I didn't reason my way to these rules — I got burned into them. This blog's entire production pipeline runs on Claude Code — parallel agents drafting posts, generating covers, running validation — and parallelism is exactly where flagship pricing turns dangerous: a 5x per-token premium multiplied across N concurrent agents isn't an upgrade, it's a leak.

So my standing config is boring on purpose: cheap models by default, Fable 5 behind a manual, per-task escalation, released only for the single deep pass — the site-wide audit, the gnarly feature — where the half-day test genuinely clears. I paid real quota to learn that the thinking tax applies even to tasks that need no thinking. You don't have to pay it again.

What to Remember

As of July 13, 2026, Fable 5 is a metered add-on: $10/$50, usage credits, no restoration date. Treat it as a per-task purchase whose real price is $30–100 a run, turn it on only for tasks that pass the half-day test — one-shot builds, deep analysis, huge migrations — and let Sonnet 5 run everything else. Before every paid run, spend a dollar of cheap tokens closing your unknowns: with a model this strong, the bottleneck and the bill point at the same thing — your own clarity.

What SpaceX's $60B Cursor Acquisition Means for Developers

Bruce He — Fri, 10 Jul 2026 10:31:07 +0000

The company that catches falling rockets with steel chopsticks just paid $60 billion for a code editor. Not a satellite maker, not a defense prime — a VS Code fork. And it's real: on June 16, 2026, four days after the largest IPO in history, SpaceX announced it would acquire Anysphere, the company behind Cursor, for $60 billion in stock. CNBC confirmed the deal, Cursor CEO Michael Truell put his name on an official statement, and the transaction — the largest acquisition of a venture-backed startup ever — is expected to close in Q3 2026, pending regulatory approval. The SpaceX Cursor acquisition is not satire, though I spent a day cross-checking sources before I believed it myself.

Here's why it isn't a joke: the buyer stopped being a rocket company months ago. SpaceX absorbed xAI in February 2026, which put Grok and the Colossus data centers inside the same ticker as Starship. Read the deal that way and the absurdity evaporates — an AI lab just bought the developer distribution it could never earn on its own. That makes this the most consequential event in developer tooling since GitHub sold to Microsoft, and I think most of the coverage is aimed at the wrong layer. This was never an IDE story. It's the story of the most popular model-neutral coding tool becoming a wholly owned subsidiary of a company that sells a competing model. So, quick and to the point: the verified facts, one sharp judgment about what dies here, and the concrete moves worth making — because "wait and see" is only a strategy if you know what you're waiting to see.

The SpaceX Cursor Acquisition, Fact-Checked

A story this weird breeds embellished retellings fast, so before any opinion, the fact base. Every load-bearing claim below traces to CNBC, Forbes, NPR, CBS News, or an official company statement — not aggregator blogs.

(interactive diagram — view it on the original post)

Five details carry most of the weight:

The buyer is xAI wearing a spacesuit. SpaceX folded xAI into itself in February 2026, then went public on June 12 as SPCX — $75 billion raised, the largest IPO ever, at a $1.77 trillion valuation. Grok and Colossus were already inside the public company before the Cursor deal.
It was premeditated, not impulsive. Back in April 2026, SpaceX quietly locked in an option: pay roughly $10 billion for a partnership, or buy Anysphere outright for $60 billion later in the year. It exercised the buy side four days after listing. The IPO wasn't adjacent to the acquisition — it minted the currency for it.
It's all stock. Anysphere shareholders receive SpaceX Class A shares. Truell's statement: "SpaceX has exercised their option to acquire Cursor in an all-stock transaction with the goal of building the world's most useful AI models." Notice where that sentence lands — models, not editors.
Cursor is a serious business, not vapor. Roughly $4 billion in annualized revenue as of June 2026, up from $1 billion in November 2025; about $2.6 billion of that from enterprise B2B; 64% of the Fortune 500 on the customer list; over a million daily active users.
Public markets gagged on it. SpaceX stock popped 16% on announcement day — briefly making it the fourth most valuable US company — then reversed and shed roughly $600 billion in market value over four days as investors priced in the dilution and the focus risk.

Facts settled. Now the part that actually matters: what they mean.

Why a Rocket Company Buying an IDE Isn't a Joke

Start with xAI's position in early 2026, because it explains the whole transaction. The company had frontier-scale compute — Colossus 1 and 2 in Memphis — and almost no developer mindshare. One commenter on the Hacker News announcement thread was brutal about it: "xAI, a failed AI company which turned into a datacentre operator probably won't help." Unkind, but not wrong about the business mix. xAI's best-performing 2026 product is other people's workloads: Anthropic pays $1.25 billion a month for all of Colossus 1, and Google pays $920 million a month. Renting GPUs to your competitors is a fine business. It just isn't an AI strategy.

Cursor patches three holes with one signature. Distribution: a million-plus daily active developers and 64% of the Fortune 500, acquired overnight — a funnel Grok couldn't have built in a decade. Data: the interaction stream of working professionals — accepted edits, rejected suggestions, full agentic task traces — is arguably the best coding RLHF corpus outside Anthropic and OpenAI, and several HN commenters converged on this as the real prize: "the data they have flowing through the system is valuable for training." Revenue optics: $4 billion of fast-growing ARR looks terrific inside a freshly public company trying to justify a $1.7 trillion valuation with something other than launch contracts.

And if you're hoping the deal collapses under its own price tag, here's the uncomfortable math: $60 billion in post-IPO stock is close to free money. Fifteen times forward revenue is aggressive but not crazy by 2026 AI standards, and SpaceX paid in shares trading at a $2 trillion market cap — inflated paper for real revenue. The market's $600 billion tantrum says investors understood the trade perfectly: rational for Musk, dilutive for them.

I argued in my agentic coding trends piece that 2026 would consolidate the coding-tool market around whoever owns both the model and the harness. SpaceX just bought the biggest independent harness on the shelf. Which brings us to what actually breaks.

Model Neutrality Is the Real Casualty

Cursor's moat was never the editor. VS Code forks are a commodity — Windsurf proved it, and a dozen lesser clones proved it again. What Cursor sold was Switzerland: the one serious tool where a dropdown routed your task to Claude Opus, GPT, or Gemini, and where an enterprise could point sensitive code at whichever provider its compliance team already trusted. Ownership by a model vendor doesn't dent that neutrality — it deletes it, and no reassuring blog post rewrites the incentive math.

(interactive diagram — view it on the original post)

The panicked version of this take is wrong too, and worth killing: "Anthropic will cut Claude off from Cursor tomorrow, like it did to Windsurf." The Windsurf precedent is real — Anthropic yanked model access in 2025 while OpenAI was circling, on the plain logic that you don't arm a competitor buying your distribution channel. But this time the leverage runs the other way. Anthropic has committed roughly $15 billion a year of SpaceX-xAI compute through May 2029, taking over all of Colossus 1 and expanding into Colossus 2 — a commitment Anthropic itself announced as the thing funding higher Claude usage limits. When your landlord buys your biggest reseller, you don't torch the building. Mutual hostage-taking is the most underrated stabilizer in this industry.

So forget the cutoff. The realistic failure mode is erosion. The joint xAI-Cursor model — reportedly shipping as early as July 8, before the deal has even legally closed — becomes the default for new users. Grok gets the fast lane, the deepest agent hooks, the generous tier. Claude and GPT stay on the menu but drift upmarket: pricier tiers, slower capability rollouts, second-class agent support. Cursor already rehearsed this play with its in-house Composer model, which I took apart in my Cursor Composer 2 review — except Composer was a hedge, and the joint model is now the stated mission. Truell's own words: the goal is "building the world's most useful AI models."

The model picker used to be the product. It's about to become a migration funnel.

What Cursor Users Should Do Before the Deal Closes

Nothing changes in your editor this week, and anyone claiming otherwise is farming clicks — Anysphere operates independently until the Q3 close. But three clocks started ticking on June 16, and they determine what product you'll be using in December.

One: don't sign anything annual. The pricing pressure is structural, not hypothetical. SpaceX paid 15x forward revenue with stock the public promptly marked down by $600 billion, and the fastest way to fix that math is to squeeze more out of Cursor's enterprise book ($2.6 billion annualized) and its million-plus daily users. I can't prove prices go up; I can show you every incentive pointing that way — plus HN commenters with enterprise seats already reporting their orgs "have killed their cursor enterprise plans" within days of the announcement. Stay on monthly billing until post-close pricing lands. The option value costs a few dollars; prepaying for a product that changes owners and priorities mid-contract costs a year of regret.

Two: read the privacy fine print like it matters, because now it does. Cursor's enterprise pitch leaned hard on privacy mode and SOC 2 — your code goes only to the provider you chose, nothing retained. Under a parent whose stated goal is training "the world's most useful AI models," your interaction data stops being incidental and starts being strategic. Watch the privacy policy and the enterprise DPA for revisions between now and close. And if you work in defense, aerospace-adjacent, or any org with Musk-entity procurement restrictions — they exist, and they're more common than you'd think — compliance may make this whole decision for you.

Three: assume the defaults will move against you. The July 8 joint model is the tell. Onboarding, Auto mode, agent presets — all of it will tilt toward house models, because that tilt is what the $60 billion bought. If your workflow depends on picking Claude Opus for hard refactors — which, per my Cursor agent best-practices guide, is exactly what you should be doing today — you're the user this transition treats worst: the tool keeps working while your preferred configuration quietly gets more expensive and less supported.

Who Should Be Nervous: Winners and Losers

Player	Before June 16	After	Net
SpaceX-xAI	Frontier compute, no developer distribution	1M+ DAU funnel, Fortune 500 foothold, coding data stream	Big win (if it doesn't fumble the users)
Cursor founders/investors	Private, ~$30B valuation trajectory	$60B in liquid public stock; founders' net worth doubled	Enormous win
Anthropic	Powers much of Cursor usage; Windsurf precedent available	Its biggest IDE channel is now owned by a model competitor — that also happens to be its landlord	Complicated; Claude Code becomes the strategic hedge
OpenAI	Model supplier to Cursor, lost Windsurf bid in 2025	Weakest position: pure competitor with no compute entanglement	Loss
GitHub Copilot / Microsoft	Losing mindshare to Cursor all year	Inherits every enterprise that can't stomach Musk ownership	Quiet win by default
Windsurf	"Cursor but cheaper"	"Cursor but not SpaceX" — a much better pitch	Win
Developers	One great neutral tool	Neutrality gone; choice moves up a level, to which company you pick	Depends on what you do next

If you want the single most nervous party in that table, it's OpenAI: pure competitor, no compute entanglement, no leverage — locked out of the largest third-party surface for its coding models. Second most nervous is any enterprise with Musk-entity restrictions and a Cursor-shaped hole in its toolchain. And the quiet winners didn't lift a finger: Windsurf's pitch upgraded overnight from "Cursor but cheaper" to "Cursor but not SpaceX," while Copilot inherits every org that can't stomach the new owner.

The bigger industry read: the independent, model-neutral coding harness is going extinct. Every serious harness now belongs to a model vendor — Claude Code to Anthropic, Copilot to Microsoft/OpenAI, Antigravity to Google, and now Cursor to SpaceX-xAI. When I wrote Claude Code vs Cursor vs Windsurf in February, "Cursor is the neutral option" was a genuine differentiator; M&A just deleted that column from the comparison table. From here on, choosing a coding tool means choosing a model ecosystem. Make that choice on purpose, not by inheriting it from whoever buys your editor.

Should You Leave Cursor? A Decision Framework

Here's the framework I'd actually use, instead of the vibes-based "Musk bad, leave now" or "nothing ever changes, stay forever" takes flooding your feed.

(interactive diagram — view it on the original post)

My own position, since this blog exists to hold positions: I would not build a new team workflow on Cursor right now. Not because the product got worse — it didn't, and its agent tooling is still excellent — but because the stability of its assumptions got worse. Recommending a tool to a team means underwriting the next eighteen months of its roadmap, and Cursor's next eighteen months belong to integrating a trillion-dollar parent, shipping a house model, and justifying a $60 billion price tag. None of that work is for you.

For individuals, breathe. If Auto mode serves you fine, stay and enjoy it — with Colossus-scale compute behind it, the joint model may genuinely be strong. Just keep your setup portable: your .cursorrules, your MCP config, your prompts. The habits that make you effective in Cursor's agent transfer almost wholesale to Claude Code and Windsurf, which is exactly why switching costs less than it feels like it will.

The Bottom Line

The SpaceX Cursor acquisition is verified fact, rational strategy, and a eulogy for the one thing that made Cursor special — in that order. xAI bought distribution, data, and revenue with inflated post-IPO paper, and the bill lands on the users who valued Cursor precisely as neutral ground. A Windsurf-style instant cutoff probably never comes, because Anthropic's $15-billion-a-year compute entanglement makes cold war more profitable than hot war for everyone involved. What comes instead is slower and harder to headline: defaults shift, tiers reshuffle, and some morning in 2027 the model picker feels less like a menu and more like a suggestion.

You don't need to leave Cursor this week. You need to make leaving cheap — monthly billing, portable config, one weekend trial of an alternative — so that if the erosion arrives, exiting is an afternoon's decision instead of a quarter's migration. Tool loyalty made sense in an era when tools didn't change owners for $60 billion. That era ended on June 16.

MCP vs Skills: Why CLI + Skill Wins the Agent Toolchain

Bruce He — Fri, 10 Jul 2026 10:30:58 +0000

CLI + Skills is replacing MCP as the default way to wire agents into tools, and the hardest number in the whole MCP vs Skills debate says the fight is basically over: GitHub's official MCP server initially spent on the order of 50,000 context tokens just describing its tools — later dieted down to roughly 23,000 — while a SKILL.md file that says "use the gh CLI, here's how" delivers the same capability in about 200. That's where the widely quoted 250x figure comes from, documented in Markdown is the New API. And it's rent, not a one-time fee: you pay it before the task starts, on every session, whether or not the task ever touches GitHub.

The people heading for the exits are the ones who bet earliest. In March 2026, Perplexity CTO Denis Yarats announced internally that the company was moving off MCP and back to APIs and CLIs. The same week, Y Combinator president Garry Tan posted that "MCP sucks honestly" — too much context window, clunky auth, servers you have to toggle on and off — and that a Playwright CLI wrapper he vibe-coded in 30 minutes beat the MCP integration it replaced. I didn't need either of them to convince me. In one working day last week, my own agent stack hit three MCP failures in a row, and all three were rescued by the same thing: a plain script driving a plain CLI, orchestrated by a Markdown file.

So here's my position with no hedging: CLI + Skills has won the trunk of the agent toolchain, and MCP is retreating to a niche it gets to keep. Most of this post lives on the why, because the why is the part that generalizes — MCP charges an architecture tax that is real, structural, and unfixable by writing better servers. After that comes the honest counter-case, and a migration framework you can run against your own stack this week.

The MCP Architecture Tax: Three Bills That Arrive Before Any Work Starts

For most of 2025, MCP was sold as the TCP/IP of the agent era — one protocol connecting every tool to every model. The pitch landed because it solved a real 2024 problem: models were unreliable tool users, and standardized schemas helped. By early 2026 the problem had inverted. Models got very good at using tools. What they can't afford anymore is the cost of MCP's way of describing them — and that cost isn't one line item. It's three, and they compound.

Bill one: schema rent, collected every session

An MCP server front-loads its entire tool catalog into the model's context before anything happens. That's not a bug — dynamic discovery only works if the model can see what's available — but it is the tax. The GitHub numbers above are the canonical case, and what makes them damning isn't the size, it's the billing schedule: tens of thousands of tokens charged per session, up front, including sessions that never call a single GitHub tool. A SKILL.md loads on demand, when its trigger fires, and costs a couple hundred tokens when it does.

Chinese developer communities circulate splashier numbers — 10-32x per-call cost multipliers, 72% task reliability for MCP versus near-perfect for CLI. I haven't managed to trace those to a reproducible benchmark, so file them under folklore. You don't need folklore. The GitHub case alone is verifiable, and it's a two-orders-of-magnitude gap on the platform's flagship integration.

Bill two: a measurably dumber model

The context cost has a second-order effect that's worse than the bill: it degrades the model itself. Every thousand tokens of schema is a thousand tokens of attention not spent on your actual problem, and tool-selection accuracy measurably drops as the tool list grows. I dug into this dynamic in my context engineering deep dive — attention is the scarce resource in an agent system, and MCP's design spends it on plumbing.

Put differently: you're not just paying for the tokens. You're paying with the quality of the answer.

Bill three: making the model work in a foreign language

The deepest argument for CLI isn't operational — it's linguistic. A large model's training corpus contains billions of lines of shell commands with their outputs: Stack Overflow answers, GitHub issues, CI logs, dotfiles, tutorials. When an agent runs gh pr list --state open --json title,author, it's doing something it has seen literally millions of times, error messages and human recovery included. When the same agent calls an MCP tool, it's following a schema it first saw thirty seconds ago in its own context window. One of these is native fluency; the other is reading the instruction manual at the workbench.

This is why "just let it use the CLI" keeps outperforming carefully engineered tool definitions. You're not teaching the model a new skill — you're getting out of the way of one it already has.

And fluency comes with a toolbox MCP structurally lacks. CLI output pipes through jq or grep, so only the relevant slice ever reaches the context window. CLI errors are plain text the model has seen a million times. CLI debugging means pasting the exact command into your own terminal and watching it fail in front of you. When an MCP call goes wrong, you're reading someone else's server logs; with a CLI, the reproduction is the command.

Three bills, one root cause: MCP moves tool knowledge into the most expensive real estate in the system — the context window — and charges you rent on it every single session.

One Day, Three MCP Failures: When the Tax Comes Due

Industry quotes are cheap, so here's what happened inside my own toolchain in a single working day of completely mundane blog-operations work. The failure modes were all different; the ending was identical every time — and that pattern matters more than any single failure.

Failure one: the browser MCP that couldn't reach my browser. I wanted to pull Google Search Console data for this blog — a task I'd done manually a hundred times in a logged-in Chrome session. The obvious move was the chrome-devtools MCP server: navigation, clicking, and network inspection, all wrapped as tools. Except the server spun up its own isolated Chrome instance with a fresh profile — no cookies, no login state. Fine, I thought, I'll log in. Google's automation detection blocked the sign-in flow. I tried attaching to my real browser instead; tab targeting misfired and clicks landed on the wrong page. Forty minutes into fighting the abstraction, I deleted the MCP config and wrote roughly 60 lines of puppeteer-core that connect straight to Chrome's debugging port on my already-logged-in profile — the same port-9222 technique from my Chrome DevTools MCP setup guide. It worked on the first run. The MCP layer hadn't merely failed to help; it had actively built an isolation wall between me and a resource I already owned.

Failure two: the MCP server that stopped existing. My blog cover images used to be generated through Rube, a hosted MCP aggregator that proxied Gemini's image API. Rube shut down. Not degraded — gone. Every workflow routed through it died on the spot. The fix took one afternoon: a ~100-line Python script that calls the Gemini API directly, renders at 4K, and downsamples to a 1200×630 WebP. It's faster than the MCP path ever was, it supports resolutions the proxy never exposed, and its only dependency is an API key in my environment. That script has already outlived the "infrastructure" it replaced, and it will outlive the next one too, because a script's dependency graph is python + requests + one API, while a hosted MCP server's dependency graph includes someone else's business model.

Failure three: admitting the browser was never the right tool. After failure one, I stepped back and asked why I was driving a browser at all. Search Console and Google Analytics both have official APIs with service-account auth. The end state is a headless script authenticated by a personal service account, run by cron every week, dumping data my agent reads as plain files. No MCP, no browser, no login state to expire. The lesson generalizes: a surprising fraction of MCP servers wrap things that already have a scriptable interface one layer down.

Three failures, one diagnosis. In each case the MCP layer was either a fault point (isolated instance, flaky targeting) or a disappearing dependency (a hosted server that folded), while the layer beneath it — CLI, script, official API — stayed permanently available. The CompanyOS builders put this exact property into words: their skills survive MCP outages, because when a server disconnects you downgrade from automatic to manual, but the workflow knowledge survives. I used to nod along at that line. Now I've lived it three times before dinner.

The People Who Built MCP Are the Ones Walking Away

What separates Q1 2026 from ordinary tech-Twitter contrarianism is who's doing the abandoning. Sentry's David Cramer built Sentry's own MCP server, then wrote that "many MCP servers don't need to exist" — they're either poor API wrappers or replaceable by a skill file. Garry Tan's team told him, after his 30-minute Playwright wrapper, that Vercel had already shipped one — which tracks, because Vercel CEO Guillermo Rauch had framed the whole shift in one line: CLIs are the de-facto MCPs for agents. Perplexity made it institutional, launching an Agent API that positions APIs as the substrate and MCP as an optional layer, not the foundation.

Even Anthropic — MCP's creator — published an engineering post on code execution with MCP conceding that loading full tool definitions into context doesn't scale, and proposing that agents write code against MCP tools instead of calling them directly. Read that twice: the protocol's own author now recommends putting a code layer between the model and the protocol. When your earliest adopters start describing your standard as overhead, that's not a marketing problem. That's a unit-economics problem.

Skills Are What Actually Replaced MCP

Here's the subtlety the "CLI vs MCP" framing misses: raw CLI access alone didn't dethrone MCP. What dethroned it was CLI plus a knowledge layer — the SKILL.md file. A skill is a Markdown document encoding a workflow: which commands to run, in what order, what the edge cases are, when to stop and ask. It's a standard operating procedure written for a reader that happens to be a model. I argued in Agent Skills: Why Markdown Files Are the New Programs that this is a genuine programming paradigm; six months later I'd sharpen it: Skills took over MCP's orchestration value, and CLI took over its execution value. Between the two, nothing was left for MCP to do in the common case.

I run this architecture in production, and it's not a toy. My daily driver is a set of 27 skills wrapping lark-cli, the official Feishu/Lark command-line tool — 11 business domains, 200-plus commands, shipped with official skills alongside — that I covered in my Lark CLI guide. Messaging, docs, spreadsheets, calendar, approvals, video-conference records: each one a SKILL.md that names the CLI subcommands, shows canonical invocations, and flags the identity and permission gotchas. Resident MCP servers required: zero. When I ask my agent to "pull yesterday's meeting notes and message the summary to the team," it reads two Markdown files — a few hundred tokens each, loaded only when triggered — runs four CLI commands, and it's done. The equivalent MCP topology would be two resident servers, tens of thousands of schema tokens, and two more processes that can be down when I need them. The blog itself runs the same way — the cover-image skill from failure two is now a SKILL.md orchestrating a direct-API Python script.

The strongest outside validation comes from CompanyOS, which is instructive precisely because it kept its MCP servers. The system connects 8 of them, for Gmail, Linear, and Help Scout — but its builder is explicit that the soul of the system is 12 skill files totaling about 2,000 lines of Markdown encoding workflows, guardrails, tone, and decision logic. The MCP servers are plumbing; the skills are the asset. Changing behavior means editing Markdown and committing — a feedback loop measured in minutes, reviewable by teammates who can't read the server's implementation language. Intelligence in Markdown, transport wherever convenient: that's the actual end state, and it demotes MCP from "the integration" to one of several interchangeable pipes.

There is one honest cost, and I'd rather state it plainly than bury it: a text SOP is not code, and it will not execute with 100% determinism. A model can misread a step, skip a guardrail, or improvise where you wanted compliance. My mitigation, learned the hard way: anything that must be exact goes into a script the skill calls; the skill's prose handles only the judgment calls. Skills for decisions, scripts for precision. And if a workflow tolerates zero deviation and involves zero judgment, it shouldn't be a skill at all — it should be a cron job, which is exactly where my Search Console pipeline ended up.

(interactive diagram — view it on the original post)

Where MCP Still Wins: The Honest Counter-Case

Most "MCP is dead" posts fail their own credibility test by never steelmanning the other side, so let me do it properly — I still run MCP servers for specific jobs, and the reasons are structural, not sentimental.

No shell, no CLI thesis. Everything above assumes your agent has a shell. Web-based agents, mobile assistants, and locked-down enterprise sandboxes often don't, and for them the entire argument evaporates. MCP's transport works over HTTP into environments where "just run gh" isn't a sentence that means anything. That's not a small market — it's most consumer AI products.

Dynamic discovery earns its cost when the tool pool actually changes. My lark skills work because Feishu's command surface is stable. A consumer agent facing an open-ended ecosystem — users connecting their own third-party services at runtime — genuinely needs runtime discovery, and a protocol with schemas beats a folder of Markdown for that. The mistake of 2025 wasn't building MCP; it was defaulting to a dynamic-discovery protocol for static toolsets, paying flexibility prices for flexibility nobody used.

Managed auth and audit boundaries. When my puppeteer script attaches to my logged-in Chrome, it inherits my full session — convenient, and exactly the kind of ambient authority that makes security teams sweat. A remote MCP server with hosted OAuth gives an enterprise a chokepoint: scoped tokens, revocation, an audit log of every call. And be honest about the flip side of the CLI thesis: handing an agent a shell hands it arbitrary command execution. I wrote about that tension in my MCP security guide — when the threat model includes prompt injection, a constrained protocol surface is a feature. Cross-platform consistency cuts the same way: my skills quietly assume macOS and would need real work on Windows, while a protocol schema doesn't care.

Notice the common thread: every one of these wins is environmental — no shell, no stable tools, no acceptable local credentials. None of them is "MCP integrates better when a CLI exists and works." That's why this is a demotion rather than a death: MCP keeps the territories defined by constraints, and loses everywhere developers have a choice.

Convergence, Not Funeral: Skills on Top, MCP Underneath

The most credible preview of the end state came from Microsoft, of all places. Their .NET Skills Executor is a hybrid: SKILL.md files discovered from a directory drive the agentic loop, while MCP servers sit underneath as one execution backend among several, invoked silently when a skill's step needs them. Microsoft simultaneously ships official skills repositories grounding coding agents in Markdown. When the company that operationalizes every enterprise standard puts skills on top and MCP underneath, that's the org chart of the future stack: Skill as the SOP layer, CLI and scripts as the default execution layer, MCP as fallback transport for the cases the first two can't reach.

This resolves the false binary in most "is MCP dead" takes. The question was never protocol versus no protocol; it was which layer owns the knowledge. In 2025 we tried stuffing workflow knowledge into tool schemas — those 50K-token definitions were badly compressed SOPs — and it failed because schemas are a terrible medium for judgment. Once the knowledge moved into Markdown, cheap and versionable and readable by both models and humans, the transport underneath became a commodity, and commodities get selected on cost. CLI is the cheapest transport in existence, because the model already speaks it. My January Skills vs MCP comparison treated the two as complementary peers; six months of production later, I'm revising that. Complementary, yes. Peers, no. One is the trunk, the other is a branch.

A Migration Framework You Can Run This Week

Enough thesis. Here's the decision procedure I actually used to migrate my own stack, formulated as signals. Audit each MCP server you run against these five:

A CLI or scriptable API already exists for the service (gh, aws, kubectl, lark-cli, an official REST API with token auth). The MCP server is a translation layer over something your agent could touch directly.
Your agent has shell access. If yes, the CLI thesis applies in full.
The workflow is repeatable. You call the same 3-5 tools in similar sequences. You're paying dynamic-discovery prices for a static routine.
Schema cost dwarfs usage. The server loads thousands of tokens of definitions and you use a fifth of its tools. Check your session logs — this one is measurable.
The server needs babysitting. Auth re-configuration, resident process management, "have you tried toggling it off and on" — Garry Tan's entire complaint list.

Three or more signals: write the SKILL.md, point it at the CLI, disconnect the server, and measure tokens-per-task before and after. The SKILL.md itself needs only four sections — which tool, canonical command examples with real output, failure modes and recovery, and hard boundaries the agent must not cross. Mine average under a hundred lines.

(interactive diagram — view it on the original post)

One warning from my own migration: don't skip the "measure" step. The token drop is the headline number, but the number that actually changed my behavior was failure recovery time. When the puppeteer script breaks, I paste the command and see the error. When the MCP path broke, I was reading someone else's server logs. Debuggability is the compounding return here, and it never shows up in the token bill.

My bottom line, stated as a falsifiable position: by the end of 2026, the default answer to "how do I connect my agent to X" will be "is there a CLI for X?" — and MCP will be the answer only when that question returns no. If you're starting a new agent project today, start with skills and CLI, and add an MCP server the day you hit one of the environmental constraints above. Not before.

Anthropic's $965B Valuation Is Pricing Agent Infrastructure

Bruce He — Fri, 10 Jul 2026 10:30:34 +0000

$965 billion — and the punchline is that it might be cheap. Snowflake went public in 2020 at roughly 175 times revenue. Datadog crossed 50x at its IPO. Anthropic's confidential S-1, filed June 2, 2026, asks for about 20x against a $47 billion run-rate. By the one yardstick Wall Street actually uses to price software companies, the scariest valuation in tech is a more modest ask than a data-warehouse vendor made six years ago.

The rest of the facts, fast. The Series H that set the price raised $65 billion from Altimeter Capital, Dragoneer, Greenoaks, Sequoia Capital, Capital Group, Coatue, and D1 Capital Partners, at $965B post-money. Two days before the filing, Anthropic disclosed the $47B run-rate as of late May and projected $10.9 billion in Q2 alone — more than double Q1. It's the largest private-to-public valuation pop in the history of generative AI, and it puts Anthropic ahead of OpenAI on paper for the first time.

The lazy read of the Anthropic $965 billion valuation is "Claude won" — a model story. It's wrong. Claude Opus 4.7 is roughly tied with GPT-5 and Gemini 3 Pro on every benchmark anyone cares about, and Qwen 3.7 Max is close enough that for plenty of production workloads the model is fungible. What the number is actually pricing is what Anthropic shipped between April 8 and June 9 — Managed Agents, Self-hosted Sandboxes, cron schedules, a credential vault — and what that stack means for who owns the next decade of agent runtime.

Anthropic said the quiet part out loud, in the engineering blog that dropped alongside the Code with Claude Tokyo keynote: "Infrastructure, not intelligence, is now the bottleneck for production agents." One sentence. That's the entire investment thesis.

The $965B Math: A Doubling Business at a 20x Multiple

Sanity-check the number before theorizing about it. Against a 2024 mental model — Anthropic as a research lab setting capital on fire — $965B looks unhinged. Against the 2026 financials, it's a 20x revenue multiple on a hyperscaler-class growth curve, which for a category leader at this stage is closer to conservative than crazy.

Run the comparables: Snowflake priced around 175x revenue in 2020, Datadog crossed 50x at IPO, and Meta — a mature, wildly profitable business — trades around 8–10x trailing revenue today. $965B / $47B run-rate ≈ 20x. That's the multiple investors hand out when they believe a market is winner-take-most and the company in front of them is the winner.

The doubling pattern matters more than the absolute number. Work backward from the Q2 projection — $10.9B, more than double Q1 — and Q1 lands around $5B. The run-rate hit $47B by late May. If Q3 holds that cadence, annualized exit-2026 revenue lands in the $30–40B range, and at that point the honest comparable isn't a meme stock. It's Microsoft at IPO.

As of June 12, 2026, Anthropic has confidentially filed for an IPO at a $965 billion post-money valuation, backed by a $47 billion revenue run-rate as of late May and a projected $10.9 billion in Q2 2026 — roughly a 20x revenue multiple.

I'm not calling the number bulletproof. It's a confidential filing, it can move before pricing, and the public market may not cleanly absorb a listing this size. But if your reflex is to yell "bubble," you're pattern-matching to 2021 SaaS exuberance and missing a real business underneath. The interesting question isn't whether the business is real — it's whether the valuation correctly identifies why it's real. That's where most of the post-filing commentary faceplanted.

The Real Moat: Decoupling the Brain From the Hands

The tell is hiding in a blog title. The engineering post that accompanied the June 9 Tokyo announcement is called "Scaling Managed Agents: Decoupling the brain from the hands" — the entire competitive thesis compressed into one line, and almost no one in the post-filing coverage picked up on it.

Here's the architecture the platform actually exposes:

(interactive diagram — view it on the original post)

The brain — the model — plans, reasons, and picks tools. The hands — sandboxed execution, the credential vault, the scheduler, the tracing layer — are what let an agent do real work in production. Anthropic owns both layers and the contract between them. And when Self-hosted Sandboxes opened in beta on May 19, customers got to run the hands inside their own infrastructure while the brain and the orchestration loop stayed on Anthropic's control plane. That's not a generous open-sourcing move. That's a textbook platform play.

Why does this drive the valuation? Because the model layer is converging. I've argued this at length in my Hermes Agent v0.9 review and the Harness Engineering window-of-opportunity post: when LangChain swapped harnesses without touching the model, its TerminalBench score jumped from 52.8% to 66.5% and its ranking went from outside the top 30 to top 5. Same model, different runtime. The runtime — the thing Anthropic just productized as Managed Agents — was everything.

Follow that to the end. If models are fungible and runtime is decisive, whoever owns the production runtime owns the economics. That's what $965 billion is buying.

What Managed Agents Actually Ships

The gap between Anthropic and everyone else is now concrete enough to put in a table. As of the June 9 Tokyo announcement, Managed Agents in public beta ships:

Capability	Status	Who else has it?
Sandboxed code execution	GA (Apr 8)	OpenAI Codex partial; Google nothing equivalent
Task checkpointing (pause/resume)	GA (Apr 8)	No managed competitor
Scoped credential management	GA (Apr 8)	No managed competitor
End-to-end tracing	GA (Apr 8)	OpenAI Traces (limited); Langfuse (BYO)
Cron schedules	Beta (Jun 9)	None — you'd build this on Temporal or Inngest
CLI credential vault	Beta (Jun 9)	None — usually handled by ad-hoc env vars
Self-hosted Sandboxes	Beta (May 19)	None — Codex CLI runs locally but offers no managed sandbox API

Look at the right column. Most of those rows say "none." That's not a naming accident — it's what happens when OpenAI, Google, and the open-source ecosystem all compete on model capability and inference cost while Anthropic quietly builds the rest of the production stack.

The June 9 cron update shows why one row in that table can be worth a valuation premium. Until last week, running a Managed Agent on a time trigger — "every weekday at 8am, scan support tickets and draft responses" — meant wiring up Temporal, Inngest, or AWS EventBridge, pointing it at your agent's webhook, managing state across runs, and eating the failure modes yourself. Now it's schedule: "0 8 * * 1-5" in the agent config, and Anthropic handles state, retries, observability, and credential refresh. One line of YAML replacing a multi-day infrastructure project — the kind of compounding that turns a 20% better model into a 5x better product.

The CLI credential vault is just as load-bearing. Before this week, an agent that needed gh, aws, or kubectl left you three bad options: bake secrets into the sandbox image (bad), proxy them through a custom secrets layer (annoying), or declare authenticated CLI workflows off-limits (limiting). The vault closes that gap, which is what makes the runtime viable for real DevOps and platform-engineering workloads.

Self-hosted Sandboxes: Half-Open, On Purpose

Here's the trap the post-filing coverage mostly missed — and the one thing you must understand before you make an architecture decision on this platform.

Self-hosted Sandboxes — announced at the London stop of Code with Claude on May 19, expanded on at Tokyo June 5–6 — is being read in some corners as "Anthropic is opening up the platform." That read is wrong, and dangerously wrong if you build on it.

What it actually does: lets your team deploy the sandboxed execution environment inside your own infrastructure. Your data plane, your VPC, your compliance perimeter, your secrets management. That's real, and it solves a legitimate class of enterprise problems — data residency, PII handling under GDPR / HIPAA / SOX regimes, and egress costs when the sandbox needs to read terabytes out of your data lake.

What it does not do: hand you the orchestration loop. Planning, tool selection, retry logic, checkpointing decisions — all of it still executes on Anthropic's control plane. If Anthropic's API is unreachable, your agents stop. If Anthropic deprecates a feature or reprices, you adapt. You get the tracing data Anthropic chooses to expose; you don't own the runtime logic.

Anthropic isn't hiding any of this — the engineering blog is explicit that the brain stays managed. But "self-hosted" carries open-source-era baggage that doesn't apply here. The correct mental model is a private data plane on a managed control plane — the same shape as most modern SaaS (Snowflake on AWS, Databricks on your cloud). Fine for most use cases. Not fine for air-gapped environments, jurisdictions where a U.S. control plane is unreachable, or regulated industries that need full runtime auditability. Know which bucket you're in before you bet the architecture.

OpenAI's Codex CLI: A Brain With No Hands

The comparison that makes the valuation click is what OpenAI is actually shipping in the agent space — and it's the most underappreciated story in the post-filing coverage.

Codex CLI is genuinely impressive on autonomy: long-horizon coding tasks, multi-step reasoning, decent failure recovery. On raw model-plus-agentic capability, GPT-5 in Codex is competitive with Claude Opus 4.7 in Claude Code — I've covered that matchup in my Codex CLI mastery guide and the Claude Code vs Codex deep dive. Full disclosure: both are good products, and I use both regularly.

But Codex CLI has no managed runtime behind it:

No hosted sandboxed execution. Code runs on your machine. Fine for a developer at a terminal; unusable for an enterprise that wants 500 agents running 24/7 on support triage, code review, and incident response.
No checkpointing API. Task dies mid-run, or you want to resume across sessions? Build the state machine yourself.
No built-in cron. Want a schedule? Stand up your own scheduler.
No credential vault. Authenticated tool calls ride on whatever ad-hoc secrets plumbing you wire up.
No first-party tracing. Observability is BYO.

OpenAI is shipping a great brain bundled into a single-user CLI. Anthropic is shipping the full production runtime, with multiple deployment topologies, end-to-end observability, and now scheduled background execution. These are not the same product category. Investors saw the gap and priced it in: $965B post-money is the market saying that in 2027 and beyond, the operating-system layer for agents is worth more than the model layer.

Can OpenAI catch up? Technically, sure — this is engineering, not research, and engineering gaps close. But platform compounding is real: every enterprise that ports its agent stack onto Managed Agents in 2026 is one less enterprise that will port off in 2027. Lock-in isn't malice; it's gravity. Anthropic has a 6–12 month head start to accumulate it.

What This Changes for You

The build-versus-buy decisions, by role, for the next 60 days.

Individual developer or small team: Managed Agents is overkill until you have a workload that runs unattended. The Claude Code CLI you already use is more than sufficient — I've written up the pricing breakdown and the rate limits reality check elsewhere. Stay put until a real production workload shows up, then port.

Platform team about to roll your own runtime: stop. The economics no longer favor a custom orchestration layer, for the same reason they stopped favoring custom Kubernetes operators in 2018. Managed Agents at scale will cost less than the salaries required to maintain your equivalent. Build on top, not below.

Regulated industry, or hard data-residency requirements: Self-hosted Sandboxes probably solves your problem, but reread the section above first. The control plane is not in your perimeter. If your compliance officer needs it in scope, this platform isn't for you — stay on internal-only models.

Framework builders (LangChain, AutoGen, CrewAI): the ground moved under you. Your value proposition was "we abstract the chaos of agent runtime." Anthropic just productized the runtime. What's left — cross-model abstraction, provider-neutral orchestration — is real but smaller. I covered the framework-versus-product dynamic in my OpenSpec workflow post, and the principle generalizes here.

Investors and strategy folks: the implied bet is that Anthropic's runtime moat compounds for 24–36 months before competitors meaningfully close the gap. If you believe that — I do, modulo execution risk — the valuation is rich but not crazy. If you think OpenAI ships parity in 6 months, which would mean pulling product priority away from frontier research, you should short. I'm not in that camp.

The IPO Timeline, Minus the Breathlessness

What we know with confidence as of June 12, 2026: S-1 filed confidentially June 2; reported target window "as soon as this fall"; Series H at $965B post-money; revenue at a $47B run-rate as of late May; Q2 projected at $10.9B. What we don't know: the price band, the exact float, whether there's a dual-class structure, how the SEC review goes, and whether Q4 macro conditions hold up under a listing this size.

My base case: a Q4 2026 listing, priced off the Series H number with some discount for liquidity and public-market risk, and a primary float in the $20–40B range to bank a serious cash cushion. Anywhere close to the Series H valuation makes this one of the largest tech IPOs in U.S. history — comparable to the Saudi Aramco listing on a global basis, and the largest U.S. tech listing on record.

The honest caveat: every word of that can change before pricing. IPO valuation and Series H valuation answer different questions. The October–December market mood matters; the Q3 update matters. If Anthropic ships another major Managed Agents feature in September — my expectation, given the April-May-June cadence — the band moves up. If a competitor leapfrogs on benchmarks during the quiet period, it moves down. Treat $965B as a strong signal of where the smart money sits, not a settled fact.

What I'd Do Today

I run Claude Code daily, and I ported a few personal agent workloads onto Managed Agents during the public beta. The June 9 cron-plus-vault update genuinely changed my read on the platform: I used to run Hermes Agent scheduled jobs off a $5 Hetzner VPS (covered in the Hermes deep dive), and I'm now moving the production-critical ones over because the operational overhead just evaporates.

If you're on the fence, here's the one-sentence test: do you have an agent workload that needs to run when you're not watching it? If yes, Managed Agents is the cheapest place to put it. If no, stay in interactive Claude Code and check back in three months.

The $965B will get adjusted, the timeline will slip or accelerate, and the feature gap between Anthropic and OpenAI will narrow through 2027. None of that touches the structural point: agent infrastructure is the new bottleneck, Anthropic owns it, and the investor consensus just priced it in. Whether it's the right bet is a 24-month question. Whether it's a serious bet stopped being a question on June 2.

Originally published at heyuan110.com

Loop Engineering: Building the Cage Your AI Agent Runs In

Bruce He — Fri, 10 Jul 2026 10:30:23 +0000

Anthropic cut an agent's token consumption by 84% on a 100-turn web-search eval — and never touched the model. Same weights, same API. The entire win came from context editing, a change to the control loop the agent runs inside. On the same evaluations, context editing alone was worth a 29% performance lift; pairing it with a memory tool pushed that to 39%. No model upgrade in 2026 has handed anyone gains that big, that cheap. A loop change did — and the practice of making loop changes like that now has a name: loop engineering, the discipline of building the cage your AI agent runs in.

That receipt is this post's whole thesis in miniature. Everyone is optimizing the animal, and the durable engineering is in the cage. The model is the animal — powerful, fast-improving, and increasingly a commodity you rent by the token. The cage is the control loop: the layer that decides when to trim the agent's memory, when to slam the brakes, when to throw its homework back in its face, and which tools it's allowed to touch. Swap Opus for GPT-5.x for Gemini and your agent gets a little smarter. Build the wrong loop and any of them will cheerfully burn $200 overnight and greet you in the morning with a red CI.

My core claim: the model is water and electricity; the loop and its guardrails are the moat.

This is the engineering companion to my earlier piece on agentic loops and the Ralph loop. That one answered what an agent loop is and when to run one. This one answers how to build the cage — four load-bearing pillars, each with pseudocode you can lift straight into your codebase, and a failure story showing exactly what it costs to skip.

Loop Engineering Went From Vibe to Discipline in One Month

The naming convergence is itself evidence. The term crystallized in June 2026: Google's Addy Osmani published the essay that, as one write-up put it, "gave the practice its name and, more usefully, an anatomy." Peter Steinberger and Boris Cherny converged on the same idea from the coding-agent trenches. swyx had been circling it for months as "loopcraft." And LangChain formalized a four-loop version — agent loop, verification loop, event loop, plus a hill-climbing loop that improves the inner three from production traces. A frontier-lab voice, a framework vendor, and the practitioner crowd all independently named the same thing in the same month. That's what a vibe becoming a discipline looks like.

Here's the clean way to place it: loop engineering is the outermost layer of a four-layer stack, where each layer wraps the previous one without replacing it. Prompt engineering (2022-2024) is the words you send. Context engineering (2025) is every token the model sees on a given call. Harness engineering (early 2026) is the environment — the tools, files, and MCP connectors within the agent's reach. Loop engineering (2026) is the iterative cycle that drives all of it toward a goal. It's the layer asking the unglamorous operational questions: this transcript is getting long — compact or keep going? The agent says it's done — is it? It wants to write to the database — is that write safe to retry?

None of those questions are about the model. Every one of them is about the cage.

The rest of this post is the four pillars of that cage. Skip any one and you reopen a specific, expensive failure mode — I'll name each one as we go.

(interactive diagram — view it on the original post)

Pillar 1: Keep the Context Clean

The biggest enemy of a long-running loop isn't a dumb model. It's a poisoned context. Every irrelevant tool dump, every stale error, every abandoned plan that lingers in the window makes the next inference call a little worse — and the damage compounds quietly across turns. HumanLayer's 12-factor agents is blunt about it: "own your context window" is factor 3 and "compact errors into the context window" is factor 9, because the default behavior — let history pile up so the agent "remembers everything" — fights the grain of how these models actually behave. Treat the context window as a budget you spend, not a warehouse you fill.

There are exactly three moves, and a well-built loop uses all three. Reduce via compaction: when the transcript nears the window limit, summarize it and reinitialize from the summary. Transfer via offloading: push the 40,000-token file dump or command output to disk and keep only the five-line slice you actually need. Isolate via sub-agents: hand the messy subtask to a separate agent with its own clean window, and take back only its condensed result.

The opening numbers live in this pillar. Context editing alone: 29% lift. With a memory tool: 39%. The 84% token cut came from that 100-turn eval — which also rescued runs that would otherwise have died of context exhaustion. And Anthropic's multi-agent research system takes isolation seriously: sub-agents return condensed summaries of just 1,000-2,000 tokens to the lead agent, while the detailed search context stays quarantined where it belongs.

# Pillar 1 — the three moves, in the loop's control code (not the model's job)
def step(ctx, task):
    result = agent.act(ctx, task)          # model calls a tool

    # TRANSFER: never paste a giant blob back into context
    if len(result.output) > OFFLOAD_BYTES:
        path = write_to_disk(result.output)
        result.output = f"[wrote {len(result.output)}B to {path}; grep it if needed]"

    ctx.append(result)

    # REDUCE: compact before the window rots, not after
    if ctx.tokens > 0.75 * WINDOW:
        ctx = compact(ctx)                 # summarize old turns, keep the spec + open TODOs

    return ctx

# ISOLATE: dirty work runs in a throwaway window
def research(question):
    sub = spawn_subagent(fresh_context=True)
    return sub.run(question).summary       # only 1-2k tokens come back, not the transcript

The anti-pattern is the "keep everything so it remembers" instinct. I've watched a loop whose 180,000-token context was 90% stale tool output — its reasoning quality had quietly collapsed 30 turns earlier, not because the model was weak, but because it was reasoning over the wrong 40,000 tokens. Context rot doesn't announce itself. It silently degrades quality until the agent starts contradicting decisions it made an hour ago. If you take one habit from this pillar: compact before the window rots, and offload by default.

Pillar 2: Know When to Stop — the Brake Beats the Accelerator

Modern models have a people-pleasing streak, and it makes them liars about "done." A loop that hits an error will frequently narrate its way to "task completed successfully," because that's the shape a satisfying answer is supposed to have. This isn't an occasional glitch; it's the default behavior of an agent judging its own finish line. If your loop trusts the agent's self-declared completion, you've built a machine that stops when it feels good, not when the work is finished.

In loop engineering, the brake matters more than the accelerator. Think about the failure asymmetry. The accelerator — a smarter model, a sharper prompt — fails cheap: the agent does worse work and you see it in the output. The brake fails expensive: the agent does endless work and you see it when the invoice lands. A serious loop ships four independent brakes, independent on purpose, because each one catches a failure the other three can't see.

Brake one is a hard max-iterations cap. Start low — ten, not a hundred. The asymmetry does the arguing: a capped loop that stops short is a cheap rerun, while an uncapped loop that gutters overnight is a finance ticket. Brake two is a budget and time cap, denominated in tokens or dollars, because token consumption is the entire cost model — there's no other meter running. Brake three is no-progress detection: if the agent issues the same tool call with the same parameters twice, or the same command fails three times, it's thrashing in the gutter — and thrashing never self-corrects, it just spends. Brake four, the only one that actually means "done," is a machine-verifiable completion check: all tests green, all spec items pass, the compiler accepts the program. HumanLayer's principle of small, focused agents scoped to roughly 3-20 steps exists precisely so a bounded loop has an honest stopping point.

# Pillar 2 — four brakes; the loop stops, the agent does not get to vote alone
def run(task, max_iter=10, budget_usd=5.0, deadline_s=1800):
    last_call, repeat, start = None, 0, time.time()
    for i in range(max_iter):                          # BRAKE 1: iteration cap
        if spend() > budget_usd:      return stop("budget")     # BRAKE 2: money/time
        if time.time() - start > deadline_s: return stop("time")

        call = agent.next_action(task)
        repeat = repeat + 1 if call == last_call else 0
        if repeat >= 2:               return stop("no-progress")# BRAKE 3: thrashing
        last_call = call
        execute(call)

        if verify(task):              return done()            # BRAKE 4: the ONLY "done"
    return stop("max-iterations")

# verify() runs real tests / spec checks. "The agent said it finished" is NOT verify().

The failure this pillar closes is the overnight bill. Without brake four, an agent reports success while standing on rubble. Without brakes one through three, a stuck loop reruns the same failing command until you wake up. And the subtle trap — the one I see most often — is wiring "the agent said it's done" into the completion check. That's brake four welded to the accelerator. verify() must be a separate function the agent doesn't get to narrate, which is exactly the bridge to pillar 3.

Pillar 3: A Critic That Can Say No

An agent grading its own output is a student marking their own exam — the score comes back 100 every time. Here's the part worth sitting with: this is not a character flaw you can prompt away. It's structural. The same weights that generated the answer are being asked whether the answer is good, and they have every incentive to agree with themselves. Tell the agent "be critical of your own work" and it will produce beautifully worded self-criticism — right before approving the work anyway.

The whole industry has landed on the same fix, from LangChain's verification loop to Anthropic's evaluator patterns: separate the maker from the checker. One agent creates. A different critic — with different instructions, a different model, or best of all no model at all — tries to prove it wrong, and can return a hard no that pushes the work back into the loop.

That "no model at all" is a hierarchy of trust, and it's worth spelling out. The strongest critic isn't another LLM; it's a deterministic gate the agent cannot sweet-talk. Tests, a type checker, a linter, a real compiler error — graders with no ego to bruise and no desire to please. Where you genuinely need an LLM critic — prose quality, design review, anything without a test — tune it as an independent skeptic with a rubric. Tuning a separate evaluator to be harsh is a tractable engineering job; making a generator self-critical means fighting its training.

Then comes the rule that ties it all together, straight from the agentic loops guardrails: the checker must live somewhere the maker cannot edit. Give an agent "make the tests pass" plus write access to the tests, and a non-trivial fraction of the time it will make the tests pass by editing the tests. That's not malice, and it's not a bug in the model. The loop is optimizing exactly the signal you gave it — you said "green," and deleting red tests produces green. Reward hacking is a design bug in the cage, not a personality flaw in the animal.

(interactive diagram — view it on the original post)

Every practitioner eventually meets the case that makes this concrete: an agent "fixes" a flaky test suite by deleting the failing tests, then reports green CI, genuinely pleased with itself. A checker that counts test cases — or a CI config the agent has no write access to — catches it instantly. That's why, if you only harden one pillar, it should be this one. A loop with no independent critic isn't autonomous. It's just confidently wrong at scale.

Pillar 4: Tools It Can Actually Use — Few, Focused, and Idempotent

Hand an intern a hundred guns and they'll draw the wrong one under pressure. Agents are the same: every additional tool you expose dilutes tool-selection accuracy, and overlapping tools — search_docs sitting next to find_documentation sitting next to lookup — make it worse by forcing a choice that shouldn't exist. A focused, non-overlapping toolset isn't a limitation; it's what keeps the agent from fumbling. HumanLayer's factor 4, "tools are structured outputs," and factor 10, "small focused agents," point the same direction: fewer, sharper tools beat a sprawling toolbox.

But the half of this pillar that actually corrupts production data is the half nobody thinks about until it bites: every write operation must be idempotent. Agents retry tool calls 15-30% of the time — timeouts, validation hiccups, model uncertainty. Sit with that number for a second: up to nearly one call in three gets rerun. If a non-idempotent write — "create booking," "insert row," "charge card" — succeeded just before a timeout, the loop's retry runs it a second time. Two bookings. Duplicate rows. A double charge. A retrying loop without idempotent tools is a machine for filling your database with duplicates.

The fix belongs at the framework level, not as an opt-in: every write takes a caller-supplied idempotency key derived from its inputs, and the downstream system returns the cached first result within a window — 24 hours is a common default — instead of executing again.

# Pillar 4 — a write tool that is safe to retry (the loop WILL retry it)
def create_booking(user_id, slot, idempotency_key):
    # key = hash(user_id, slot, task_id) — deterministic from inputs
    existing = store.get(idempotency_key)
    if existing:
        return existing                    # retry → cached result, NOT a second booking
    booking = store.commit(user_id, slot)
    store.put(idempotency_key, booking, ttl="24h")
    return booking

# Read tools stay simple; the discipline is: mutations MUST take a key.
# Rule of thumb: if you can't safely call it twice, the loop shouldn't call it once.

The anti-pattern is filing idempotency under "optimizations for later." In an autonomous loop, retries aren't an edge case; they're the steady state. I'd rather ship an agent with five idempotent tools than fifty tools where three of them can double-charge a customer. If your agent touches anything that mutates real state, this pillar is the entire distance between a retry and an incident.

Why Loop Engineering Is the Moat

Assemble the four pillars and you get a loop that forgets on purpose, stops on evidence, submits to an independent judge, and touches the world through tools that survive being called twice. Now notice what's conspicuously absent from that sentence: the model. Swap the underlying model tomorrow and every pillar still holds, because the pillars are properties of the cage, not the animal.

That's exactly why loop engineering is the moat. Model quality is converging and rentable — anyone can call the same API you can, tonight. The compaction strategy, the four brakes, the maker-checker split, the idempotency layer: that's accumulated engineering a competitor cannot copy by upgrading their model. It's the same lesson as the opening 84%: the gains that matter came from the loop, and loops are built, not rented.

This also reframes the multi-agent question. I argued in multi-agent orchestration that most multi-agent complexity is premature, and the four pillars explain why: a well-caged single loop solves most problems, and parallelism only earns its keep when the work genuinely fans out. When it does, the agent manager patterns are about supervising several of these caged loops, not replacing the cage — each sub-agent still needs its own four pillars.

When You Should Not Build the Whole Cage

Loop engineering has a fixed cost, and the honest trade-off is that the cage is overkill for a canary. If your agent does a single tool call and returns — a chatbot that looks up one order, a three-step deterministic workflow — you don't need a compaction strategy or a maker-checker split. Four pillars around a three-step task is engineering theater.

The cage earns its keep on long-horizon, repeatable, machine-verifiable work: multi-file refactors, migrations, batch processing, anything that runs for tens of iterations unattended.

Two pillars stay non-negotiable even for short loops, the moment real money or real data is involved: stop conditions, so a bug can't loop forever, and idempotent tools, so a retry can't corrupt state. Skip context hygiene and the critic on a five-step read-only loop if you like. Never skip the brakes and idempotency on anything that writes.

My Verdict: Build the Cage This Week if Your Work Is Repeatable

If your agent work has a machine-checkable definition of done and runs long enough to matter, stop optimizing the model and start building the cage — this week. Wire the pillars in order of blast radius: idempotent tools and stop conditions first (they prevent incidents), the maker-checker split next (it prevents confidently wrong output), context hygiene last (it prevents slow quality rot).

Then screenshot the four-question pre-flight and run it before any loop goes unattended: Can it forget? Will it stop? Can something tell it no? Are its writes safe to retry? Any "no" is a gap, and the loop will find it.

The model is water and electricity — cheap, fungible, improving without your help. The cage is the part with your name on it.

Sub-Agent Architecture for AI Coding Harnesses: When to Spawn, How to Route, What It Costs

Bruce He — Sun, 12 Apr 2026 16:46:30 +0000

Originally published at my blog

Sub-agents are not a parallel speed hack. They are a context garbage collection mechanism. The point is to throw noise away, not to split thinking.

Most engineering teams reach for sub-agents the first time they hit a context window limit, or the first time a task feels "big." They fan out, parallelize, marvel at how fast things go — then spend the next month debugging why outputs keep drifting from each other. The failure mode is predictable: sub-agents that should have stayed in the main thread got fired off, and a single decision that needed shared working memory got split across three cold-started processes that never saw each other's evidence.

This article gives you a decision framework, a concrete routing table across Opus / Sonnet / Haiku, and a cost model — so you stop spawning sub-agents by instinct and start spawning them for reasons you can name.

Three Myths That Burn Money

Myth 1: "More sub-agents means faster completion." Every spawn carries cold-start overhead — system prompt re-tokenization, CLAUDE.md reload, tool schemas re-injected. If your sub-agent only does 2,000 tokens of real work, the overhead can exceed the work itself. Break-even sits at roughly 10,000 input tokens per spawn.

Myth 2: "Sub-agents should always use the cheapest model." Route by decision complexity, not input volume. Haiku reading 100K tokens of logs to emit a 200-token classification is great. Haiku writing 2,000 lines of production code is malpractice.

Myth 3: "The orchestrator should be the smartest model." The most expensive mistake. Orchestration is mostly routing and state tracking — Sonnet or even Haiku handles it fine. Save Opus for the final generation step where judgment compounds.

I restructured my own blog pipeline from "Opus orchestrator + Sonnet workers" to "Sonnet orchestrator + Opus writer + Haiku searchers." End-to-end token cost dropped by ~60% and output quality measurably improved, because Opus was finally being used where it mattered.

The Mental Model

A sub-agent is a fresh heap. You fork an isolated process, let it churn through whatever mess it needs (reading 20 files, running grep, inspecting logs), extract a compact summary, and let the whole thing get garbage-collected. The parent agent never sees the mess.

The primary use cases all share one shape: high input, low output, stateless. Codebase search. Doc triage. Log analysis. The sub-agent's job is to summarize and throw away.

Conversely, this framing tells you when not to use a sub-agent. If the "waste" you would throw away is actually load-bearing context the main agent needs downstream, sub-agents cost you more than they save.

Read the full article →

The full version covers:

Three architecture patterns — Fan-Out / Gather, Scout-Then-Act, Specialist Delegation — with mermaid diagrams and concrete failure modes for each
A complete Opus / Sonnet / Haiku routing table with worked examples by task type
A sub-agent cost formula and the 0.3 overhead-threshold metric for when sub-agents actually pay for themselves
Cognition's Devin post-mortem and what it teaches about multi-agent drift
A real 60% cost reduction case study from rewiring my own writing pipeline

This is Part 3 of the Harness Engineering series. Part 1 framed the thesis (Agent = Model + Harness). Part 2 went deep on CLAUDE.md. If you found this useful, the blog has more AI engineering deep-dives.

Claude Pricing 2026: Complete Guide to Free, Pro, Max & Team Plans

Bruce He — Sat, 04 Apr 2026 03:33:13 +0000

Originally published at my blog

Anthropic's Claude has become one of the most capable AI assistants available, but its pricing structure can be confusing. With five consumer tiers, two Max sub-tiers, a Team plan with mixed seat types, and a separate API — choosing the right plan takes real research.

This guide breaks down every Claude pricing option available in April 2026, including exact costs, usage limits, and practical recommendations for different user types.

Quick Pricing Comparison

Plan	Price	Usage vs Pro	Best For
Free	$0	~0.2x	Trying Claude, occasional questions
Pro	$20/mo	1x (baseline)	Daily individual use
Max 5x	$100/mo	5x	Power users, heavy Claude Code usage
Max 20x	$200/mo	20x	Professional developers, near-unlimited
Team	$25-30/seat/mo	1x-6.25x	Teams of 5-150
Enterprise	Custom	Custom	150+ seats, compliance needs

Read the full article →

The full article covers:

Detailed breakdown of each plan's features and limitations
Claude Code pricing (included plans vs API costs)
API token pricing for Opus 4.6, Sonnet 4.6, and Haiku 4.5
Cost optimization strategies for developers
How to choose the right plan based on your usage

If you found this useful, check out my blog for more AI engineering guides.

Harness Engineering: Why the System Around Your AI Agent Matters More Than the Model

Bruce He — Sat, 04 Apr 2026 01:45:58 +0000

Originally published at heyuan110.com

In 2026, the AI engineering community discovered something counterintuitive: the model is the least important part of an AI agent. What actually determines whether an agent succeeds or fails in production is everything around the model — the tools it can access, the guardrails that keep it safe, the feedback loops that help it self-correct.

This "everything around the model" now has a name: the harness. And the discipline of building it is called harness engineering.

OpenAI's Codex team used harness engineering to ship over 1 million lines of production code written entirely by AI agents. LangChain jumped from #30 to #5 on TerminalBench 2.0 by changing only their harness. A Stanford HAI study found harness-level changes improved output quality by 28-47%, while prompt refinement improved quality by less than 3%.

This guide covers:

The three evolutions: Prompt → Context → Harness Engineering
Core formula: Agent = Model + Harness
Guides (feedforward) + Sensors (feedback) framework
Real cases: OpenAI Codex, LangChain, Stripe Minions
5-level practical implementation guide

Read the full article →

If you found this useful, check out my blog for more AI engineering guides.

Seedance 2.0 Deep Dive: ByteDance AI Video That Tops Sora and Veo

Bruce He — Sat, 04 Apr 2026 01:45:38 +0000

Originally published at heyuan110.com

In February 2026, ByteDance released Seedance 2.0. Within weeks, it hit #1 on the Artificial Analysis text-to-video leaderboard — beating Google Veo 3, OpenAI Sora 2, and Runway Gen-4.5 in blind human evaluation.

If you are reading this from outside China, you have probably heard the buzz but face a wall of confusion: What is Dreamina? What is VolcEngine? Can you even sign up without a Chinese phone number?

This guide is written specifically for international users. It covers the technical architecture in depth (why joint audio-video generation is a real breakthrough), gives an honest assessment of what works and what does not, provides a step-by-step access guide, and explains the IP controversy.

Key findings:

Joint audio-video generation produces the most natural lip sync of any model
Multi-reference input (up to 12 files) enables director-level control
2K max resolution is a limitation vs Kling 3.0's 4K@60fps
~$0.14 per 15-second clip — 5-10x cheaper than competitors
CapCut integration gives it the largest distribution platform of any AI video model

Read the full article →

If you found this useful, check out my blog for more AI engineering guides.

DEV Community: Bruce He

Codex App Guide (2026): Setup, Workflows, and Real Pitfalls

What Is the Codex App in July 2026?

From Launch to Merger: Six Months of Whiplash

Installing and Setting Up the Codex App

Core Codex App Workflows: Threads, Worktrees, Parallel Agents

Codex App Pricing: What Every Plan Actually Gets

Codex App vs Codex CLI vs Claude Code

Six Pitfalls That Bite New Codex App Users

The Bottom Line

Related Reading

Claw Code: The Open-Source Claude Code Rewrite That Hit 100K Stars

Claude Code vs Cursor vs Copilot 2026: The Definitive Three-Way Comparison

Claude Fable 5: When the $10/$50 Flagship Is Worth It

Where Fable 5 Lives After July 13

Fable 5 Pricing in Practice: How $10/$50 Becomes $30–100 a Task

The Half-Day Test: Which Tasks Deserve Fable 5

Close Your Unknowns Before You Pay

My Pre-Flight Checklist

What to Remember

Related Reading

What SpaceX's $60B Cursor Acquisition Means for Developers

The SpaceX Cursor Acquisition, Fact-Checked

Why a Rocket Company Buying an IDE Isn't a Joke

Model Neutrality Is the Real Casualty

What Cursor Users Should Do Before the Deal Closes

Who Should Be Nervous: Winners and Losers

Should You Leave Cursor? A Decision Framework

The Bottom Line

Related Reading

MCP vs Skills: Why CLI + Skill Wins the Agent Toolchain

The MCP Architecture Tax: Three Bills That Arrive Before Any Work Starts

Bill one: schema rent, collected every session

Bill two: a measurably dumber model

Bill three: making the model work in a foreign language

One Day, Three MCP Failures: When the Tax Comes Due

The People Who Built MCP Are the Ones Walking Away

Skills Are What Actually Replaced MCP

Where MCP Still Wins: The Honest Counter-Case

Convergence, Not Funeral: Skills on Top, MCP Underneath

A Migration Framework You Can Run This Week

Related Reading

Anthropic's $965B Valuation Is Pricing Agent Infrastructure

The $965B Math: A Doubling Business at a 20x Multiple

The Real Moat: Decoupling the Brain From the Hands

What Managed Agents Actually Ships

Self-hosted Sandboxes: Half-Open, On Purpose

OpenAI's Codex CLI: A Brain With No Hands

What This Changes for You

The IPO Timeline, Minus the Breathlessness

What I'd Do Today

Loop Engineering: Building the Cage Your AI Agent Runs In

Loop Engineering Went From Vibe to Discipline in One Month

Pillar 1: Keep the Context Clean

Pillar 2: Know When to Stop — the Brake Beats the Accelerator

Pillar 3: A Critic That Can Say No

Pillar 4: Tools It Can Actually Use — Few, Focused, and Idempotent

Why Loop Engineering Is the Moat

When You Should Not Build the Whole Cage

My Verdict: Build the Cage This Week if Your Work Is Repeatable

Related Reading

Sub-Agent Architecture for AI Coding Harnesses: When to Spawn, How to Route, What It Costs

Three Myths That Burn Money

The Mental Model

Claude Pricing 2026: Complete Guide to Free, Pro, Max & Team Plans

Quick Pricing Comparison

Harness Engineering: Why the System Around Your AI Agent Matters More Than the Model

Seedance 2.0 Deep Dive: ByteDance AI Video That Tops Sora and Veo