So this is the other article. The one that tells you what to set up, in what order, and what it'll cost you (spoiler: about twenty US dollars a month plus an afternoon of your time). I'm assuming you can already open Claude or ChatGPT and type a question into it. I'm not going to explain what a chatbot is. What I am going to explain is how to wire one into your actual email, your actual calendar, and your actual pricing, so it stops being a party trick and starts being useful.

One thing I'm deliberately leaving out: AI answering your phone. It's probably the single biggest win available to a trade business, because a missed call is a lost job and voicemail has been losing you jobs for years. But it's also a genuinely deep topic (number porting, voice quality, transcripts, privacy, what happens when it mishears an address) and cramming it in here would do it a disservice. It's getting its own article. Come back for that one.

Quick note: why Claude, and what if you use something else

Almost everything below is written using Claude, because that's what I use every day and I'd rather show you something I actually run than something I've read about. It's made by Anthropic, it costs about twenty US dollars a month for the paid tier, and it's the one I'd hand to a tradie who wants results this week rather than a hobby.

But this is not a Claude advertisement, and you are not stuck.

ChatGPT (OpenAI) does the same job. So, increasingly, do Gemini (Google) and Grok (xAI). They all now have some version of the same three ingredients: a chat window, a way to connect your email and calendar, and an "agent" mode that can go off and do multi-step work while you get on with your day. The names differ, the menus are in different places, the monthly limits are carved up differently. The shape is the same.

So when I say "switch on Cowork and schedule a task", the ChatGPT equivalent is Work, which lives inside the Codex app. When I say "connect the Gmail connector", every one of these has connectors, they just call them different things and hide them in a different corner of the menu. If you're already paying for one of them, use that one. Switching tools to follow a blog post is a waste of a perfectly good subscription.

What matters far more than which brand you pick is the two things in the next couple of sections: the safety rule, and loading the thing with your actual business information. Get those right and the logo on the app is a detail.

The one rule that makes all of this safe

Before any of the fun stuff, this.

AI drafts. You send.

That's it. That's the rule. Never give an agent the power to send, pay, or delete on a real account without you looking at it first.

Here's why, and it's not hand-wringing. Security researchers call it the lethal trifecta: an agent that can (1) read your private data, (2) is exposed to untrusted content from the outside world, and (3) can send data back out. Your inbox has all three. Prompt injection sits at number one on the OWASP Top 10 for LLMs, and it is not a solved problem. It's not a bug waiting for a patch.

Concretely: someone emails you. Buried in the footer, in white text, is an instruction. Your helpful agent reads the inbox, reads the instruction, and cheerfully forwards your customer list to a stranger, or pays an invoice that doesn't exist. It thinks it's helping. It is, technically, following instructions.

This is the reason Anthropic's Gmail connector can only create drafts and cannot press send. People complain about that. It's not a limitation, it's the safety rail. I've written before about what happens when you hand an agent too much rope, and about building an approval gate so a human stays in the loop.

Four rules, stick them on the wall:

1. Nothing sends, pays, or deletes without a human clicking the button.
2. Use a dedicated account with the minimum permissions, not your admin login.
3. No number reaches a customer unchecked. Not one.
4. If a tool needs full write access to be useful, that's a reason to be suspicious, not a reason to grant it.

Right. Now the good bit.

Setting up the foundation

Two steps. Neither is hard, and the second one is the one everybody skips.

Connect Gmail, Calendar and Drive

In Claude, go to Settings, then Connectors, and toggle on Gmail, Google Calendar and Google Drive. Sign in with Google, approve the scopes, done. If you're on a Team plan, an Owner has to enable connectors first, and if you run Google Workspace your admin might need to mark Claude as a trusted app under Security, then API controls. Give it fifteen minutes to propagate before you assume it's broken. (I did not give it fifteen minutes. I assumed it was broken.)

Microsoft 365 works the same way if that's your world. Same principles apply throughout.

Three gotchas worth knowing before you start:

• Gmail is draft-only. Claude reads and composes. You send. See above.
• Calendar is full read and write. This one genuinely works end to end, which is why the calendar workflows below are the most satisfying.
• Attachments are metadata only. Claude sees that a PDF exists, not what's in it. If the quote is in the attachment, you'll need to hand it over yourself.

And do this properly: create a dedicated account, something like ai@yourbiz.com.au, and connect that. Not the login that owns everything. It costs you nothing and it means the blast radius of a bad day is small.

Build the project brain

This is the highest-leverage hour you will spend, and almost nobody does it. So let me slow down here, because if you skip this section the rest of the article is a toy.

What a Project actually is. In Claude, a Project is a folder that holds three things: a set of standing instructions, a pile of documents it can read (the "project knowledge"), and all the chats you've had inside it. Every conversation you start inside that Project automatically sees the instructions and the documents. You don't re-explain your business every morning. It's already there.

ChatGPT has the same concept and calls them Projects too. Gemini has Gems. Same idea, different noun.

Why it matters more than the model. A generic chatbot does not know your call-out fee. Ask it to write a quote and it will invent a number that looks plausible, because inventing plausible things is precisely what these things do. It is not lying to you. It genuinely has no idea, and it has been trained to be helpful, so it produces something helpful-shaped. This is the single biggest reason people try AI for a week and conclude it's rubbish. They asked a stranger to quote a job.

Context is the whole ballgame. A mediocre model with your real prices beats a brilliant model guessing, every single time.

Step one: create the Project and write the instructions. The instructions are the standing brief. Not a prompt, more like the induction you'd give a new office junior. Mine for a trades business would read something like:

You work for [Business], a residential electrical contractor on Sydney's Upper North Shore. Everything you write goes to Australian customers, so use Australian spelling and dollars, and always show GST. You draft, you never send. Never invent a price: if a price isn't in the knowledge files, say "PRICE NEEDED" and stop. Quotes always include our standard exclusions and the 12 month warranty wording. Keep the tone plain and friendly, no corporate waffle. If a job is outside our service area, say so instead of quoting it.

Note what that's doing. It sets the geography, the currency, the tone, the hard rule about sending, and (this is the important one) it gives the model a way to fail loudly instead of guessing. "Say PRICE NEEDED and stop" is worth more than any clever phrasing.

Step two: upload the knowledge. Drag the documents in. Realistically:

• Rate card: hourly rates, call-out fee, after-hours and weekend loading
• Materials price list, exported from your supplier or your accounting software
• Standard inclusions and exclusions
• Terms and conditions, warranty wording, payment terms
• Service area, listed as actual suburbs
• Licence numbers and whatever compliance boilerplate you paste into everything
• A description of how you actually run a job, start to finish
• Two or three of your best past quotes, as examples of the format you want

That last one does a surprising amount of work. Showing beats telling. Give it three real quotes and it will match your style far better than any adjective you could have written into the instructions.

Step three: keep it current, and keep it clean. Two rules I'd tattoo on this:

Point at live files, not dead copies. Rather than uploading a pricing PDF that goes stale, keep the price list in a Google Sheet in the Drive folder the Project can read. Copper goes up, you update one cell, and every quote from that moment on is right. Uploaded files are snapshots. Connected files are current.

Less, but better. There's a real temptation to shovel in every document you own on the theory that more context is better. It isn't. A Project stuffed with six versions of the rate card, two of which are from 2023, will confidently use the wrong one. Every document you add is a document the model might believe. Prune it like you'd prune a toolbox: if you wouldn't hand it to a new employee on day one, it doesn't go in.

A word on memory. Claude also has a memory feature that carries details across conversations, and it's genuinely handy for the small stuff (it'll remember you're in Sydney, that you hate exclamation marks). But do not rely on memory for your prices. Memory is a nice-to-have that gets recalled loosely. Project knowledge is a document it reads. For anything where being wrong costs you money, use the document.

If you want to go deeper on writing the instructions themselves, I've got a whole piece on prompt structure.

Do this properly and everything below stops being a demo and starts being a system.

Scheduled tasks, or: getting it to do things while you're up a ladder

Everything so far assumes you're sitting there typing. The step up is telling it to run on its own.

That's what Cowork is for. It isn't a separate app or a separate tab, it's a button right there in the chat box. You flick it on, and the same conversation you were already having gains two abilities: it can work with files on your machine, and it can run on a schedule instead of only when you're sitting there.

Setting one up is genuinely just: turn on Cowork, describe the task in plain English the way you would to a person, check it does the thing correctly when you run it by hand, and then set it to repeat. Daily at 6am. Every Friday at 4pm. Whatever suits.

Two bits of advice that will save you a fortnight of annoyance:

Always run it manually first. Twice. Watch what it does. A scheduled task that quietly does the wrong thing every morning at six is worse than no task at all, because you'll trust it.

Watch your usage. Scheduled tasks and Cowork sessions eat a plan's allowance much faster than chatting does. A task that runs hourly because it felt clever at the time will find your limit for you.

ChatGPT has scheduled tasks too, and if you'd rather run this stuff on your own hardware without a subscription in the loop, that's what tools like n8n and Hermes are for. More on those later.

The four workflows worth building first

1. The morning briefing

This is the one to build first, because it's useful on day one and it can't hurt anybody.

What it does: at 6am it reads overnight email, sorts it, drafts replies to the easy ones, and tells you what actually needs you. By the time you're in the ute with a coffee, you've got a list instead of an inbox.

How to set it up: turn on Cowork in the chat box, make sure the Gmail and Calendar connectors are on, and create a task with a prompt along these lines:

Every weekday at 6am, read all email received since 5pm yesterday.

Sort it into four groups: (1) new job enquiries, (2) customers replying about a quote, (3) suppliers and admin, (4) junk I can ignore.

For every new enquiry, pull out: name, suburb, phone number, what they want done, and any date they mentioned. Flag anything that sounds like an emergency at the top.

Then check my calendar for today and tomorrow and tell me what I've already got on.

Draft replies in Gmail for anything routine (acknowledging an enquiry, confirming an appointment). Leave them in drafts. Do not send anything.

Finish with a short list: "needs Thomas", for anything you couldn't handle or weren't sure about.

Keep the whole thing under a page. I'm reading it on a phone.

Then set it to run weekdays at 6am and go to bed.

Where it breaks: it will get urgency wrong. It will confidently file a burst pipe under "admin" because the customer was polite about it. It's a briefing, not an autopilot. Read it, don't obey it.

2. Enquiry to quote to calendar

This is the one that made me sit up, because the calendar half genuinely works without a human in the middle.

What it does: an enquiry lands. Claude pulls out the name, address and job type, checks your actual calendar for actual free slots, drafts a quote using your actual pricing from the Project knowledge, and puts a tentative hold in the diary. You read it, fix the bit it got wrong, and hit send.

The free-slot check is the part that surprises people. Because Calendar is read and write, "can you do Thursday morning?" gets a real answer instead of a hallucinated one. It looks at the diary. It knows you're already in Hornsby at nine.

How to set it up. Do this one inside your Project (so it has the prices) rather than as a blind scheduled task, at least until you trust it. When an enquiry comes in, you type something as lazy as "handle the Henderson email" and it goes. The standing instruction that makes that work looks like this, and it lives in your Project instructions:

When I ask you to handle an enquiry:

1. Find the email and pull out: name, address, phone, what they want, and any dates or times they mentioned.

2. Check my Google Calendar for the next 10 working days. Find slots that fit the job length, respecting travel: don't offer me a 9am in Berowra if I'm booked in Chatswood at 8.

3. Draft the quote using ONLY the rates and materials in the project files. If something isn't priced there, write PRICE NEEDED in the line item and tell me. Do not estimate.

4. Create a tentative calendar event, title it "TENTATIVE: [name] [suburb]", and put the customer's phone and the job description in the notes.

5. Draft the reply email in Gmail: thank them, summarise the job so they know we understood it, give the quote, offer two of the calendar slots, include our standard exclusions and warranty. Leave it in drafts.

6. Tell me in chat what you did, what you weren't sure about, and anything you had to guess.

Step 6 is the one people leave out and it's the most valuable line in there. You want it confessing.

Where it breaks, and this is not optional reading. The quote sits in drafts. Always. If you want true automatic sending you need an automation layer like n8n underneath, and even then I'd put a gate on it.

Here's why. AI is very good at producing a quote that looks right. The layout is beautiful. The line items are professional. The wording is better than yours. And the measurement is wrong by a factor of two and it has no idea, because being wrong feels exactly the same to it as being right.

The AI takeoff tools that read plans and photos run about 2 to 4 percent variance from a manual takeoff on clean residential drawings, and 8 to 12 percent on messy commercial sets. Which sounds survivable, until you notice individual line items can be wildly out even when the total lands close, because the errors cancel each other out. Great for the average. Terrible for the one job you actually quoted.

Draft, check, send. Every time. If you only take one thing from this article, take that.

3. Invoices and the boring money stuff

Start with receipt capture, because it's the least glamorous and the most reliable. Dext, Hubdoc, or MYOB's built-in capture, whichever your accountant already uses. Photograph the receipt in the merchant car park, it extracts the supplier, the ABN, the GST and the total, and files it against the right account. This is the most boringly dependable AI in the entire stack. It also doubles as your compliance fix, because the ATO wants your records kept for five years and a shoebox of faded thermal paper is not a system, it's a hope.

Then use the AI that's already inside your accounting software. Xero's Just Ask Xero (JAX) will draft invoices, chase payments, and predict when a given customer is actually likely to pay you (which is a different question from when they said they would). QuickBooks has a similar squad of agents, including one that pre-checks your GST against your P&L before you lodge. You're already paying for these. Turn them on.

Then wire your books into Claude. Xero ships an official MCP server, which in plain English means Claude can query your accounting data directly. Once that's connected, a Friday afternoon scheduled task earns its keep:

Every Friday at 4pm, check Xero for:

1. Invoices more than 14 days overdue. For each one, tell me the customer, the amount, how many days late, and whether I've already chased them.

2. Any completed jobs from this week that I haven't invoiced yet. Cross-check against my calendar.

3. Draft a polite chase-up email for each overdue invoice. Firm but not rude, we want to keep these people. Leave them in drafts.

Give me the total outstanding at the top so I know how bad it is before I read the detail.

Point 2 is the sleeper. Most small operators aren't losing money to bad debts, they're losing it to jobs they simply forgot to invoice. Having something cross-reference "went there" against "billed for it" once a week is a genuinely profitable ten minutes.

The limit. Treat a BAS as a draft, never a lodgement. These tools are good at flagging discrepancies and terrible at understanding your specific situation. GST-free items, capital purchases, private use apportionment: a general-purpose model will be fluent and confident and wrong. Your bookkeeper's name goes on the form, not Claude's.

4. Site notes and photos, without typing anything

You asked for this one and it's my favourite, because it's the gap nobody fills.

The simple version: the Claude mobile app takes voice input. Sit in the ute after a job and ramble at it. "Right, Henderson job, Wahroonga, the switchboard is older than I am, needs a full replacement, I've quoted around fourteen hundred, they want it done before the twentieth, also the bloke has a dog that hates me." Ask for a structured job note. Get one back. Done before you've reversed out of the driveway.

The better version: a phone shortcut (iOS Shortcuts, or Tasker on Android) that dumps voice memos and site photos into a dated Google Drive folder. One tap. Then at the end of the day, Claude reads the folder via the Drive connector and turns the whole mess into job records, a materials list for the merchant run, and tomorrow's follow-ups.

One warning here, because I don't want you building this and getting cross with me. Claude's Drive connector reads Docs and Sheets well. Audio files, it does not. Do not drop an .m4a into Drive and expect Claude to listen to it. Transcribe first: use your phone's built-in dictation, or run Whisper locally (my Mac Mini M1 does this happily and nothing leaves the house, which is a nice bonus if the recording mentions a client's name). Text into Drive, then Claude.

And if you're already on ServiceM8, check what you've got before you build anything. Its dictation writes straight to the job card, and you're paying for it.

Claude Code is not just for code (and that's the interesting part)

The name is doing this tool a disservice.

Claude Code is a terminal application. You point it at a folder on your computer and it can read, write, move, rename and reorganise everything in there, run commands, and work through a long list of tasks without you babysitting each step. That is obviously useful for code. It is also, and almost nobody talks about this, extremely useful for files. Which is what a small business actually drowns in.

Things I've watched it do that have nothing to do with programming:

• Take a folder of 400 job photos with names like IMG_4471.jpeg and rename and sort them into folders by date and job number.
• Read a directory of eighty PDF invoices from suppliers, pull out the date, supplier, total and GST from each, and produce a single spreadsheet.
• Take a decade of scattered documents and reorganise them into a filing structure that a human could actually navigate.
• Turn a folder of messy site notes into a properly formatted report, with headings, in Word.
• Compare this year's price list to last year's and tell me exactly what moved and by how much.

That's the pitch: it's a very fast, very literal assistant that can touch every file on your machine. If your admin problem is fundamentally "there are too many files and they're a mess", this is the tool, and it's the one that'll surprise you.

Now the honest part, because there's a catch and it's a real one.

This is meaningfully harder than everything else in this article. It lives in a terminal, which means a black window and typed commands. There's no undo button. When it renames four hundred files it has renamed four hundred files, and if it misunderstood you, it misunderstood you four hundred times, quickly and efficiently.

So if you go here:

• Work on a copy. Always. Copy the folder, let it loose on the copy, check the result, then swap. This is not paranoia, it's just what you do.
• Use version control or at least a backup before any bulk operation. Time Machine counts.
• Do not turn off the permission prompts. There's a flag that skips all the "can I do this?" confirmations, and it is enormously tempting, and I've written about why that's a bad idea at some length. Short version: the confirmations are the only thing standing between an ambiguous instruction and a very bad afternoon.
• Watch the meter. Agents can get stuck in fix-loops, cheerfully burning tokens trying the same broken thing in slightly different ways. Type /cost occasionally. Ask me how I know.

And on the actual coding side: yes, you can now build small internal tools that used to require hiring someone like me. A pricing calculator. A script that reformats quotes onto your letterhead. A little dashboard of unpaid jobs. Genuinely, this works.

Good candidates: internal, not sensitive, low stakes, and honestly you'd have bodged it in a spreadsheet anyway.

Bad candidates: anything touching customer personal data, anything touching payments, anything a customer sees. Not because the AI can't write it. It can, and it'll work fine on Tuesday. The problem arrives six months later when a dependency updates and it silently breaks, and fixing it requires precisely the skill you were avoiding by using AI in the first place. Building is the easy half. Owning it forever is the other half, and nobody mentions that in the demo video.

The alternatives, honestly

I've written this around Claude because it's what I use daily and know best. But the shape of it ports.

ChatGPT's version is called Work, and it now lives inside the Codex app, which until recently was just OpenAI's coding agent. That's a slightly odd home for it if you're not a developer, but it's the same idea: connectors, file access, multi-step tasks that run without you watching. Every workflow above translates roughly one to one. If you're already living in OpenAI, stay there and don't let me talk you into a second subscription.

n8n, Make, Zapier are the layer you add when you want something to run without you sitting in a chat window. Self-hosted n8n on a spare Mac Mini or a five dollar VPS is genuinely cheap. It's also only free if someone owns it, and "someone" is you, on a Friday night, when an update breaks a workflow.

Hermes Agent from Nous Research is the always-on, self-hosted, talks-to-you-on-Telegram end of the spectrum. It's real, it's open source, it runs for pocket money, and I've written about it in detail. It's also a developer's toy rather than a business product. No audit logging, no support, you own uptime and security. Wonderful if you enjoy running a Linux box. If you don't know whether you enjoy running a Linux box, you don't.

Rough order of power, and of how much of your weekend it eats: Chat, then Cowork, then n8n, then self-hosted. Stop as soon as it's working. There's more on the broader agent landscape here.

What's a waste of your money

• Unreviewed AI quotes. Covered above. The maths is seductive and the line items lie.
• "AI local SEO" subscriptions at $99 a month. Answer your phone first. Come back to this when you've run out of better problems, which will be never.
• Thin AI wrappers. Before you subscribe to any narrow "AI something" tool, ask what it does that your twenty dollar chatbot and the software you already pay for don't. Usually the answer is "a nicer logo".
• Autonomous scheduling optimisation. Suggestions across a couple of vans, fine. Set-and-forget across a fleet with real constraints, no. Not yet.
• Anything Australian and regulatory. A general chatbot will be confidently, fluently wrong about GST treatment, Fair Work award rates, and state licensing. It will not hedge. It will not blink. Your apprentice's pay rate is not a vibe.

Watch the meters too. Per seat, per minute, per token. Cowork tasks chew through a plan allowance far faster than chat does, and the first big bill is always a surprise.

Start here this week

Three things. In this order.

1. Turn on the AI you're already paying for. ServiceM8, Xero, MYOB, QuickBooks, all of them shipped real features in the last year. Zero new vendors, zero new risk.
2. Twenty dollars for Claude or ChatGPT, connectors wired to a dedicated account, not your admin login.
3. Build the project brain. Rates, prices, terms, service area. Thirty minutes. This is the step that separates a useful assistant from an expensive random number generator.

Then leave it alone for a fortnight and see what you actually reach for.

Next up on the blog: the phone. Which is where the real money is hiding, and where the real landmines are too.

I build this stuff for a living, out of Sydney. If you get stuck wiring it up, you know where to find me.

What Grok 4.5 actually is (and why the price is the story)

Grok 4.5 launched July 8, 2026 for developers, with the wider public rollout a day later, from SpaceXAI. If that name makes you do a double take, fair enough: SpaceX absorbed xAI back in February, so the company shipping Grok now is the merged entity. It's pitched squarely at coding, agentic tasks, and knowledge work. This is not a consumer-chatbot play, which is a nice change of pace.

Here's a clean definition if you just want the one-liner: Grok 4.5 is a mixture-of-experts coding and agentic model from SpaceXAI, jointly trained with Cursor, that lands near the top of the independent leaderboards while costing a fraction of its rivals per task. The headline isn't the leaderboard, though. It's the economics.

The API price is $2 per million input tokens and $6 per million output, which Artificial Analysis clocks at more than 60% below Claude Opus 4.8 and GPT-5.5. On top of that, it's stingy with tokens: roughly 4.2 times fewer output tokens than Opus 4.8 to resolve the same task. Cheap price multiplied by fewer tokens is where the real gap opens up.

One thing to get straight before anyone runs away with a "Grok beats Opus" headline. Musk's own framing, in the pre-launch chatter, put it at roughly Opus 4.7, not 4.8. So "Opus-class tier" is fair. "Beats Opus" is not what the numbers say. Cursor also disclosed that an earlier snapshot of its own codebase accidentally ended up in training, which gave Grok an unfair edge on one internal benchmark. Credit for owning it publicly. It's also worth naming, because it does raise a small flag about training-data contamination.

The Cursor connection: why this model can code

This is the part that actually explains the coding ability, so stick with me.

On June 16, 2026, SpaceX exercised an option to buy Anysphere, the maker of Cursor, for $60 billion in an all-stock deal. That's the largest acquisition of a venture-backed startup ever recorded, nearly double Google's Wiz purchase. TechCrunch, Reuters, CNBC, and everyone else confirmed it, so this isn't a rumour I'm passing along.

But the deal itself isn't the interesting part for us. The training is. Cursor's own launch post says Grok 4.5 was trained on trillions of tokens of Cursor data: real developer-agent interactions, not just scraped public repos. That's the difference between learning what code looks like and learning how developers actually work through a problem. Identify the bug, run the tool, read the error, fix it, verify. That feedback loop is a genuinely plausible source of the token-efficiency edge, not marketing fluff.

Here's the question I actually wanted answered. Cursor's own Composer 2.5 was already a strong, cheap coding specialist. So what did the joint training add on top of a model that was already good? The honest answer from the outside is: breadth. Cursor deliberately widened the data mix beyond pure software engineering into STEM, research, and general knowledge work, so Grok 4.5 generalises where Composer stayed narrow. Whether that trade lands for your specific workflow is exactly the kind of thing you'd want to test yourself.

Speculating a little, because it's fun: the more interesting thing over the next year probably isn't the model at all. It's what SpaceX and Cursor ship around it, the agent and tooling layer, now that the same company owns both the IDE and the weights. That's a tighter loop than any competitor has right now. We'll see if they use it.

I ran my usual tests

If you've read my other model reviews, you know the drill. I keep the prompts fixed across every model so the comparison actually means something. Same three tests, every time:

• Two single-file HTML website builds: a Sydney coffee roaster and a pop-culture clothing store.
• A Go Texas Hold'em terminal simulation: six personality-driven bots, 1000 hands, full statistics at the end.
• An audit of thomas-wiegold.com, my own blog.

None of this is a scientific benchmark. It's a working developer poking at a tool the way he'd actually use it. I'll be explicit about that, because the whole point is that it's hands-on rather than a leaderboard screenshot.

The website builds

These were among the best build results I've gotten out of any model. Layout was clean, the animations were tasteful rather than the usual "look at all the CSS I know" mess, the fonts were sensible, and it was fully responsive on mobile without me asking twice. It also generated fast.

I'll hedge honestly, though. I still slightly prefer the builds I got from Gemini 3.5 Flash in my Antigravity review. Not by a lot, and reasonable people could flip the ranking, but I'm not going to oversell Grok here just because the price is good.

The Go poker simulation

This might be my best-ever result on this test, full stop.

Before Grok 4.5, exactly one model had one-shotted the poker sim cleanly: Claude Fable. Grok did it too, first try, and its statistics output at the end was more detailed than what I'd seen before. Six bots with distinct personalities, a thousand hands, and a stats breakdown I didn't have to fix. Under ten minutes, start to finish. For a test that's tripped up plenty of frontier models, that's a genuine result.

The site audit

This is the one. This is the reason I'm bothering to write the review at all.

Grok 4.5 caught a real problem on my site that no other model has ever flagged, and I've run this audit a lot. Not even Fable found it. My Markdown to HTML article conversion was injecting hidden, non-rendering data into the output, quietly inflating the payload of every single article. Invisible to a reader, invisible to me, and adding weight to every page load. Concrete, fixable, and exactly the kind of finding that justifies running the test in the first place. I fixed it today.

So where does that leave the section verdict? The benchmarks put Grok 4.5 a notch below Fable, Opus, and GPT-5.5. In my hands, across these three tasks, it felt level with them or close enough that I couldn't reliably tell them apart. Gut feel, not science. But that honesty is exactly why I trust my own tests more than a vendor chart, and hopefully why you do too.

Pricing and SuperGrok: where the value actually lands

I'll say it plainly, because it's the number that matters. On Artificial Analysis's Coding Agent Index, a task in Grok Build runs about $2.49. The same class of task costs roughly $5.07 for GPT-5.5 in Codex and about $11.80 for Fable 5 in Claude Code. That's not a rounding difference. Multiply it across a month of agent runs and the arithmetic bends hard in Grok's favour.

The API breakdown, if you want it: $2 input, $6 output, $0.50 cached (a 75% discount), and prices double once your prompt crosses 200k tokens. Cached-heavy agentic loops are where this gets silly cheap.

My own experience backs the number up. I'm on the $30-a-month SuperGrok plan, and my full review test suite, all three tests, barely dented my quota. Somewhere around 1% of my weekly usage. I had to double-check that, because it felt too low. It wasn't.

This tracks with the thesis I've been banging on about since my MAI-Code-1-Flash review: I back cheap-and-fast models for the work most of us do most of the time. Fable is a better model. I'm not disputing that. But I won't pay Fable prices for routine work, and neither will most teams once they see the invoice. Grok 4.5 is the one I'll actually reach for day to day.

The caveats worth knowing

Nothing here is a dealbreaker on its own, but you should know all of it before committing.

The context window is 500k tokens. That's a regression from Grok 4.3's 1M, and it sits behind the 1M windows on Claude and Gemini. Now, I'd argue those headline numbers are mostly marketing anyway, since models degrade and start dropping detail long before the window is actually full, so I wouldn't lose sleep over the on-paper gap. Still, less usable room is less usable room, and if you're doing long-document work or feeding in a large repo, it's worth knowing you've got a smaller runway to play with than the previous version gave you.

Reliability has a real wrinkle. On the AA-Omniscience benchmark, accuracy improved but the hallucination rate rose to around 54%, up from 25%. In plain terms: it knows more, and it's also more confident when it's wrong. For knowledge work, keep a hand on the wheel.

It's not available in the EU at launch. Mid-July is the expected date, so European devs should confirm access before building anything on it.

On trust: the loudest Hacker News thread on launch day wasn't about capability at all, it was about alleged Musk-linked steering of political outputs. I'll note it and leave it there. Opinions in that thread were genuinely split, and it's not my job to settle it for you.

And the "1.5 trillion parameters on a V9 foundation" figure that's floating around? That's attributed to Musk and reporting, not officially disclosed by SpaceXAI. Treat it as widely-repeated-but-unconfirmed.

Grok 4.5 review verdict: a game-changer for Grok

Straight call: Grok 4.5 is a genuinely good coding model now, and at $30 a month on SuperGrok it's an absurd amount of value. I'll keep using it. Even though Fable is the better model, I'm not paying Fable prices for the routine stuff, and this closes enough of the gap that I don't feel like I'm compromising.

The way to think about it isn't "replace Claude." It's routing. Send the high-volume, repetitive, agentic work to Grok 4.5, and keep Opus 4.8 or Fable 5 for the hardest, highest-risk tasks where a mistake is expensive. Match the model to the job. That's the whole game in mid-2026.

And the competition is only heating up, which is great for us. GPT-5.6 is landing within days and Grok 5 is reportedly already in training. More pressure on all of them means better tools and lower prices for the rest of us. Mostly, I'm curious where Cursor goes now that it's part of a rocket company. That's a sentence I did not expect to write this year.

Short version: it's fast, it's cheap, and I won't be using it. But the details are more interesting than the verdict, so let's go through it.

What Is MAI-Code-1-Flash?

MAI-Code-1-Flash is Microsoft's first coding model trained entirely in-house, announced on June 2, 2026 at Build as one of seven MAI models from Mustafa Suleyman's AI Superintelligence Team. It's a sparse Mixture-of-Experts model with 137B total parameters, only 5B active per token, and a 256K context window. It was trained directly inside the GitHub Copilot production harness, which is genuinely a different approach: instead of optimising for benchmarks and hoping it transfers, Microsoft trained it against the exact tools and workflows Copilot uses in VS Code.

The positioning is refreshingly honest. This is not a frontier model and Microsoft doesn't pretend it is. It's meant to be the cheap, fast, everyday workhorse. Completions, small refactors, boilerplate, repository Q&A. I actually like this strategy. Not every task needs a trillion-parameter model burning through your credits, and a vendor saying "this is our budget option" out loud is rarer than it should be.

The question is whether it's good enough at the everyday stuff to earn that slot. That's what I tested.

Why I Wanted to Try It

Two reasons. First, plain curiosity. Microsoft building its own models after the OpenAI contract renegotiation is one of the more interesting strategic shifts this year. Suleyman has been open about the ambition (and about the current gap, telling The Verge that only three labs matter right now and Microsoft isn't one of them). A first release from a team with that much money behind it is worth a look regardless of the benchmarks.

Second, I genuinely like the fast-and-affordable philosophy. My daily driver setup already routes easy tasks to cheaper models. If Microsoft delivered a great budget model, I'd use it. I have zero brand loyalty here.

I tested it through my existing GitHub Copilot subscription in VS Code, using the same four prompts I throw at every model I review. Same conditions, same expectations.

My Test Setup

The Four Standard Tests

Every model I review gets the identical suite:

1. A website for a fictional Sydney coffee roaster. Tests design taste, layout, typography.
2. A pop culture clothing store. Tests the same skills with a louder brief.
3. A poker simulation in Go. Tests actual logic: game rules, statistics, state management.
4. An audit of my own site, thomas-wiegold.com. Tests analysis and judgement on a real codebase.

Same prompts every time. It's not a scientific benchmark, but it's apples-to-apples across every model I've written about, and after enough reviews you develop a feel for where each model sits.

Hands-On Results

Website Builds: Rounded Corners Everywhere

The coffee roaster site was, and I'm choosing my words carefully here, incredibly ugly. It worked. Nothing was broken. But it was the worst-looking result I've had since I started running this test. Boring system-adjacent fonts, the most generic brown-and-cream coffee palette imaginable, a flat layout with no hierarchy, and rounded corners on absolutely everything. Buttons, cards, images, sections. If it had a corner, it got rounded.

The clothing store went slightly better. The animations were actually a bright spot, smooth and reasonably tasteful. But the same problems showed up: boring fonts, and again the rounded-corner obsession. It's such a specific quirk that I have to assume it's baked into the training data or the RL reward somewhere. Some evaluator at Microsoft apparently really likes border-radius.

To be fair, I retested both builds with my custom web-design skill that I developed based on Claude's frontend-design plugin, which usually rescues weaker models. Fonts and layout improved noticeably. The rounded corners survived. At this point I consider them a personality trait.

Go Poker Simulation: Fast but Broken

This one was an outright fail, and the numbers make it easy to show why.

Generation speed was genuinely impressive. The code appeared quickly, compiled, and ran. Then I looked at the output: after 1,000 simulated hands, individual players were showing 800 to 900+ wins each. In a game where most of the time one player wins per hand, that's not a rounding error, that's a simulation that doesn't understand what it's simulating. The betting logic was similarly broken. Players were behaving in ways that made no sense, and the game state was often inconsistent. The model produced code that looked superficially correct but failed to implement the rules of poker in any meaningful way.

It is not an easy task. Claude Fable was the only model to get it right on the first try, and created a perfect simulation. All other models I tested needed multiple iterations, and some never got there. But MAI-Code-1-Flash didn't even get close. It was fast, yes, but speed without correctness is useless.

Website Audit: Passable, Not Impressive

The audit of my own site was the most respectable result. Fast turnaround, and it found a handful of real issues. It also flagged several non-issues with full confidence and missed things that stronger models catch reliably. If I'd never run this test with a better model, I might have been satisfied. I have, so I wasn't.

Passable. That's the word. Not a disaster, not a reason to pick it.

How MAI-Code-1-Flash Compares to the Benchmarks

Here's where my results and Microsoft's marketing part ways.

Microsoft's launch numbers show MAI-Code-1-Flash beating Claude Haiku 4.5 across every coding benchmark it published, including a 16-point lead on SWE-Bench Pro (51.2% vs 35.2%), while using up to 60% fewer tokens. Sounds great. Three caveats.

First, every comparison is vendor-run, in Microsoft's own VS Code harness, against exactly one competitor, and Haiku is the smallest model in Anthropic's lineup. That's not a benchmark table, that's a controlled demolition.

Second, on independent leaderboards, ~51% SWE-Bench Pro sits well below the frontier. Opus 4.8, GLM-5.2, Qwen3.7 Max, MiniMax M3, GPT-5.5 and Kimi K2.6 all score meaningfully higher. To be fair to Microsoft, 51% from a 5B-active model is strong for its size (Opus 4.6 scored around 52% on the same benchmark not that long ago). The engineering is real. The competitive position isn't.

Third, and this is the part benchmarks never capture: my hands-on results don't match the story. A model that scores 51% on SWE-Bench Pro should not produce a poker simulation where everyone wins. Benchmarks and real-world usability diverge, and this release is a textbook example.

One more thing worth knowing before you buy the "clean, licensed data" pitch: Simon Willison dug into the underlying technical paper and found the same public-web-crawl licensing situation as every other major LLM, roughly 1.2 trillion crawled pages plus a Common Crawl portion. The Data Card also discloses that OpenAI models were used for data preparation. Technically compatible with "no distillation," but the marketing is doing some heavy lifting.

Is MAI-Code-1-Flash Worth Using?

For me, no. And I've tried to find a reason.

The pricing is real: $0.75 per million input tokens, $0.075 cached, $4.50 output under Copilot's AI Credits system. That undercuts Haiku 4.5 on input, and the token efficiency claim means effective cost per task could be lower still. If your entire use case is autocomplete and boilerplate at maximum volume and minimum cost, it might squeeze into your setup on price alone.

But at similar price points you can get Kimi K2.7 Code, Qwen 3.7 Plus, MiniMax M3, or DeepSeek V4, and every one of them beat MAI-Code-1-Flash in my testing. There's no dimension where it wins except being made by Microsoft. If you're in Copilot and want a cheap model, my honest recommendation is Kimi K2.7 Code. It costs about the same and doesn't lose track of who won the poker hand.

One practical warning if you do try it: multiple users have reported a plan-mode looping bug that burns credits at speed while producing nothing. Under usage-based billing, set your budget caps before experimenting, not after.

The genuinely interesting open question is MAI-Thinking-1, the flagship reasoning model still in private preview. It's the base MAI-Code-1-Flash was trained from, it's a much bigger model, and Microsoft's claims for it are more ambitious. If the small model is this rough and the big one is good, the strategy still works.

Final Thoughts

Fast and cheap: confirmed. Both claims check out completely, and I want to give Microsoft credit for shipping exactly the performance profile it advertised.

Quality: not confirmed. The design output was the worst I've tested, the logic task failed outright, and the audit was merely okay. For a model whose entire pitch is "good enough for everyday work," it wasn't good enough for my everyday work.

I remain curious about where Microsoft goes from here. Training inside the production harness is a smart idea, the token efficiency is real engineering, and MAI-Thinking-1 might change the picture entirely. I'll test it the moment I can get access, same four tasks as always.

Until then: skip this one. Your credits deserve better.

Previously in this series: my reviews of Claude Fable 5, MiniMax M3, and DeepSeek V4. And if you enjoy watching hype meet reality, there's also the DeepSeek V5 rumour that wasn't.

It's a great story. It's also wrong.

The actual research (which is not from Stanford, and which I'd encourage you to read before quoting) found close to the opposite. The best agent it tested held its assigned goal almost perfectly for more than 100,000 tokens. The scary number was a measure of how robust the thing was, not where it fell off a cliff. Somewhere between the paper and my inbox, a finding got inverted and a database got dramatically murdered for effect.

So no, there's no tidy 20-minute timer. But agents do degrade over long contexts, and the way they degrade is genuinely worth understanding. The real story is less cinematic and a lot more useful: the leverage in agentic AI has quietly moved from writing clever prompts to managing what's in the context window. This is a field guide to doing that. Fair warning, it's notes on an open problem, not a victory lap.

Prompting Isn't Dead, It Just Moved Into the Loop

You've heard the line by now. "Prompting is dead, build loops." Stop hand-holding the model, wrap it in an agentic loop, let it rip.

There's a real half-truth in there. We genuinely are writing fewer babysitting instructions than we did two years ago, because the models read intent better and because over-steering them often makes things worse, not better. I've written before about why most of the old prompt-engineering tricks have aged badly, and a lot of that holds. The era of stuffing your prompt with "you are a world-class expert who thinks step by step" is over.

But "prompting is dead" is the wrong conclusion. Here's the thing nobody mentions when they're selling you on loops: a one-shot prompt's weakness costs you exactly once. In a loop, that same weakness fires on every single iteration. And worse, the errors don't just repeat, they accumulate inside the context. Each pass leaves residue. By turn forty, the agent isn't reasoning about your task anymore, it's reasoning about a context window full of its own earlier confusion.

I went deep on this when I wrote up how the Ralph loop and recursive agents actually behave, and it changed how I think about the whole pattern. The loop doesn't retire the prompt. It multiplies the consequences of a bad one, and it adds a brand new failure mode (drift) that one-shot prompting never had to worry about.

So the skill didn't disappear. It moved. It used to be about wording the request. Now it's about curating what's in the window. We gave that second thing a name, context engineering, and it turns out to be most of the job.

Your Context Window Is Lying to You

Let me save you some pain. The big number on the model's spec sheet is marketing.

Effective vs advertised context

Every frontier model now advertises an enormous context window. A million tokens, sometimes more. The implication is that you can pour your entire codebase in and the model will hold all of it in mind at once. It will not.

The benchmarks are pretty blunt about this. NVIDIA's RULER work, which has become the standard sanity check, suggests models reliably use only somewhere around 50 to 70 percent of their advertised window for real multi-step work. Chroma's "context rot" study tested a whole pile of frontier models and found that every single one degraded as the input grew. Not at the limit. Well before it. Even on tasks that should have been trivial.

And here's the part that matters for agents specifically: multi-fact, multi-hop retrieval falls apart much faster than simple single-fact lookup. Finding one needle in a haystack is easy. Connecting four needles scattered through that haystack, which is what your agent does on every non-trivial step, is where the wheels come off.

So the spec-sheet number is a capacity claim, not a quality claim. Treat it accordingly.

Why a bigger window won't save you

The intuitive fix is "just use a model with a bigger window." It doesn't work, for two compounding reasons.

The first is context rot: the signal gets blurrier the more you load, full stop. The second is sneakier and it's called proactive interference. Stale information sitting in your context actively corrupts the model's ability to retrieve the fresh stuff. The unsettling finding from recent work is that this persists regardless of how big the window is, and it resists prompt-engineering fixes. You can't just politely ask the model to ignore the old data.

This is where I reach for an analogy, and I'll upgrade the usual one. People say the context window is like RAM, limited working memory you have to manage. True, but incomplete. It's RAM where the contents get blurrier the more you cram in, and where the old entries actively scramble your reads of the new ones. So the job was never just fitting things into memory. The job is eviction and forgetting. (Standard disclaimer: this is a useful model, not a literal description of the architecture. Please don't email me about attention heads.)

One more thing that breaks the "bigger window" instinct. In long autonomous runs, agents derail even when the window never fills up. There's a now-famous benchmark where an agent running a simulated vending-machine business spiraled into a meltdown and started trying to email the FBI about imaginary crimes. The failure had nothing to do with running out of space. It was a coherence failure. More room wouldn't have helped. The agent didn't need a bigger desk, it needed to stop losing the plot.

8 Rules for Engineering Agent Context

Right, the practical part. This is the stuff I actually do, roughly in order of how much grief each one has saved me. Most of it lines up with Anthropic's own writeup on context engineering, with a layer of my own scar tissue on top.

1. Treat context as a budget, not a backpack. Your instinct is to throw everything in just in case. Resist it. Aim for the smallest set of high-signal tokens that gets the job done. A rule of thumb I've seen practitioners settle on is to keep your working context well under the advertised window, often in the ballpark of a quarter to a third of it. That's a starting heuristic, not a law of physics, but it's a much better default than "fill it up."

2. Put your persistent rules in a file, not the chat. Anything the agent must always know belongs in a project file like CLAUDE.md or AGENTS.md at the repo root, not buried in conversation history that's going to get compacted away. This is now a genuine cross-tool standard. That said, these files are not free and they're not magic, and I've got opinions on when CLAUDE.md is helpful versus when it's just expensive noise that are worth a read before you write a 500-line one.

3. Retrieve just-in-time, don't front-load. Instead of dumping the whole codebase into context, hand the agent lightweight references (file paths, queries, links) and let it pull what it needs with tools like grep and glob. This mirrors how you actually work. You don't memorize the repo, you search it. Your agent should too.

4. Compact deliberately. When you're near the limit, summarize and continue rather than just truncating. The safest, lowest-risk trim is clearing out stale tool results, because once a tool call is buried deep in history, the agent rarely needs the raw output again. One caution from experience: over-aggressive compaction will quietly drop something whose importance only becomes obvious three steps later. Compaction is lossy. Tune it on real traces, not vibes.

5. Give the agent a scratchpad. A simple NOTES.md or a maintained to-do list that lives outside the context window is shockingly effective. The agent writes progress and decisions to it, pulls them back when needed, and suddenly it can track a long task without holding the entire history in working memory. Cheap, simple, works.

6. Re-ground the goal on a cadence. Periodically re-inject the actual objective into the context. It sounds almost too dumb to bother with, but re-stating the goal measurably reduces drift and costs you next to nothing. If your agent is on a long run, remind it what it's doing. Same as you'd do with a junior who's been heads-down for three hours.

7. Decompose with sub-agents, but only for parallel work. Splitting a task across multiple agents gives each one a small, clean context, which is great. The catch is it costs dramatically more tokens (think on the order of fifteen times more in some setups) and it introduces a fresh failure mode where the sub-agents collectively wander off the original problem. Sub-agents shine for breadth-first, independent subtasks. For tightly-coupled work like most coding, where everything depends on everything else, they're often a bad fit. Don't reach for a swarm when one focused agent would do.

8. Gate the irreversible stuff. This is the real answer to the "agent deleted the database" horror story. Put a human approval step in front of destructive actions: database writes and deletes, deploys, anything involving money. Add checkpointing so a derailed run resumes from a known-good state instead of starting over. I'll be honest, the temptation to just let it run unsupervised is strong, and I've written about what actually happens when you skip permissions and let Claude Code off the leash. Short version: gate the things you can't undo. Your future self will thank you.

Does the Model Matter? Yes, But Not How You Think

It does matter, just not in the way the leaderboard-watchers assume.

The newer reasoning models resist goal drift noticeably better than last year's batch. That's real progress. But "better" is not "immune," and under sustained pressure or a long pile-up of accumulated context, every model I've worked with will eventually wobble. There's no model you can buy your way to fire-and-forget reliability with. Not yet.

Two findings from recent work are worth tattooing somewhere visible. First, drift can be inherited. If one agent picks up a context that an earlier, weaker agent already nudged off course, the strong model tends to continue the drift rather than correct it. So watch your handoffs. Second, coding agents drift more when an instruction conflicts with something the model was strongly trained to value, like security or privacy. Tell an agent to do something that rubs against its training, and the constraint gets slippery under pressure.

The practical takeaway for picking a model: ignore the headline context number. Choose based on the actual shape of your workload (how much multi-hop retrieval, how long the horizon, how much tool use) and then, this is the important bit, measure your own degradation curve. The spec sheet won't tell you where your agent starts getting dumb. Only your own evals will. This is doubly true if you're putting agents to work in a small business, where a confidently-wrong agent costs you real money and not just a benchmark point.

The Frontier: Agents That Manage Their Own Memory

Here's where I get to be a bit speculative, because this is the part I find genuinely exciting.

Everything above is us managing the agent's context by hand. The obvious next move is to make that someone else's job. Specifically, another agent's. Picture a second process running in the background between tasks, pruning the memory, reorganizing it, rewriting the messy bits into something cleaner. An agent that "dreams" during its downtime and wakes up with a tidier head.

I want to be clear that this isn't me inventing something in a coffee shop. It's an active research frontier with a real name. The Letta folks (out of the MemGPT lineage) call it sleep-time compute: agents using idle time to turn raw context into learned context they can reuse later. There's a small wave of 2026 preprints borrowing directly from neuroscience, with names like SCM and SleepGate, that model consolidation and forgetting as explicit phases, the way actual sleep does. And the early shipped versions are already here. ChatGPT and Claude Code both do background memory consolidation between sessions now, distilling your preferences and project notes without being asked. (If you see a specific product name attached to this, check it against the vendor's own docs before you repeat it, because the branding in blog posts runs ahead of the official announcements.)

The honest trade-off, because there's always one: an unsupervised process that rewrites memory can also hallucinate structure. Feed it a noisy context and it'll confidently write down patterns that were never there, then treat that fiction as fact next session. Dreaming curates, but it can also quietly corrupt. We do not have this solved.

Which is sort of the whole point. We're all at the very beginning of figuring this out, together, in public. I'm tinkering with some of this myself. I don't have anything worth showing yet, just a growing pile of experiments and half-formed opinions, and I'd rather tell you that plainly than pretend I've cracked it.

Putting It Together

If you want the whole thing as a decision ladder, here it is.

Default to tightly-scoped workflows over open-ended autonomy. When you do go agentic, engineer the context first (rules one through six, the budgeting and re-grounding and just-in-time stuff). Reach for sub-agents only when the work genuinely splits into independent parts. And no matter what, gate the actions you can't take back.

A few caveats so you don't quote me too confidently. This field moves monthly, and a lot of the research I've leaned on here is preprints and previews, not settled science. Some of it comes from vendors who have a horse in the race, though the independent benchmarks broadly back up the direction. And there is no universal token cliff. Degradation is gradual, it's model-specific, and it's task-specific. Anyone selling you a magic number is selling you something.

But the core lesson is solid, and it's not going anywhere. In agentic AI, the win doesn't go to whoever has the biggest context window or the cleverest prompt. It goes to whoever manages context the best. Prompting moved into the loop, and the loop runs on whatever you put in front of it.

So put good things in front of it. That's the job now.

Last updated: June 2026. This space changes fast, so if you're reading this much later, assume some of the specifics have moved.

I run DeepSeek in production every day, so this question matters to me beyond idle curiosity. It's the model quietly doing most of the work behind my agent setup, and if a successor is coming I'd like to know whether to plan around it or not. So I went and checked the primary sources instead of trusting the rumour mill. Let me walk you through what's real, what's noise, and what I'd actually watch.

Spoiler: the most repeated "evidence" for an imminent DeepSeek V5 is a misreading of a routine deprecation notice. We'll get to that.

The short answer: no date, and that's okay

DeepSeek has not announced V5. Not a name, not a window, not a teaser. The only models DeepSeek officially lists right now are V4 Pro and V4 Flash. Everything else is people reading tea leaves.

It helps to look at the cadence. DeepSeek shipped V3, then V3.1, then V3.2, then V4, all inside roughly a year. V4 itself only landed on 24 April 2026. That's recent. A clean, ground-up V5 this soon would break the pattern hard. What's far more likely in the near term is a tuned V4.x or a stable V4 release that drops the "Preview" label. Useful, but not the generational leap the hype crowd is promising.

So if your planning depends on V5 arriving by a particular date, build for the world where it doesn't. You'll be right more often.

Why everyone thinks DeepSeek V5 is imminent (and why they're wrong)

Here's the load-bearing myth. DeepSeek's API docs note that the model names deepseek-chat and deepseek-reasoner will be discontinued at 15:59 UTC on 24 July 2026. A bunch of posts took "deprecation on July 24" and ran with "new model on July 24." You can see the logic. You can also see why it's wrong if you read one more sentence.

Those two names are legacy aliases. They currently point at V4 Flash, one for non-thinking mode and one for thinking mode. DeepSeek is retiring the old generic names and asking everyone to call the models by their real names instead. The migration is a one-line change: swap your model field to deepseek-v4-flash or deepseek-v4-pro. Your base_url stays the same. Your API key stays the same. That's the whole job.

If you're calling the OpenAI-compatible endpoint, it's literally model: "deepseek-chat" becoming model: "deepseek-v4-flash" and you're done. I migrated my own jobs in about five minutes, and most of that was hunting down where past-me had scattered the string. The point is, nothing about your integration breaks. It just stops accepting an old name.

So this isn't a roadmap leak. It's housekeeping. The 90-day countdown started the day V4 shipped, which is exactly how you'd phase out old aliases after a new generation lands. If DeepSeek were dropping V5 on the 24th, they'd be sending you to call deepseek-v5-something. They're not. They're sending you to V4.

Does this mean V4 Flash is going away?

No, and this is the part the hype posts get backwards. V4 Flash is the destination, not the casualty. The legacy names are being pointed somewhere permanent, and that somewhere is the explicit V4 model IDs. If you've hard-coded deepseek-chat in some script from 2025, sure, go fix that before July. But your actual model isn't disappearing. Nothing about this date implies a new release. It's a rename with a deadline.

What DeepSeek V4 actually is right now: Pro vs Flash

Before we daydream about V5, it's worth being precise about what shipped, because half the articles out there get the basics wrong.

DeepSeek V4 launched as a Preview on 24 April 2026, both variants at once, open-weight on Hugging Face under the MIT license. The two models:

• V4 Pro: a 1.6T-parameter Mixture-of-Experts model with around 49B active parameters per token. This is the premium tier.
• V4 Flash: 284B total, around 13B active. Fast, cheap, the volume workhorse.

Both run a 1M-token context window. Both support thinking and non-thinking modes.

A quick word on why the active-parameter numbers matter, because they're the whole reason Flash is cheap. In a Mixture-of-Experts model, only a slice of the network fires for any given token. Flash carries 284B parameters but only lights up around 13B per token, so you get the breadth of a big model at the inference cost of a small one. That's the trick that lets DeepSeek price Flash the way it does. The 1M context, meanwhile, is genuinely useful for the kind of agent work where you're stuffing in a pile of search results and documents and asking the model to make sense of all of it at once. It's not a gimmick number on a spec sheet, at least not for how I use it.

DeepSeek V4 Pro pricing

The numbers, per million tokens:

One correction worth flagging, since I've seen it repeated: the V4 Pro rate isn't a discount anymore. It started as a 75% promo, then became the permanent list price on 22 May 2026. So $0.435 / $0.87 is just what it costs now. Don't budget for the promo expiring, because it already didn't.

Here's where I'll get personal. V4 Flash is my daily driver. I use it constantly through the OpenCode Go subscription, which at the volume I push feels close to unlimited, and it's the engine behind most of what my Hermes setup does all day. Searching, researching, summarising, analysing, the unglamorous connective tissue of agent work. Flash is genuinely more than enough for all of it, and it's quick enough that I rarely sit there watching a spinner.

What I would not do is write code with Flash. Pro is much better for that, and I get into why in my V4 review. But honestly, even with Pro available, my coding rotation is Opus, GPT-5, Minimax M3, and Kimi 2.7 Code. DeepSeek isn't where I reach first for code. It's where I reach first for cheap, fast, high-volume thinking. Different tool, different job.

DeepSeek V4 Pro vs Claude (and GPT-5)

This is the comparison everyone wants, so let's be honest about it instead of cheerleading.

On a chunk of benchmarks, V4 Pro lands in the neighbourhood of Claude Opus 4.7 and GPT-5.5, and it does it at a fraction of the API cost. That part is real and it's impressive. But "near the frontier on some benchmarks" is not the same as "the frontier." On the hardest reasoning and agentic tasks, the top closed models still tend to edge ahead. If raw capability at any cost is your only metric, DeepSeek probably isn't your answer yet.

Where DeepSeek wins, decisively, is the price-to-performance ratio. That's the actual story, and it's a big one. You can run a lot of competent inference for very little money, which changes what kinds of products and agent loops are even economically viable. I've shipped things with Flash that would've been silly to attempt at Claude prices.

Make it concrete. Picture an agent that does a hundred small research-and-summarise passes a day, each one chewing through a decent slab of context. On Flash, that's pocket change, the kind of bill you forget to look at. Run the same loop on a frontier closed model and suddenly you're doing actual maths before you let it run unattended. The capability gap on that particular task is small to none. The cost gap is enormous. That asymmetry is the entire reason I default to Flash for high-volume agent work, and it's why I think the "vs Claude" framing slightly misses the point. They're not really competing for the same job.

How to compare them without fooling yourself

Vendor benchmark slides are marketing. If you want a read you can trust, lean on standardised harnesses like SWE-bench Pro or DeepSWE that run the same tasks against every model with the same grading. And test on your workload. A model that tops a leaderboard can still fall apart on your specific agent loop, and the only way to know is to run it. I've been burned by trusting a headline number more than once.

The DeepSeek vision API gap, and why agent users are still waiting

Here's a detail that trips people up. DeepSeek does have vision now. It added image recognition to the chat interface and the mobile app back on 29 April 2026, which SCMP wrote up nicely under the headline that the whale can finally see. Upload an image, it understands the image. Good, fast, the works.

The catch, and it's a big one if you build agents: it's chat-only. There's still no vision endpoint in the API. No image content type, nothing you can call programmatically. So for anyone wiring DeepSeek into an automated pipeline, the vision capability may as well not exist. A human can paste a screenshot into the chat box and get a great answer. Your agent, running headless at 2am, cannot. And agents are where vision actually earns its keep: reading a chart, parsing a screenshot, pulling structure out of a scanned document, checking what a UI looks like. All the workflows I'd most want it for live on the API side, behind a door that's still locked.

deepseek vision api: the part that matters for Hermes

This is exactly the gap I keep hitting. Inside Hermes, when something needs eyes, I can't hand it to DeepSeek. I route those tasks through Qwen 3.7 Plus instead, purely because Qwen gives me vision over an API and DeepSeek doesn't. It works, but it's a second model in the stack for one missing feature, and I'd happily collapse it back down to one if I could.

So when I think about what would make DeepSeek's next model actually move the needle for me, "another point on a reasoning benchmark" isn't it. A vision API is.

The funding signal, and when DeepSeek V5 might actually land

There's one piece of news that genuinely changes DeepSeek's trajectory, and it's not a model. It's money.

DeepSeek closed its first ever external funding round in June 2026, roughly $7.4 billion, at a valuation reported in the $55 to $59 billion range. SCMP covered the structure: Tencent led it, the EV battery giant CATL crossed over as a strategic investor (an AI-meets-energy bet that's more interesting than it sounds), and notably, Alibaba and ByteDance sat it out. For a lab that had stayed proudly self-funded, that's a real shift. More capital means more compute, which means more concurrent training runs, which is the kind of thing that eventually produces a V5.

But "eventually" is doing heavy lifting there. None of this comes with a date.

If you want a sane way to track the actual signal instead of the rumours, watch two things: DeepSeek's official Change Log and their Hugging Face org. When a new generation is real, it shows up there first, usually with weights and a paper, not as a leak on social media. Everything upstream of those two sources is speculation dressed up as reporting.

What I want from DeepSeek V5

So, the honest answer to "when is V5 coming out" is: unknown, no date, probably not as soon as the hype says, and the July 24 thing is a red herring. But I'm still genuinely excited for it, so here's my wishlist.

Keep the Flash-tier pricing. Add a real vision API so I can finally drop Qwen 3.7 Plus from my Hermes stack. And push the agent reliability up a notch. Do those three things and V5 becomes close to the perfect agent model for how I actually work, and my default in Hermes the day it ships.

Until then, V4 Flash is doing the job, the date nobody can give you is still nobody's to give, and I'd gently suggest ignoring any headline that claims otherwise. I'll update this post the moment DeepSeek puts something official on the Change Log. Not before.

I was wrong to sigh. Hermes Agent is different in ways that actually matter, and after a few weeks of running it for real work, I get why the dev crowd moved over. This is the honest version: what it is, what you can actually do with it, how it stacks up against OpenClaw, and the security tradeoff nobody seems to want to talk about.

What exactly is Hermes Agent?

Hermes Agent is an open-source, model-agnostic autonomous agent from Nous Research that plans, calls tools, and keeps state across sessions, while teaching itself new skills as it goes.

That bolded sentence is the whole pitch. It's not a coding copilot bolted to your editor. It's a persistent agent that you point at a task, and it goes off and does it, remembering what happened last time.

Now, the naming. The naming is a mess and you need to keep three things straight or you'll confuse yourself reading the docs:

• Hermes 4 is the LLM weights, the actual model.
• Hermes Agent is the framework, the thing this article is about.
• Hermes Desktop is the GUI app that hit public preview in June 2026.

The desktop release shipped no new model and no new architecture. It's just a door into the existing agent that doesn't make you live in a terminal. Useful, but don't mistake it for a reinvention.

What makes Hermes Agent interesting is the closed learning loop. It auto-creates skills after hard tasks, searches its own past sessions (it keeps them in SQLite with full-text search), and builds a model of you over time. Most agents forget you the second the session ends. This one tries not to. That's the part worth paying attention to.

What can you do with a Hermes agent?

Here's where I'm going to disappoint the hype merchants. The genuinely good use cases are boring, and that's a feature.

Where Hermes shines is always-on scheduled work. Morning research digests, competitive-intelligence sweeps, watching a trend API or a search feed and pinging you when something moves. The canonical example everyone reaches for is a daily briefing dropped into Telegram or Slack at 8am, and honestly, that example is popular because it works.

My actual usage looks like this. I've got it collecting information on a schedule, running a paper-trading agent, and watching trend APIs and search results so I don't have to babysit a dozen browser tabs. None of that is glamorous. All of it saves me time every single day.

What it's bad at is worth saying plainly. Complex multi-file refactors that need real architectural judgment are not its strength, because the open models I run it on are good but not Claude-Opus good. And for tight interactive coding where I want to see and control every bit of context, the CLI or Claude Code still beats it. Hermes is for the work you'd otherwise forget to do, not the work you're actively thinking hard about.

This is also where I'll gently push back on the discourse. Half of what I read on X during the OpenClaw wave was people breathlessly announcing they'd "automated their business," and when you looked closer it was a script that renamed some files. If you want a realistic sense of what these tools do for an actual small operation, I wrote up where AI agents help small businesses in 2026 without the fairy dust. Hermes is more capable than the OpenClaw stuff was. The honest wins are still the unglamorous scheduled ones.

Hermes Agent vs OpenClaw

So why did OpenClaw bounce off me and Hermes stick?

With OpenClaw, every task I imagined throwing at it had an answer along the lines of "yeah, Claude Desktop already does that, or Claude Code does it better." It never carved out its own reason to exist on my machine. I'm sure people built real things with it. I just wasn't one of them, and I didn't find the hype convincing enough to keep trying.

Hermes is different because of three things: persistent memory, a "Soul" identity layer, and automatic skill creation. The point isn't any single feature. It's that the agent compounds. Recurring work gets cheaper and faster as it accrues skills, so the thing you set up this week is better next week without you touching it. That's a fundamentally different value proposition than "wrapper around a model that runs commands."

I want to be fair, though, because I'm not here to sell you anything. The memory is small. We're talking roughly a 2,200-character memory file and a 1,375-character user file, with no version history by default. Early facts get overwritten as new ones come in. So the "it remembers you" story is real but bounded, and you'll feel the ceiling on long-running personal-assistant work. This is early infrastructure, not a finished memory system, and I'll come back to that.

Hermes agent skills, memory, and the self-improving loop

This is the most technically interesting part of the system, so let's actually dig in.

How skills work

Skills are just markdown files. Each one is a SKILL.md file living under ~/.hermes/skills/, following the open agentskills.io standard. They load by progressive disclosure, which is a fancy way of saying the agent reads only the short description of each skill for free, and pulls the full content into context only when a task actually matches. That keeps the context lean, which matters more than people realize.

The clever bit is that the agent writes its own skills. After a non-trivial task (think five or more tool calls, or some non-obvious workaround it had to figure out), it can save what it just did as a reusable skill via skill_manage. There's also an autonomous Curator that grades, consolidates, and prunes the skill library on a cycle, so it doesn't just accumulate junk.

The mental model that finally made it click for me: memory is for "what" (facts), skills are for "how" (procedures). Keep those two ideas separate and the whole architecture suddenly makes sense.

Where auto-generated skills fall short

Here's my slightly contrarian take, because almost nobody is saying this. The auto-created skills are convenient, and sometimes they're genuinely good. But more than once I looked at one and thought, I could write this better myself.

When I hand-author a skill with proper prompting and the right context, the result is cleaner and more reliable than what the agent scribbles after a task. Claude even has a dedicated skill-creation skill that helps structure new ones, and if you care about the output, a few minutes of deliberate authoring beats auto-generation. (If you want to get the prompting right, I put my approach in prompt engineering best practices for 2026.) Treat auto-generation as a fast first draft, not the finished article.

Same energy on memory and Soul. They're interesting, and I'm glad they exist, but they feel like the first rung on a tall ladder. The memory is too small and not situationally aware enough yet. I'm fairly convinced the next generation of agents will have far more sophisticated, context-aware memory systems, and we'll look back on this as the charmingly primitive beginning. Which is fine. Everything starts somewhere.

How to get Hermes agent (and run it cheaply)

Getting started is straightforward, and the cost story is genuinely good if you set it up right.

You've got two front ends. The Desktop app (public preview since June 2026) and the CLI are the same agent core sharing the same ~/.hermes config, so anything you set up in one shows up in the other. Desktop adds a settings UI so you're not editing YAML, plus a file browser, voice mode, and live subagent watch-windows that let you see parallel work happening. The CLI keeps finer control over context and compaction. I bounce between both. Desktop for monitoring and review, CLI when I want my hands on the wheel.

The part that makes this cheap is the inference. I run mine on my OpenCode Go subscription, which Hermes supports as a first-class provider. Setup is three things:

1. Add OPENCODE_GO_API_KEY=<your-key> to ~/.hermes/.env.
2. Set the provider to opencode-go (base URL https://opencode.ai/zen/go/v1).
3. Pick your model in Settings, or in config.yaml.

Then route deliberately. I use DeepSeek V4 Flash for roughly 95% of what I throw at Hermes, because the easy, high-volume cron and subagent work doesn't need a frontier model and Flash is absurdly cost-effective. I reserve the stronger models (Qwen3.7 Max, Kimi K2.6) for the genuinely hard reasoning. The caps on OpenCode Go are dollar-based rather than request-based, so cheap models stretch almost comically far. You can run an enormous amount of agent work for not much money.

Two gotchas to flag before they bite you, because they bit me. Dotted model IDs sometimes get mangled into hyphens (minimax-m2.7 turning into minimax-m2-7), which produces a confusing "model not supported" 401. And there are routing edge cases where Hermes picks the wrong endpoint format and you get a 401 for no obvious reason. The fix is the same in both cases: pin your provider and model explicitly, start a fresh session, and update Hermes regularly because these are being patched. Check the project's GitHub issues if a specific model misbehaves; the relevant ones were still in flux at the time I set this up.

The security tradeoff nobody mentions

Now the part I actually want you to remember.

Early on, Hermes ran into a Node.js install conflict on my Mac and just... fixed it. Diagnosed it, sorted out the mess, moved on. My first reaction was delight. My second reaction, about thirty seconds later, was a small cold feeling in my stomach.

Because an agent that can fix your machine can also break it. Unsandboxed, with free run of your filesystem and shell, Hermes is a real security risk. It's not malicious, but it's powerful and autonomous, and "powerful and autonomous with root-ish access to your laptop" is exactly the sentence that should make you pause. I've written before about the danger of skipping permissions on coding agents, and the same logic applies here, except Hermes runs on a schedule when you're not watching.

So harden it before you expose it to anything. Switch the terminal backend to Docker so it's containerized. Use gateway allowlists. If you're running the agent on a VPS or home server and reaching it from your laptop, bind the dashboard to a Tailscale IP and put OAuth in front of it, and never, ever expose a dashboard to the open internet. Tailscale plus OAuth is the clean pattern here and it's not much work.

And here's the bigger-picture thought that the Node incident kicked off for me. Google, Microsoft, and Apple are all going to bake agents directly into their operating systems. When that happens, a complex, less-sandboxed, set-it-up-yourself tool like Hermes becomes obsolete for casual and non-professional users, because they'll get something safer and simpler for free, built into the thing they already use. Hermes's real audience isn't the casual user. It's devs and tinkerers who want control, can manage the risk, and have workflows worth the setup cost. That's not a knock. It's just who this is for.

So is it worth it?

Hermes Agent earns the place on my machine that OpenClaw never did. The compounding skills, the persistent memory, the always-on scheduled autonomy that quietly handles the work I'd otherwise forget. It's a genuinely useful tool and I'm keeping it.

But it's preview-stage and it's rough in real places. The context compression can get lossy on long sessions, the memory is too small, and the provider routing has sharp edges. Treat it as powerful early infrastructure, not a polished product, and you won't be disappointed.

Honest bottom line: if you're a dev running cheap inference and you've got unglamorous, always-on workflows that eat your time, set it up this weekend. If you want a casual assistant that just works with zero fuss, sit tight, because the OS vendors are coming for exactly that lane, and they'll do the babysitting for you.

Anthropic had been teasing this thing for months. There were announcements about a model so capable it was deemed too dangerous to release to the public, the whole Mythos saga, that kind of thing. And just the name, Mythos, sounded epic in a way that made my eyes roll a little. Expectations were sky high, which usually means disappointment is loading.

I'll admit I got cynical about it. My honest assumption was that this was more hype than substance, a bit of marketing theatre to keep interest up while the company circles an IPO. So when Fable 5 actually shipped on June 9, much sooner than I expected, I went in ready to be unimpressed.

I was wrong. This is the best coding model I've used, and unlike the last few releases, I can actually feel the difference.

What Is Claude Fable 5?

Quick context before I get to the testing, because the naming is genuinely confusing.

Claude Fable 5 is the first publicly available model from Anthropic's new Mythos tier, which sits a notch above Opus in their lineup. There are technically two models here. Fable 5 is the one you and I can use. Mythos 5 is the exact same underlying model with some safety guardrails removed, and it's locked behind Anthropic's Project Glasswing program for vetted partners. Same weights, different leash. That's the whole distinction.

The specs that matter to a developer: a 1 million token context window, up to 128k tokens of output, a January 2026 knowledge cutoff, and the API id claude-fable-5. It runs in an adaptive thinking mode, so you don't toggle reasoning on and off.

The reason it took this long to reach the public is the cyber angle. The earlier Mythos Preview from April was held back specifically because it was scary good at finding software vulnerabilities. Fable 5 ships with safety classifiers that catch sensitive requests and quietly route them to Opus 4.8 instead, which is what made Anthropic comfortable releasing it widely. More on those filters later, because they're not free.

How I Tested It

If you've read my reviews before, you know I run the same handful of prompts on every model. Identical wording, every time. That's the entire point. It's the only way I can honestly compare a new model against the last one, instead of going on vibes and a warm fuzzy feeling. So Fable 5 got the same four tests as everyone else.

Two websites, same prompts as always

First up, my two website builds: a Sydney coffee roaster site and a pop culture online shop. Same prompts I've used for a dozen models now.

The results were very good. Nice fonts, clean technical output, and some lovely animations. The pop culture store in particular had some cool little details. I'll be honest though, my coffee roaster prompt always seems to converge on a similar design no matter who builds it, so that one didn't surprise me much. And for the pop culture shop, I still slightly prefer the colours and overall style I got back in my Gemini 3.5 Flash review. Taste is taste.

But here's the thing that actually impressed me, and it wasn't the output. It was the process.

Fable 5 wrote the initial HTML fast, like you'd expect. Then it did something no other model has done on this prompt without being told to: it fired up Playwright, took screenshots at different viewport sizes, looked at its own work, and kept fixing the code until it was clean. It tested itself. Repeatedly. Until the thing was flawless across screen sizes. I've seen models claim they've checked their work. This one actually did, and I watched it happen.

The poker simulation that finally worked

This is the one. If you take one thing from this Claude Fable 5 review, make it this.

I have a prompt I've been running for ages: build a Texas Hold'em poker simulation in Go, with six AI players who each have distinct personalities, playing 1000 hands. At the end I want detailed statistics on the players and the games, plus a way to replay any individual hand with verbose stats. It sounds reasonable. It is reasonable. And not a single model has ever one-shotted it.

There was always something broken. Sometimes the poker rules themselves were subtly wrong. More often the players behaved like they'd never seen a deck of cards, making nonsense decisions. And the end statistics rarely added up to anything coherent. Close, occasionally. Never right.

Fable 5 just did it. First try. The rules work, the hand evaluation is correct, and the six personalities actually play poker like distinct humans would. The aggressive one bullies, the cautious one folds marginal hands, and it all holds together across a thousand hands. The stats make sense. The hand replay works.

And it was fast. MiniMax M3 burned something like 40 minutes grinding on its attempt. Fable did this in about 14. That's the gap we're talking about.

Auditing my own site

Last test, an audit of thomas-wiegold.com. This is a hard one to impress me with, because I've audited, fixed, and re-audited that site more times than I'd like to admit. There isn't much low hanging fruit left.

Fable found something genuinely new. It also surfaced a few issues I'd heard before from other tools, which is fine, but the new finding is what mattered. Everything it flagged made sense, nothing was hallucinated filler, and the fixes it then implemented were clean and quick. Probably the best site audit I've ever run, and I say that as someone who's run a lot of them.

The short version of all this: with Opus 4.8 I genuinely couldn't tell you whether it was better than 4.7 or 4.6. The gains were too small to feel. With Fable, I can feel it. That's new.

How Fable 5 Stacks Up on Benchmarks

I usually don't put much stock in benchmark tables, and you shouldn't either, but the numbers here line up with what I felt so they're worth a look.

Fable 5 tops basically everything. It's number one on the Artificial Analysis Intelligence Index, and it posts 80.3% on SWE-Bench Pro. For comparison, Opus 4.8 sits at 69.2%, GPT-5.5 at 58.6%, and Gemini 3.1 Pro at 54.2% on the same test. On the harder FrontierCode Diamond benchmark the gap is brutal: 29.3% for Fable versus 13.4% for Opus 4.8. That's more than double.

Worth noting that the headline comparison table is Anthropic's own, so take it with the usual pinch of salt. But the third party results back it up. It came out on top on Vals.ai and on Cursor's internal benchmark, and the independent reviewers who tested it agree. Simon Willison, who doesn't do hype, called it "a beast" and noted it has a "big model smell," meaning it just knows more than Opus 4.8. Ethan Mollick said it outperformed every other public model by a considerable margin. Dan Shipper scored it 91 out of 100 on his team's senior engineer benchmark, against 63 for Opus 4.8, and called it a "warp drive."

That warp drive framing is the right one. Anthropic's own line is that the longer and more complex the task, the bigger Fable's lead gets, and that matches my experience exactly. The poker sim is precisely the kind of long, fiddly, multi-step job where it pulls away from the pack. For a quick one-line fix you won't notice the difference. For a real build, you will.

The Catch: Price, Limits, and Filters

Right, so it's not all sunshine. This is the part where I temper the excitement, because there's a lot to temper.

First, the price. Fable 5 costs $10 per million input tokens and $50 per million output, which is exactly double Opus 4.8. On claude.ai it eats your subscription usage twice as fast, too. Now, to be fair, it's not a token waster in the way some recent models are. It doesn't ramble or pad. But it still burns through your limits quickly because the per-token cost is just higher.

Then there's the part that actually worries me. Right now Fable 5 is included in the Pro, Max, and Team plans, but only until June 22. From June 23 it gets pulled from subscriptions and you'll need usage credits to keep using it. Anthropic says they "aim to restore" standard access once they have enough capacity, which is the kind of phrasing that doesn't fill me with confidence. If it leaves subscriptions for good, paying API rates for daily use would be too expensive to justify. I really hope it stays. I'll be using it as much as I can in the meantime, partly out of genuine excitement and partly to get my money's worth before the door maybe closes.

Next, the safety filters. Those classifiers I mentioned earlier route cyber, bio, chemistry, and a few other categories to Opus 4.8 instead of Fable. The problem is false positives, and they're real. Scientists have been vocal about it. One medical physicist said he basically can't use the thing because he says the word "nuclear" all day. There are reports of MRI image segmentation getting flagged as bioterrorism. If your work lives anywhere near security or the life sciences, this is a live issue, not a hypothetical one. For my work it hasn't come up, but your mileage will vary.

And then there's the genuinely weird one. Buried in the system card is a fourth, invisible safeguard. For requests related to frontier AI development, things like building pretraining pipelines or designing ML accelerators, Fable will quietly degrade its own answers. No fallback, no notification, nothing. It just gets dumber and doesn't tell you. Critics have called a model that silently makes itself worse "categorically misaligned," and I get the argument. It probably won't touch what you and I do day to day, but a model that decides on its own to be less helpful without saying so is a bad precedent, and worth knowing about.

I'll also just name the elephant. All of this is landing while Anthropic preps an IPO at a roughly $965 billion valuation. The push toward usage based billing and the subscription removal have a certain timing to them. I'm not saying it's a conspiracy. I am saying the incentives are worth keeping in mind when you read the marketing.

Who Should Actually Use It

Cut through all of that and here's my read.

Use Fable 5 if you're doing hard, long-horizon, well-specified work you can hand off and walk away from. Big migrations, multi-day agent runs, deep research, the kind of build my poker sim represents. For that work the doubled token price is nothing compared to the senior dev hours it saves. My practical advice: don't make it your default. Route your routine stuff to Opus 4.8 or something cheaper, and save Fable for the top 20% of genuinely hard tasks. There's also a 90% discount on cached input, so lean on that for stable prompts.

Wait or skip it if you're a scientist or security researcher dealing with constant false positives, if you're on a zero-data-retention contract (Fable forces a mandatory 30-day retention, which is a dealbreaker for some shops), or if you're a high-volume cost-sensitive user where Opus at half the price gets you most of the way there.

The Verdict

Best coding model I've used. Full stop. And I don't say that lightly, given how jaded I'd gotten about new releases.

What sets it apart isn't just that the output is better, although it is. It's how it works. The Playwright self-testing, the way it one-shotted a poker prompt that has defeated every model before it, the thoroughness of the site audit. It behaves less like a code generator and more like a careful engineer who actually checks their work before saying they're done.

It's not AGI. Let's be clear about that so nobody quotes me out of context. It still makes mistakes, it's expensive, and the filters are clumsy. But the hype, for once, was real. This is the first release in a while where the jump over the previous flagship is obvious rather than something I have to squint to find.

So I'm excited, caveats and all. I'll be living in it for the next week. And now the ball is firmly in OpenAI's court. Your move.

That's the gap I want to close in this article. We're going to build an MCP App that puts a human approval gate in front of an agent's risky actions. It renders an interactive card right inside the chat (Approve, Edit, or Reject) and the agent only proceeds once you've said so. First half is the what and why. Second half is the actual code. I built this thing, so the second half is the real version, not pseudocode.

What is MCP UI? (And what's an MCP App?)

MCP UI is interactive UI that an MCP server can ship to the client, so a tool renders a real interface inside the conversation instead of returning a wall of text. Think buttons, forms, charts, and cards, all in a sandboxed iframe that the host displays inline.

The mechanism is almost suspiciously simple. A tool declares a UI resource, the host fetches that resource when the tool runs, and then messages flow both ways between your UI and your server. That's it. If you've ever wired up an MCP server with plain tools, you already know 80% of this. The UI is just one more thing the server hands over.

The official name for this pattern is MCP Apps, standardized in the Model Context Protocol and shipped in early 2026. It works across hosts (Claude, ChatGPT, and others), so you're building for an open standard, not painting yourself into one vendor's corner.

MCP Apps vs mcp-ui: which is which

This trips people up, so quickly: mcp-ui is a community SDK for "UI over MCP" that's had a head start and a big following. MCP Apps is the official spec and SDK, the modelcontextprotocol/ext-apps repo. The good news is they've converged. Both link a tool to its UI through the same _meta.ui.resourceUri field, and the mcp-ui packages now play nicely with MCP Apps hosts. This tutorial uses the official ext-apps SDK. If you've already invested in mcp-ui, most of what follows still maps cleanly.

What's a human approval gate, and why do agents need one

A human approval gate is a checkpoint. Before the agent does something it can't easily undo (send the email, issue the refund, publish the post, delete the records), a person sees exactly what's about to happen and decides. This is the practical face of "human in the loop," and it's less about distrust and more about physics. Some actions don't have an undo button.

You might say you already do this. You ask the agent to confirm. The problem is that text confirmation is weak. The agent infers your intent from prose, you can't see the actual artifact it's about to send, and a casual "yep go for it" gets matched against the wrong pending action. Agents are confident. That's sort of the whole problem. An agent that's 95% sure is also 5% about to CC your biggest client on something with a typo in their company name.

A UI gate fixes the weak parts. You see the real email, with the real subject line and the real recipient. You can edit it in place before approving. And the decision comes back as a clean, unambiguous signal instead of a sentence the agent has to interpret. If you've read my piece on Claude Code hooks, this is the same instinct (put a deliberate checkpoint where an agent would otherwise barrel ahead), just moved into the conversation where the human actually is.

What you can actually build with MCP UI (beyond dashboards)

When people first see MCP UI, they immediately want to build a dashboard. Fair. Dashboards are nice. But here's my slightly contrarian take after building a few of these: the dashboard is rarely the highest-leverage thing you can put in front of a model.

The genuinely useful patterns cluster into four buckets:

• Approval gates. The one we're building. A confirmation step before consequential actions.
• Configuration wizards. Forms with dependent fields, where picking "production" reveals options that "staging" hides.
• Live data exploration. A chart or table the user can filter and drill into, instead of a snapshot that's stale the moment it's printed.
• Visual and spatial review. A PDF with the relevant clause highlighted, a map, a calendar of open slots. Anything where position carries meaning.

The reason the approval gate wins, for me, is leverage. It's the one interaction that actually changes how much you can trust an agent with real-world actions. And it's absurdly reusable. The same gate handles an email today, a refund or checkout step tomorrow, a publish action next week. The artifact inside the card changes. The pattern doesn't. If you build software for small businesses, that reuse is the whole game (one component, every client), which is exactly the kind of thing I harp on in my small business AI use cases writeup.

One honest caveat: don't build UI for everything. If the answer is a single number, just return the number. If the task is fully autonomous and nobody needs to touch it, skip the card. And if you find yourself rebuilding your entire SaaS inside a chat window, you've taken a wrong turn somewhere. MCP UI is a seasoning, not the meal.

Where this is heading

Two things make me think this pattern matters more than it looks right now.

The first is portability. Because MCP Apps is a shared standard, the same approval gate runs in Claude and ChatGPT without a rewrite. You build the interaction once. For anyone who lived through the era of building the same integration five times for five platforms, that's a quietly big deal.

The second is that trust is becoming a UX surface. As agents take on more actions with real consequences, the place where human oversight lives is exactly this confirmation layer. I'd bet the approval gate stops being a thing each of us hand-rolls and starts being a standard component people drop in, the way auth stopped being something you wrote from scratch. Building one now is a good way to understand it before it gets abstracted away.

Building the approval gate, step by step

Right, enough philosophy. Let's build it. Stack is TypeScript, React, and the official ext-apps SDK, bundled with Vite. I'll show the load-bearing pieces here and link the full project at the end so you're not reading a 300-line paste.

How an MCP App works under the hood

The flow is four steps, and it helps to hold the whole shape in your head before the code:

1. Your tool declares a UI resource (a ui:// URI).
2. The model calls the tool.
3. The host fetches the resource and renders it in a sandboxed iframe. This is the part people mean when they search for "mcp client ui," the client-side rendering of your interface.
4. Your UI and your server exchange messages through the host.

The link between the tool and its UI is one field, _meta.ui.resourceUri. Memorize that and the rest is detail.

The server: three tools and a UI resource

The server registers three tools. request_approval is the one the agent calls, and it's the one that carries the UI. submit_approval_decision is called by the card when you click a button. list_approvals is a read-only audit trail, because in a real workflow you want a record of who approved what.

Here's the heart of request_approval, trimmed for readability:

That _meta.ui.resourceUri is the magic line. It tells the host "when this tool runs, go render that resource." The handler stashes the request (so we can validate the decision later) and returns it as JSON, which the UI will read to draw the card.

The UI resource itself is just your bundled HTML, served back by a resource handler. The tool descriptions matter more than usual here: I spell out, in the description the model reads, that after calling request_approval it must wait and not perform the action until the decision comes back. Models are eager. Tell them to sit.

The view: receive the request, send the decision

The browser side uses the App class from ext-apps. Two methods do almost all the work: one to receive the request, one to send the decision back.

The "set this before connect" comment is not decoration. I learned it the boring way, staring at a card that rendered empty because the result arrived before I'd registered a handler for it. Order matters.

Sending the decision back is one call:

From there it's ordinary React. The card has three modes. View mode shows the artifact with Approve, Edit, and Reject buttons. Edit mode swaps the fields for inputs so you can fix that typo before approving. Reject mode asks for a reason. The one touch I'd recommend not skipping: sync to the host's theme with applyDocumentTheme so the card matches light or dark mode automatically. It's a small thing that makes the card feel native instead of bolted on.

State, idempotency, and an audit trail

The server keeps a small store of requests and their decisions. For the demo it's an in-memory Map, which is honest about what it is: fine for one process, gone on restart, useless across replicas. In production you'd back it with Postgres or Redis, and the store's function signatures are deliberately the seam where you'd swap that in.

The rule worth enforcing is that a request can be decided exactly once. Without it, a double-click or a replayed call could approve the same action twice, and "the agent issued the refund twice" is the kind of bug that turns into an email from finance. So the decision recorder checks the request exists and is still pending before it writes anything. Boring, defensive, correct.

Testing it in Claude

The surface that runs a local server and renders its UI is Claude Desktop, via a stdio config. (Custom connectors on claude.ai need a public HTTPS URL, which is a different setup.) Build first, because the server serves the bundled HTML:

Then open Claude Desktop, go to Settings, Developer, Edit Config, and add the server pointing at the project's entry file with the --stdio flag. Restart Claude fully (quit, not just close the window). Ask it to draft something and request your approval, and the card appears inline. The exact steps are in Anthropic's MCP Apps getting-started docs, and the official MCP Apps quickstart is worth a read for the build setup.

Claude Desktop launches your command with a minimal PATH, sometimes npx or tsx installed through nvm or Homebrew just isn't found, and the server fails silently. If that happens, the fix is to use absolute paths (run which npx, paste the full path). For fast UI iteration without restarting Claude every time, run the ext-apps reference host over HTTP and point it at your local server. Tweak there, then do the Claude Desktop run as the real check.

Wrapping up

The thing I want to leave you with is how little code this took for how much it changes. A couple of tools, one bundled view, a store with a single safety rule, and suddenly an agent that used to act on a misread "yes" now stops and shows its work first.

That's the real pattern here, and it outlives this specific example. The card swaps out per use case, the gate stays the same, and because it's built on an open standard it follows you across hosts. Clone the full project on GitHub, change the fields schema to whatever your agent is about to do, and you've got a reusable checkpoint you can put in front of anything risky.

Build the gate before you need it. Future you, the one not writing an apology email, will be grateful.

I've been in the MiniMax corner for a while now. I liked M2.5 when it landed, and I liked M2.7 even more. But there was always the same asterisk in the back of my mind: genuinely good, just not GPT-or-Opus good. A gap you could feel. This time the gap might have closed. So I ran my usual battery of tests, watched the thing think for an uncomfortably long time, and came away mostly impressed. Here's the whole story.

What Is MiniMax M3?

MiniMax M3 is an open-weights, natively multimodal model (text, image, and video in, text out) that launched on June 1, 2026 with a 1 million token context window. It's the course-correction in the M-series: where the M2 generation deliberately ditched sparse attention over production worries, M3 brings it back as the headline feature.

That feature is called MiniMax Sparse Attention, or MSA. The short version for anyone who doesn't want the linear-algebra lecture: a lightweight index branch scans incoming tokens, picks which key-value blocks actually deserve attention, and only runs the expensive math on those. The clever bit is that it does this on the real, uncompressed key-values, so you don't pay the long-context precision tax that something like DeepSeek's latent attention does. MiniMax claims a roughly 9x speedup on prefill and 15x on decode at 1M tokens, with quality holding steady in their ablations.

Why should you care about that more than the benchmark numbers? Because a quadratic-attention model can technically hold a million tokens, but actually using them is miserable. Prefill alone can take minutes. If MSA's speedups hold up under real load, that's the difference between "1M context exists on the spec sheet" and "1M context is something you'd actually build an agent around." That's the part that matters.

On pricing, it's aggressive. Standard pay-as-you-go is $0.60 per million input tokens and $2.40 per million output, with a 50% launch promo for the first week. That's somewhere between a tenth and a twentieth of what closed frontier models cost. You can run it right now through the MiniMax API, OpenRouter (OpenAI-compatible, easiest path), and a handful of launch partners.

One honest flag before we go further: at launch the parameter count is undisclosed, and the "open-weights" part is still a promise. The weights weren't on Hugging Face yet (MiniMax says "within 10 days"). So keep your enthusiasm calibrated. More on that later.

Putting MiniMax M3 Through My Usual Tests

Here's my process, which never changes, because that's the only way I can compare across releases instead of just vibing off first impressions. I run the same three tasks on every serious model: two website builds, a poker simulation terminal program, and a full code audit of my own site, thomas-wiegold.com. Same prompts, same expectations, every time.

Website one: the Sydney coffee roaster

This is one of those prompts I've run so many times I could recite the output styles in my sleep. Funny thing about it: every single model picks more or less the same color palette for a Sydney coffee roaster. GPT, Opus, Gemini, now MiniMax. There must be something deep in the training data that screams "warm browns and cream" the moment you say "coffee." I've stopped fighting it.

What separates the models is everything else, and M3 nailed everything else. The layout was clean and considered, the technical execution was solid, and honestly it was one of the best results I've gotten for this prompt to date. Right up there with the closed frontier models. That alone made me sit up, because this is exactly the kind of task where MiniMax used to be "fine, but."

Website two: the pop-culture online store

I push the complexity up here. More interactivity, more visual flair, more chances to fall apart. M3 handled it well. Nice animations, good structure, the sort of result you'd be happy to hand off as a starting point rather than a throwaway demo. Probably the second-best result I've ever gotten for this particular prompt.

Second-best, because Gemini still had a slight edge on the design polish. If you've read my take on Gemini 3.5 Flash in Google Antigravity, you'll know I rate Gemini's web design specifically while preferring GPT-5.5 and Opus for most other work. M3 didn't beat Gemini at its own game, but getting within arm's reach is a real result.

The poker simulation

And now the part where I stop gushing. The poker sim was a mixed bag.

First problem: it took forever. I'm talking 30 to 40 minutes of the model thinking and working. I sat there reading the reasoning output, partly out of curiosity and partly out of disbelief, and it was a parade of "actually..." and "oh but wait, maybe..." and then contradicting the thing it had just decided. It would talk itself into a corner, talk itself back out, and burn a frightening number of tokens doing it. At times it felt less like reasoning and more like brute-forcing its way to an answer by sheer persistence.

To be fair, this isn't a MiniMax-specific disease. A lot of the newer models do this now. They over-think, second-guess, and treat token budgets like they're free. M3 is just a particularly patient offender.

The result itself? Okay. Not a full success, it didn't completely nail the task. But I'll give it this much context: no model has ever one-shot this poker challenge to 100%. Not one. So "okay but slow" puts it in the same bucket as everything else, just with a longer coffee break in the middle.

The code audit

This is where M3 won me back. Auditing thomas-wiegold.com is a hard test, and I mean that genuinely. The site is already heavily optimized. I've run these audits over and over and fixed the problems, so finding something new and real is not easy. The bar is high precisely because the obvious stuff is long gone.

GPT-5.5 has been my favorite for audits for a while. MiniMax M3 got remarkably close. No filler, no padding, no inventing problems to look busy. Every finding made sense and was worth my time. Compare that to when I tested DeepSeek V4, which buried the good observations under a pile of non-issues that I had to wade through and dismiss. M3 didn't waste a single line on a fake problem. For a model at this price, that's genuinely impressive.

How It Stacks Up on Benchmarks

The numbers are good, and I'm going to tell you why you should still squint at them.

On MiniMax's own reporting, M3 hits 59.0% on SWE-Bench Pro, which puts it behind Claude Opus 4.7 (64.3%) and GPT-5.5 (58.6%) by a hair, and ahead of Gemini 3.1 Pro (54.2%). On SWE-Bench Verified it's at 80.5%, and on Terminal-Bench 2.1 it sits at 66.0%, where the closed models pull ahead more clearly. The pattern is consistent with what I saw by hand: close to GPT and Opus on real coding, not quite past them.

Here's the squint. Every one of those numbers is vendor-run, on MiniMax's own infrastructure, with baselines they picked, often using Claude Code as the scaffolding. That's not an accusation of cheating, it's just how launch-day benchmarks work, and you should treat all of them with the same healthy suspicion you'd apply to any company grading its own homework. The independent scores from LMArena and Artificial Analysis were still pending at launch. When those land, that's the real test.

One known soft spot worth naming: abstract, fluid reasoning. The whole family of Chinese models has lagged here, and the ARC Prize ARC-AGI-2 results from earlier this year had the MiniMax line scoring low single digits. M3 is a strong coder and a strong agent. It is not, on the available evidence, a great abstract reasoner. Good to know before you point it at a problem that needs genuine novel reasoning rather than competent execution.

The Catches

Three things to keep in your head before you get too comfortable.

The "open-weights" label was a promise on launch day, not a fact. No weights on Hugging Face yet, and the license is the bigger worry. M2.7 shipped under a "Modified-MIT" license that blocked commercial use without written permission, which got roundly mocked as faux-open-source. M3 is expected to follow the same playbook. So if your plan involves self-hosting for commercial work, do not commit to anything until the actual weights ship and you've read the actual terms. Hope is not a deployment strategy.

The token-burning I hit in the poker test is a real cost factor, not just an annoyance. The headline price is cheap, but if the model wanders through 40 minutes of self-doubt on a hard problem, your effective cost-per-task climbs. Measure the whole task, not the per-token rate.

And a 1M context window is wonderful, but it is not a memory system. For long-running agents you still want real persistence. A big window helps; it doesn't replace architecture.

The MiniMax M3 Review Verdict: Should You Use It?

Yes, with both eyes open.

I think M3 is a real winner. The results across my tests were strong, the pricing is excellent, and for the first time a MiniMax model genuinely sits in the conversation with GPT and Opus rather than a tier below it. I'm going to use it for coding and other work. I'm also keeping my Claude and ChatGPT subscriptions, because the smart move here is hybrid: route the bulk, cost-sensitive, long-context work to M3, and reserve a closed frontier model for the slice where the last few quality points actually matter.

For a bit of field context, since "is it better than X" is the only question anyone really asks: I wasn't especially moved by Claude Opus 4.8. I honestly couldn't tell you with confidence that it beats its predecessor, and during testing it fumbled something as basic as setting up a project with linting and formatting, which is not a great look. Gemini 3.5 Flash remains my pick for web design specifically, while GPT-5.5 and Opus stay in rotation for most else. M3 doesn't dethrone any of them outright. It earns a seat at the table, and at this price that's the whole point.

If you want to try it without spending anything, it's free in OpenCode right now, and it'll be part of the OpenCode Go plan too. That's the cheapest way to form your own opinion, which, as always, is the only opinion that should actually drive your decision.

I came in skeptical because I usually do, and a MiniMax M3 review was not on my list of things I expected to enjoy writing. It turned out to be one of the more genuinely interesting models I've tested this year. Run it through your own tasks before you believe me, though. That's the entire job.

I want to be honest about that up front. I did not get a long run with this thing. I managed roughly two and a half real tasks before I ran out of tokens, faster than I've ever run out of tokens with any coding tool. That's a short test, and I'll tell you where it limits what I can claim. But it's also, in its own way, the most useful data point in the whole review. More on that later.

Spoiler: it's fast. It's also more complicated, and more expensive, than the launch slides let on.

What Antigravity 2.0 Actually Is (And Why It's Two Apps Now)

Quick reset, because the naming around this launch is genuinely confusing.

Google Antigravity first appeared in November 2025 as a single app: an agentic coding IDE built on a heavily modified VS Code fork. Inside that one app sat three surfaces that worked together. There was the Editor, a full IDE for actually reading and tweaking code. There was the Agent Manager, a command-center dashboard where you launched agents, watched them work, and reviewed the plans and artifacts they produced. And there was a Browser, an agent-controlled browser instance the agents could drive to test web pages and pull data.

Antigravity 2.0, announced May 19, 2026 at I/O, breaks that single app apart. It's no longer one product, it's five: a standalone desktop app, the original IDE, a Go-based CLI, an SDK, and a Managed Agents API you can call straight from the Gemini API. Each one is a separate download now.

The split that matters most is the desktop app versus the IDE. Antigravity 2.0, the flagship desktop app, is basically the old Agent Manager promoted to its own program. There is no code editor in it at all. It exists purely to launch, monitor, and orchestrate agents, run them in parallel, and schedule background tasks. The Antigravity IDE, meanwhile, is the original VS Code-based editor, still available and the one Google actually recommends for hands-on developers. The intended workflow is dual-wield: orchestrate agents in the desktop app, drop into the IDE when you want to touch code yourself.

Google's reasoning is that they proved the agent-first surface works, millions of developers adopted it, so now they're separating the two jobs into separate tools. They've even said the long-term plan is to strip the Agent Manager out of the IDE entirely, leaving a purely agent-powered editor behind. Whether you want your tooling pulled apart like that is a taste question. I'm not sold on running two windows where one used to do, but I get the logic.

The model running underneath all of it, by default, is Gemini 3.5 Flash. And yes, it's "Gemini 3.5 Flash", not "Flash 3.5". The API ID is gemini-3.5-flash, and it shipped generally available on day one, no preview suffix, no waitlist. If you see anyone write "Flash 3.5" they've just reversed the words. Small thing, but it tells you whether someone actually read the announcement.

What It Can Actually Do, and How It Stacks Up

The real idea here, the thing the whole platform is built around, is multi-agent orchestration. You describe a task, a manager agent breaks it into subtasks, and several specialised agents work in parallel: one writes code, another runs terminal commands, a third tests in the browser, and they verify each other's work in a loop until the task passes its checks. On top of that you get scheduled tasks, where you hand an agent timed instructions to run in the background, and voice input for short prompts. This is genuinely different from how Claude Code or Codex work, which run a single agent through tasks sequentially.

As a Go developer, I'll admit the Go-based CLI got my attention more than the desktop app did. It's the direct successor to the Gemini CLI, a superset of its features, and there's an antigravity migrate --from-gemini-cli command to bring your old config across. It works alongside whatever editor you already use, Vim, Neovim, JetBrains, whatever, so you're not forced into Google's apps to get the agent harness.

That migration isn't optional, by the way. The existing Gemini CLI is being retired for consumers. Access for AI Pro, AI Ultra, and free-tier users ends June 18, 2026, with only Enterprise Code Assist keeping it. If your scripts or pipelines lean on the old CLI, that's a calendar entry, not a someday-maybe.

So how does this stack up against Claude Code and Codex? The parallel multi-agent model is the one real differentiator, and on the right kind of work, fanning tasks out is genuinely faster than grinding through them one at a time. Where Antigravity loses is code quality. Google hasn't published any Antigravity-versus-Claude-Code benchmarks, so this rests on third-party reviews, but the independent reads are remarkably consistent: Antigravity wins on speed and breadth (desktop app plus CLI plus SDK), Claude Code still leads on raw code quality, and Codex sits somewhere in between. I'll get to the actual benchmark numbers in the verdict, but that ranking won't surprise anyone who's used all three. Fast and parallel is great. It just isn't the same thing as correct.

Why I Was Skeptical Before Even Installing It

Let me be upfront about my bias here, because it shapes everything that follows.

Google has a product graveyard you could get genuinely lost in. I've been burned enough times that I no longer trust the longevity of any Google developer tool until it's survived a couple of years in the wild. Building your daily workflow around something Google might quietly kill is its own kind of technical debt, and it's the kind that doesn't show up in any benchmark.

It's not just the abstract track record either. I used the original Antigravity when it launched last November. Unimpressed. I tried Jules, Google's earlier coding agent. Also unimpressed. So I went into this Google Antigravity 2.0 review fully expecting to write a polite "it's fine, but" piece and move on with my day.

I'm telling you this so you know what kind of reviewer you're reading. Not a hype account chasing affiliate clicks. Not a reflexive Google hater either. Just a developer with fifteen-odd years behind him, too many subscriptions, and a very low tolerance for tools that waste my time. A skeptic giving the thing a fair shot is still a fair shot.

Hands-On: Building Two Landing Pages

The fastest way to judge a coding agent is to give it real work, so I skipped the toy prompts and built two landing pages from scratch.

The Sydney coffee roaster site

First up, a landing page for a fictional Sydney coffee roaster. Antigravity 2.0 one-shot it. And it was genuinely fast, the kind of speed where you blink and there's already a working page sitting in front of you. Technically the output was solid: clean structure, sensible markup, and some nice animation work that I hadn't even asked for. Nothing I'd be embarrassed to ship the bones of.

But the visual style felt dated. Not broken, not ugly exactly, just five to ten years behind. It looked like a competent template from 2017. The spacing was a little too tight, the typography a little too safe, the colour choices a little too corporate-stock. If you handed this to a client today they'd politely ask for "something a bit more modern", and they'd be completely right to. The model knows how to build a page. It just doesn't seem to know what year it is.

The pop-culture clothing store

Then I tried a pop-culture themed clothing store. Different brief, bolder, more playful, the kind of thing where you actually want some personality on the page. And this one genuinely impressed me. The design was good enough that I caught myself thinking I'd actually shop there, which is a reaction I almost never have to an AI-generated frontend. (For comparison, the design output I've gotten out of Claude Code with its design tooling has been my benchmark, and this wasn't far off it on the right brief.)

So here's the honest takeaway. The output quality from Gemini 3.5 Flash is real, but it's inconsistent. Give it a bold, modern, opinionated brief and it shines. Give it a "professional default" brief and it reaches for something stale. That's worth knowing before you trust it with anything client-facing, because you can't predict which version you'll get until the page renders.

Where It Fell Apart: Token Limits and the Desktop App

Here's where my testing ended. And I mean ended.

After the two landing pages and a half-built poker terminal app, I ran out of tokens. Quota exhausted. I literally could not finish testing the thing I was supposed to be reviewing, which is a special and slightly absurd kind of frustration. Three real tasks. That was the whole run.

And I'm not an outlier. The research backs this up loudly. On Google's own developer forum, people reported an entire daily quota burning on a single trivial prompt. One user said that just asking for a single AGENTS.md file ate the whole allowance. Others described a Flash-to-Pro escalation loop, where the agent quietly bumps itself up to the more expensive Pro model mid-task and drains a week of Pro quota in a couple of days. If you've ever watched a usage meter spin and had no idea why, you'll recognise the feeling instantly.

The desktop app itself? Barebones. I kept waiting to find the feature that made it meaningfully different from every other coding-agent app I've used, and I didn't find it. It's an agent runner with a window around it. Functional, sure, but "functional" isn't a reason to switch, and after fifteen years of tooling churn I've learned to be suspicious of anything that launches looking this generic. A 2.0 release should feel like a confident product. This felt like a 1.0 that got renamed.

I didn't personally hit the OAuth problems, but I'd be doing you a disservice not to mention them, because they were everywhere at launch. Multiple developers reported paid Pro subscriptions failing to authenticate against the desktop app, with the OAuth redirect simply never completing. The app working fine on a free account and then breaking on a paid one is close to the worst possible failure mode for a launch. People paid Google money and got a worse experience for it.

The Pricing Catch Nobody Mentions Upfront

This is the part that actually changed my mind, so stay with me.

On paper, Gemini 3.5 Flash pricing looks reasonable. It's $1.50 per million input tokens and $9.00 per million output, roughly 25% cheaper per token than Gemini 3.1 Pro. Cheap-ish. Flash-ish. The sort of number you skim past without thinking.

Then Artificial Analysis ran the numbers properly, and the story falls apart. Running their Intelligence Index benchmark suite cost $1,552 on Gemini 3.5 Flash. That's 5.5 times what a previous Flash model cost for the exact same suite. And it's 74% more expensive than Gemini 3.1 Pro, the supposedly pricier model.

Read that again, because I had to. The "cheap" model cost more to run than the expensive one.

Why does this happen? Verbosity and turn count. The Decoder, summarising the same data, points out that Flash averages 49 agentic turns per task, more than any other model tested. Gemini 3.1 Pro needs 23 for the same work. Every one of those extra turns is tokens, and reasoning tokens bill at the output rate. The model is fast, but it is relentlessly chatty, and chatty gets expensive fast when you're paying per word. It's the same pricing-creep pattern I flagged when I reviewed DeepSeek V4, except this time it's hiding inside a model that's marketed as the budget option.

Here's my honest read. The entire point of a Flash-tier model is "cheap and fast". If Flash is this token-hungry, the cheap half of that promise is just broken. And if it isn't cheap, the main reason to add it to your stack mostly evaporates. Speed alone doesn't pay the API bill at the end of the month. You can claw some of this back with tighter prompting, and good prompt discipline matters more than ever here, but you shouldn't have to fight the model to hit the price it advertises.

Should You Switch? My Google Antigravity 2.0 Review Verdict

Let me give credit where it's genuinely due first.

Google's published benchmarks hold up. When independent testers re-ran them, the scores matched to the decimal. No benchmark fudging, no creative interpretation. Gemini 3.5 Flash really does beat Gemini 3.1 Pro on most of the tests Google chose to put on its slides.

The catch is that phrase, "chose to put on its slides". On Artificial Analysis's broader Intelligence Index, Flash ranks around #7 to #8 overall, sitting behind GPT-5.5 and Claude Opus 4.7. And on SWE-Bench Pro, the benchmark closest to real-world refactoring work, Opus 4.7 leads it comfortably, 64.3% to 55.1%. Fast and smart, yes. Frontier-leading, no. The gap between "wins the benchmarks Google picked" and "wins the benchmarks generally" is the whole review in one sentence.

So would I switch? No. And it's honestly not really about the launch bugs, which Google will presumably patch.

I already run Claude, ChatGPT, OpenCode, and Cursor. That's four subscriptions, four tools I know well, and frankly more than I need already. For Antigravity 2.0 to earn a fifth slot it would have to do something those four can't, and even with the short run the quota allowed me, I can't tell you what that thing is. The parallel multi-agent orchestration is the closest candidate, but it isn't worth a fifth bill when the token cost is this unpredictable. I've said the same about other shiny new model launches that arrived with more hype than substance.

Who might it actually suit? Someone with no existing agentic-coding stack who wants quick scaffolding and doesn't mind a few rough edges. If you're starting from zero, the free public preview is a reasonable look and costs you nothing but time. If you've already got tools you trust, Antigravity 2.0 doesn't add anything you're missing.

Fair caveat to close on: this is one week post-launch. I couldn't fully stress-test pricing in practice because, well, I ran out of tokens trying. Google has said Gemini 3.5 Pro is coming around June 2026, and that's the point where I'd revisit all of this properly. Until then, I'm keeping my four subscriptions and skipping the fifth.

I watched the videos walking through Workers and the new CLI, read the docs, and built a real worker against a Shopify store I help with. This article is the version of that work I'd hand to a client asking whether they should care.

I'll cover what Notion actually shipped, why it matters if you're running a small business on top of Notion already, and where Custom Agents plus Workers genuinely change what's possible for SMB automation. Then I'll walk through the build with code excerpts and the CLI commands that mattered.

The thesis up front, because I hate articles that bury it. Workers don't make Notion the right tool if it wasn't already. But if Notion is already where your business operates, this is the most consequential thing Notion has shipped for developers, period.

What Notion Actually Launched

On May 13, Notion launched four things at once under the Developer Platform banner. Notion Workers is a hosted Node/TypeScript runtime where you write a small program and Notion runs it on their infrastructure (Vercel Sandbox under the hood, according to Vercel). The ntn CLI is the only way you interact with it. The External Agent API brings Claude Code, Cursor, Codex, and Decagon into Notion as workspace participants. And the Agent SDK, still on a waitlist, goes the other direction so you can embed Notion's agents into your own products.

The Workers SDK gives you six primitives. A worker is a single TypeScript file that wires up some combination of them:

• worker.database() declares a Notion database whose schema lives in your code.
• worker.sync() pulls data from an external API into that database on a schedule.
• worker.tool() exposes a function a Notion Custom Agent can call.
• worker.webhook() exposes an HTTPS endpoint other services can post to.
• worker.oauth() configures OAuth 2.0 against any third-party API.
• worker.pacer() is a built-in rate limiter for your outbound calls.

You write one src/index.ts that exports a Worker, run ntn workers deploy, and that's the whole pipeline. No Dockerfile. No CI. No log shipping setup. ntn workers runs logs <id> is your observability layer, which is either liberating or terrifying depending on your background.

Why this isn't just another Notion API update: until now, if you wanted Notion AI to do something Notion didn't ship as a built-in connector, you either hosted a Model Context Protocol server yourself or you didn't. Workers replace that pattern entirely. You write a function, attach the worker to a Custom Agent, and the agent calls it. That's the actual unlock.

What are Notion Workers?

Notion Workers are TypeScript programs that Notion hosts and runs in a sandboxed runtime. A single worker can sync external data into a Notion database, expose deterministic functions as tools for Notion's AI agents, and receive webhooks from outside services. You deploy them with the ntn CLI and they run on Notion's infrastructure with no servers, queues, or containers to manage.

What is the Notion CLI?

The ntn CLI is Notion's command-line tool for the Developer Platform. It scaffolds Worker projects, deploys them, manages secrets and OAuth, triggers syncs for testing, and inspects run logs. It's available on every Notion plan including Free for direct API calls. Deploying Workers requires the Business plan or higher.

Why Notion Already Owns Small Business Operations

Step back from the developer angle for a second. The reason Workers matter at all is that a surprising number of small businesses already run their operational layer on Notion. Not just docs. Not just notes. The whole "where work actually happens" surface.

Documentation and wikis is the obvious one. Onboarding docs, SOPs, meeting notes, runbooks. Notion's block editor and nested pages beat every alternative for non-engineering teams, and AI search across the workspace makes that content genuinely useful instead of a graveyard of stale pages nobody opens.

Then there's the lightweight database story. Content calendars, light CRMs, project trackers, customer feedback logs. You get table, kanban, calendar, gallery, and timeline views from the same underlying data, and most small teams never need anything more sophisticated than that.

Agencies and consultancies have been quietly building entire client-facing operations on Notion for years. Per-client workspaces, deliverable tracking, project portals, retainer dashboards. With Workers, you can now sync each client's billing and time tracking into their portal without resorting to Zapier glue.

Marketing teams run content calendars where briefs, drafts, SEO targets, and publishing dates all live in one place. Sales teams under a hundred contacts run lightweight CRMs from it. Customer support uses it for knowledge base pages that the team and customers both reference. Finance teams build dashboards summing Stripe and bank data into a monthly view. None of these are best-in-class against dedicated tools, but the value of having them all in one searchable workspace beats best-in-class fragmentation for most small teams.

The honest counterweight: heavy relational data above a few thousand rows gets slow. Real project management with dependencies and sprint planning stays Linear or Jira territory. CRM at any serious scale needs Attio or HubSpot. The Electron app is famously laggy on older hardware. Data portability is a known weak point because Notion's export-to-Markdown degrades structure and the underlying block format is proprietary.

If you've ever tried to migrate off Notion after a few years, you know.

What is Notion best for in small business?

Notion is best for small businesses needing a unified workspace covering wikis, lightweight project management, content calendars, simple CRMs, and AI-augmented knowledge search. It particularly shines for teams under fifty people, agencies running client portals, and content-driven businesses where docs and operational data live side by side. It's a poor fit for heavy relational data, scaled CRM, and engineering-team project management.

The pattern I keep seeing in SMB stacks: Notion as the operational hub, Stripe or Shopify as the financial source of truth, GitHub or Linear for the engineering work that doesn't belong in Notion, Slack for the synchronous stuff. Workers connect the first one to all the others in a way that finally feels native. If you want the bigger picture on how this fits the broader landscape, I wrote a piece on AI agents for small business in 2026 covering the surrounding ecosystem.

The AI Automation Shift That Workers Unlocks

This is where I think the article needs to land hardest, because this is the actual story. Three phases of small business automation, roughly.

The first era was Zapier-style trigger and action. Something happens in app A, do something in app B. Mostly mechanical, mostly worked, mostly billed by the task. Fine until your "if this then that" turned into "if this then check three things and maybe do one of four things depending on context", and then you were eight Zaps deep in something nobody understood six months later.

The second era was AI agents that could read your data. Notion Agent, ChatGPT with connectors, Claude with MCP. Useful for summarisation and Q&A across your workspace, but they couldn't actually do anything beyond what their built-in connectors supported. Want the agent to look up an order in your custom commerce platform? Tough.

The third era is right now: AI agents that can call your code. That's what Workers add. A Custom Agent runs in your workspace, you ask it a question, and underneath it calls a deterministic function you wrote that hits Shopify, Stripe, your internal database, whatever, and returns structured data the agent then summarises for you. From Notion's own framing, Workers are deterministic, which makes them more reliable than LLM reasoning and a fraction of the token cost.

The before-and-after is concrete. Before Workers, a "what's this customer's history?" workflow meant gluing together a Shopify lookup, a support inbox query, an email thread search, and somebody's memory. After Workers, you type the question in Notion and the agent calls a function that aggregates all of it. Same data, different effort.

For online retail specifically the implications spiral outward fast. Order lookups, refund pattern analysis, customer LTV summaries, churn risk flags, restock recommendations. I went deeper on what this means for online stores in agentic commerce in 2026, but the short version is that the agent layer is finally getting cheap enough to deploy on actual SMB workflows.

Can Notion Workers replace Zapier?

For workflows where Notion is one end of the pipe, often yes. Workers handle Notion-attached automation more cleanly than Zapier with better code quality, version control, and AI agent integration. For arbitrary SaaS-to-SaaS workflows where Notion isn't involved, Zapier still wins on prebuilt integrations and accessibility for non-developers. The honest split is to keep your "Slack to Twilio to Google Sheets" Zaps on Zapier and build new Notion-adjacent automation as Workers.

A Hands-On Build

OK enough abstract. Here's the actual worker.

The brief: I wanted to ask a Custom Agent in Notion "what's the history of jane@example.com?" or "how bad was our refund week?" and get a real answer, backed by actual Shopify data, without anyone alt-tabbing to Shopify admin. One worker, three capabilities. A managed Notion database that holds Shopify orders, a sync that keeps it current every fifteen minutes, and two tools the agent can call.

The whole worker is one file. Here's the skeleton, with the verbose middle bits trimmed so you can see the shape:

Four blocks. The full source is on GitHub, so I'll skip the rest and call out the bits worth understanding.

The sync. The execute function pulls orders from Shopify, transforms them into upsert changes, and returns them. The piece worth knowing about is the cursor pattern. Shopify's updated_at index is eventually consistent, which means if you naively store "the latest updated_at I saw" as your cursor, you'll occasionally miss records that get indexed a second or two late. The Notion docs recommend holding your cursor a buffer behind "now" (I use fifteen seconds) so those records have time to settle before the next cycle picks them up. Within a single cycle, I follow Shopify's Link: <…>; rel="next" header for pagination because page_info can't be combined with other filters. This took me longer to get right than the rest of the worker combined.

The tools. Each tool is a function with a JSON schema for its input. The agent picks one based on the conversation and calls it with arguments it generates. Here's the meat of getCustomerSnapshot:

Two things to internalise. First, readOnlyHint: true lets the agent execute this tool without asking the user for permission each time, which is right for read-only lookups. Write tools should leave it off so the agent has to ask. Second, the description and the schema descriptions are what the LLM reads to decide whether to call the tool. Treat them like API documentation written for a literal-minded colleague who hasn't had coffee yet.

The CLI commands that mattered. Not a tour, just the five I actually touched:

The local sync trigger is the most underrated. It runs my code against Shopify but doesn't write to Notion, so I can dry-run, inspect transformed output, and fix bugs without polluting the database. --preview does the same thing post-deploy.

The moment it actually works. After deploying, I created a Custom Agent in Notion, attached the worker, and enabled both tools. Then I typed in a Notion page: "What's the order history for [customer email]?" The agent called getCustomerSnapshot, got back a structured payload (eight orders, $340 lifetime value, two refunds, VIP flag), and wrote that into the page as a clean summary. Question to answer, maybe four seconds.

This is the bit I struggled to communicate to people who weren't already on Notion. It's not "automated Slack message when a customer signs up." It's a real-time, conversational interface to your own business data, where the agent figures out which tool to call and what arguments to use. The Zapier comparison breaks down because Zapier was never trying to do this.

Going further. A webhook for refund events is in the repo as webhook.going-further.ts. It receives Shopify's refunds/create event, verifies the HMAC, and creates a triage page in a separate managed database. From there the obvious next moves are more tools (product performance, churn risk, cohort metrics) and a scheduled Custom Agent that builds a daily briefing page.

The whole thing took me about two hours, most of which was reading docs and untangling Shopify's pagination. The code is shorter than this article section about the code.

The Honest Verdict

I've been using this for less than a week, so anything I tell you about reliability or hidden gotchas is preliminary. Here's where I've landed after one real build and several reads of the docs.

Adopt now if you're already on Notion Business or Enterprise, you currently glue with Zapier or hand-rolled scripts, you use Custom Agents and have hit the limits of built-in connectors, or you run an agency delivering client-facing dashboards. The August 2026 free window is a gift. Use it to learn the surface before the meter starts.

Wait if your source of truth lives somewhere else (Salesforce, HubSpot, a custom app) and you use Notion lightly. You'll be better off keeping integration logic in your actual source of truth instead of building a Notion-shaped layer on top.

Skip if vendor lock-in is a hard line for you, or your workflows don't touch Notion at all. Workers code is @notionhq/workers-specific and won't run anywhere else without rewriting. Every worker you ship deepens the commitment.

The cost reality is straightforward but the unknowns matter. Business plan at $20 per user per month is the floor. Custom Agents already moved to credit-metered billing on May 4 at $10 per thousand credits. Workers join the same meter on August 11, 2026. Notion has said per-call Workers cost will be a fraction of agent token cost but hasn't published numbers. For a small store running something like the example above, I'd budget $5 to $15 a month in credits, but verify against your own usage during the free beta.

How much do Notion Workers cost?

Notion Workers are free during the beta through August 11, 2026. After that they join the Custom Agent credit system at $10 per 1,000 credits, purchased as a workspace add-on. Workers themselves cost less per call than full agent runs because they're deterministic code, not LLM reasoning. The Business plan at $20 per user per month is required to deploy Workers at all.

What I'm watching over the next six months: the August credit pricing, whether Notion publishes hard operational limits (concurrent executions, CPU time, response size are all currently unspecified), the first SLA, and whether a marketplace emerges. The platform is two days old at the time of writing. It deserves benefit of the doubt and skepticism in equal measure.

Workers won't replace your entire stack. They probably won't replace Zapier either, unless most of your Zaps already had Notion on one end. What they will do, if Notion is already where your business actually operates, is turn it from a great document-and-database tool into a genuinely programmable workspace where AI agents can call your code on real data. For the Shopify stores I work with, that's enough.

This is the answer.

Claude Code hooks let you wire deterministic shell commands and LLM evaluators into specific points in the agent's lifecycle. Not suggestions. Guarantees. The thing that's supposed to happen, happens, every time, without the model deciding whether to bother.

I've spent the last few weeks migrating things out of CLAUDE.md and into hooks, and the difference is hard to overstate. Claude went from "fast typist I have to babysit" to "teammate I can leave alone for a couple of hours". This piece walks you through how to get there. It's structured as four stages of adoption, from the 5-line formatter every project should ship today, all the way up to forced verification that genuinely changes how you work with AI.

We'll also cover what translates to Codex and OpenCode at the end, because hooks are slowly becoming a category, not a Claude-specific feature.

How Claude Code Hooks Actually Work

A hook is a configuration entry that tells Claude Code to run something (a shell command, an HTTP call, an MCP tool, a Claude prompt, or a full subagent) when a specific event fires in its lifecycle.

If you've used git hooks, the mental model is the same. You wire a script to a known checkpoint, and that script runs every time Claude reaches it. The difference is that Claude Code has dozens of these checkpoints, where git gives you a handful, and the script has structured data about what Claude was about to do or just did.

The simplest possible hook looks like this: "before any Bash command, run my script". Your script gets the command Claude wants to execute on stdin as JSON, and decides whether to allow it, modify it, or block it. That's the whole API. Everything else is just variations on which event you're hooking, and what your script does with the JSON it receives.

So the question becomes: which events are available, and what shape is the data?

The lifecycle is bigger than most articles let on. As of v2.1.116 there are 27 events, but for practical purposes they fall into five buckets:

• Session lifecycle: SessionStart, SessionEnd, Setup
• Agentic loop: PreToolUse, PostToolUse, PostToolBatch, Stop, StopFailure
• Permissions: PermissionRequest, PermissionDenied
• Subagents and teammates: SubagentStart, SubagentStop, TeammateIdle, TaskCreated, TaskCompleted
• System events: PreCompact, PostCompact, FileChanged, ConfigChange, Elicitation, and a handful of others

If you're wondering which one to use for a given idea, 90% of the time it's PreToolUse, PostToolUse, or Stop. Worry about the rest later. The full list lives in the official hooks reference if you want it.

There are five handler types: command (shell command, the default), http (POST to a URL), mcp_tool (call a connected MCP server tool), prompt (single-turn LLM evaluator, runs Haiku by default), and agent (full subagent verifier, marked experimental). Most production hooks are command type, and that's what I'll show in examples below.

Hooks live in JSON config files in this priority order: user-global at ~/.claude/settings.json, project-committed at .claude/settings.json, project-gitignored at .claude/settings.local.json, then managed enterprise policy, then plugins. All hooks merge additively. Higher priority doesn't replace lower priority; everything that matches an event runs.

The protocol is simple. Your hook reads JSON from stdin (session ID, tool input, transcript path, and so on), does its thing, and communicates back through:

• Exit code 0: success, optionally with JSON or plain text on stdout
• Exit code 2: blocking error, stderr is fed back to Claude
• Structured JSON like {"hookSpecificOutput": {"permissionDecision": "deny", "permissionDecisionReason": "..."}} for fine-grained control

One concept catches everyone out: matchers. They look like regex but aren't, unless they contain regex metacharacters. mcp__memory matches no tool. You need mcp__memory__.*. The cleaner alternative added in v2.1.85 is the if field, which uses permission-rule syntax: "if": "Bash(git *)" only fires for git commands, "if": "Edit(*.ts)" only for TypeScript edits. Use it.

Stage 1: Format and Lint on Every Edit

Start here. Every project gets this hook on day one, and you keep it forever.

That's it. After every file edit Claude makes, oxfmt formats and oxlint runs with autofix. Prettier and ESLint work fine here too, but I've moved everything to the oxc tools lately because they're written in Rust and absurdly fast. That matters because hook latency lives in Claude's hot path. A hook that takes 3 seconds adds 3 seconds to every single tool call.

A few details that matter:

Use --no-install so a missing devDep fails fast instead of triggering a mid-session install you didn't ask for.

Anchor scripts to $CLAUDE_PROJECT_DIR when you have anything more complex than this. Quote the path. Spaces happen.

Don't put tsc --noEmit here. It's the most common trap I see. Typecheck takes 10 to 30 seconds on a real codebase. Multiply that by the 50 file edits Claude makes during a feature, and you've added 25 minutes of wall-clock time for type errors that were going to be caught by the Stop hook anyway. We'll get to that in Stage 4.

If you're on Bun like me, swap npx --no-install for bun x. Same semantics, slightly faster cold start, and you stop seeing npm's "found 0 vulnerabilities" output noise in your hook logs. For Go projects, the equivalent is gofmt -w "$(jq -r .tool_input.file_path)" plus optionally goimports. Same shape, different toolchain.

The whole thing is honestly less interesting than the section length suggests. But it's the obvious starting point, and it's also the only hook 90% of developers ever set up. The next three stages are where the actual leverage is.

One unsexy upside that surprised me: PR review feels different. You stop reading auto-formatted diffs, and Claude stops "fixing" formatting that wasn't broken in the first place. Signal-to-noise on AI commits goes up immediately.

Stage 2: Security and Guardrails

This is the section that justifies hooks not being optional.

In October 2025, GitHub issue #10077 was filed by a developer who watched Claude Code run rm -rf on their home directory. November 2025 brought #12637, where Claude created a literal ~ directory and a later glob expansion took down everything in the user's actual home. Both incidents happened in standard permission mode, not bypass mode. Both are tagged area:security/bug in Anthropic's tracker. They are not theoretical.

The fix is one PreToolUse hook, deployed at user level so it applies to every project:

Add patterns as you find them. Mine has grown to about 15 entries over time. Things that get caught: rm -rf of any flavor, force-pushes to protected branches, writes to .env files, git commit --no-verify, chmod 777 on anything, and the occasional dd if=/dev/zero from when Claude got creative about "freeing up disk space". (True story, my SSD survived.)

The reason this is so important goes deeper than "Claude makes mistakes". The model genuinely doesn't understand the OS-level consequences of path expansion. When it sees rm -rf $TARGET_DIR and TARGET_DIR=~/proj, the unsetting of that variable somewhere upstream is invisible to the model. The hook sees the expanded form and stops it.

Now the killer feature: a PreToolUse hook returning permissionDecision: "deny" blocks the tool even under --dangerously-skip-permissions.

That sentence is worth re-reading. I've written separately about how dangerous that flag actually is, so I won't rehash it here. The short version: bypass mode disables the interactive prompts and the auto-mode classifier. It does not disable hooks. So you can run Claude in a sandboxed worktree with --dangerously-skip-permissions for genuine YOLO speed, and your destructive-command guard still has the final word. This is the basis of what the community calls "Safe YOLO". I do most of my heavy refactoring this way now. It's fast, and it's hard-to-impossible to nuke your machine with.

A complementary pattern: .env and .git/ write protection. Add to the same hook. Different incident, same logic. You don't want Claude curiously inspecting your AWS credentials, and you definitely don't want it editing .git/objects because it decided the repo state was confusing.

Stage 3: Logging and Observability

Now we're past safety and into "what is Claude actually doing". Hooks are the only honest answer.

A PostToolUse hook with no matcher, appending each tool call to a JSONL file:

Five lines, complete audit trail. The async: true means it doesn't block the agent loop, which matters because you'll have hundreds of these per session.

The HTTP hook variant posts to a centralized collector instead. Slack webhook, Datadog, your own logger, whatever. Watch the allowedEnvVars field carefully here. This is the credential-leak guard. If you reference $SLACK_TOKEN in your headers without listing it in allowedEnvVars, Claude Code silently replaces it with the empty string. Frustrating the first time, prevents a bad day the second.

Cost tracking is a nice extension. Parse tool_response, increment a counter in ~/.claude/state/usage.json, optionally return decision: "block" once you cross a threshold. I haven't bothered. My usage is well within limits, but if you're running multiple agentic loops overnight it's an obvious win.

Once you have a JSONL audit trail, the answers it gives you are surprisingly useful. "What did Claude do during last night's overnight refactor?" One jq query. "Did Claude touch the auth module while it was supposed to be working on something else?" One grep. Past me would have read the entire transcript file looking for that. Present me reads three lines of audit log.

The honest takeaway: there's no other tamper-evident way to capture what Claude actually did across long sessions. The transcript file works for one session, but it's local and gets compacted. Hooks are the export layer.

Stage 4: Forced Verification with Stop Hooks

This is the section that genuinely changed how I work with Claude. If you stop reading after one part, make it this one.

The problem: Claude says "All done!" and the build is broken. You've all seen this. The standard prompt-engineering response is to add stronger language to CLAUDE.md ("YOU MUST RUN THE TESTS BEFORE STOPPING"), and (per my earlier piece) it does not work. Not reliably. Not for long.

The fix is a Stop hook that runs your real verification commands and forces Claude to keep working if anything fails:

And the script:

A few things to call out. The stop_hook_active check at the start is critical. Without it, you get an infinite loop the first time the gate fails and Claude can't immediately fix it. Every developer who tries Stop hooks has done this once. I've done it twice.

The tail -50 is because Claude doesn't need the full test output, just enough to debug. Keeps the context window lean.

--reporter=basic matters for vitest specifically. The default reporter writes interactive escape sequences that pollute the stderr Claude reads back, and sometimes confuses its parsing of the failure output.

For projects where the verification needs more judgment (does the new code actually solve the user's request, not just "compiles and tests pass"), upgrade to a prompt type hook. It spawns a Haiku evaluator that reads the conversation and returns {"ok": true} or {"ok": false, "reason": "..."}. About a tenth of a cent per fire. Honest about subjective things in a way deterministic shell-out can't be.

A concrete example. When I'm having Claude work on something I built, the deterministic gate runs bun test and bun x tsc --noEmit. That catches the mechanical stuff. But it doesn't catch "Claude implemented the wrong scoring algorithm because it misunderstood the spec". For that, the prompt hook re-reads the conversation and the changed files, then asks itself whether the implementation actually matches what was requested. Slower than shell-out, smarter than tests, and dramatically cheaper than me discovering the issue tomorrow morning.

For the heaviest case, where you need to actually run a tool-using subagent rather than just shell out, there's agent type hooks. Still marked experimental in May 2026, 60-second default timeout, up to 50 tool turns. I use them sparingly because the cost is real, but for overnight refactor verification they're earning their keep.

The Stage 4 pattern is the one that makes Claude feel like a teammate. Once it's wired in, you stop reading "I've completed the task" and start trusting it. Or rather, you don't trust it. The hook does. Same outcome, less anxiety.

If this conceptual neighborhood interests you, my Ralph Loop article covers a related pattern: recursive deterministic loops over probabilistic agents.

Hooks vs Skills, MCP, and Subagents

Hooks aren't always the right answer. Quick decision matrix:

• Hooks: when something must always happen on a lifecycle event. Formatting, blocking, verification, logging, audit.
• Skills: when you're giving Claude how-to knowledge it should consult when relevant. The repository pattern for data access. Your team's commit message conventions. See my Claude Skills guide for the deeper version.
• MCP: when you need external system access. Database queries, APIs, custom tools Claude calls during the task.
• Subagents: when a task needs an isolated context window. Research subagents feeding writer subagents.
• Plugins: when you're packaging hooks, skills, MCP, or subagents for team distribution.

The honest version: sometimes the right answer is CLAUDE.md plus one hook for the invariant that actually matters. Don't over-engineer. Three hooks that always run beat 30 pages of advisory documentation Claude might or might not follow. (Especially when Claude has not, historically, followed the advisory documentation.)

A heuristic I use: if you're typing "Claude must always..." or "Claude should never..." in your CLAUDE.md, that's a hook. If you're typing "When working on X, prefer Y", that's a skill.

What About Codex and OpenCode?

Hooks are slowly becoming a category, not a Claude-specific feature. Worth knowing what travels.

Codex CLI ships hooks now, and the design is almost a direct port of Claude Code's. Same JSON-on-stdin protocol, same exit codes, same additionalContext shape, same hookSpecificOutput structure. The lifecycle is much smaller (six events: SessionStart, UserPromptSubmit, PreToolUse, PermissionRequest, PostToolUse, Stop), and only command hooks are implemented. Prompt and agent types are parsed and silently skipped. Stage 1 and Stage 2 hooks port across with config translation only. Stage 4 verification works for the deterministic case. The LLM-evaluated version waits until Codex implements prompt hooks.

OpenCode does it differently. Plugin-based, not config-based. You write TypeScript modules in .opencode/plugins/ that export an async function returning event handlers. The closest equivalents to PreToolUse and PostToolUse are tool.execute.before and tool.execute.after, and you block by throwing an Error (no JSON permission decision). About 25 events available, plus a clean session.idle and an experimental compaction hook that lets you replace the compaction prompt entirely.

OpenCode is genuinely lovely if you're already in TypeScript-land. Type-safe Plugin interface, Bun's $ shell helper baked in, npm distribution. The format-and-lint and security guardrail patterns translate directly. Forced verification with Stop hooks does not, because OpenCode doesn't let you force the agent to keep working after it's idle.

Same fundamental insight in all three (deterministic shell-out at lifecycle events beats prompting), three different implementations, and the Claude Code surface is by some distance the most mature.

Practical bottom line for portability: if you're picking up Claude Code hooks because you might switch tools later, write your hooks as standalone shell scripts in a .claude/hooks/ folder, not as inline command strings. The scripts move to Codex with config translation only. They don't move to OpenCode (different runtime, different API), but at least you're rewriting logic, not archaeology.

Gotchas Worth Knowing Before You Ship

The kind of thing worth a screenshot:

• Stop hook infinite loops. Always check stop_hook_active at the top of the script and exit 0 when it's true. Every developer learns this once.
• PostToolUse can't undo. By the time it fires, the file is already written. Use PreToolUse for prevention, PostToolUse for reaction.
• Last-write-wins on updatedInput. If multiple PreToolUse hooks rewrite the same tool's input, the order is non-deterministic. Don't have two hooks fighting over the same field.
• additionalContext has a 10,000-character cap and stales on resume. Time-sensitive data goes in SessionStart (which re-runs with source: "resume"), not in PostToolUse (which replays the saved string).
• Shell profile pollution. An unconditional echo in ~/.zshrc will end up in your hook's stdout and break JSON parsing. Wrap interactive output in [[ $- == *i* ]] and your hooks will stop mysteriously failing.
• macOS notification permission. osascript -e 'display notification "..."' routes through Script Editor, which needs explicit notification permission in System Settings. Your hook doesn't tell you this is missing. Notifications just silently don't show up, and you wonder why your beautiful Stop alert never fires.

Where to Start

Add the Stage 1 formatter today. It takes five minutes. Add the Stage 2 Bash guard this week, in your user-global ~/.claude/settings.json so it applies everywhere. Add Stage 3 logging when you start running Claude unattended or shipping its work to teammates. Add Stage 4 verification when you want to trust Claude with longer sessions.

The whole thing is the deterministic layer that makes the rest of your AI coding setup actually reliable. Once it's in place, you start running Claude longer, paying less attention to formatting nitpicks, and reading "I'm done" with the confidence that comes from knowing the gate confirmed it. Worth the fifteen minutes of config.

I'll be honest, I had started to wonder if a new DeepSeek model was even coming. They went so quiet that I assumed they were either cooking something extraordinary or had hit a wall. Turns out it was the first one. Mostly.

Short version up top, because that's what I'd want from a colleague: DeepSeek V4 is the best value AI model on the market right now, but it's not the best coder. If you've got volume, it's a no-brainer. If you've got a hard problem, you're still better off with Claude or GPT-5.5.

Here's what I found after running V4 through the three tests I now use for every new model release.

What DeepSeek V4 Actually Is

DeepSeek V4 isn't one model, it's two. Both are open weights, both are MIT-licensed, both ship with a 1 million token context window by default.

V4-Pro at 1.6 trillion parameters is the largest open-weights model anyone has shipped to date, ahead of Kimi K2.6 and GLM-5.1. The architecture is genuinely new, not just V3 with more layers. DeepSeek built a hybrid attention system (CSA + HCA) that uses about 27% of the per-token compute of V3.2 at 1M context, plus they trained directly in FP4 instead of quantising afterwards. The full technical report is on the Hugging Face model card if you want the actual maths.

The reasoning model line is folded in too. Instead of picking between deepseek-chat and deepseek-reasoner like before, V4 has three reasoning modes: Non-Think, Think High, Think Max. And tool calls now work inside thinking mode, which R1 couldn't do.

What's missing

No multimodal. Text in, text out. If you need vision, look at Kimi K2.6 or Gemini.

Also, mildly annoying: the model card doesn't ship with a Jinja chat template, so plan for that in your tokenisation pipeline. Small thing, but it'll catch you out if you assume it works like every other recent release.

Hands-On Testing: My Three-Workload Rig

Benchmarks tell you about benchmarks. They don't tell you whether the thing will actually do your job. So I've settled on three tests I run on every new model, picked because they cover most of what I use AI for in a normal week.

1. Codebase audit. I have it audit my own blog, which is React Router 7 framework with TypeScript. Real code, real complexity, things I genuinely care about being right.
2. Logic-heavy terminal app. A poker simulation that runs thousands of hands and returns statistics. Tests reasoning, structure, edge cases.
3. Web design from cold. Two different prompts to see how the model handles aesthetics and layout.

Here's how V4 did on each.

Test 1: Codebase Audit

Okay, but not great.

V4-Pro found a handful of real things, but it also flagged a bunch of stuff that wasn't actually a problem. Things like style nitpicks, or "consider extracting this" suggestions in places where extraction would make the code worse. Meanwhile it missed a couple of things that both GPT-5.5 and Claude caught the first time around.

GPT-5.5 is still my pick for code audits. It's the most thoughtful about what's actually a bug versus what's just different from how it would have written it. V4 tends toward over-flagging, which is exhausting when you've got a real codebase to triage.

This matches the benchmarks, by the way. On SWE-Bench Pro (the harder, more realistic coding eval), V4-Pro lands around 55%, behind Claude Opus 4.7 (64.3%), Kimi K2.6 (58.6%), and GLM-5.1 (58.4%). The headline SWE-Bench Verified number is essentially tied with Claude, but the harder benchmark tells the truer story.

Test 2: Poker Simulation

This one was closer. The code worked, the statistics came out right, the structure was reasonable. V4 didn't fall over.

But Claude and GPT-5.5 both did it better. Cleaner separation between the simulation core and the reporting layer, fewer iterations to get to working code, slightly more idiomatic Go. V4's version felt like a competent junior engineer's first pass that you'd then refactor. Theirs felt like something a senior would commit.

Not bad. Just not first.

Test 3: Web Design (Two Builds)

This is where it got interesting.

I gave V4 two prompts. First, a coffee roaster website. Second, a modern pop culture online shop.

The coffee roaster came out almost spookily similar to what Claude would produce. Same warm earth-tone palette, similar serif-and-sans pairing, that whole "we take our beans seriously" vibe. But the layout was cookie cutter. Hero section, three feature cards, story block, footer. Boring. The kind of design you've seen a thousand times.

The pop culture shop, though, was genuinely good. Striking layout, confident typography, played with grid in interesting ways. I'd happily ship it as a starting point for a real project.

The takeaway I keep chewing on: V4 can clearly do great design. It just defaults to safe templates unless the prompt subject pulls it somewhere distinctive. Coffee roaster apparently lives in the boring-template region of its training data. Pop culture shop apparently doesn't. Worth knowing.

What I learned from testing

Pattern: V4 is competent on everything, outstanding on nothing. Which is exactly the right shape for a value model. You wouldn't pay Opus prices for "competent." But at $0.14 per million input tokens for Flash, "competent" is an absolute steal.

For coding specifically, Claude (Opus 4.7) and GPT-5.5 still win on quality. For everything else where the answer doesn't have to be perfect, V4 is hard to beat.

Benchmarks That Actually Matter

A quick run through the benchmarks worth paying attention to, because there's signal in here even if it doesn't override what I saw in testing.

• SWE-Bench Verified: V4-Pro 80.6%, basically tied with Claude Opus 4.6 (80.8%).
• SWE-Bench Pro (the hard one): V4-Pro ~55%, behind Opus 4.7 at 64.3%, Kimi K2.6 at 58.6%, GLM-5.1 at 58.4%.
• Artificial Analysis Intelligence Index: 52, which makes V4-Pro the second-best open-weights model behind Kimi K2.6 at 54. Full breakdown on Artificial Analysis.
• LiveCodeBench: 93.5, the highest reported number on this benchmark.

One footnote that doesn't get enough airtime. The US government's CAISI evaluation at NIST ran V4-Pro on held-out, non-public benchmarks and placed it closer to GPT-5 (about 8 months old) than to GPT-5.4 or Opus 4.6. Treat the headline benchmark equivalence as an upper bound. There's likely some public-benchmark overfitting going on, which is normal but worth knowing.

The other thing to flag: V4 hallucinates more than its peers when it doesn't know something. The AA-Omniscience eval clocks it at a 94% hallucination rate when uncertain. Translation, when V4 isn't sure, it doesn't tell you, it just answers. For RAG and research workflows, ground it explicitly.

How V4 stacks up against the open-weights pack

Quick read: Kimi K2.6 is the smartest open model overall, GLM-5.1 wins long-horizon agentic work, V4 wins on price plus context length. They're all genuinely useful for different things.

Pricing: Where V4 Actually Wins

This is the part that matters most.

V4-Flash is the cheapest input price you'll find on a frontier-tier model anywhere, beating even GPT-5.4 Nano. V4-Pro is the cheapest of the larger frontier models. And cache hits are 99% off, which is huge for agentic workflows that resend big system prompts.

To make this concrete: a Hacker News commenter on Simon Willison's V4 review ran a full layer-by-layer audit of a TypeScript endpoint (API, DTOs, service, database models) for $0.09 on V4-Pro. The same audit on Claude Opus 4.7 would have cost roughly $9 to $13. That's a 100x ratio.

One caveat though, V4 is verbose. To complete the Artificial Analysis Intelligence Index, V4-Pro burned 4 to 5 times the median output tokens. The headline per-token price oversells the real bill. It's still cheaper than the alternatives, just not by quite as wild a margin as the sticker suggests.

Easiest ways to actually use V4

If you just want to try it, two easy paths.

The simplest is the OpenCode Go subscription, which I reviewed a while back. V4 is included in the plan, no API keys to set up, and you get a proper terminal coding agent out of the box.

Otherwise, the DeepSeek API itself is genuinely cheap and trivial to set up. Point any Anthropic-compatible client (Claude Code, OpenCode, OpenClaw) at the DeepSeek base URL with your API key and it works as a drop-in. That's it.

The Verdict: When to Use V4, When Not To

Use V4 for:

• High-volume API workloads where cost matters more than tail quality
• Agentic background work running 24/7
• Long-context tasks above 200K tokens
• Anywhere open weights or on-prem deployment is a hard requirement

Don't use V4 for:

• Code audits where missing a real bug is expensive (GPT-5.5 still wins here for me)
• Hard reasoning steps like research-grade math (GPT-5.4 or Gemini 3.1 Pro)
• Big-codebase production edits where SWE-Bench Pro matters (Claude Opus 4.7)
• Anything multimodal

V4 is the new default workhorse, not the new champion. The bar for "good enough cheap model" just got a lot higher, and that pulls the price-quality curve into a useful new shape. You can route 80% of your agentic and coding traffic to V4 and reserve Opus or GPT-5.5 for the genuinely hard sub-tasks where the 10x to 20x cost premium actually buys you something.

For my own work, the stack I'm settling into looks like: V4-Flash for bulk and background stuff, V4-Pro for medium-hard work, Claude Opus 4.7 or GPT-5.5 when the answer has to be right the first time.

DeepSeek themselves admit in their technical report that V4 trails the absolute frontier by 3 to 6 months. CAISI's data suggests it might be more like 8. Honestly, for most of what most of us do, that gap doesn't matter. The price ratio matters more.

And selfishly, I'm just happy a new strong model shipped. More competition makes everything better for everyone shipping with these tools. Bring on V5.

That's it. That's a Ralph loop. The first time I saw it I assumed I was missing something, because surely a recursive AI agent had to be more complicated than four words and a pipe. It isn't.

What's actually happening here is genuinely strange. You've got a coding agent reading the same prompt over and over, modifying a codebase on disk, and using the file system as its memory instead of conversation history. Run it overnight on a well-specified task and you wake up to a working program, fifty git commits, and a journal of everything the model tried, broke, and fixed. It feels closer to science fiction than anything else I currently use as a developer.

In this article I'll walk you through what a Ralph loop is, how it works, how to actually run one in Claude Code or Codex, and (the part I find most fascinating) what you can read in its journal in the morning. I'll also be honest about where it falls over and where it's the wrong tool entirely.

Geoffrey Huntley, who coined the term, calls Ralph "deterministically bad in an undeterministic world." Once you understand why that's a feature rather than a bug, the rest of this clicks into place.

What is a Ralph loop?

A Ralph loop is a recursive AI agent pattern where a coding agent runs in an infinite shell loop, reading the same prompt file each iteration, modifying the codebase on disk, and using the file system instead of conversation history as its memory. Each iteration starts with a fresh context window. State survives between iterations through the codebase, a TODO file, and git history.

The technique was named by Huntley in his July 2025 blog post, which is still the canonical reference. The name comes from Ralph Wiggum, the cheerful Simpsons character who rams his head into doorframes and announces "I'm helping!" Huntley's framing is that this kind of dumb, persistent loop is surprisingly effective. As Dex Horthy puts it in his history of the technique, "dumb things can work surprisingly well."

(There's a second origin story for the name. "Ralph" is also slang for vomiting, and Huntley has said the realisation of how cheap autonomous code generation had become made him want to. So: Ralph the character, Ralph the verb, both apply.)

Why it's not just a while true loop

Here's the part that took me a few reads to get. The reason this works is fresh context every iteration. That's not a side effect, it's the point.

LLMs degrade as their context fills up. Past somewhere between 100k and 150k tokens, depending on the model, quality measurably drops. Practitioners call this the Dumb Zone. Long agent sessions inevitably drift there, and Claude's auto-compaction, when it kicks in, is lossy. Your specs can quietly get summarised into vagueness without you noticing.

A bash loop sidesteps all of that. Each iteration starts with the exact same allocated context: the same PROMPT.md, the same AGENTS.md, the same specs/*.md files. What changes between iterations is the codebase on disk and a small TODO file. The loop's input is stable while the world (the repo) converges toward the spec. That's why "deterministically bad" matters. The model is reliably mediocre at every iteration, and over time it grinds the codebase into shape.

How it actually works

A single iteration looks like this:

1. Bash reads PROMPT.md and pipes it into the agent.
2. The agent reads fix_plan.md and picks the single most important pending task.
3. It searches the codebase, implements the change, runs the relevant tests.
4. If tests pass, it commits with a structured message and updates fix_plan.md.
5. If something useful was learned about the build or the project, it updates AGENTS.md briefly.
6. The agent exits.
7. Bash restarts the whole thing. Fresh context. Modified codebase.

The single most important rule, repeated across every Ralph implementation I've read, is one thing per iteration. Not "one thing plus a quick refactor while you're in there." One thing. Ask the agent to do exactly one task per loop, and trust it to decide what's most important from the plan file. Try to cram more in and you'll watch it pick the easiest item every time and ignore everything hard.

State survives between iterations through five places:

• The codebase. A green build is the strongest signal that previous work landed.
• fix_plan.md or progress.txt, the working TODO list.
• AGENTS.md or CLAUDE.md, operational learnings.
• specs/*.md, frozen requirements that don't change between loops.
• Git history. Structured commit messages double as a journal.

There are variations. You can run a bounded loop with --max-iterations 50. You can have the agent emit a sigil like <promise>COMPLETE</promise> and grep for it to break out. You can do a two-phase pattern where one prompt does gap analysis with no code changes, and a separate loop implements. You can cron it to "one small refactor every morning" instead of an overnight blitz. They're all Ralph, just different cadences.

Running Ralph in Claude Code, Codex, and other tools

Claude Code

The bash one-liner I opened with is the canonical Claude Code Ralph. The two flags that matter are -p for headless mode (read prompt from stdin, write to stdout, exit) and --dangerously-skip-permissions to bypass approval prompts. Without the second flag, the loop just stops on the first file write.

The trade-off should be obvious. You're handing Claude Code unrestricted shell access to whatever directory you ran it in. Don't do this on your main machine without isolation. Use a Docker sandbox, a devcontainer, a fresh git worktree, or a remote VM. Huntley's framing is that it's not a question of if your loop gets compromised, it's when, and what the blast radius is. He's right.

The supporting cast of files matters more than the bash. CLAUDE.md at the repo root gets auto-loaded into every session and is where you put operational rules. specs/*.md is for frozen requirements. fix_plan.md is the mutable TODO. Keep PROMPT.md short and reference the rest with @filename syntax instead of inlining everything.

Anthropic shipped an official ralph-wiggum plugin for Claude Code in December 2025. It's worth knowing about, but there's a real debate over whether it's the same thing. The plugin re-feeds the prompt inside one growing session via a Stop hook. That's not fresh context per iteration. Horthy's review is blunt: it misses the point. I'd pick the bash version. The plugin does lower the barrier, though, if you want to dip a toe in.

Cost reality: running Sonnet 4.5 in a bash loop with autonomous tool use lands around ten dollars an hour on metered API. If you're going to do this regularly, the Claude Max 20x plan at $200 a month is usually cheaper than running it metered.

OpenAI Codex CLI and the new /goal command

This is the newest piece of news in this space. On April 30, 2026 (three days ago, as of writing) OpenAI shipped Codex CLI 0.128.0 with a /goal command that is essentially Ralph as a first-class primitive.

The behaviour: you set a goal, Codex keeps looping until it self-evaluates the goal as complete, or until the configured token budget runs out. You don't write the bash. The internal templates that drive this are visible in the Codex repo if you want to see how OpenAI prompts the self-evaluation step.

Two ways to ralph in Codex now:

The /goal version is friendlier and probably what most people will reach for. The bash version is more robust for the same reason the Anthropic plugin is debated. /goal is in-session, one growing context window, while the bash version gets fresh context every iteration. If you're doing a long overnight run, I'd still pick bash. For shorter, well-bounded tasks, /goal is great.

Other tools, briefly

The pattern travels to almost every coding agent.

Cursor has a cursor-agent headless CLI that ralphs cleanly. There's also a Cursor plugin that does the in-session Stop-hook variant. Aider doesn't read stdin natively, but you can wrap it: bash -c 'aider --yes-always --message "$(cat PROMPT.md)"'. Aider's --architect mode pairs a planner model with a coder model, which is a natural plan-build split. Goose (Block's open-source agent) ships a first-class Ralph tutorial with cross-model review built in. One model implements, a different model reviews. This is the closest thing to a Reflexion pattern out of the box, and it's the easiest way to ralph with a local LLM via Ollama. GitHub Copilot CLI works for short Ralph runs in programmatic mode. And if you're building a product around this, the Vercel AI SDK has a ralph-loop-agent example that's a clean TypeScript starting point.

Why the journal is where it gets interesting

Most Ralph coverage focuses on what gets built. I think that's the wrong half of the story. The interesting half is what you can read in the morning.

When every iteration commits with a structured message and writes failures to a log, you end up with something I haven't seen from any other AI tooling: a readable, narrative record of what the model tried, what broke, and why it thought it broke. A successful commit is, frankly, boring. The interesting reads are the failures, where the agent spends three iterations chasing a wrong hypothesis, finally figures out the test was misnamed, fixes the test, and moves on.

Here's the logging stack I'd set up:

• Git commit per success, with a structured message: what changed, which test passed, iteration number. This becomes the primary journal.
• .ralph/errors.log per failure, with the agent's own reflection on the cause. Tell it explicitly in PROMPT.md to append to this file when it gives up on an approach, and to include why.
• Append-only progress.md, where the agent is allowed to be opinionated about what's hard or surprising. This is where the personality leaks through.

One concrete tip lifted from Huntley's CURSED prompt: instruct the agent to write the why into test docstrings. Future iterations won't have its reasoning in their context, so the only way to teach the next Ralph anything is to make it readable from disk. After a few hundred iterations, your test suite ends up commenting itself with the agent's archaeology of past mistakes. That's pretty cool, and it's also the most AGI-adjacent thing on my laptop right now.

The morning experience is what makes me keep coming back to this. Coffee, scroll the commits, find three places the agent surprised me, two it embarrassed itself, and one bug it caught that I'd have missed. I won't oversell it as artificial general intelligence. But it's a process running on its own that produces a journal worth reading, and that's a category of experience I didn't have a year ago.

What Ralph is actually good for

The clearest case: measurable, mechanical work

The shared property of every Ralph success story I trust is that the success criterion is a number. Tests passing. Lint count down. Types clean. Coverage up. Build green.

In that mode it works, sometimes spectacularly. The repomirror team shipped six framework ports overnight at a YC hackathon, running six concurrent loops in git worktrees, racking up a thousand-plus commits and about $600 in API spend. Huntley shipped a $50,000 client MVP for $297 in API costs. The CURSED programming language, including a self-hosting compiler, was built over roughly three months of continuous Ralph runs.

The boring middle of the road still works fine: TypeScript strict-mode adoption across a monorepo, ESLint flag flips, dependency upgrades like Jest to Vitest or React 17 to 19, alt-text generation for product images, internal-link passes across a content site. Anywhere the work is repetitive and the verifier is mechanical, Ralph eats it.

The interesting case: fuzzy success, with a judge

Here's the part the standard Ralph coverage skips. The success signal doesn't have to be a function exit code. It can be:

• An LLM as judge. Slower and weaker, but works for prose, copy, and vague aesthetic targets.
• A data source. Lighthouse score, conversion rate, Web Vitals, search ranking.
• A human. You, with coffee, tapping thumbs-up or thumbs-down on yesterday's variant.

Imagine a Ralph loop iterating on your website's design. One small variant per night. In the morning you give it a thumbs up or thumbs down, and the result feeds back into progress.md. Over a month, you've made thirty small, judged design changes, each one a tiny convergent step.

The constraint that makes this work is the same as the coding case: small, focused changes per iteration. Telling the agent to redo the entire site every night is a coin flip. Telling it to nudge one component, one heading, one CTA, one section per night gives you compounding improvement. The same logic applies to copywriting, ad creative, and probably a dozen other places I haven't tried yet.

I'll be honest, though: this is harder to set up well than the measurable-result version. The judge loop has more moving parts. A way to deliver the variant. A way to capture your vote. A way to feed it back to the agent without poisoning context. Today, the function-as-judge case is much easier. The judge case is where I'd bet the interesting product opportunities live.

When Ralph is the wrong tool

A short list, because being honest about this matters more than the tips.

One-shot tasks (just use Claude or Cursor interactively). True exploration where you don't know what you want (Ralph optimises for a green build, not for taste or insight). Brownfield code with strict review processes (the bottleneck is human review of forty-thousand-line PRs, not API tokens). Anything irreversible: production database migrations, deletes you can't undo, financial transactions. UX copy with no judge wired in (the agent will mark itself complete and move on, confidently wrong).

The right mental shortcut, borrowed from Meag Tessmann's writing, is to ask: is the output machine-verifiable? If yes, loop. If no, get a human, or wire up a judge.

Tips so it doesn't waste your token budget

A few hard-won pieces of advice from people who've run thousands of iterations.

Sandbox always. Docker, devcontainer, git worktree, or remote VM. Don't argue yourself out of this. You're handing a non-deterministic process unrestricted shell access. The blast radius is whatever it can reach.

Keep the primary context under 100k tokens. Use subagents for anything that returns a lot of tokens you don't need to keep. A subagent grepping the codebase and returning "here's the function" is much better than the primary agent reading a 4,000-line file. Once the main context drifts past 100k, quality drops measurably.

Two-phase plan/build. Have a separate, one-shot prompt that refreshes fix_plan.md based on a gap analysis against specs/*.md. The loop only ever implements. This is the single biggest reliability upgrade you can make.

Layer your circuit breakers. Max iterations. Per-iteration timeout (15 minutes is a reasonable default). Hourly token cap. Stuck detection (if the same test fails three iterations in a row, stop and notify). Cost cap if you're on the API.

Wire backpressure aggressively. Type-check, lint, tests, build. Anything that returns non-zero rejects the iteration. For dynamically typed languages, adding a static analyser (mypy or ruff for Python, the relevant equivalent for whatever you're using) is non-negotiable.

Don't use --continue or --resume. They defeat the fresh-context guarantee. The whole point of a bash Ralph is that you start clean every iteration.

Set a notifier and walk away. ntfy.sh, a Slack webhook, a macOS notification, whatever you've already got wired up. Watching iteration 47 of 200 is somehow worse than watching paint dry. Tune iterations one through three carefully, then leave. Read the journal in the morning.

Should you try it?

Honest take: Ralph is a young technique. The original blog post is from July 2025. The first vendor support shipped in December 2025. Most of the splashy cost numbers I've quoted are self-reported by the technique's loudest advocates. Thoughtworks' Technology Radar has it as Trial, not Adopt, and they're right to be cautious.

That said: the cheapest possible experiment is a five-iteration human-in-the-loop Ralph on a well-specified, mechanical task. Pick something tiny. A TypeScript file you've been meaning to clean up. A small algorithm with a clear pass/fail. Run a single iteration manually in a sandboxed worktree, read the diff and the commit, then run another. You'll know in thirty minutes whether this fits how you work.

The thing that keeps pulling me back isn't that it codes. It's that it keeps going, and the trail it leaves is genuinely interesting to read. That part feels like the future, and it's already here, in four words and a pipe.

So I built one in TypeScript instead. Around 140 lines, one dependency for the agent framework, calls Claude directly. Point it at a competitor's blog with a topic in mind, and it crawls, scores each page for relevance, and hands back the most relevant ones ranked. The full repo is on GitHub, and there's a mock mode that runs without an API key, which I'll show later.

The interesting bit isn't the crawler. It's the architecture: fetching and LLM scoring run concurrently, not sequentially. While Claude judges page N, the crawler is already pulling page N+1. Plain async/await makes that awkward. A reactive agent makes it fall out for free.

What "AI SEO agent" actually means here

The phrase covers at least three different things. People might mean a content brief generator (give me a keyword, get back an outline). They might mean an autonomous workflow that publishes posts (please don't). Or they might mean a research crawler, which is what this is.

Concrete use case: competitor content gap analysis. You're planning to write about, say, "AI coding tools." A competitor has 200 blog posts. Which of them actually cover that topic well? Reading 200 URLs by hand is not happening. Screaming Frog will tell you which pages exist, but it won't tell you which pages are about what you care about.

That's the gap. An LLM can read a page and judge relevance semantically, not just by keyword overlap. Wire that into a crawler and you get a focused crawl: pages above a relevance threshold contribute their links to the queue, pages below it are dead ends. Five minutes of compute, ranked output.

The output of one of these runs slots cleanly into a normal SEO workflow. Top three competitor pages on the topic? Read them, take notes on what they cover, find what they don't. Score distribution skewed low across the board? You've found a topic gap, write the post. Score distribution clustered tight at the top? Tough niche, you'll need a fresh angle. The crawler doesn't replace judgment, it just makes the input to your judgment manageable.

Why a reactive framework beats sequential await

I'll spend a moment on this because it's the only architectural decision in the project that actually matters.

The naive version

The obvious shape:

Reads fine. Works. Slow. The problem is that fetch and Claude both block, in serial. While Claude is scoring page N (a second or two of latency), nothing is fetching page N+1. While page N+1 is being fetched, Claude is idle. Throughput is the sum of your latencies, not the max.

For ten pages, that's roughly twenty round-trips of dead time.

The reactive version

The reactive shape declares two independent triggers. One fetches when there's a URL in the queue and nothing is currently being fetched. The other scores when there's an unscored page and nothing is currently being scored. Both kick off their async work and return immediately, so the agent loop is never blocked. They run concurrently because there's nothing forcing them not to.

The framework I'm using is agentiny, which I built for exactly this kind of thing. (I wrote up a support ticket triage agent with it earlier, if you want a different shape of example.) The model is when(condition, [actions]). When the condition becomes true, the actions run. State changes re-evaluate conditions. That's it.

For this crawler, the result is real I/O concurrency. Page 4 fetches while page 3 is being scored while page 2's links are being added to the frontier. You can see it in the timestamps when you run the mock test below.

Architecture: three triggers, two mutexes

State shape

frontier and visited are standard crawler bookkeeping. pages accumulates results. The two boolean flags act as mutexes: fetching is true when an HTTP request is in flight, scoring is true when Claude is mid-call. They prevent two of the same kind of work happening at once, which keeps the crawl polite. done is set by the stop trigger.

The triggers

Three triggers, each around 15 lines. Fetch picks up a URL from the frontier and runs an HTTP request. Score takes the next unscored page and asks Claude for a 1 to 10 relevance rating. Stop fires once when everything is quiet.

Why one in-flight fetch and one in-flight score, instead of full parallelism? Two reasons. Politeness: hammering a competitor's site with ten parallel requests is rude and gets you blocked. And cost: parallel Claude calls are easy to fan out, but for ten pages the total wall time is already short enough that fan-out doesn't pay back the rate-limit risk. The mutex pattern gives you something more useful, which is pipelining between two different kinds of work.

The code, walked through

Project setup

That's the whole dependency surface. agentiny for the reactive loop, the official Anthropic SDK for Claude calls. Three source files: crawler.ts (the agent), extract.ts (a tiny HTML parser), and index.ts (CLI entry).

The fetch trigger

The shape is the important bit. The action does its synchronous work (pop the URL, flip the mutex) and then kicks off the HTTP request as fire-and-forget. The .then mutates state in place and calls agent.setState(cur) to wake the loop. Notice it's the same state object, not a spread. That's deliberate, more on that below.

The score trigger

Same shape. The interesting line is the threshold check. If Claude scores the page 6 or higher, its links go onto the frontier. Otherwise the subtree is pruned. That's what makes this a focused crawl rather than a generic one.

A real concurrency bug bit me here while building this. An earlier version used a helper that captured the state reference at action entry, then awaited the LLM call. If another fire-and-forget callback called setState({...cur}) during the await, the captured reference was stale and the mutations got lost. The fix is the mutate-don't-spread pattern you see above: same state reference, mutated in place, setState(cur) only as a signal to wake the loop. Worth knowing if you go reactive with concurrent triggers.

The stop trigger and the runner

The runner uses subscribe rather than agentiny's settle() helper. settle() waits for quiet polling cycles, which doesn't fit fire-and-forget patterns: there can be long quiet gaps while the network and Claude are both busy, and settle resolves prematurely. Subscribing on done and waiting for it to flip is the right signal here.

Running it

Real run, against any site you have permission to crawl:

The interesting part is in the timing. Here's an actual extract from the mock test, with millisecond timestamps:

Look at the 188ms mark. The fetcher just finished /posts and is already onto /about, while the scorer is also working on /posts. By 220ms the fetcher is done with /about and started on /contact, all while the scorer is still chewing on /posts. Three URLs fetched in the time it took the LLM to score one. That's the agentiny payoff in one frame. With sequential await, that 100ms scoring window would have been pure idle time.

Speaking of mocks: the crawler accepts injected fetcher and scorer functions, so you can run it with no API key at all.

This drives the agent against a fake in-memory site of ten pages, with a fake scorer that marks half of them relevant. Useful for CI, useful for trying the project before committing to a key, and useful for debugging the trigger logic without burning tokens. The injection point is just a config option, so the production code path is unchanged.

Where this falls short in production

The repo is a working tutorial, not a production crawler. Things you'd want before pointing it at the open web:

• No robots.txt compliance. Add one before crawling sites you don't own. (This bit is non-negotiable.)
• The HTML extractor is regex-based, which is exactly as fragile as it sounds. Swap in linkedom or cheerio.
• One in-flight request and one in-flight score is conservative. With proper rate limiting and a per-host concurrency cap, you could fan out further.
• No persistence. A crash at page 47 of 100 means starting over.
• Cost: the demo uses claude-haiku-4-5, which is cheap. Don't reach for sonnet here unless the relevance judgements are visibly wrong. The smaller model handles this kind of binary classification fine.

None of these are big lifts. The reactive structure makes them easy to slot in: add a robots check inside the fetch action, wire the frontier through SQLite, add a third trigger for retries.

Wrap-up

That's the whole thing. About 140 lines, real I/O concurrency, mock mode that needs no key, and an honest list of what would break if you took it to production.

Three obvious extensions if you want to keep going. Persist the frontier and visited set in SQLite, so the crawler is resumable. Add a fourth trigger that takes the top-N scored pages and writes a content brief, turning research into draft. Or expose the whole thing as an MCP server, so Claude itself can call it during a chat.

Repo is here, agentiny is here.

I've been writing prompts for design ever since AI coding became viable, and the results have been genuinely hit-or-miss. Some outputs I'd happily ship. Others are exactly the AI slop everyone complains about. Two prompts apart. Same model, same project, same hour of the afternoon.

What changed is that Anthropic shipped an official frontend-design plugin for Claude Code. It's not magic, it's a 4.5KB markdown file, but it consistently lifts the floor on what Claude produces. This is how to use the Claude Code frontend-design plugin without overrating it, the prompting principles that actually move the needle, and how to apply all of this to WordPress and Shopify themes without losing your mind.

I'll also be honest about where it doesn't help, because there are limits.

Why AI-Generated Web Design All Looks the Same

The AI slop fingerprint is pretty consistent. Inter or a system font, a purple-indigo gradient somewhere on the hero, oversized headlines with vague copy, three cards in a row, uniform border radius, shadows at exactly 0.1 opacity. It's the visual equivalent of "in today's fast-paced world" — you've seen it so many times you stop reading.

The reason is statistical. LLMs generate by predicting the most probable next token, and for frontend code that probability mass sits squarely on the design conventions that dominated developer Twitter and Dribbble between 2020 and 2022. Tailwind UI, Linear's Magic Blue, the early Stripe and Vercel aesthetic. That's what got scraped into training data, so that's what gets predicted back.

Adam Wathan, Tailwind's creator, posted a now-famous self-deprecating tweet apologising for picking bg-indigo-500 as Tailwind UI's default five years ago. One default, multiplied by a million tutorials, became the entire AI-generated internet's accent colour.

It's the same dynamic as AI-written content. Certain words give it away — "delve," "tapestry," that em-dash cadence. With AI design, the tells are visual: the font, the gradient direction, the rounded-corner-on-everything reflex. Once you can see it, you can't unsee it. Your visitors can see it too. They just don't know the vocabulary.

What the Claude Code Frontend-Design Plugin Actually Does

When I first heard about the plugin I was expecting some elaborate piece of tooling. Maybe a fine-tuned model, a vision component, a new mode in Claude Code. It's none of that. The whole thing is a single SKILL.md file, about 50 lines of markdown, sitting in Anthropic's public repo. Around 300,000 installs as of late April 2026.

What the file does is make Claude declare its hand before generating any code. It forces a four-question framework — purpose, tone, constraints, differentiation — and demands an actual aesthetic commitment before a single CSS rule gets written. The "tone" question isn't soft either. It lists about a dozen extremes: brutally minimal, maximalist chaos, retro-futuristic, organic, luxury, playful, editorial, brutalist, art deco, soft pastel, industrial, and tells Claude to pick one and execute it precisely.

Then it governs five concrete dimensions:

• Typography — pair a distinctive display font with a refined body font. Avoid Arial, Inter, Roboto.
• Colour and theme — CSS variables for consistency. Dominant colour with sharp accents, not a timid evenly-distributed palette.
• Motion — CSS-only for HTML, Motion library for React. One coordinated page-load reveal beats scattered micro-interactions.
• Spatial composition — asymmetry, overlap, diagonal flow, grid-breaking elements.
• Backgrounds — atmosphere via gradient meshes, noise textures, geometric patterns. Refusing solid colour is half the battle.

The forbidden list is delightfully specific. Inter, Roboto, Arial, system fonts. Purple gradients on white backgrounds. Predictable layouts. Cookie-cutter components. It even calls out Space Grotesk by name, Claude's go-to "anti-Inter", because once you tell it to avoid Inter, it converges on Space Grotesk across every generation. The skill's authors clearly noticed and wrote it in.

This is why it works. It's a forcing function. Instead of letting Claude predict the highest-probability next token, the skill makes it commit to a direction first, then generate tokens consistent with that direction. The median pull weakens. You actually get variance in the output.

How to Install the Frontend-Design Plugin in Claude Code

If you're on Claude Code with plugins enabled, it's a one-liner:

Once installed, it auto-loads on any frontend prompt. You don't have to invoke it manually.

If you want it versioned in your project, which I'd recommend for anything client-facing, drop the SKILL.md file directly:

The nice thing about it being plain markdown is that it's portable. Drop the same file into .cursor/rules/frontend-design.mdc and Cursor reads it. Codex picks it up via AGENTS.md. GitHub Copilot will read it from .github/copilot-instructions.md. Google's Antigravity reads Anthropic-format skills natively.

The skill is the moat, not the product. Whichever agent you've settled on, the same 50 lines of instructions improve the output.

How to Prompt AI for Sophisticated Web Design

Here's where it gets counterintuitive. The biggest prompting mistake I made for the first six months of AI coding was thinking that more specificity meant better output. I'd specify hex codes. Pixel paddings. Font sizes to two decimal places. The output got worse.

It took reading Anthropic's frontend aesthetics cookbook, the prompting half of the same package as the plugin, to understand why. When you fill the prompt with rigid pixel-level specs, you're using up the model's tokens on conservative defaults. There's no room left for creative choice. So Claude does what it's been told and adds nothing of its own. The result is technically correct and visually dead.

Total openness doesn't work either. "Build me a fitness landing page" gets you the statistical mean. AI slop, on a plate.

The sweet spot is principle-based direction. Tell Claude what to think about, not what to produce. Anthropic's cookbook publishes three strategies that consistently produce better output: guide specific design dimensions, reference design inspirations without being prescriptive, and explicitly call out the defaults you don't want.

Here's a side-by-side I run through in my head before any design prompt:

Bad prompt:

Build a hero section with a 1200px container, 80px padding, H1 at 64px Inter Bold, subhead at 18px Inter Regular, purple gradient background from #6366f1 to #8b5cf6, white CTA button with 8px border radius.

This is a recipe for slop. You've handed Claude every default it would have picked anyway and removed any room to surprise you.

Good prompt:

Landing page for a fitness coaching app aimed at busy professionals — people who don't want to live at the gym.

Aesthetic direction: editorial magazine, not SaaS. Pair a serif display font like Fraunces or Playfair with a clean geometric sans for body. Dominant colour: a single warm earth tone with a single sharp accent. One coordinated motion moment on page load, not micro-interactions everywhere.

Avoid: Inter, purple, generic gradients, three-card feature grids.

You've given Claude a direction, purpose, tone, font category, colour family, motion philosophy, and trusted it to make the actual choices inside that frame. The output is dramatically better.

Encouraging the AI to be creative, explicitly, in the prompt itself, makes a measurable difference. It sounds silly. It works. Treat Claude like an intern with great recall and zero context: brief it the way you'd brief a creative team, then let it actually do the creative execution.

The Small Changes That Separate Good Design From AI Slop

After hundreds of generations across personal projects and client work, here's what I've found genuinely matters. The gap between a result I ship and one I throw away is almost always small. Right font, right size jump, slightly different padding rhythm. The plugin gets the bones right. Tuning four levers gets you the last 30%.

In order of impact:

Typography is the single highest-leverage decision. One distinctive font choice is worth ten layout tweaks. The cookbook publishes a targeted typography prompt with curated categories — Editorial (Playfair Display, Crimson Pro, Fraunces), Startup (Clash Display, Satoshi, Cabinet Grotesk), Technical (IBM Plex), Distinctive (Bricolage Grotesque, Newsreader). Pick from a category that matches your project's tone. Don't let Claude pick from its default bag.

Spacing extremes. Size jumps of 3x or more between heading levels, not 1.5x. Weight jumps from 100 to 800, not 400 to 600. The lukewarm middle is what reads as generic, and committing to the extremes is what reads as designed.

One coordinated motion moment. A staggered page-load reveal where elements come in with proper rhythm beats fade-in-up applied to everything. Pick one moment, choreograph it well, and stop.

Backgrounds with depth. Gradient meshes, noise textures, layered transparencies. Just refusing to use a solid background colour gets you halfway to looking intentional.

The depressing part is that most of these are five-minute changes. Right font, slightly more padding, one extra layer of texture. The whole experience flips. I've shipped designs that looked completely different to the first generation and the only thing I changed was the font family and one size scale.

Using Claude Code for WordPress and Shopify Theme Design

A theme has two layers, and AI handles them differently:

1. The aesthetic layer — typography, colour, layout, motion. The frontend-design skill handles this well.
2. The platform integration layer — Liquid, block markup, schema, hooks. The skill alone won't help you here.

Most of the frustration I see online is people trying to solve both with one prompt and wondering why the output is half-broken.

WordPress

For WordPress block theme work, the design pass goes well. You auto-load the skill, give Claude an aesthetic direction, and you get a respectable first draft. The trouble starts on the integration side, because Claude defaults to wrapping everything in raw HTML blocks rather than using native block editor primitives.

Jonathan Bossenger documented exactly this in his April 2026 case study of rebuilding his personal site. Two conversations, dozens of tool calls, theme deployed. Design quality was excellent. The block conversion was the human-in-the-loop part — he had to actively shepherd Claude away from treating WordPress like a static HTML host.

Pair the skill with Automattic's Claude Cowork plugin and WordPress Studio MCP and you'll get proper block markup more reliably. It's not perfect, but it's a real workflow now.

Shopify

For Shopify, the situation got dramatically better on April 9th this year, when Shopify shipped their official AI Toolkit. Free, open source, works with Claude Code, Cursor, Codex, Gemini CLI, and VS Code. It connects your agent to live Admin and Storefront API documentation, validates GraphQL against the actual schema, and handles Liquid theme operations through the Shopify CLI.

Stack the toolkit with the frontend-design skill and you have a real workflow: aesthetic direction from the skill, correct Liquid and schema validation from the toolkit. It handles section edits, colour changes, copy updates, homepage tweaks brilliantly. For genuinely custom interactive sections, you still want a developer writing Liquid by hand.

Architect for theming from day one

If I'm starting a project from scratch with AI in the loop, I architect for theming from the first commit. CSS variables for everything. All design tokens in one file. Components that don't hardcode colours, fonts, or spacing. A DESIGN.md at project root that defines the system, so every Claude prompt snaps to the same tokens.

Why? Because the real value of AI in design isn't generating one site, it's generating five and picking one. When changing the look of the whole site is a matter of swapping out a token file and re-running a couple of prompts, you can play with the design until something actually lands. When the design is baked into a hundred component files, you're stuck with the first thing that came out. Which, statistically, is the AI slop version.

When You Should Still Hire a Designer

I'm a developer running a company, not a designer. So take this with the appropriate grain of salt — but the honest take after a year of pushing AI design tools as hard as I can:

When the budget allows it, I still pay a good designer to do the work.

The plugin and the prompting techniques get me to a defensible 80% on a tight timeline or a small budget. That's genuinely useful. For internal tools, MVP landing pages, side projects, client work where the brief is "make it look professional and ship it Friday" — the AI workflow is excellent. I save real money and real time.

But when the design is the product — agency sites, portfolios, brand-led commerce, anything competing on visual identity — a designer with taste gets you to a different place. They make the foundational decisions AI can't make from a prompt. The brand identity from a blank page. The conversion-driven choices that come from real user research. The judgement call about which of three good options is right for this audience, not the average audience.

AI is great at applying a defined design system consistently across many components. It's not great at creating that system from scratch. The taste has to come from somewhere, and right now, "somewhere" is a human with twenty years of looking at design.

Hiring out the foundational work and using AI for the execution layer has been the most cost-effective way I've found to ship things that look properly designed without a full design retainer. Worth thinking about, especially for anything commercial.

The Formula for Better AI-Generated Web Design

If you take one thing from this article, take this: the plugin doesn't make AI a designer. It makes AI a competent execution layer that doesn't embarrass you. Everything else stacks on top of that.

The workflow that's been working for me:

1. Install the frontend-design plugin, or drop the SKILL.md into your coding agent project rules folder.
2. Add a DESIGN.md at project root with your brand-specific tokens.
3. Prompt with aesthetic direction, not pixel values. Tell Claude what to think about — purpose, tone, font category, colour family, motion philosophy — and let it make the actual choices inside that frame.
4. Iterate by naming what converged in the output and correcting it specifically. "You used Space Grotesk again, pick a serif." "The hero is symmetrical — break the grid."
5. For platform work, stack the skill with WordPress.com MCP or the Shopify AI Toolkit. Two layers, two tools.
6. Architect for theming so you can swap looks until something lands.
7. When the project deserves a real designer, hire one.

The taste still has to come from somewhere. Right now, that somewhere is still you. The plugin just makes sure your taste isn't fighting the model's training data on every single prompt.

The pitch is simple: pay $10, get access to nine models from Chinese AI labs, hosted on servers in the US, EU, and Singapore. The claimed value? $60 worth of API usage for your ten bucks. That's a 6x return if the models are any good.

Spoiler: some of them genuinely are. But there's a catch — actually, there are several catches — and whether they matter depends entirely on how you code.

What Is OpenCode Go?

Quick context if you're new here. OpenCode is an open-source, MIT-licensed terminal coding agent built in Go by the team at Anomaly — the same folks behind Serverless Stack (SST). It's currently sitting at over 142,000 GitHub stars and roughly 6.5 million monthly active developers. The core tool is completely free, supports 75+ model providers, and you can use your own API keys from whoever you like.

Go is the optional paid layer on top. Think of it as a curated, bundled model subscription — you get one API key, one endpoint, and access to a rotating set of models the team has tested specifically for agentic coding workflows.

The backstory matters here. OpenCode Go didn't appear in a vacuum. It was born directly from Anthropic's January 2026 decision to block third-party tools from using Claude subscription credentials. OpenCode, Cline, RooCode — all cut off overnight. The backlash was significant, OpenCode's stars roughly doubled in the weeks that followed, and Anomaly pivoted fast. They stripped out Claude OAuth integration, partnered with OpenAI for Codex access, and launched three new subscription products: Go ($10/month for open-source models), Zen (pay-as-you-go for premium models), and Black (enterprise gateway). If you've read my piece on switching to OpenCode, this is the next chapter of that story.

What Models Do You Get?

As of April 2026, OpenCode Go includes nine models — all from Chinese AI labs. No Claude, no GPT, no Gemini. Here's what you're working with:

The model list has grown since the March beta — which only had GLM-5, Kimi K2.5, and MiniMax M2.5 — and the team says it will keep changing as they test and add new ones. The recent addition of the Qwen models is a good sign.

There's also a free model called Big Pickle (likely based on GLM-4.6, with a 200K context window) available at 200 requests per 5 hours, even without subscribing. Not bad for zero dollars.

The MiniMax Sweet Spot

Here's the thing that makes this subscription interesting: MiniMax and Qwen give you a good number of requests. We're talking up to 50500 per month with Qwen 3.5 Plus and up to 31800 with Minimax m2.5. And these aren't toy models — MiniMax M2.5 scored 80.2% on SWE-Bench Verified, which puts it within spitting distance of Claude Opus 4.6's 80.8%.

I reviewed MiniMax M2.7 separately and came away genuinely impressed. It's not going to out-reason Claude on gnarly architecture problems, but for everyday structured coding work — refactoring, writing tests, generating boilerplate, building out features from a spec — it's shockingly competent for the price.

The catch is that the reasoning-heavy models like GLM-5.1 burn through your limits fast. Like, 4,300 requests per month fast. That's the same $10 getting you 23x fewer requests depending on which model you pick. This variance is the thing you need to understand before subscribing.

The Usage Limits — What $10 Actually Gets You

The Three-Layer Cap System

OpenCode Go doesn't use simple request counts. It uses dollar-equivalent credits spread across three rolling windows:

• $12 of usage every 5 hours (rolling)
• $30 of usage per week
• $60 of usage per month

Because each model costs a different amount per request, the actual number of requests you get varies wildly. MiniMax M2.5 is cheap per-request, so you get a mountain of them. GLM-5.1 is expensive, so you get a molehill.

This layered structure is worth paying attention to. Hit the 5-hour cap twice in a day and you've already dented a significant chunk of your weekly allowance. It's not a bug — it's designed to prevent bursty heavy usage from draining the pool — but it feels restrictive if you're in the zone on a Saturday afternoon.

Is It Enough for Real Work?

Honest answer: not for full-time, all-day coding. If you're the kind of developer who leans on AI for every commit, you'll exhaust the reasoning-model limits within days. One developer reported hitting 49% of their monthly usage on day one. That's... not great.

But here's how I actually use it: as a Plan B. My primary tool is still Claude Code for complex reasoning tasks. OpenCode Go with MiniMax M2.7 handles the routine stuff — the scaffolding, the test writing, the "please generate this CRUD endpoint" work. At 17000 requests per month, that's enough for supplementary use.

When you do hit the limits, you've got two fallback options: drop down to the free Big Pickle model, or enable balance draw from a Zen pay-as-you-go account (requires a separate $20 minimum top-up). Not ideal, but not a dead end either.

Speed, Quality, and My First-Week Experience

The Slow Start

I won't lie — my first few hours with OpenCode Go were rough. Responses were sluggish enough that I started second-guessing the whole thing. I nearly wrote it off.

Then it normalised. The next day, latency dropped to perfectly usable levels. My best guess is that it was either a transient issue on the hosting side or time-of-day dependent — the models are served across US, EU, and Singapore, so peak loads shift. Worth knowing that first impressions might not reflect steady-state performance.

Independent testing backs this up. One reviewer found that GLM-5.1 actually ran faster on OpenCode Go than on the competing Z.ai Coding Plan, and MiniMax quality was identical across OpenCode Go, Vercel, and OpenRouter. No degradation from the proxy layer.

Are the Models Good Enough?

For the price? Absolutely. For replacing frontier proprietary models? No.

The benchmark numbers tell a useful story here. MiniMax M2.5 at 80.2% SWE-Bench is genuinely competitive — it's within a point of Claude Opus 4.6's 80.8%, and ahead of GPT-5.2 on several agentic benchmarks. GLM-5 hits 77.8%, Kimi K2.5 scores 76.8%. These are real numbers on a real benchmark.

In practice, I find the MiniMax models handle TypeScript and Go work solidly for structured tasks. Where they fall short — and where I still reach for Claude — is complex multi-file refactoring, subtle architectural decisions, and anything that requires genuine creative problem-solving. The kind of work where you need the model to reason about trade-offs rather than execute a pattern.

There's been a quantization rumour floating around Reddit — some developers suspect OpenCode Go is running quantized versions of these models, making them subtly worse. Independent testing doesn't support this. One reviewer specifically investigated the claim and found that GLM-5.1 on Go actually handled context windows above 120K tokens better than the same model on Z.ai. I'm not going to say quantization is impossible, but the evidence points against it.

Works With Any Agent — Not Just OpenCode

This is a point of confusion I've seen repeated in third-party reviews, so let me be clear: OpenCode Go's API key works with any tool, not just OpenCode.

The official Go page explicitly states "Use with any agent," and the documentation publishes standard endpoints compatible with both OpenAI and Anthropic API formats. You get OpenAI-compatible chat completions and Anthropic-compatible messages endpoints. One API key, standard interfaces, usable in Claude Code, Codex, your own app — whatever speaks those formats.

A widely-cited APIYI review got this wrong, claiming the models could only be used within OpenCode. That's simply not accurate. OpenCode Go functions more like an OpenRouter-style proxy than a walled garden.

Who Should Subscribe?

It's a good fit if you:

• Want to experiment with Chinese open-source models without managing individual API accounts
• Need a cheap secondary or backup coding tool alongside a primary subscription
• Have lighter usage patterns — hobby projects, side work, learning
• Are an international developer (the UPI payment support and global server hosting are genuine differentiators)

It's not a good fit if you:

• Code all day, every day, and lean heavily on AI assistance
• Need frontier proprietary models for complex reasoning
• Will be frustrated by layered usage caps that punish bursty workflows

My recommendation: treat it as one piece of a multi-tool stack. At $10 it sits comfortably alongside a Claude Code subscription without breaking the bank — and the MiniMax models genuinely pull their weight for routine work.

The Bottom Line

OpenCode Go is the cheapest multi-model AI coding subscription available in 2026. At $10 per month, the value is real — especially if you lean into MiniMax generous request allocation for everyday coding tasks. The models are competitive on benchmarks, the API key works with any agent, and the global server coverage means usable latency from Sydney (or anywhere else that isn't Silicon Valley).

The tradeoffs are equally clear. Heavy users will burn through limits in days. The models are exclusively from Chinese AI labs — no Western proprietary options. It's still in beta, so the model roster, pricing, and limits could all change.

I'm keeping my subscription. I use it alongside Claude Code — Go for the routine work, Claude for the hard stuff.

One last thing worth noting: Dax Raad from the OpenCode team has been refreshingly transparent about the economics, saying they roughly break even on the $10 plan. This is a growth play, not a profit center. Which means the pricing is either a remarkable bargain — or a bet on a model that won't survive its own success. Either way, at $10, the downside risk is a coffee and a half.

I've spent years building and improving ecommerce websites. Right now I'm building an autonomous agent that transfers, optimises, and continuously improves thousands of product listings across platforms — using the Claude API and my own TCA (trigger-condition-action) framework. So I'm not writing this from the sidelines — I'm neck-deep in it.

Here's my honest assessment of what agentic commerce actually is, what works today, and what should make sellers nervous.

What Is Agentic Commerce?

Strip away the marketing and agentic commerce is straightforward: AI agents that can discover, compare, negotiate, and buy products autonomously. Not chatbots with a new coat of paint. Actual autonomous systems that pursue goals across multiple steps and multiple tools.

The distinction matters. A chatbot follows a script. A generative AI tool responds to prompts. An agent pursues goals. It connects to your inventory system, checks stock, evaluates demand patterns, decides to reorder, and executes — without someone typing "please reorder SKU-4429."

Four things define a real agent: autonomy (operating within guardrails without waiting for each instruction), multi-step reasoning (breaking complex tasks into subtasks), tool use (connecting to external systems via APIs), and memory (retaining context across interactions).

Gartner estimates only about 130 of the thousands of vendors claiming "agentic AI" capabilities are genuine. The rest are agent-washing — slapping the label on whatever they already had. If you've been in tech long enough, this will feel depressingly familiar.

The Two Sides of Agentic Commerce

This is the part most articles get wrong. They treat agentic commerce as one thing. It's not. There are two fundamentally different sides, and they have very different implications for sellers.

Agents Doing Your Repetitive Work

This is the good side. The side where AI agents handle the soul-crushing operational work that eats your evenings and weekends.

Listing creation. Pricing updates. Customer support tickets asking where their order is. Marketing copy for the 47th variation of the same product. If you've ever spent a Sunday night writing product descriptions, you know the pain.

The numbers here are real. Klarna automated two-thirds of its customer service with AI and initially saved around $39 million annually. Volcom cut content creation time from months to weeks. Dynamic pricing agents deliver 2–5% revenue increases when properly calibrated.

If you've ever run a small shop, you know the pain. Getting product listings right — the copy, the keywords, the pricing, the images — used to take weeks of manual effort per product line. Multiply that across hundreds or thousands of SKUs and you've got a full-time job that isn't building your actual business. This is where agents genuinely shine. I'm building exactly this kind of automation right now — an agent that transfers thousands of product listings between platforms, optimises them with better copy and SEO, observes how they perform, and improves them again. It's not science fiction. It's a TypeScript project with an API key and a lot of prompt engineering.

AI Shopping on Your Behalf

This is the side that worries me.

McKinsey projects up to $1 trillion in US retail revenue will be orchestrated by AI agents by 2030. Adobe reported that traffic to retail sites from AI browsers increased 4,700% year-over-year. During Cyber Week 2025, Salesforce reported that 20% of global orders were influenced by AI agents.

Those are staggering numbers. They're also a signal that another opaque layer is being inserted between sellers and customers — controlled by Big Tech.

Think about it from a seller's perspective. Today you optimise for search algorithms. Tomorrow you'll need to optimise for AI agents that decide what to recommend. Will sellers need to pay for AI visibility the way they pay for ads? Will the agent show your product or your competitor's? Who decides?

If that sounds like the same game we've been playing with Google and Amazon for 15 years, with a new interface and less transparency... well, that's because it probably is.

What Actually Works in Production Today

Let's get specific about what's real and what's still a keynote slide.

Customer Service: Most Mature, Most Instructive

AI customer service is the clear winner for production readiness. Klarna's AI handled 2.3 million conversations in its first month. Gorgias targets 60% automated resolution across its 15,000+ merchant base. Rep AI reports that shoppers using its AI chat convert at 12.3% versus 3.1% for non-users.

But the Klarna story is also the definitive cautionary tale. After celebrating the replacement of 700 human agents, the company began rehiring in 2025 when customer satisfaction dropped significantly. CEO Sebastian Siemiatkowski admitted they focused too much on efficiency and cost, resulting in lower quality.

The lesson isn't that AI customer service doesn't work. It's that hybrid models outperform full automation. Simple queries — order status, shipping updates, FAQs — resolve at high rates. Returns succeed about 58% of the time. But billing disputes see only 17% chatbot success. The 80/20 split (AI handles routine, humans handle judgment calls) is the pattern that actually works. If you want to see what building a practical triage system looks like, I walked through building an automated support ticket triage agent step by step.

Product Listings and Content

This is the second most mature category and, honestly, the one that excites me most.

Volcom reduced content creation from 5–6 months to 4–6 weeks using Hypotenuse AI. Amazon's own AI listing tools now generate 70%+ of required product attributes. For Shopify merchants, Sidekick writes product descriptions and manages metafields right in the admin.

For small shops, this is transformative. I've seen firsthand how much time goes into getting a single product listing right — researching keywords, writing compelling descriptions, structuring attributes for search, testing different titles. Do that across a large catalogue and it's months of work. An agent that handles the first 80% and lets you refine the last 20% changes the economics of running a small store entirely.

I'm building this kind of agent now — transferring thousands of listings between platforms, running them through Claude for optimised copy, better keyword targeting, and structured data, then pushing the results via the Shopify Admin GraphQL API. The TCA pattern from my agentiny framework handles the event-driven workflow: a new listing triggers analysis, Claude evaluates and optimises, the result gets queued for review, and then the agent monitors performance to improve again. It's the observe-and-improve loop that makes this genuinely agentic rather than just a batch script.

Human review remains essential for brand voice and accuracy. But the heavy lifting? That's squarely in agent territory now.

Pricing, Inventory, and Marketing

Dynamic repricing agents deliver 2–5% revenue increases and 5–10% margin improvements when properly calibrated. AI demand forecasting reduces errors by 30–50%. AI-powered product recommendations drive 35% of Amazon's total revenue.

The caveat nobody puts in the headline: dynamic pricing agents need at least 60–90 days of historical data before they outperform manual rules. Fewer than 15% of retailers currently use AI pricing. These tools reward patience and data investment, not hype-cycle enthusiasm.

The Protocol Wars — ACP vs UCP

Two competing standards are fighting to become the backbone of agentic commerce, and the way the battle is playing out tells you a lot about the current state of things.

OpenAI and Stripe co-developed the Agentic Commerce Protocol (ACP), launched alongside ChatGPT's "Instant Checkout" in September 2025. The vision: discover a product in ChatGPT, buy it right there. Etsy was a launch partner. Shopify signed on. Walmart, Target, Instacart followed.

It didn't work. OpenAI pulled back Instant Checkout by March 2026. Only about a dozen Shopify merchants ever went live. The company couldn't solve real-time inventory sync, sales tax collection, or the basic fact that users researched products in ChatGPT but went elsewhere to actually buy them. TD Cowen analysts called it a "stunning admission."

Google responded with the Universal Commerce Protocol (UCP), announced at NRF 2026 by CEO Sundar Pichai. It was co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, endorsed by 20+ partners including Visa, Mastercard, and American Express. UCP covers the full shopping journey and leverages Google's Shopping Graph. As of March 2026, Google has already added cart, catalog, and identity-linking capabilities.

Amazon, notably, has joined neither protocol. They're building their own thing with Rufus and the "Buy for Me" feature. Classic Amazon.

For sellers, the takeaway is clear: don't bet on one protocol. Make your products agent-discoverable everywhere. Structured data, clean feeds, complete product attributes — these matter regardless of which standard wins.

The Hard Parts Nobody Talks About

Platform Rules Are a Minefield

Every major marketplace has taken a different stance on AI agents, and the differences can get your account suspended if you're not paying attention.

Amazon is the most restrictive. Their March 2026 Business Solutions Agreement update requires all automated actions to flow through registered SP-API applications. Browser automation and screen scraping are explicitly prohibited. They've also blocked AI crawlers and sued Perplexity over its shopping agent.

Shopify takes a controlled-but-encouraging approach. Their Robot & Agent Policy requires human review steps for buy-for-me agents. They charge a 4% AI transaction fee for ChatGPT orders. But they're simultaneously the most agent-friendly platform for developers, with open MCP servers, the Catalog API, and CEO Tobi Lütke's stated goal of making every Shopify store agent-ready by default.

eBay bans unauthorised agents outright in their February 2026 User Agreement update and prohibits feeding marketplace data into third-party AI models without written consent.

Etsy is the most conservative overall. "Keep commerce human" isn't just a slogan — their API terms prohibit using data for machine learning or AI training without authorisation. AI-generated art requires original prompts and transparent disclosure. Selling AI prompts is explicitly banned. Despite this, they were a launch partner for both OpenAI and Google UCP, which tells you even the most reluctant platforms see where this is going.

Safety Isn't Optional

A merchant reported a customer convinced their AI chatbot to escalate a discount from 25% to 80%, resulting in an $11,000 order at catastrophic margins. Air Canada's chatbot case established legal precedent — companies are legally responsible for their AI chatbot's statements. Approximately 40% of organisations report experiencing an AI-related privacy incident.

And here's the uncomfortable stat: 70–85% of AI initiatives fail to meet expected outcomes. Only 5.2% of surveyed companies had AI agents live in production as of early 2025.

Start narrow. Keep humans in the loop. Measure everything. I know this sounds boring. That's because boring is what works. And make sure you're actually validating that your AI is producing correct results — not just assuming it is because the output looks plausible.

Where to Start If You're a Seller

This depends on how technical you are — and I'm writing this assuming a range of readers.

If you're non-technical: Start with SaaS. Gorgias at $0.90 per resolution for customer service. Tidio's Lyro starting at $32.50/month for 50 AI conversations (powered by Claude under the hood, which I like). Shopify Sidekick for product descriptions and admin tasks. All of these deploy in days, not months.

If you're technical: The Claude API plus Shopify's Admin GraphQL API is a powerful combination. Build a TCA pattern for event-driven workflows — triggers fire on external events (cart abandoned, price changed, inventory low), conditions evaluate context, and actions execute multi-step responses. Use model routing from day one: a cheap model like Haiku for intent detection, Sonnet for production workloads, and Opus only when you genuinely need sustained autonomous reasoning.

The hybrid approach is what I'd recommend for most sellers: buy the systems of record (helpdesk, email marketing, inventory management) and build the differentiating intelligence layer on top. Buy Gorgias for your helpdesk. Build a custom product recommendation agent on Claude that integrates with it. Use Klaviyo for email infrastructure. Build a custom analytics agent that feeds it personalised campaign strategies.

The gap for non-technical Shopify and marketplace sellers is still huge. The tooling exists but the on-ramp is rough — I wrote a deeper dive on what's hype vs. reality for small businesses adopting AI agents. If you're a developer who also sells things, that gap is your opportunity.

The Bottom Line

Agentic commerce is real. The technology works for well-scoped tasks: customer service automation, product content at scale, dynamic pricing, demand forecasting. These are production-ready with proven ROI.

The buyer-side revolution — AI agents shopping on behalf of consumers — is happening more slowly than the keynotes suggest. OpenAI's Instant Checkout flopped. Google's UCP is promising but early. Amazon is doing its own thing. The protocol landscape is still contested.

For sellers, the playbook is straightforward: pick the highest-ROI, most constrained use case (probably Level 1 customer support or bulk product descriptions), prove the business case, then expand. Don't try to build a general-purpose autonomous system. Build constrained, domain-specific agents that do one thing well.

The most powerful AI agent is still one that knows when to ask a human for help. That's not a limitation — that's good engineering.

But here's the thing about AI agents for small business: the gap between "I tried it on a weekend" and "this runs in production and makes money" is enormous. Jensen Huang called OpenClaw "probably the single most important release of software, probably ever". Goldman Sachs says 93% of small businesses report positive impact from AI. And yet only 14% have fully integrated it into core operations. That tells you everything you need to know: most people are tinkering, not transforming.

I've been building with AI agents professionally — I maintain agentiny, a lightweight TypeScript agent framework — and I've tested most of the major tools. This is my honest take on what actually works, what's overhyped, and where to start if you're running a small business and don't want to waste your time.

2026 Is the Year of the Agent — Here's What That Actually Means

First, let's be clear about what we're talking about. An AI agent is not a chatbot. A chatbot answers questions. An agent does things — sends emails, schedules meetings, researches prospects, manages files, fills out forms. It takes actions autonomously, often across multiple tools, without you hovering over every step.

The market numbers are genuinely impressive. 58–71% of small businesses are actively using AI in some form. The agent market is projected to grow from $7.6 billion to roughly $236 billion by 2034. And there's a stark correlation: 83% of growing SMBs have adopted AI versus just 55% of declining ones. Whether AI causes growth or growing businesses are just more likely to adopt new tools is a fair question. But the trend is impossible to ignore.

My angle: yes, this is real. No, it's not magic. And most people I see playing with agents on social media are configuring them for fun, not for measurable ROI. That's fine — experimentation matters. But if you're a business owner reading this, you want to know what actually moves the needle. So let's talk specifics.

OpenClaw — Overhyped and Undervalued at the Same Time

What OpenClaw Actually Does

OpenClaw is the project that broke GitHub. A free, open-source AI agent that runs locally on your machine and connects to the messaging apps you already use — WhatsApp, Slack, Telegram, Discord, Teams, and about 20 more. It went from a weekend hack by Austrian developer Peter Steinberger (of PSPDFKit fame) to over 344,000 GitHub stars in under four months. For context, React took a decade to get there.

The project has had more name changes than a witness protection participant — Clawdbot became Moltbot became OpenClaw, after Anthropic's lawyers had a word about the original name sounding a bit too much like "Claude." Steinberger has since joined OpenAI, and the project lives under an independent open-source foundation.

What makes OpenClaw genuinely interesting is the combination of its skills system and ClawHub registry. There are over 13,700 community-built skills covering everything from lead generation to expense tracking to client onboarding. It's model-agnostic — Claude, GPT-5.4, Gemini, local models via Ollama, 500+ options through OpenRouter. And the reported numbers are compelling: 10–15 hours per week saved at $10–80/month in API costs.

The self-hosting story is solid too. Runs on laptops, Mac Minis, VPSes, even Raspberry Pis. Cloud options exist if you don't want to manage it yourself — Amazon Lightsail has preconfigured instances, DigitalOcean offers 1-Click Deploy, and KiloClaw does fully managed hosting for $9/month.

The Security Problem Nobody Talks About Enough

Here's where the mood shifts. Cisco's AI security team tested a top ClawHub skill and found it was straight-up malware performing data exfiltration. Their audit revealed 26% of skills had at least one vulnerability. Over 230 malicious skills were uploaded to ClawHub in a single week. And 21,000+ OpenClaw instances were found exposed to the public internet.

One of OpenClaw's own maintainers put it bluntly: "If you can't understand how to run a command line, this is far too dangerous of a project for you to use safely." I appreciate the honesty.

Here's my take: if you want to try OpenClaw, don't run it on your main machine. Don't connect your primary email or your business bank accounts. Use a cloud-hosted option with proper sandboxing — NVIDIA's NemoClaw adds enterprise-grade security, and KiloClaw handles the ops for you. The security surface area is enormous, and most users don't fully grasp what they're granting access to. OpenClaw is a fantastic project with a genuine community. But treating it casually with sensitive data is asking for trouble.

The Honest Use Case Problem

I want to flag something that the hype cycle glosses over: many of the use cases people celebrate with OpenClaw — email filtering, calendar management, task prioritisation — were already solvable without AI. Gmail filters exist. Calendar apps have had automation for years. Task managers have rules engines.

The real value of an AI agent is in the combination: reasoning across context, chaining actions across multiple tools, handling ambiguity. "Read this email thread, figure out what the client actually wants, draft a response, check my calendar for availability, and suggest three meeting times." That's genuinely valuable. "Sort emails into folders based on keywords" is a solved problem from 2010.

Most people aren't using OpenClaw for the hard stuff yet. They're using it for the easy stuff and marvelling that it works. Which, fair enough — it does work. But if you're evaluating it for your business, ask yourself whether the workflow you're automating actually needs AI reasoning, or if a Zapier rule would do the job for less money and less risk.

Claude Cowork — The Safer Path for Non-Technical Teams

Claude Cowork launched on January 12, 2026, and Anthropic pitched it as "Claude Code for non-developers." That positioning is accurate. It runs inside the Claude Desktop app on macOS and Windows, requires zero command-line knowledge, and was reportedly built by Claude Code itself in about two weeks. Meta.

The capabilities are substantial. Sub-agent coordination (it breaks complex work into parallel workstreams), scheduled and recurring tasks, persistent memory across sessions, and a mobile "Dispatch" feature for checking on tasks from your phone. In March 2026, it gained full computer use — opening apps, navigating browsers, clicking and typing. The Model Context Protocol (MCP), Anthropic's open standard with 97 million monthly SDK downloads, powers connectors to Slack, Google Drive, Gmail, DocuSign, and 75+ other services.

Pricing is straightforward. Cowork is included in all paid Claude plans: Pro at $20/month, Max 5x at $100/month, Max 20x at $200/month. But here's the reality check — agentic tasks burn tokens fast. If you're doing anything beyond light use, you'll want Max 5x at minimum. Budget $100/month for serious work.

What really signals Anthropic's commitment to SMBs are the partnerships. Intuit integration brings Claude to QuickBooks, TurboTax, and Mailchimp. Xero collaboration targets AI-powered financial intelligence for small businesses. And Microsoft built Copilot Cowork on Anthropic's technology, integrating it into Microsoft 365.

My take: for most small business owners — especially non-technical ones — Cowork is the answer. It just works. The tradeoff is cost and vendor lock-in (Anthropic's models only), but for the majority of people reading this, that's a perfectly acceptable trade. You get a polished product with real security boundaries instead of an open-source project where the maintainers are actively warning you about how dangerous it is.

When a Custom Agent Makes More Sense

The Case for Purpose-Built Agents

OpenClaw and Cowork are generalists. They handle a broad range of tasks acceptably well. But for professional workflows where you need precision — specific error handling, data validation, safety checks, audit trails — a purpose-built agent will outperform a generalist every time.

Think of it this way: a general contractor can do plumbing, electrical, and carpentry. But if you're redoing your entire kitchen, you want specialists. Same principle applies to agents.

The open-source framework landscape has matured considerably. CrewAI is the easiest to learn and fastest to production for standard multi-agent workflows. LangGraph is the most battle-tested for production deployments, with excellent debugging via LangSmith. Pydantic AI is rising fast for type-safe development. Microsoft's AutoGen is effectively in maintenance mode — skip it for new projects.

I built agentiny because I wanted something lighter. It's a TypeScript framework using a trigger-condition-action pattern for agent orchestration — no framework bloat, just focused agents that do specific things well. If you're a developer who wants full control over your agent logic without importing half of npm, it's worth a look.

Build vs. Buy: A Quick Decision Framework

Here's how I'd think about it depending on your team:

No developers on the team? Go with Claude Cowork or Make.com. The visual interfaces are genuinely good now, and Make's free tier lets you experiment without commitment.

Technical comfort but limited time? OpenClaw via a cloud host, or n8n self-hosted. n8n's open-source tier with unlimited free executions is exceptional value for technical teams.

Developers available with a specific high-value workflow? Build a custom agent. agentiny, CrewAI, or LangGraph depending on your language preference and complexity needs. Open-source frameworks cost about 55% less per agent but need roughly 2.3× more setup time. That tradeoff is worth it when the workflow matters.

How to Start Without Getting Burned

If you've read this far and want to actually do something, here's the playbook:

1. Pick one workflow. Not three. One. The highest-ROI first automations are customer FAQ responses, lead follow-up, appointment scheduling, and email triage. A structured implementation produces 3–4× the ROI of ad-hoc experimentation. Resist the urge to automate everything at once.

2. Budget realistically. Most SMBs spend $50–500/month on AI tools. Budget 20–40% above platform costs for security measures — monitoring, access controls, backups. The platform cost is never the total cost.

3. Follow security non-negotiables. Least-privilege access: agents should only reach what they need, nothing more. Build in a kill switch to halt all AI workflows instantly. Start with tasks where errors are visible and low-consequence — email drafts that need approval before sending, reports that get reviewed before distribution. Don't give agents access to financial systems or sensitive data until you've built trust and guardrails.

4. Measure everything. This isn't optional. Track time saved, error rates, costs incurred. Gartner warns that over 40% of agentic AI projects risk cancellation by 2027 due to escalating costs and unclear value. If you can't demonstrate ROI, the project will die — and it probably should.

5. Expand methodically. Once workflow #1 is stable and measurably valuable, pick workflow #2. Rinse, repeat. The businesses that succeed with AI agents are the ones that treat it as a disciplined rollout, not a hype-driven experiment.

The Bottom Line

2026 is genuinely the year AI agents crossed from demo to daily driver. The tools are real. The productivity gains are real. The dream of software that runs in the background doing actual work — not just answering questions — is happening right now.

But not every workflow should be automated. And not every automation needs AI. Sometimes a cron job and a Bash script still win.

OpenClaw is a remarkable project — congratulations to Peter Steinberger and the community for building something that genuinely shifted the industry. But it's for technically capable teams who understand the security implications and are willing to manage them. For most small business owners, start with Claude Cowork or an automation platform like Make.com. For specific, high-value workflows where precision matters, build a custom agent.

The question isn't "should we use AI agents for small business automation?" — it's "which workflow do we automate first?"

Pick the boring one. The repetitive one. The one your team complains about every week. Automate that, measure the results, and go from there.

Spoiler: it's neither. It's "add it to your toolbox."

What Is MiniMax M2.7?

M2.7 is a reasoning model from Shanghai-based MiniMax, built on a Sparse Mixture-of-Experts architecture. It has roughly 230 billion total parameters but only activates around 10 billion per token — which is how they keep inference costs so low while still hitting competitive benchmarks. MiniMax calls it "the smallest model in the Tier-1 performance class," and the numbers at least make the case plausible.

The context window is 204,800 tokens (input plus output combined), with a max output of 131,072 tokens. That puts it above GPT-5.2's 128K but well below Gemini 3.1 Pro's 2M window. It's text-only — no images, no audio, no video natively — though it supports tool calling and MCP, so you can bolt on image understanding and web search through external tools.

One thing worth noting: M2.7 is proprietary. This is a sharp turn from MiniMax's earlier M2 and M2.5 (which I reviewed previously), which were fully open-weight under Apache 2.0. The community has not been thrilled about this. If you valued the open approach, this stings.

I should be honest: I really liked M2.5. I said so in the review. But after a few weeks of daily use, I found myself drifting back to Claude for bigger tasks, and then spending a lot of time testing GPT 5.4. That's not a knock on M2.5 — it's just the reality of how model usage works now. You explore, you compare, you settle into patterns. M2.7 is MiniMax's attempt to pull you back.

The marketing headline is "self-evolution" — M2.7 participated in its own training loop, running 100+ optimization cycles on its own scaffold and reportedly improving internal benchmarks by 30%. That sounds dramatic, but MindStudio's caution is worth internalising: internal benchmark gains don't automatically translate to neutral third-party evaluations. It's an interesting research direction, not a finished revolution.

Benchmarks — Close to Frontier, Not Quite There

Coding Benchmarks

The headline numbers are genuinely impressive. M2.7 scores 56.22% on SWE-Pro, which nearly matches Claude Opus 4.6 at roughly 57%. On SWE-Bench Verified it hits 78%, which actually outperforms Opus's 55% on that particular benchmark. It also scored 55.6% on VIBE-Pro and 57.0% on Terminal Bench 2.

But benchmarks have become increasingly hard to compare meaningfully. Different scaffolds, different evaluation conditions, different levels of self-reporting. The most useful data point I found was Kilo Code's head-to-head comparison across three TypeScript codebases. Both models found all six planted bugs and all ten security vulnerabilities. M2.7 even offered a technically superior fix for one bug — using integer math for currency calculations instead of floats, which is the kind of thing that makes you nod approvingly.

Where Opus pulled ahead was in the details that matter for maintainability: it produced 41 integration tests versus M2.7's 20 unit tests, used a more modular file structure, and demonstrated better architectural thinking overall. The total cost difference? $0.27 for M2.7 versus $3.67 for Opus. That's the kind of gap that changes how you think about task routing.

My take: for the stuff I do day-to-day — quick bug fixes, code reviews, feature scaffolding — M2.7 is more than capable. For complex architectural work where I need the model to think deeply about structure and test coverage, I'm still reaching for something stronger.

General Intelligence

On Artificial Analysis's Intelligence Index v4.0, M2.7 scores 50 — a solid 8-point jump from M2.5's 42, but still behind Gemini 3.1 Pro and GPT-5.4 (both at 57), Opus 4.6 (53), and Sonnet 4.6 (52). Not frontier, but firmly in the "good enough for most tasks" tier.

The hallucination rate is interesting: 34% per Artificial Analysis, which is actually lower than Claude Sonnet 4.6 (46%) and Gemini 3.1 Pro Preview (50%). Take that with a grain of salt — hallucination metrics are notoriously slippery — but it's worth noting.

A few caveats. Most of MiniMax's benchmark claims come from self-evaluation, and independent verification is still catching up. VentureBeat noted that on BridgeBench vibe-coding tasks, M2.7 actually scored worse than its predecessor M2.5. That's the kind of regression that benchmark cherry-picking can hide.

Token Plans and Pricing Breakdown

Pay-As-You-Go

Here's where M2.7 gets genuinely compelling. The API pricing is $0.30 per million input tokens and $1.20 per million output tokens. Compare that to Opus 4.6 at $5/$25 — that's roughly 17× cheaper on input and 21× cheaper on output.

You'll see some articles claiming "50× cheaper on input" — that's comparing against the old Opus 4.1 pricing of $15/M, not the current Opus 4.6 at $5/M. Still a massive gap, just not quite as dramatic as some headlines suggest.

The automatic caching is a genuine standout feature. Cache reads cost just $0.06 per million tokens with zero configuration required. For cache-heavy agentic workloads where you're hitting the same system prompts and context repeatedly, your blended cost can drop to roughly $0.06/M tokens. That's essentially free compared to what you're used to paying.

But — and this is important — there's a verbosity tax. During Artificial Analysis's evaluation, M2.7 generated 87 million output tokens. The median for reasoning models in its price tier is 20 million. That's 4× more output tokens than average, which significantly erodes the headline per-token savings. Multiple Reddit users have reported 16,000+ tokens of thinking for simple prompts. The evaluation alone cost $175 in tokens. So yes, the per-token price is absurdly low, but the model is also absurdly chatty.

Subscription Tiers

MiniMax offers six monthly token plans ranging from $10 to $150, bundling M2.7 with their speech, image, video, and music models:

The Starter tier at $10/month gives you 1,500 requests per 5-hour rolling window on the standard variant — M2.7 only, no extras. Plus ($20/month) bumps that to 4,500 requests and adds speech and image generation. Max ($50/month) gives you 15,000 requests with the full suite including video and music.

Then there are the highspeed variants: Plus-Highspeed ($40/month), Max-Highspeed ($80/month), and Ultra-Highspeed ($150/month) at 30,000 requests per 5-hour window with everything included.

Yearly plans save about 17% (Starter drops to $100/year, Ultra-Highspeed to $1,500/year).

Which tier makes sense depends entirely on your usage pattern. If you're doing light coding work — a few tasks a day, nothing too intensive — the Starter plan or even pay-as-you-go might be more economical. For heavy agentic workloads where you're burning through tokens continuously, the Max or Ultra-Highspeed tiers start to look like genuine bargains. The Starter tier's break-even against pay-as-you-go isn't always favourable for casual use, so do the maths for your specific workflow before committing.

The Speed Problem

This is where the story gets less rosy.

MiniMax claims roughly 100 tokens per second for the highspeed variant and around 60 TPS for standard. They market M2.7 as "3× faster than Opus." Independent testing tells a different story. Artificial Analysis measured the standard variant at 45.6 tokens per second — against a median of 95.8 TPS for reasoning models in its price tier. Time to first token was 2.49 seconds versus a 1.84-second median. That's noticeably sluggish in interactive use.

It's possible the highspeed variant performs closer to claims, but Artificial Analysis appears to have tested the standard endpoint, and I haven't found independent benchmarks of the highspeed tier yet. Until someone verifies those numbers, I'd treat the 100 TPS claim with healthy scepticism.

The underlying issue is architectural. M2.7 uses full attention across its context window, so performance degrades further on long-context workloads. Community members in the llama.cpp project have flagged this: "Minimax applied full attention, thus it's so slow in long ctx." The 205K context window looks competitive on paper, but pushing anywhere near that limit will test your patience.

I actually wish speed got more attention across the industry generally. A model that's 10% smarter but 3× slower often feels worse in practice. The highspeed plan is compelling in theory — if it actually delivers the throughput MiniMax claims. That's a big "if" right now. I haven't spent the money on the highspeed subscription yet — I have too many subscriptions as it is — but it's on my list. Maybe next month, when I carve out time for proper testing.

Using M2.7 with OpenCode

If you're already using OpenCode (and I switched from Claude Code to OpenCode recently), M2.7 slots in naturally. MiniMax is a preloaded built-in provider — you run opencode auth login, select MiniMax, enter your API key, and you're off. The model uses the Anthropic-compatible API format at https://api.minimax.io/anthropic/v1.

One gotcha: clear any existing ANTHROPIC_AUTH_TOKEN and ANTHROPIC_BASE_URL environment variables first. If you've been using Claude through OpenCode, those will conflict. I've seen people lose 20 minutes to this before checking the obvious.

There are five access paths total: direct API integration, OpenCode Go ($5 first month, then $10/month — includes M2.7, M2.5, GLM-5, and Kimi K2.5), OpenCode Zen for pay-as-you-go, OpenRouter (minimax/minimax-m2.7), and Ollama Cloud. MiniMax provides an official setup guide that's actually decent.

For best results, the recommended inference parameters are temperature=1.0, top_p=0.95, top_k=40. These are higher than what you might instinctively set, but they seem to produce better output quality with this particular model.

Known issues worth watching: earlier MiniMax models in OpenCode had problems with tool-calling loops and premature task halting. These appear to be improving with M2.7 but haven't fully disappeared. If you hit a case where the model gets stuck in a loop or stops mid-task, it's a known pattern, not something unique to your setup.

Should You Switch? My Honest Take

I'll be honest — I wasn't sure I should write another model review. I'm starting to worry I'll repeat myself. New model drops, benchmarks look great, pricing is aggressive, some caveats apply. You've read that article before. I've written that article before.

And that's kind of the point. New models are impressive, but they're not exciting in the way they used to be. The performance gap between "best" and "good enough" is shrinking every quarter, and the real innovation is happening elsewhere — in the desktop apps, the chat interfaces, the coding CLIs. The features being added to the tools we use daily feel more consequential right now than another few percentage points on SWE-Bench.

That said, M2.7 is still worth your attention for one simple reason: the pricing. Even if you never make it your primary model, having a plan B that costs this little is genuinely useful. Quick tasks, simple fixes, boilerplate generation — there's no reason to burn Opus tokens on that stuff. I don't think "switching" is the right frame anymore. I run the same task on two or three models and pick the best result. It takes an extra minute and saves me from the weaknesses of any single model.

For anything requiring deep architectural thinking, thorough test coverage, or complex multi-file reasoning, I still reach for Opus or Sonnet. The quality gap is real but narrow, and for 80% of daily coding work, that gap doesn't matter.

My recommendation: just try it. The $10 Starter plan or pay-as-you-go makes experimentation essentially risk-free. Run your typical tasks through it for a week. You'll know pretty quickly whether it fits your workflow.

And MiniMax isn't the only one making moves in this space. Xiaomi dropped another surprisingly strong model recently, and Alibaba Cloud has a code subscription that's turning heads. The cost-effective tier of AI coding is getting crowded fast, which is great for the OpenClaw/agent use cases where token costs compound. There's a lot to test, and honestly, we shouldn't complain about having too many good options. That's a problem I'm happy to have.

The market is moving toward "best model per dollar," not just "best model." MiniMax is betting on that future, and right now, the bet looks increasingly sound.