DEV Community: Stephan Miller

Apple Books Hides Your PDF Highlights. My Obsidian Plugin Now Digs Them Out.

Stephan Miller — Wed, 29 Jul 2026 12:00:00 +0000

Of all the little plugins I’ve vibe coded into existence, the Apple Books Annotation Import plugin is the one I actually use. Not “use” in the way you use a project once, screenshot it for a blog post, and never open again. I mean I run it every week. It’s my favorite thing I’ve built, and it’s been humming along for over a year without me touching it.

Then a few weeks ago I went looking for a highlight I knew I’d made in a PDF. It wasn’t there. None of my PDF highlights were there. A year of trusting this thing, and it turns out it had quietly been ignoring an entire category of my books the whole time.

So I went digging. And it turns out Apple Books handles PDFs in a completely different way. This is the story of getting those highlights out, and the 1.1.0 release that finally does it.

A Quick Refresher On What This Thing Does
Where Apple Actually Hides PDF Highlights
Reading Highlights Out Of A Raw PDF
Hooking It Into The Machine That Already Worked
The Tradeoff: It’s Slower, But It’s Everything Now
How To Install It (It’s Not In Community Plugins Yet)
The Takeaway

A Quick Refresher On What This Thing Does

If you’ve never seen the plugin before, here’s the pitch. It’s macOS desktop only, and I’m fine with that, because being desktop only is the entire reason it can do what it does. I read in an iPad and I pay for the cheapest rung of iCloud specificallly because of this plugin to get the books where the plugin runs.

When you highlight something in Apple Books, that highlight has to live somewhere on disk. On a Mac it does. On an iPhone it’s locked in a sandbox you can’t reach. So the plugin sits on the desktop where all the good data is and pulls from every source it can find:

The Books SQLite databases. This is where your EPUB highlights and notes actually live, buried in ~/Library/Containers/com.apple.iBooksX. The plugin reads them straight out of SQLite.
The EPUB files themselves. The database doesn’t have everything. So the plugin also cracks open the EPUB to grab the real metadata: ISBN, publisher, language, subjects, and the cover image.
And now, as of 1.1.0, the PDFs themselves.

Out of all that it builds a clean markdown note per book: your highlights as blockquotes, color-coded to match the highlighter you used, optional notes, dates, citations, cover image, and an author page with a Dataview query that lists every book by that author. It has a smart overwrite mode that hashes the note so re-importing only rewrites files that actually changed. Pick “Import all books” or cherry-pick from a list.

The whole point is completeness. I’m not scraping one source, I’m triangulating across three. Which is why the missing PDF highlights bugged me so much. There was a hole in the completeness.

Where Apple Actually Hides PDF Highlights

Here’s the part that took real detective work, and where my first assumption was flat wrong.

My mental model was simple: highlights go in the SQLite database, PDFs are books, therefore PDF highlights go in the database. So I looked. And there they were. Sort of.

The database had a row for every PDF I’d ever opened. But every single one looked like this:

ZANNOTATIONSELECTEDTEXT = (empty)
ZANNOTATIONSTYLE = 0
ZANNOTATIONTYPE = 3
ZPLUSERDATA = <binary plist: BKPageLocation, pageOffset 21>

No text. No color. No note. Just a page number wrapped in a binary property list. That’s not a highlight. That’s a bookmark. Apple Books drops one of these in the database for every PDF so it can remember what page you were on, and my plugin had been correctly throwing them away for a year because they have no selected text.

So the highlights weren’t in the database at all. That meant they had to be in the PDF files, which on a Mac live in your iCloud Books folder:

~/Library/Mobile Documents/iCloud~com~apple~iBooks/Documents/

I grepped one of my highlighted PDFs for the PDF highlight marker, and there it was:

58 occurrences of /Subtype /Highlight
71 QuadPoints arrays

That’s the answer. Apple Books writes PDF highlights back into the PDF file as standard PDF annotations. Not into its own database like it does for EPUBs. Into the file. Which is actually the more portable choice, it’s just the opposite of everywhere else the app stores things.

Reading Highlights Out Of A Raw PDF

A PDF highlight annotation doesn’t store the text you highlighted. That would be too easy. It stores QuadPoints, which are the rectangles the yellow marker was painted over, in PDF coordinate space. To get the actual words you have to line those rectangles up against the text on the page and read out whatever sits underneath.

That’s a job for pdf.js, Mozilla’s PDF engine. It gives me the annotations on each page and, separately, every run of text with its position. For each highlight I:

Turn its QuadPoints into one box per highlighted line.
Find the text on the page whose baseline falls inside each box.
Clip the first and last lines, because a highlight usually starts and ends mid-sentence, snapping the cut to the nearest word boundary so I don’t slice a word in half.

I tested it against a highlight I knew the exact wording of, and it came back verbatim, starting and ending in exactly the right place. Colors came out too. pdf.js hands them back as plain RGB values from 0 to 255, and Apple’s highlighter yellow is (250, 205, 90), so I map that to the same little yellow square the EPUB highlights already use.

Hooking It Into The Machine That Already Worked

This is the part I’m actually happy about, and it’s the part that keeps this from being a bolt-on mess.

The plugin already had a whole pipeline for EPUBs: an Annotation object shape, a markdown renderer, the smart-overwrite dedup, author page creation, file naming. All of it keyed off two internal types. So instead of writing a parallel universe for PDFs, I made the PDF extractor produce those exact same types. A PDF highlight becomes an Annotation. A PDF file becomes a BookDetail, with its title and author pulled from the Books library database so the note gets a real title instead of a mangled filename.

Once the shapes matched, the entire existing machine just ran. The renderer, the dedup, the author pages, the color emoji, none of it knew or cared that these highlights came out of a PDF instead of a database. PDF import is just a second phase inside the same “Import all books” command, plus one new toggle in settings so you can turn it off (because it is now the slow part of the plugin).

The genuinely annoying part was bundling pdf.js into a single-file Obsidian plugin. pdf.js wants to run its parser in a Web Worker loaded from a separate file, and an Obsidian plugin ships as one main.js. The trick is to run the worker on the main thread by handing pdf.js its own worker module through a global:

import * as pdfjsWorker from 'pdfjs-dist/legacy/build/pdf.worker.js';
(globalThis as any).pdfjsWorker = pdfjsWorker;

That, plus telling the bundler to leave the optional canvas dependency alone, and it works. It also took main.js from about 250KB to 4.3MB, because I’m now shipping an entire PDF engine inside a note-taking plugin. Such is life.

The Tradeoff: It’s Slower, But It’s Everything Now

I’m not going to pretend this is free. The database approach for EPUBs is instant. The PDF approach is not.

Apple doesn’t track which PDFs you’ve highlighted anywhere I can query, so the plugin has to go look. It scans your entire iCloud Books folder, does a cheap byte-level check for the highlight marker to skip the hundreds of PDFs you never marked up, and then parses the survivors with pdf.js on the main thread. In my library that’s 748 PDFs to glance at. So yes, “Import all books” takes noticeably longer than it used to, and a book with a lot of highlights can make the app pause for a second while it works.

I decided I’ll take that trade every time. A slightly slower import that gets me everything beats an instant import with a hole in it.

And I do mean everything. Between the SQLite databases, the EPUB files, and now the PDFs, I’m fairly confident there’s nothing left in Apple Books that I can’t pull out. EPUB highlights, PDF highlights, notes, metadata, covers. If Apple is storing it on my Mac, this plugin can reach it. I went looking for one more hidden source after the PDFs and came up empty, which for once is the good outcome.

How To Install It (It’s Not In Community Plugins Yet)

Fair warning: this plugin is not in the Obsidian community plugin browser. It’s mine, it’s niche, and it reads files out of your macOS system libraries, so it lives on GitHub for now. That means two ways in.

The easy way, with BRAT. BRAT is the Beta Reviewers Auto-update Tool, and it exists exactly for plugins like this one. Install BRAT from the community plugins, then add this repo as a beta plugin:

eristoddle/apple-books-annotation-import

BRAT installs it and keeps it updated whenever I push a new release. I wrote a whole walkthrough of this if you’ve never done it: How to Install Obsidian Plugins, including the BRAT section.

The manual way. Grab main.js, manifest.json, and styles.css from the latest release, drop them in a folder under .obsidian/plugins/apple-books-annotation-import/ in your vault, and enable it in settings. No auto-updates, but it works.

Either way, once it’s on, flip on “Import PDF highlights” in the settings, hit “Import all books,” and give it a minute to chew through your library.

The Takeaway

The lesson here isn’t really about PDFs. It’s that “it works” and “it’s complete” are two different claims, and I’d been quietly making the first one while believing the second for over a year. The plugin worked. It just wasn’t done. It took actually going looking for a specific missing highlight to find the gap.

If you build tools for yourself, this is the failure mode to watch for. The thing runs, you trust it, and you stop checking whether it’s still telling you the whole truth. Apple gave me a good excuse by hiding PDF highlights in a completely different place than everything else, but the hole was mine to notice.

Anyway. It’s fixed. Every highlight I’ve got, in every format Apple Books supports, now lands in Obsidian. Which means I’m out of excuses and back to actually reading the books.

Claude Opus 5: The Flagship Got Cheaper (There's a Catch)

Stephan Miller — Tue, 28 Jul 2026 13:00:00 +0000

For about a year now, every model launch has followed the same script. A lab drops a new flagship, it’s a little smarter than the last one, and it costs more. You brace for it. New tier, new price, same shrug. So when Anthropic put out Claude Opus 5 on July 24, I opened the pricing page already wincing.

Then I read it twice, because it was half the price.

Not half the price of some bloated competitor. Half the price of Anthropic’s own current king, Fable 5. And on the Artificial Analysis Intelligence Index, Opus 5 edged out Fable 5 for the number one spot. Smarter and cheaper, in the same launch. That’s not how any of this has gone for a year.

And then, three days later, the biggest open-weights model in human history dropped on Hugging Face, and I sat there doing the math on whether I could run it. Spoiler: I cannot. Nobody with fewer than eight datacenter GPUs can. Welcome to the week.

The Flagship Got Cheaper (Wait, What?)
The 2.8 Trillion Parameter Paperweight
The Actually Useful Release Nobody Tweeted About
Cheapskate Picks: What I’d Actually Pay For
The Horror Show
The Still-Waiting Room
The Takeaway

The Flagship Got Cheaper (Wait, What?)

Here’s the part I keep re-reading. Claude Opus 5 costs $5 per million input tokens and $25 per million output. That’s the exact same price as Opus 4.8, the model it replaces. Meanwhile Fable 5, Anthropic’s big expensive brain, sits at $10 in and $50 out. So Opus 5 is literally half the sticker of the model it just beat on the intelligence leaderboard.

On the Artificial Analysis Intelligence Index, Opus 5 (max) scores 61. Fable 5 lands at 60. GPT-5.6 Sol comes in at 59, and Moonshot’s Kimi K3 at 57. It’s a photo finish at the top, but the point is that the cheaper Anthropic model is the one holding the trophy this week.

The number that actually matters, though, isn’t the Index rank. It’s cost per task. Sticker price per token lies to you, because different models burn different amounts of tokens to finish the same job. Artificial Analysis measured it: running their full Intelligence Index costs about $2.03 per task on Opus 5 versus $2.75 on Fable 5. That’s roughly 26 percent cheaper to do the same work, on top of the lower per-token rate. For anyone running agent loops where the bill compounds, that’s the real headline.

The benchmarks back up the “it’s genuinely good” claim, not just the “it’s cheap” one. On Frontier-Bench v0.1 it hit 43.3 percent, against Fable 5’s 33.7 and GPT-5.6 Sol’s 34.4. On ARC-AGI-3 it scored 30.2 percent while Opus 4.8 managed a sad 1.5. It’s the new default on Claude Max and the strongest model available on Claude Pro.

So what’s the catch, because there’s always a catch. The catch is buried in the launch chart. On the Frontier-Bench numbers, Anthropic notes that Opus 4.8 “stood in as a fallback” whenever a safety classifier refused an Opus 5 request. Fine. Except they never said how often that happened. So the flagship benchmark quietly folds in a weaker model’s answers by an amount nobody will tell you. If you remember the refuse-and-reroute mess that followed Fable 5 around, this is the same species of problem wearing a nicer suit.

The 2.8 Trillion Parameter Paperweight

While Anthropic was cutting prices, Moonshot was flexing. On July 27 they released the open weights for Kimi K3, and this thing is a monster: 2.8 trillion parameters, the largest open-weight model ever shipped. On the Artificial Analysis Index it scores 57, which makes it the highest-scoring open model on the board, ahead of everything else you can actually download.

Here’s where the dream meets the parking lot. The download is about 1.4 terabytes of weights even at MXFP4 quantization. The architecture is a mixture of experts, 896 experts total with 16 active per token, so roughly 50 billion parameters are actually doing work on any given pass. To load it you need something like four to eight H100 80GB GPUs. Your 4090 can’t touch it. Your maxed-out Mac Studio can’t touch it. “Own your weights” is a beautiful slogan right up until you price the hardware to hold them.

So in practice, for almost everyone, Kimi K3 is still just an API you rent at $3 per million in and $15 per million out. The weights being open is great for labs, cloud providers, and the three guys on Reddit with a GPU rack in the garage. For the rest of us it’s a philosophical victory, not a practical one.

And it’s not a clean win even on quality. Accuracy went up about 13 points over the K2.6 generation, which sounds great, but the hallucination rate also climbed about 12 points. Moonshot frames that as the model being “more willing to answer.” Cute. For regulated, legal, medical, or financial work, “more willing to answer” is a polite way of saying “more confidently wrong more often,” and there’s no dial to trade it back.

The Actually Useful Release Nobody Tweeted About

Buried under the Opus 5 launch and the Kimi K3 spectacle, Google shipped the model I’d actually reach for on a Tuesday. Gemini 3.6 Flash landed July 21 at $1.50 in and $7.50 out. That output price is down from the $9 that Gemini 3.5 Flash charged, and Google says it uses about 17 percent fewer output tokens on top of that. Cheaper rate, fewer tokens, same 1 million token context, knowledge cutoff pushed to March 2026.

The funny part: Artificial Analysis gives 3.6 Flash the same Intelligence Index score as 3.5 Flash, a 50. So the tech press mostly shrugged. No leap, no headline. But it gained on the benchmarks that matter for real work, SWE-Bench Pro up to 58.7 percent from 55.1, OSWorld computer use up to 83 from 78.4. And it sits inside the competitive band of five of the six Arena categories I track. Cheaper than the thing it replaces, and it beats the mid-tier of the pricier labs. That’s the whole pitch, and it’s a good one.

Cheapskate Picks: What I’d Actually Pay For

Here’s the trick I run every week, because I’m cheap and I have to be. The Arena leaderboards cluster tight at the top. The entire Overall top 20 this week fits inside 32 rating points, from Fable 5 at 1508 down to a pack at 1476. When the whole visible field is that compressed, paying the leader’s price buys you almost nothing over something a fraction of the cost. So the game is: find the cheapest model still inside spitting distance of the category leader.

Here’s where that landed this week:

Category	Leader	$ out	Cheapskate pick	$ out	Δ rating	Cheaper by
Overall	Fable 5 (1508)	$50	MiMo v2.5 Pro (1465, #37)	$0.87	−43	~57x
Coding	Opus 4.7-thinking (1553)	~$25	MiMo v2.5 Pro (1519, #25)	$0.87	−34	~29x
Creative Writing	Fable 5 (1507)	$50	Gemini 3-Flash (1458, #21)	$3	−49	~16.7x
Instruction Following	Fable 5 (1515)	$50	MiMo v2.5 Pro (1469, #23)	$0.87	−46	~57x
Hard Prompts	Fable 5 (1535)	$50	MiMo v2.5 Pro (1494, #25)	$0.87	−41	~57x
Math	Fable 5 (1539)	$50	Qwen3.7 Max (1490, #14)	$4.42	−49	~11.3x

MiMo v2.5 Pro, Xiaomi’s open-weights model, is the actual story this week, not Gemini 3.6 Flash. It sweeps four of six categories, Overall, Coding, Instruction Following, and Hard Prompts, all at the same $0.87 output price, and it does it by sitting at rank 23 to 37 in every one of those boards. A top-20 read misses it every single time, which is exactly the mistake I made drafting this section the first time around: I caught it on Coding, went back and checked the rest, and found the same miss in three more categories. Nobody’s talking about it. It’s just sitting there, MIT-licensed, being the actual answer.

Gemini 3.6 Flash, the model with a whole section above this one, doesn’t win a single category outright once you look past the top 20. It’s still inside the band in five of six categories, so it’s a perfectly good pick if you want something you don’t have to go hunting for or self-host, but the honest cheapest option in four of six categories is a phone company’s open-weights model most readers have never heard of.

Creative Writing breaks the pattern in both directions. MiMo doesn’t even show up in this category’s band, because Arena’s Creative Writing top end closes off faster (around rank 22 here) than the other categories do. And the actual cheapest thing inside that narrower band isn’t Gemini 3.6 Flash either, it’s the older, cheaper Gemini 3-Flash at $3, forty-nine points back and sitting right at the edge of the cutoff.

Math is the one category where nothing changed. Qwen3.7 Max is still the cheapest model in the band, and it’s still clinging to the very edge at 49 points back. Grok 4.5 and Gemini 3.6 Flash both sit closer to the leader for a bit more money if you’d rather not ride the edge.

One caveat on Overall and Hard Prompts: I pulled 40 rows deep for each category and the band technically hadn’t closed yet at row 40 in those two (the cutoff-adjacent rows were still inside the window). MiMo’s $0.87 is close to the price floor this cycle, so it’s very unlikely anything cheaper is sitting a few rows further down, but “very unlikely” isn’t the same as “confirmed,” so treat those two picks as high-confidence rather than fully closed.

If you’re keeping score: MiMo v2.5 Pro is the boring, correct answer this week, not Gemini 3.6 Flash. Four out of six categories, one price tag, and it took reading past rank 20 in every single one of them to find that out.

The Horror Show

Every roundup needs a section where I tell you what broke. This week was generous.

The big one was DeepSeek’s migration cliff. DeepSeek is the single most-used vendor on OpenRouter right now, about 17.6 percent of all routed tokens. On July 24 at 15:59 UTC they hard-retired the old model names deepseek-chat and deepseek-reasoner. Not deprecated with a grace period. Retired. Calls to those names now return errors with no fallback, so any service that didn’t repoint to deepseek-v4-flash or deepseek-v4-pro started throwing user-facing failures the moment the clock hit. Worse, reasoning moved from being a model name to being a request parameter, so lazy integrations silently lost their thinking mode before the hard cutoff even arrived. If your app went weird last Friday afternoon, there’s your answer.

Then there’s the Opus 5 fallback I already whined about. A benchmark that quietly swaps in a different model when the safety filter trips, by an amount nobody discloses, is exactly the kind of asterisk that gets left out of the headline.

And Kimi K3 has a confidence problem. The hallucination rate climbing 12 points while the marketing calls it “more willing to answer” is going to bite somebody who wired it into a pipeline that trusts its output. Retrieval checks and citation verification are not optional with this one.

The Still-Waiting Room

The upcoming section is short and it’s mostly one name. Gemini 3.5 Pro missed its target again, and I’ve lost count, but this is at least the fourth slip. It’s still stuck in Vertex AI enterprise preview. Instead of the Pro model everyone actually wanted, Google shipped a fistful of Flash variants on July 21, which is how we got 3.6 Flash. TechCrunch’s headline said it plainly: three new Gemini models, but no 3.5 Pro. Reporting says the model keeps failing to hit Google’s own internal performance bar. At some point “delayed” starts to read as “in trouble.”

On the open side, expect the Kimi K3 community quants and finetunes to start rolling now that the weights are public, assuming you have the hardware to do anything with them.

The Takeaway

For most of the past year, the story in these roundups was rent versus own. Big closed models you pay for by the token, versus open Chinese weights you could theoretically host yourself. This week broke that frame in both directions at once. Anthropic made the closed flagship cheaper than its predecessor, and Moonshot made the open flagship so enormous that owning it is meaningless unless you run a datacenter.

So the real question quietly changed. It’s not rent versus own anymore. It’s how much intelligence can you actually afford to run. Opus 5 answers it one way, by dropping the price of the top shelf. Gemini 3.6 Flash answers it another, by being 85 percent cheaper and good enough. Kimi K3 answers it by being technically free and practically out of reach.

For the record, the market keeps drifting east while all this happens. Chinese models hit a record 58 percent of tokens processed by US firms on OpenRouter this month, peaking around 63 percent earlier in July. DeepSeek alone is that 17.6 percent, Qwen another 13.9, and Anthropic is the last US lab standing in the top 10. Make of that what you will.

Me, I’m going to keep running Gemini 3.6 Flash for the boring stuff and paying up for Opus 5 when the task actually needs a brain. And I’m going to keep not running Kimi K3, because I do not, in fact, own a rack of H100s. Maybe next week.

Obsidian iCloud Sync in 2026, Including the Windows Problem

Stephan Miller — Mon, 27 Jul 2026 13:00:00 +0000

I sync Obsidian to two MacBook Pros, a Windows desktop, an iPad, and an Android phone, and I pay nothing for it. iCloud is not how I do it. I wrote up every method I know of in my full guide to syncing an Obsidian vault across devices, and iCloud got a short section in that post with a warning attached, because the moment an Android phone enters the picture iCloud is done.

But that pillar post never had room to explain the part people actually get burned by. So this is the long version. How to set iCloud sync up properly, what the Apple-only happy path looks like, and the specific ways iCloud Drive on Windows starts leaving random markdown files around your vault.

Who Obsidian iCloud Sync Is Actually For
How to Create a New Obsidian Vault in iCloud
How to Move an Existing Obsidian Vault to iCloud
The Mac, iPhone, and iPad Happy Path
The Setting That Quietly Destroys Your Vault
The Windows Problem
- The Workaround That Actually Respects the Problem
- When To Just Not Do It
Obsidian Sync vs iCloud
Is Obsidian iCloud Sync Encrypted?
Cleaning Up the Duplicates You Already Have
Frequently Asked Questions
The Verdict

Who Obsidian iCloud Sync Is Actually For

iCloud is the best free option in exactly one situation: every device you touch has an Apple logo on it.

Mac plus iPhone plus iPad is close to zero configuration. Obsidian on iOS has a first-class iCloud option built into the vault creation screen, which is more than you can say for Dropbox or Google Drive on that platform.

Everywhere else it gets worse. Windows is possible but unreliable, covered in detail below. Linux has no official iCloud Drive client at all. And Android is not possible in any way I would recommend to a human being, because there is no iCloud Drive client for Android that syncs a folder to local storage, and Obsidian on Android needs a real local folder. That is why my own vault lives in Dropbox with Remotely Save handling Android. My phone is the constraint that decided the whole architecture.

If your phone is an iPhone and your desktop is a Mac, stop reading comparison posts and just use iCloud. It is free, it is already on, and it works.

How to Create a New Obsidian Vault in iCloud

Two completely different procedures get searched for here, and people mix them up constantly. Creating a fresh vault in iCloud is the easy one. Do this first if you are starting clean.

On iPhone or iPad:

Open Obsidian and tap Create new vault.
Give it a name. Make it something you will recognize in Files.
Turn on Store in iCloud.
Tap Create.

On Mac:

Open Obsidian and choose Create new vault.
For the location, browse to iCloud Drive and pick or make a folder there.
Create the vault.

On disk, the Mac path is ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/, which shows up in the Files app as iCloud Drive > Obsidian. That is where the iOS app puts vaults, and it is worth knowing because it is the folder you will be pointing other tools at later. Obsidian’s own docs are direct about this: vaults should live inside the Obsidian folder in iCloud Drive. A vault you drop somewhere else in iCloud Drive will sync between Macs fine and then fail to show up in the iOS app’s vault list, which is a confusing hour of your life you can skip.

How to Move an Existing Obsidian Vault to iCloud

This is the one that goes wrong. The instinct is to drag your vault folder into iCloud Drive and open it. Do not start there.

Back the vault up first. Copy the entire folder somewhere outside any sync service. A zip on your desktop is fine, and it is the only thing standing between you and a bad afternoon.
Close Obsidian on every device. Not backgrounded on your phone. Closed. Two clients writing into a folder during an initial upload is how you generate conflicts on day one.
Create a new empty vault in iCloud using the steps above, with the same name as your existing vault.
Move the contents of your old vault into that new iCloud folder. Include the hidden .obsidian folder if you want your settings, themes, hotkeys, and plugins to come along. On Mac, Cmd + Shift + . toggles hidden files in Finder.
Wait for the upload to finish completely before opening Obsidian anywhere. Watch the iCloud status in Finder’s sidebar. Rushing this is the whole problem.
Open it on your Mac first , let plugins load, then open it on iOS.

On a big vault, leave the attachments out of the first pass. Sync the markdown, confirm it works, then move the images. Markdown files are tiny. Attachments are what blow up the initial sync window and give conflicts room to happen.

The Mac, iPhone, and iPad Happy Path

Once the vault is in place, the Apple-only setup genuinely is the low-maintenance option. Edits show up on the other device in a few seconds when both are awake and online. Obsidian’s own settings sync along with the vault because .obsidian is just another folder, so if you have gone deep on installing Obsidian plugins you do not have to set them up again per device.

Two habits keep it that way. Let one device finish syncing before you start editing on another, because sync services do not have opinions about which version of a paragraph you meant. And never run a second sync system on the same vault. Not Obsidian Sync on top of iCloud, not Dropbox pointed at the same folder, not a Git plugin committing every two minutes. Two sync engines fighting over one folder is the most reliable way to lose notes, and it is self-inflicted every time.

The Setting That Quietly Destroys Your Vault

Turn off Optimize Mac Storage for iCloud Drive, or at least understand what it does before you leave it on.

When macOS decides you are low on space, it evicts the local copies of files it thinks you are not using and leaves a placeholder with a little cloud icon. For photos, fine. For an Obsidian vault, not fine. Search, graph view, and backlinks all depend on files actually being present on disk. An evicted note is not a note. Searches come back short, links look broken, and nothing warns you that half your vault is currently a stub.

The setting is in System Settings > [your name] > iCloud > iCloud Drive. If you need it on for storage reasons, open iCloud Drive in Finder, control-click the vault folder, and choose Keep Downloaded to exempt it. Windows has the same concept with a different name, and it is worse there, which is a good segue.

The Windows Problem

Obsidian’s own documentation says flatly that iCloud Drive on Windows may lead to file duplication or corruption. When the people who make the app warn you off a sync method, that is worth more than any blog post, including this one.

iCloud for Windows exists. You install it from the Microsoft Store, sign in, and get an iCloud Drive folder in File Explorer. You can point Obsidian at a vault inside it. It will appear to work. Then, over days and weeks, these things start happening.

Placeholder files instead of real files. iCloud for Windows does on-demand downloads the same way OneDrive does. A file with a cloud icon next to it is not on your disk. Obsidian tries to read it, and depending on timing you get an empty note, a failed read, or a plugin that throws. Vault-wide operations like search and Dataview queries are the worst hit because they touch everything at once. You can fight this by right-clicking the vault folder and choosing Always keep on this device , which pins it locally. Do that before anything else if you are going to attempt this at all.

Duplicate files with numbers appended. This is the classic symptom and the reason people search for this problem. You end up with Meeting Notes.md and Meeting Notes 2.md, sometimes several generations deep. It happens when the Windows client and another device both write a file before either has seen the other’s version. iCloud does not merge and it does not prompt. It keeps both and renames one.

The .obsidian folder taking damage. Your config folder is a pile of small JSON files that get rewritten constantly as you use the app. That write pattern is exactly what a lazy sync client handles worst. Corrupted workspace.json, plugin settings reverting, hotkeys resetting, community plugins disabling themselves. If your Windows machine keeps forgetting your setup, this is why.

Sync that just stops. The client parks in a pending state and stays there. No error, no notification, just a folder that stopped updating while you kept typing into it.

Timing that encourages all of the above. iCloud on Windows is slower to propagate changes than it is between Apple devices. A longer window between “I saved” and “the other machine knows” is a bigger window for conflicts.

The Workaround That Actually Respects the Problem

The fix that works is to stop letting Obsidian and iCloud touch the same folder.

Keep your working vault in a plain local folder on the Windows machine, somewhere iCloud cannot see. Then run a separate process that syncs that local folder to the iCloud copy, with real conflict handling. Obsidian only ever talks to fast local disk, and the sync layer deals with iCloud’s nonsense on its own schedule.

gursimar/obsidian-icloud-windows-sync does exactly this. It is a Python three-way sync engine that tracks the local vault, the iCloud copy, and a history snapshot so it can tell the difference between “this file changed here” and “this file changed on the other side.” When both changed, it keeps the newer one by modification time and saves the loser as a _CONFLICT_<timestamp> file rather than silently picking a winner. It uses atomic writes and a stabilization delay so it is not reacting to Obsidian’s autosave mid-keystroke. The README is explicit that it must run natively on Windows and not under WSL, because iCloud placeholder files behave incorrectly when accessed through WSL.

That is a real answer, but be honest with yourself about what it is. It is a Python script you have to configure with a YAML file, keep running, and troubleshoot when it stops. If that sounds like a project rather than a solution, it probably is one for you.

When To Just Not Do It

If your setup is Windows plus iPhone, iCloud is the wrong tool. You are picking the option that is worst on your primary computer for the sake of convenience on your phone.

Dropbox with Remotely Save covers Windows and iOS without any of this. So does Syncthing if you want nothing in the cloud at all. Obsidian Sync costs money and handles it. Any of those is a better use of your evening than fighting a sync client that is not designed for the write pattern of a notes app.

I keep a Windows desktop in my rotation. I have never once been tempted to put my vault in iCloud on it.

Obsidian Sync vs iCloud

The honest comparison, since “obsidian sync vs icloud” is what a lot of people are really asking.

	iCloud	Obsidian Sync
Price	Free with your existing iCloud storage	Standard $5/mo, or $4/mo billed annually. Plus $10/mo, or $8/mo annually
Storage	Shares your iCloud quota	Standard 1 GB. Plus 10 GB, upgradable to 100 GB
File size cap	iCloud Drive limits	Standard 5 MB. Plus 200 MB
Version history	Whatever iCloud keeps, not note-aware	Standard 1 month. Plus 12 months
Windows	Unreliable, see above	Works
Android	No	Works
Linux	No	Works
Encryption	In transit and at rest, Apple holds the keys unless Advanced Data Protection is on	End-to-end by default
Conflict handling	Duplicate files	Merges, with per-file history to recover from

Four dollars a month is the price of not reading this article. If you use Obsidian daily and your devices are not all Apple, that is a rounding error against the time any free method will cost you. I do not pay it, but I also enjoy this kind of problem, which is not a normal thing to enjoy.

The version history row is the one people undervalue. iCloud can restore some files some of the time. Obsidian Sync keeps per-note history that understands what a vault is. The first time you need it, that gap is enormous.

Is Obsidian iCloud Sync Encrypted?

Yes, but probably not in the way you are assuming.

iCloud Drive is encrypted in transit and encrypted on Apple’s servers by default, and Apple holds the keys. That means Apple can access the contents and can be compelled to hand them over. Standard data protection is the default on every account.

Turning on Advanced Data Protection moves iCloud Drive to end-to-end encryption, so only your devices hold the keys. It is in System Settings > [your name] > iCloud > Advanced Data Protection on a Mac, and the same path under Settings on iOS. The tradeoff is real. Apple makes you set up at least one alternative recovery method first, either a recovery contact or a recovery key, because once it is on Apple does not have the keys to help you. Lose your recovery methods and the data is gone. That is the entire point of it.

Obsidian Sync is end-to-end encrypted by default with no configuration. If your vault holds anything you would call sensitive, that difference matters more than the price difference does.

Cleaning Up the Duplicates You Already Have

If you got here after the fact, the vault is already littered with numbered copies. Work in this order.

Close Obsidian everywhere, let iCloud finish syncing, and copy the whole vault out to somewhere iCloud does not control. Then find the offenders. On Mac, from the vault root:

find . -name "* 2.md" -o -name "* 3.md" -o -name "*conflicted copy*"

On Windows, in PowerShell:

Get-ChildItem -Recurse -Filter "* 2.md"

Diff before you delete. Most numbered copies are identical to the original and safe to remove. Some contain the only copy of a paragraph you wrote:

diff "Meeting Notes.md" "Meeting Notes 2.md"

Merge what matters, delete the rest, fix any internal links that pointed at the duplicate, then fix the cause or you will do this again next month. Fixing the cause means taking the Windows machine out of the iCloud path, or moving the vault to a method that handles conflicts properly.

You can also automate the finding part. Obsidian Cleaner, one of the plugins I had Kiro build for me on free monthly credits, surfaces conflicted copies, numbered duplicates, and zero-byte markdown files as a checklist you can review before deleting. I built it because I kept hitting this, which tells you how common the problem is across every sync method, not just iCloud.

Frequently Asked Questions

How do I sync Obsidian with iCloud? On iOS, enable Store in iCloud when you create the vault. On Mac, put the vault in ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/.

How do I connect Obsidian to iCloud on a vault I already have? Close Obsidian everywhere, create an empty iCloud vault with the same name, and move your files plus the hidden .obsidian folder into it. The order matters more than the steps do.

How do I move my Obsidian vault to iCloud without losing anything? Back up first, and wait for the initial upload to finish before you open the vault on a second device. On a large vault, sync the markdown first and the attachments second.

Does Obsidian iCloud sync work on Windows? It runs, but it is unreliable. If you must do it, keep the working vault in a plain local folder and mirror it to iCloud with a tool like gursimar/obsidian-icloud-windows-sync rather than letting Obsidian edit inside the iCloud folder.

Is Obsidian iCloud sync encrypted? Encrypted in transit and at rest, but Apple holds the keys unless Advanced Data Protection is on. Obsidian Sync is end-to-end encrypted by default.

Can I sync Obsidian to Android with iCloud? No. Use Dropbox with Remotely Save, Syncthing, or Obsidian Sync instead.

The Verdict

iCloud sync for Obsidian is genuinely good and genuinely free, right up to the edge of Apple’s ecosystem, where it falls off a cliff with no railing.

All Apple, all the time: use it, it is the right answer and you can stop researching. Windows in the mix: it is a maintenance project, and you should either run a real sync layer on top of it or pick a different method entirely. Android anywhere in your life: it is not a choice you have.

I landed on Dropbox and Remotely Save because of an Android phone, and I have no regrets about it, though I did spend a weekend getting there. The methods are not ranked by quality. They are ranked by which devices you happen to own, and the honest advice is to pick based on your worst device rather than your best one.

The Bottleneck Was Me: How I Stopped Racing My AI Builder and Started Pacing It

Stephan Miller — Wed, 22 Jul 2026 12:00:00 +0000

The last post ended on a clean little problem. I’d gotten my PLAN.md lean: the decisions up top, the history filed away, a skill that keeps it that way so I don’t have to. The plan was finally generating work faster than I could build it. And that exposed a new bottleneck on the build side: my setup hands one task at a time to a background Sonnet agent and waits. The builder finishes, then sits there idle while I plan the next one. So I asked the next question: how do you keep the builder always busy?

The goal turned out to be a decent description of the symptom and a terrible description of what I actually wanted. This is the post where I figured out the difference, by doing it backwards first.

This is part three of a series about working with AI coding agents using a single living PLAN.md instead of vibe coding or spec-kit ceremony. Post one is the thesis. The doc is the deliverable, the code is the byproduct. The last post was about keeping that doc from turning into a 28,000-word novella.

The Batch That Hooked Me
The Experiment: A Pre-Specified Queue
I Optimized the Wrong Thing
The Gap Was the Point
The Model: A Serial Queue
Two Ways to Stack
The Real Bottleneck Was Never the Task Slot
The Name
The Honest Scope Note
What’s Next

The Batch That Hooked Me

The seed of this whole idea was a session a few weeks back where I did something different. Instead of speccing one hardening task, launching it, and waiting, I lined up a batch of small mechanical jobs and drove them back-to-back as one verified sequence. Each one: Sonnet builds it, I re-read the diff and the tests, then I launch the next. The test count climbed 140 → 234 across the run.

Driving them as a batch freed up enough of my attention that I was working a second project at the same time, jumping back and forth between this content pipeline and my other repo. The fact that the builder grinding away in the background bought me time to go be useful somewhere else.

I filed that away as a direction and went back to feeding the plan. But it nagged at me, because I’d named it wrong in my own head. I called it “keeping the builder busy,” and I built the next experiment around that name.

The Experiment: A Pre-Specified Queue

Here’s how I decided to actually test it. I had a real feature coming up: making the content pipeline able to require embedded artifacts in an article. A brief could say “this post needs at least two of: a code block, a comparison table, a diagram,” and the pipeline would produce them, preserve them through the humanizer, and verify they’re actually there at the end. Four moving parts, real dependencies between them.

So instead of speccing it one task at a time the way I always had, I pre-specified the entire arc up front as an ordered queue. Four tasks. Task A, the schema that declares the requirement, had to land first, because the other three all depend on it. Then B (the writer produces the artifacts), C (the humanizer preserves them), and D (the checker verifies them) could each go independently. I wrote all four specs, mapped the dependency, and flagged the genuine design forks, the questions only I could answer, to settle before anything ran.

The point of pre-specifying the whole thing wasn’t speed. It was to find out where pre-specifying breaks down. Which specs would look airtight on paper and fall apart the moment a builder touched real code.

Then I ran it. And immediately optimized the wrong variable.

I Optimized the Wrong Thing

Task A landed first. It had to; everything blocked on it. But B, C, and D were independent. So Claude decided to run them concurrently.

Three Sonnet agents, in parallel, each on its own task, each on a disjoint set of files. And it worked. All three landed clean. The test suite went from 234 to 328. If you’d asked me to measure throughput, I’d just tripled it. By every number I’d have put on a dashboard, this was the win.

It felt awful.

Because the second those three agents came back, they came back together. The background hum that let me work on the other project and do slow human thinking. Gone. I’d taken a process whose entire value was spreading work out over time and I’d compressed it back into a single spike of “everything needs you, now.”

I’d been accidentally optimizing for throughput : get the most build done per unit time. But throughput was never what bought me the second project. What bought me the second project was the gap. Parallelism doesn’t widen that gap. It removes it.

The Gap Was the Point

The builder’s grind is not a cost to be minimized. It’s a resource. A long-enough synchronous build is a gap I spend doing the slow human work: investigating, answering my own open questions, and making the design calls that only I can make. Often on a completely different project. The ideal loop isn’t “builder always busy.” It’s two slow things overlapping in time: the machine grinding through mechanical work while I grind through judgment work. Pacing, not racing.

Once I saw it that way, the design fell out immediately:

Synchronous, one-task-at-a-time, is the default , because that’s what manufactures the gap. One builder, working a queue in order, then stopping to report. The stop is a feature. It’s the handoff point where I come back, review, and re-aim.
Parallel is a rare opt-in burst, for the specific case where I’m actively babysitting this project and want raw speed more than I want freed attention. But it’s not a default. The session that taught me this lesson proved parallel works. It just also proved it’s the wrong thing to reach for ninety percent of the time.

The Model: A Serial Queue

So the task handoff file got reshaped. It used to be TASK.md: singular, one task, overwrite it for the next one. Now it’s TASKS.md, and the active task is a serial queue of numbered pieces. The builder works them top to bottom, in one pass, then stops and reports. Finished work doesn’t get overwritten and lost. It collapses into a ✅ Done archive with a stable tag, so the file carries its own history.

Two Ways to Stack

Because once the active task is a queue you can stack as deep as you want, two genuinely different working modes fall out of the exact same mechanism:

Pacing. Stack a couple of pieces. The builder grinds them while I plan the next batch a step ahead. By the time it stops, I’ve got the next chunk ready to go. This is the everyday rhythm, the overlap of machine-grind and human-thinking I’ve been describing the whole post.

Unattended. Stack a lot of pieces (an hour’s worth) and walk away entirely. Go do something else, something not-this-project, and come back to a pile of finished, tested work and one report. Same serial builder, same queue. The only difference is how deep I stack it and whether I’m in the room.

They’re mechanically identical, but the unattended mode forced two rules that the pacing mode never exposed, because pacing rarely runs more than a piece or two before I’m back:

A blocked piece must not halt the queue. If the builder hits piece 3 of 8 and it turns out underspecified (some fork I didn’t see), the old rule was “stop and report.” Fine when I’m sitting right there. Catastrophic when I’m gone for an hour, because pieces 4 through 8 never run even if they don’t depend on the broken one. So the rule is now: mark the blocked piece, skip it, and keep going with anything that doesn’t depend on it. Halt only when nothing left can proceed. An hour away should come back with six of eight done, not two.

State gets logged on every stop. This is the one that matters most for walking away. Whenever the builder stops, finished or blocked, it writes its state directly into TASKS.md: which pieces are done, which are blocked and why, what’s left, where to resume. It flips a status box on each piece as it goes.

## Design — pieces
- [x] 1. Schema: declare required_artifacts on the brief
- [x] 2. Writer produces the artifacts
- [!] 3. Humanizer preserves them — BLOCKED: heading-protection
       order is ambiguous, needs a call
- [x] 4. Checker verifies presence (depends on #1)

### ▶ Run state
3 of 4 done. #3 blocked on a design fork (see above). Resume there.

Why in the task file and not somewhere clever? Because that file is already what the builder is working in, it survives the session getting killed, and if I come back tomorrow having completely forgotten where I left off, the file tells me. No memory required, mine or the agent’s. The thing that makes unattended runs safe to walk away from is that every piece keeps the test suite green, so “done” actually means done, and the state log means “interrupted” never means “lost.”

The Real Bottleneck Was Never the Task Slot

I’d assumed the constraint on keeping a builder fed was the single-task slot: one TASK.md, one job at a time, obviously that’s the chokepoint. It isn’t. The real bottleneck is spec throughput. The builder only stays fed if there’s a backlog of fully-specified, mechanical tasks waiting for it. The moment a task hits a real design fork, a genuine “should it do A or B” that only I can answer, the queue stalls, no matter how clever the queue is.

And pre-specifying that whole embedded-artifacts arc up front is what made this visible, because it told me exactly where my specs leak. The verdict: pre-specifying nails structure and leaks on judgment. The file decomposition was right. The dependency order (A blocks the rest, B/C/D are independent) was right. What broke was subtler:

One task rested on a wrong premise. I’d specified the “diagram” artifact as something the pipeline could satisfy with an ASCII drawing. But my actual diagram practice is to render real images, with ASCII only as a fallback. That’s not a fork the builder could catch or resolve. It’s a wrong assumption baked into the spec, and only I could see it, because it lived in my head and not in the code.
A judgment call hid inside a “mechanical” task. The artifact checker had to count distinct artifacts, and my supposedly airtight spec quietly let one image get counted twice toward the requirement. The builder implemented exactly what I wrote. What I wrote had a bug. I only caught it because I read the diff.

Which is the callback to post one’s whole “trust but verify” spine, and it’s more load-bearing in a pipeline, not less. The batch doesn’t skip verification. It removes the round-trip with me between tasks, not the rigor. I still read every diff the builder actually wrote. Both of those bugs, the double-count and a separate one where a config value silently broke its file format, got caught at my review, not by the agents. The lesson for the queue is precise: a task is only “ready” when its premises and its judgment semantics are pinned, not just its files. Pinning the files is the easy 80%. The leak is always in the other 20%, and the other 20% is mine.

The Name

The seed of this post had a whole brainstorm in it about finally renaming the skill. Its name describes one of the three things it does and I can never remember it. I had candidates: planwright, for the one who authors plans, and foreman, for the one who keeps the line moving and the builder fed. And given that this entire post is about keeping the line moving, foreman was right there, practically gift-wrapped.

I did not rename it. I codified the whole convention, ported it into the skill, patched both projects, and left the dumb name exactly where it was. The rename is real work. It’s wired into three repos now, and I wasn’t going to fake-land it just to give this post a tidy bow. So the name is still wrong, foreman is still leading, and it’ll get fixed when it gets fixed. Consider this the third post in a row where I’ve promised to rename the thing.

The Honest Scope Note

Every post gets one. Here’s this one’s: this is the frontier of the method, not a settled result.

The pacing-over-throughput call is fresh. I made it by running the throughput version, hating it, and reasoning backward, which is a strong signal but a sample size of basically one. The unattended mode, with its skip-and-continue and its state logging, is built but barely road-tested; I haven’t actually walked away for a real hour and come back to judge what I found, and I’d bet the skip-and-continue logic has edge cases I haven’t hit. The “promote a recurring judgment into an automatic rule” idea from the last post is still unproven. And the deepest claim here, that spec throughput, not the task slot, is the true bottleneck, is a hypothesis I’ve confirmed exactly once.

What I’m confident about is the shape of the mistake, because I made it cleanly: optimizing throughput when I wanted pacing is a real and seductive wrong turn, and “keep the builder busy” is exactly the kind of goal that leads you into it. The metric that’s easy to put on a dashboard, work per unit time, is not always the one you actually care about. Sometimes the gap is the product.

What’s Next

I don’t know yet, and I’m not going to force a cliffhanger. The plan stays lean, the builder runs on a paced queue, and I can stack it shallow to work alongside it or deep to walk away from it. The pieces are in place. What I don’t have is a real verdict on the unattended mode under fire, or a clue whether the “spec throughput is the bottleneck” insight holds up across more than one feature arc. Those are the next things to actually live with rather than theorize about.

There may be a post four. There may not. The method’s still moving, and I’d rather tell you what actually happened than what would make a clean ending. So far that’s served the series fine. We’ll see what the gap fills with.

Kimi K3 and Inkling: The Week the Open Models Won

Stephan Miller — Tue, 21 Jul 2026 13:00:00 +0000

Last week I signed off by saying I’d see you when Gemini 3.5 Pro and DeepSeek V4 had presumably set something on fire. Well. Gemini 3.5 Pro missed its launch date again, for the third time. DeepSeek V4 is quietly shipping with a deadline attached that’s going to ruin somebody’s Friday. And while the three biggest AI labs on the planet were busy being late, two models you can just download showed up out of nowhere. One of them is now the fourth-smartest model on Earth, ahead of Claude Opus 4.8, and it came from Moonshot, a lab most people couldn’t have picked out of a lineup a year ago.

That’s the whole week. The frontier moved, and it didn’t move at OpenAI, Google, or Anthropic. It moved open.

The Open Frontier Crashed the Party
Kimi K3 Is Genuinely Smart and It Never Stops Thinking
Inkling: Mira Murati Gives It Away
Meanwhile, the West Was Late Again
The Cheapskate Picks
Horror Stories From the Wild
What’s Coming
The Takeaway

The Open Frontier Crashed the Party

Here’s the setup you need. For most of this year, the “open weights are catching up” story has been a Chinese story. DeepSeek, Qwen, GLM, MiMo. Good models you could download, consistently a few points behind the closed Western flagships, consistently way cheaper. The pattern was reliable enough to be boring.

This week two things happened in a 48-hour window that broke the pattern.

On July 15th, Thinking Machines Lab shipped Inkling, a 975-billion-parameter open-weights model, under an Apache 2.0 license, on Hugging Face, right now, today. On July 16th, Moonshot AI shipped Kimi K3, a 2.8-trillion-parameter monster that lands at number four on the Artificial Analysis Intelligence Index. Two frontier-class open (or opening) models from two labs that are not the big three, dropped back to back.

On the Intelligence Index, Kimi K3 lands at 57.1, behind only Claude Fable 5 at 59.9 and GPT-5.6 Sol at 58.9, and ahead of Claude Opus 4.8 at 55.7. Read that again. An open-weight model from a Chinese lab is beating Anthropic’s own Opus 4.8 on raw intelligence. That is not “catching up.” That’s arrived.

Kimi K3 Is Genuinely Smart and It Never Stops Thinking

Let me tell you what makes Kimi K3 the headline and then tell you the part that’ll cost you money.

The good part first. K3 is a 2.8-trillion-parameter mixture-of-experts model, which is the largest open-weight model anybody has announced. It only activates 16 of its 896 experts per token, so it’s big but not insane to run. It’s got a 1-million-token context window and it’s multimodal. The full weights are coming to Hugging Face by July 27th under a modified MIT license that lets you use it commercially.

But the number that matters is Arena. Normally when a model launches, the Arena leaderboard takes a week or two to catch up, because Arena is vote-based and nobody’s voted on the new thing yet. New models are supposed to be invisible on Arena for a bit. Kimi K3 did not get that memo. Three days after launch it’s already in the top 10 of every category I track: Overall #8, Coding #9, Creative Writing #9, Instruction Following #10, Hard Prompts #10. On Arena data dated July 19th. Three days. That doesn’t happen unless a lot of people tried it and a lot of people liked what they saw.

On cost-per-task, Artificial Analysis clocked it at about $0.94 to run one Intelligence Index task. That’s roughly half of Opus 4.8’s $1.80 for a model that scores higher on intelligence. On paper, that’s a steal.

Now the part that’ll cost you money.

K3 always thinks. There is no non-thinking variant. The reasoning_effort is locked to maximum, and every one of those reasoning tokens bills as output at $15 per million. Simon Willison ran his usual “generate an SVG of a pelican on a bicycle” test on launch day and the model burned 13,241 reasoning tokens before it produced a 3,417-token answer. His verdict on the pricing was blunt: “This is expensive. The pelican cost 25 cents.” One pelican. A quarter.

So the cost-per-task number is real, but it’s an average, and the tail on that average is fat. The visible answer you get back is a fraction of what you actually pay for, because you’re renting the model’s internal monologue at output rates whether you want it or not. If you were burned by the whole cost-per-task lesson last week (Grok 4.5 winning on tokens-per-job while sitting fourth on intelligence), K3 is the same lesson wearing different clothes. The sticker says $3/$15. Your invoice will say something with more zeroes.

Inkling: Mira Murati Gives It Away

The other open drop is the one that made me sit up, and not because of the benchmarks.

Inkling comes from Thinking Machines Lab, which is Mira Murati’s outfit. If the name doesn’t ring a bell, she was OpenAI’s CTO. So this is a former top executive of the most closed, most commercial AI lab in the world shipping a 975-billion-parameter model on Hugging Face under Apache 2.0, framed explicitly around low cost and, in their words, “resistance to censorship.” You can legally fine-tune it, ship it in a product, and never pay Thinking Machines a cent.

The specs are interesting. 975B total parameters, only 41B active per token, multimodal across text, images, and audio. It’s got a thinking-effort dial you can turn from 0.2 to 0.99, which is exactly the knob Kimi K3 refuses to give you. Want cheap and fast? Turn it down. Want it to grind? Turn it up. That’s the right design, and Moonshot should take notes.

On the composite Intelligence Index, Inkling only scores 41, which is well down the board, so don’t expect it to beat Fable 5 in a general chat. But dig into the specific benchmarks and it’s a different story: 77.6% on SWE-bench Verified, 97.1% on AIME 2026 math, 87.2% on GPQA Diamond, and 74.1% on MCP Atlas for agentic workflows. Sebastian Raschka called it the best open multimodal generalist out there right now, and the category-level scores back that up. It’s not a great chatbot. It might be a great tool.

Here’s why these two drops matter together. The “own your weights” argument used to be a China thing, and if you had opinions about running Chinese models in production, you could opt out of the whole conversation. You can’t anymore. When Mira Murati is handing out Apache-2.0 weights and Moonshot is shipping the biggest open model ever built, the choice in front of you isn’t “American closed model or Chinese open model.” It’s “rent from three labs, or own from everybody else.” That’s a genuinely different question than it was a month ago.

Meanwhile, the West Was Late Again

While all that was happening, the closed Western frontier did its now-familiar thing: it announced a date and then missed it.

Gemini 3.5 Pro was targeting July 17th. That was already a slip from June, which was itself a slip from Google I/O in May. Google reportedly scrapped the base model entirely and rebuilt it after engineers found structural failures in recursive tool-calling and SVG generation. Ambitious. Also, the 17th came and went and it’s still limited to a handful of enterprise preview customers. No public API, no confirmed pricing, no confirmed 2-million-token context window, none of the rumored Deep Think reasoning layer you can actually touch. Third promised date, third miss. At this point I’m not writing another word about Gemini 3.5 Pro until there’s an endpoint I can hit with a real API key. It’s vapor until it isn’t.

DeepSeek V4, on the other hand, is very real, and it comes with homework. The V4 family is graduating from preview to stable, and if you use DeepSeek’s hosted API, you have a hard deadline: July 24th at 15:59 UTC. After that, the old model names deepseek-chat and deepseek-reasoner stop working. They start returning HTTP 404 and 400 errors. More on that in the horror section, because it’s nastier than it looks.

The Cheapskate Picks

Okay. The part you can actually use.

Same method as always. For each Arena category, I take the leader’s rating and find the cheapest model within 50 rating points of it. Arena’s top is compressed, so “cheapest in the band” is a real choice between models that are genuinely close, not settling for junk.

And this week I have to own something, because I got it wrong the first time I ran these numbers. “Within 50 points” is a band defined by points, not by rank, and I’d been reading down the first screen of the leaderboard and calling that the band. It is not the band. In Coding, the leader is Opus 4.7-thinking at 1553, which puts the cutoff at 1503 — and the leaderboard doesn’t drop below 1503 until rank 46. Forty-six models are inside that window. I was sorting the first twenty and declaring a winner, which is exactly the mistake this section exists to stop you from making. The bands run 44 deep in Overall, 39 in Hard Prompts, 27 in Instruction Following. Only Creative (14) and Math (6) actually fit on one screen.

Fix the band, and the answer changes in four of six categories. Arena data below is dated July 19th. Fable 5 leaders run about $50 per million output tokens; Opus-thinking leaders about $25.

Category	Leader	$ out	Cheapskate pick	$ out	Δ rating	Cheaper by
Overall	Fable 5 (1507)	$50	MiMo v2.5 Pro (1466, #33)	$0.87	−41	~57x
Coding	Opus 4.7-thinking (1553)	~$25	MiMo v2.5 Pro (1519, #23)	$0.87	−34	~29x
Creative	Fable 5 (1513)	$50	Gemini 3.5 Flash (1467, #11)	$9	−46	~5.6x
Instruction Following	Fable 5 (1513)	$50	MiMo v2.5 Pro (1470, #19)	$0.87	−43	~57x
Hard Prompts	Fable 5 (1533)	$50	MiMo v2.5 Pro (1494, #22)	$0.87	−39	~57x
Math	Fable 5 (1550)	$50	Grok 4.5 (1504, #5)	$6	−46	~8.3x

So the value story of the week is Xiaomi’s MiMo v2.5 Pro at $0.43 in / $0.87 out, sweeping four of six categories. Not narrowly, either. On Coding it sits 34 points off the best coding model in the world at a twenty-ninth of the output price , and it’s been sitting there with 11,355 votes behind that rating — this is not a preliminary number on a model that dropped Tuesday. It shipped in April. It’s MIT-licensed open weights. In a week whose headline is “the open models won,” the cheapest competitive model on four separate leaderboards turning out to be a phone company’s MIT-licensed side project isn’t a coincidence. It’s the same story from a different angle.

Two honest caveats, because a 57x price gap deserves scrutiny.

First, Artificial Analysis does not rank MiMo v2.5 Pro near the top — it scores 42 on the Intelligence Index, against Kimi K3’s 57.1. That’s the classic Arena-loves-it/AA-doesn’t split, and it means what it usually means: people prefer MiMo’s answers head-to-head, but it isn’t doing frontier-grade reasoning on the hard stuff. For everyday coding, instruction-following, and general work, preference is the metric that matches how you’ll actually use it. For genuinely hard problems, pay up.

Second, it’s slow. 58.2 output tokens per second, below median for its class. If you’re running an agent loop where latency compounds across hundreds of calls, that 57x price advantage buys you a wall-clock penalty you should measure before you commit.

Two runners-up worth knowing. If your workload is input-heavy or long-context, Qwen3.7 Plus is cheaper on the input side at $0.32 in / $1.28 out and sits inside the Coding band at #36. And last week’s champion, Meta’s Muse Spark 1.1 at $1.25 / $4.25, is still competitive on rating — but it’s now about 5x more expensive than MiMo and it’s geo-locked to US developers on OpenRouter, so it falls out of the recommendation twice over. More on that below.

Kimi K3 is right there in the Coding band too at #9, but at $15 output with that always-on thinking tax, it is not the cheapskate answer. It’s the “I want the best open model and I’ll pay for it” answer.

Math is the fun one this week, and it’s the one category where the band really is tiny — six models, top to bottom. The pure cheapskate pick is Grok 4.5 at $6 output, sitting at #5, cheapest thing in the band. But look one row up: Gemini 3.5 Flash is at #3 on Math, 1518, only 32 points behind Fable 5, for $9. For the third or fourth week running, Gemini 3.5 Flash is quietly the smart-money answer for math and creative work. If you’re paying Fable 5’s $50 to do math and Flash is sitting 32 points back at a fifth of the price, you’re not buying quality, you’re buying a rating difference smaller than the noise in the measurement.

Also worth flagging: several of these Fable 5 category-leader ratings are sitting on thin vote counts (Math #1 has under 500 votes). Don’t over-trust a fresh #1 with that little data behind it.

Horror Stories From the Wild

Every roundup needs the part where I tell you what’s going to ruin your day. This week there are three, and one of them has a countdown clock.

The DeepSeek migration cliff. July 24th, 15:59 UTC. If you’ve got deepseek-chat or deepseek-reasoner hard-coded anywhere in your codebase, those names get retired and start returning 404 and 400 errors. Here’s the sneaky part: both of those names already route to DeepSeek-V4-Flash under the hood, and have since April. So nothing looks broken today. Your code works fine right up until next Friday afternoon, when it doesn’t. And the fix isn’t a clean find-and-replace, because thinking mode moved from being its own model name to being a request parameter. If you naively swap deepseek-reasoner for deepseek-v4-flash and call it done, you’ll silently drop reasoning on all that traffic and wonder why your outputs got dumber. Go patch this now, not on the 24th.

Kimi K3’s metered brain. I already covered this up top, but it belongs in the horror section on principle. There is no way to turn K3’s thinking off. Every request pays for a full reasoning trace at $15 per million output tokens, whether the question needed it or not. Simon Willison’s pelican cost 25 cents. Scale that across an agent loop making thousands of calls and the “half the cost of Opus” headline evaporates fast. Contrast it with Inkling shipping a thinking-effort dial the same week, and K3’s design choice looks less like a feature and more like a billing strategy.

The value pick you’re locked out of. Meta shipped the cheapest competitive brand-name model of the week and then restricted it to US developers on OpenRouter. Muse Spark 1.1 was last week’s cheapskate champion in three categories, and for most of the planet it’s just a leaderboard entry you get to look at. Cool. Very open. Very connected world we live in. It got dethroned on price this week anyway, which is its own kind of answer: the model you can buy from anywhere is 5x cheaper and ships its weights.

What’s Coming

Kimi K3 open weights land on Hugging Face by July 27th, modified MIT license. This is the one to actually wait for if you want to own it instead of renting the API.
Gemini 3.5 Pro , allegedly, eventually. Missed July 17th. I’ll believe it when I can curl it.
DeepSeek V4 graduates preview to stable, with that mandatory API migration deadline on July 24th. Set a reminder.
Inkling derivatives. Apache 2.0 weights are already out, so expect fine-tunes and specialized variants to start showing up fast. That’s the whole point of shipping it open.

And the background hum, unchanged and getting louder: Chinese-origin models are now about 46% of all OpenRouter tokens, and as of July 20th they hit a record 58% share among US firms specifically. US labs have fallen from roughly 70% of token volume to 30% year over year. Anthropic’s Claude slid from 29% to 13%. DeepSeek alone is 17.6%, the single largest vendor on the platform, with Qwen right behind. Two more open flagships this week did not slow that trend. They poured gas on it.

The Takeaway

The intelligence race at the very top is still basically a tie: Fable 5, GPT-5.6 Sol, Kimi K3, Opus 4.8, all inside four points. But the interesting thing this week wasn’t who’s smartest. It was who’s ownable.

For the first time, the answer to “I want a near-frontier model I can actually hold in my hands” isn’t a compromise. Kimi K3 is fourth on the whole intelligence board and its weights ship in a week. Inkling is out right now under a license that lets you do whatever you want with it. The former CTO of OpenAI is handing out model weights. Meanwhile the three labs whose whole pitch is “trust us, it’s on our servers” spent the week being late, geo-locking their cheap model, and metering your reasoning tokens.

So here’s what I’m actually doing. I’m patching my DeepSeek model names before Friday, because I’m not getting caught by a 404 on a Friday. I’m keeping Gemini 3.5 Flash on math and creative, because paying 5x more for a rating rounding error is still stupid this week. I’m moving my bulk coding and instruction-following traffic to MiMo v2.5 Pro and eating the latency, because 29x is not a margin you argue with. I’m waiting the seven days for Kimi K3’s weights before I decide whether it’s worth the thinking tax, because owning it changes the math. And I’m downloading Inkling this weekend just to see what a 975-billion-parameter model does on my own hardware, because I can, and a month ago I couldn’t.

Rent everything, own nothing was the mood in June. In July the challengers handed out the keys. Read your bills, and maybe download a frontier model while it’s free. See you next week, when Gemini 3.5 Pro has presumably missed a fourth date.

Planning Is Cheaper Than Coding, and My Own Logs Proved Me Wrong About Why

Stephan Miller — Wed, 15 Jul 2026 12:00:00 +0000

I went into this post sure of one thing: coding with an agent burns tokens like a house fire, and planning is the cheap part where you just talk. I’ve felt it. You watch the agent grep twenty files, read half of them, figure out what it already built, then start writing, and the usage bar just keeps moving forward. Planning, by comparison, is me and Opus talking for three hours and barely denting the budget. Obvious, right?

So I did the thing I should always do before I put a claim in writing. I looked at a month of my own Claude Code session logs across two projects.

The meter came back flat. Coding and planning cost about the same to run. I was wrong about why coding is expensive.

The Slogan, and the Hole in It
What the Meter Actually Says
The Expensive Kind of Cheap
And Planning Is Dense
Even the Prototype Gets a Plan
My Freeform Rhythm
Planning Is Also How I Learn the Thing
So, Cheap Compared to What

The Slogan, and the Hole in It

The line I started with is “planning is cheap, coding is not.” I still believe it. But there’s a hole in it and I’d rather stab it myself than let a commenter do it.

Here’s the hole: agents made code fast. The whole selling point is that you describe a thing and the machine types it out in a minute. If typing is free now, in what sense is coding “not cheap”? A skeptic reads the title and closes the tab, because on its face the tool that generates 2,000 lines while you get coffee is the cheapest thing in the whole stack.

I couldn’t answer that cleanly, which usually means I don’t understand my own point yet. So instead of arguing from vibes, I went and measured.

What the Meter Actually Says

Two projects. Both ones I had genuinely no idea how to build when I started. Which is the whole reason they’re useful here. One is a content pipeline. The other is a knowledge-graph site I’ve written about before. Different domains, different stacks, both explored more or less blind.

I parsed every session’s log and split each of the agent’s turns into two buckets: conversation turns (the agent replied with text and touched nothing) and tool-action turns (it ran a command, read, edited, or wrote a file). It’s not a clean planning-vs-coding line (the agent talks during a build and reads files during planning), but across a month it’s a fair read on where the time and tokens go.

	Content pipeline	Knowledge-graph site
Sessions (about one month)	22	14
Conversation vs tool-action turns	59% / 41%	59% / 41%
Output tokens (talk vs build)	65% / 35%	61% / 39%
Tokens per turn (talk vs build)	~100K vs ~98K	~119K vs ~122K

Two things fell out of this, and one of them is the whole post.

First: both projects landed on the exact same split. Fifty-nine percent conversation, forty-one percent building. Two unrelated codebases, two different domains, both started from “I don’t know what the fuck I’m doing,” and I independently spent about sixty percent of my turns just deciding. I didn’t plan that symmetry. It’s just what working in unknown territory costs.

Second, and this is where I lied to myself: the per-turn token cost is basically flat. On the content pipeline, a conversation turn and a tool-action turn cost within about three percent of each other. Same story on the other project. Coding doesn’t burn more tokens than talking. It just feels like it does, because you sit there watching it work.

The reason is boring and it’s caching. I plan on a million-token context window, and every single turn, whether the agent is writing a paragraph of reasoning or grepping the repo, re-reads roughly the same enormous cached context. The dominant cost per turn is the size of the context, not the activity inside the turn. Reading a cached window is cheap per token, but there’s a mountain of it, and it gets re-read on every message. Planning quietly pays that toll on every back-and-forth and hides it, because nothing visible is happening. Coding pays the same toll and shows you a progress bar, so you blame the progress bar.

So “coding burns more tokens” is just false, at least for how I work. Good. Now I have to figure out what I actually meant.

The Expensive Kind of Cheap

Here’s what I meant, once the data forced me to say it properly:

Planning and coding cost about the same to run. What’s wildly different is the cost of being wrong.

A wrong decision while planning costs one edited sentence. I write “we’ll use X,” I talk it through, I realize X is dumb, I change the sentence to “we’ll use Y.” Done. The blast radius is a paragraph.

The same wrong decision, once it’s code, costs a refactor. Or a dead end. Or a start-over. Because the agent didn’t just write the line that encodes the decision. It wrote the four modules downstream that assume it, the tests that lock it in, the data shapes that depend on it. Agents didn’t make coding cheap. They made typing cheap, which is a different thing, and worse in a specific way: they make your wrong assumptions reality faster and in greater volume than you ever could by hand. By the time you notice the assumption was wrong, it’s load-bearing in a thousand lines.

That’s the real asymmetry. Not tokens. Reversibility. Prose is cheap to be wrong in because it’s cheap to change. Code is expensive to be wrong in because everything else is stacked on top of it. Planning is cheap because you can throw it away for free. Coding is expensive because you mostly can’t.

And I have the scar tissue to prove it. Of the first fifteen-or-so projects I built with AI, something like half either got completely refactored or thrown out and restarted from scratch. I burned out on the whole approach once and the lesson that came out the other side was, essentially: I had to plan more. Every one of those rewrites was a wrong decision I’d committed to code instead of catching in a sentence.

The cleanest example is a choice I didn’t pay full price for. On the content pipeline, this was my first real jump into agentic development: building workflows, not just pointing a coding agent at a repo. I’d done my own reading for a while and my instinct was the LangGraph / LangChain family. It’s what everyone reaches for. But before I committed, I spent planning sessions researching it with the agent and testing a couple of open-source projects built on it. In my testing the tokens just evaporated. Gone, nothing to show. Pair that with a pile of horror stories from people running those frameworks in anger, and I bailed. Landed on Pydantic Graph instead and it’s working well. And I can look at the code and know how it works.

Notice where that decision happened. In research and planning. Cost: a few conversations and a couple of throwaway test runs. If I’d made that call the vibe way (pick LangChain because it’s the default, build three weeks on it, then discover the token hole), that’s not a conversation. That’s a rewrite. Same wrong turn, two completely different bills, and the only variable was whether I found out in prose or in code.

And Planning Is Dense

There’s a second thing the meter doesn’t catch, and it cuts the same direction. My split, 59% talking and 41% building, counts effort. It says nothing about yield, and the yield is lopsided as hell.

Fifteen minutes of planning doesn’t buy fifteen minutes of building. It can buy an hour. A clear decision, a couple of constraints, a handoff to the agent, and it goes and runs with all of it while I do something else. Planning is dense. A little of it aims a lot of building.

Which is the reversibility point again, from the other end. That same dense fifteen minutes, if the decision underneath it is wrong, doesn’t cost you fifteen minutes back. It fans out into the whole hour that got stacked on top of it. Leverage runs both ways. A good plan multiplies what you build; a bad one multiplies what you rewrite. The denser the planning, the more each decision is worth getting right while it’s still just a sentence.

Even the Prototype Gets a Plan

The obvious objection: “Fine, but prototypes are throwaway. The whole point is to build junk fast and learn from it. Planning a prototype is like drawing blueprints for a sandcastle.”

I used to believe that. I don’t anymore, and it’s the same reversibility argument.

A prototype with no plan doesn’t actually test anything. It just generates code that looks like it works, which is the single most expensive output there is, because it lies to you convincingly. If you can’t say what question the prototype is supposed to answer, you haven’t built an experiment. You’ve built a thing that runs.

Planning a prototype doesn’t mean a spec. It means one honest sentence: what am I actually trying to find out here? Does this framework survive my token budget? Does this data shape hold up when the input gets weird? Can this feature even do the thing before I build the other five around it? That’s the plan. It’s cheap (cheaper than the prototype), and it’s the difference between a prototype that de-risks the project and one that just adds a codebase you’ll abandon.

The stakes go up in unknown territory, not down. When you already know the domain, you can afford to skip ahead, because your gut is a decent planner. When you don’t know the domain (which is where I live now, on purpose), the plan is the only thing standing between you and confidently building the wrong thing very fast.

My Freeform Rhythm

None of this means I plan the whole thing up front and then march. I never have. My process, long before AI, was tracer bullets with the safety off.

Back when I built scrapers (and I built a lot of scrapers), I’d start with a command-line app that did the one core thing. Does it actually pull the data? Yes? Okay. Then maybe a little Electron UI to wrap it. I had a vague idea of the architecture I wanted, but I’d build it up, change it, and refactor mid-stream constantly, because I wanted to see the result. That’s the honest core of it: I’m a creator and a builder more than a technologist. Code, AI, tools: those are how I make things, not the thing I love. I jump toward the result.

The AI version of this is the same shape. I get one feature working really well (not “it runs,” but “it does what I actually want as the end user”), and then I jump. Right now the article-writing pipeline is about 75% of the features I want, and I’ve hit the part I’ll admit out loud is boring. Nothing new is going to surprise me in the last 25%. There’s no “whoa, that’s cool” left in it, just grind. And I can grind, but there’s a timer on how long before I need something interesting again.

So I’m jumping to the novel-writing feature, because that’s going to be interesting for a while. The rest of the article pipeline goes on the back burner until I’m in grind mode again. One rule I don’t break, though: I’d rather leave a feature incomplete than ship one that isn’t what I want. I test each one as the actual end user (not “does it run,” but “would I be annoyed using this”) because I’ve learned the hard way that assuming a feature is right and backtracking later is exactly the expensive-code problem that is the point of this post. Incomplete is free. Wrong is a refactor.

Yeah, this probably means a pileup at the end, where everything I put off comes due at once and it’s grind mode for days. I’m aware. But that’s for the Stephan of tomorrow. He is much more patient than the Stephan of today…I tell myself.

Planning Is Also How I Learn the Thing

There’s one more reason planning earns its 59%, and it’s not on any token report.

I’m learning these domains while I plan them. I don’t know Pydantic Graph cold. I’m learning it as I go. I’m learning how graphify’s guts work slowly, session by session, on the other project. A big chunk of what looks like “planning” is really the agent teaching me the terrain before I commit to a route through it. Every back-and-forth where it explains why a graph approach beats a chunked one, or what a framework’s failure mode is, is a decision I now get to make with my eyes open instead of discovering the map by driving off the cliff.

And that learning compounds into things I couldn’t have specced on day one. Enough sessions poking at graphify taught me its node-and-edge model. Well enough that when I wanted my whole Obsidian vault in a graph, the agent didn’t just charge ahead and it didn’t flat refuse either. It made a reasoned call: pointing graphify at all ~2,400 notes in one shot wasn’t worth the grind, here’s why. So on a different project I had it build a custom connector instead, one that pulls every note’s folder, tags, and wikilinks out as structured facts, the exact raw material a graph turns into edges. I couldn’t have asked for that connector, or understood why the agent was right to talk me out of the brute-force version, before graphify taught me what a graph actually wants. The planning didn’t just produce decisions; it produced a version of me who knew enough to ask for the right thing.

Which is exactly why I never use plan mode. The official one, the structured feature: I don’t touch it, not for anything open-ended. It collapses the conversation into multiple choice. Pick A, B, or C. And when a decision is still half-formed, the options are never quite the thing in my head. I end up arguing with the menu instead of thinking. I want the back-and-forth: ask a question, get an answer, push on it, change my mind three exchanges in, then decide. That messy conversation is what has to happen. It’s where the learning lives, and it’s where the cheap decisions get made before they turn into expensive code. I wrote up the actual machinery I use instead (one living plan doc, numbered decisions, the whole system) in the living-plan post, so I won’t rerun it here.

So, Cheap Compared to What

I’m not here to tell you you’re doing it wrong. I genuinely don’t care if the vibe-coder down the street thinks planning is for cowards. Live and let live. Or live and mortgage your house to cover your coding bill, your call. Some of the best things I’ve built started as pure “just build it and see.” Prototyping to figure out how something even works is real and I do it constantly.

But I pulled my own numbers hoping to prove coding was the expensive part, and the meter told me the truth instead: it costs about the same as talking. The expense was never in the tokens. It’s in the concrete. A wrong sentence is free to fix. A wrong foundation is a rewrite, and the agent will happily pour you a bigger one, faster, than you could ever pour yourself.

So plan the thing. Plan the prototype, even. Especially the prototype. Not because planning is virtuous. Because it’s the only place left where being wrong is still cheap. Unless you’re a millionaire, of course, but for us working stiffs, coding still costs real money.

GPT-5.6 Finally Shipped, Then Grok and Meta Ate Its Lunch

Stephan Miller — Tue, 14 Jul 2026 13:00:00 +0000

Between Tuesday and Wednesday, July 8th and 9th, three different labs dropped flagship models. xAI shipped Grok 4.5. OpenAI finally let GPT-5.6 out of the building. Meta launched Muse Spark 1.1. Three frontier releases in about 48 hours, which is the kind of thing that used to happen once a quarter.

Nobody won. Not on intelligence, anyway. The smartest model in the world is still Claude Fable 5, same as last month. What every one of these launches was really fighting over was the bill. Not the sticker price on the API page. The actual amount of money that leaves your account when the agent finishes the job. That’s the whole story this week.

The 48-Hour Flagship Pileup
GPT-5.6 Shipped From House Arrest
Grok 4.5 and the Number Nobody’s Talking About
Meta Closed the Door on the Way Out
The Cheapskate Picks
Horror Stories From the Wild
What’s Coming: July 17 Is Going to Be a Bloodbath
The Takeaway

The 48-Hour Flagship Pileup

For the last two weeks I’ve been writing about GPT-5.6 as vaporware. OpenAI previewed it in late June and then locked it to about twenty government-vetted partners under a frontier-AI review process. You couldn’t use it. I couldn’t use it. It was a press release with a benchmark chart attached.

Then on July 9th it went fully generally available on ChatGPT, the API, Codex, and GitHub Copilot, all at once. Great. Except the day before that, xAI dropped Grok 4.5, a model priced so aggressively it makes GPT-5.6 Sol look like a luxury purchase. And the same day GPT-5.6 shipped, Meta launched Muse Spark 1.1 at roughly a quarter of what Anthropic and OpenAI charge for their flagships.

So OpenAI’s big moment, the flagship it had been dangling for a month, got sandwiched between two competitors on the same 48-hour window, both of them attacking the exact axis OpenAI is weakest on. If you’re keeping score at home on the Artificial Analysis Intelligence Index, the top now reads something like Fable 5 at 60, GPT-5.6 Sol at 59, Opus 4.8 at 56, Grok 4.5 at 54. That’s a dogpile inside six points. When the top four models are that close on capability, “which one is smartest” stops being an interesting question. “Which one is cheapest to actually run” becomes the only question.

GPT-5.6 Shipped From House Arrest

Let’s give OpenAI its due first. GPT-5.6 comes in three sizes and, unlike some past launches, the naming actually maps to something useful:

Sol , the flagship: $5 in / $30 out per million tokens
Terra , the everyday model: $2.50 / $15, which OpenAI pitches as “GPT-5.5 performance at half the price”
Luna , the cheap one: $1 / $6

All three carry a 1M context window and 128k max output. Sol lands at #2 on the AA Intelligence Index at 59, and it set a new high on Agents’ Last Exam at 53.6, beating Fable 5 by a full 13 points. If you’d stopped reading OpenAI’s launch post there, you’d think they’d taken the crown.

Then you flip to SWE-Bench Pro, the coding benchmark, and Fable 5 scores 80% while Sol manages 64.6%. OpenAI’s response to that gap was, roughly, to question whether the benchmark is any good. Which is a bold move when it’s the same benchmark everyone was citing last month. Here’s the thing I keep coming back to: the headline eval and the embarrassing eval are on the same page of the same launch. That’s not a knock on the model, it’s a reminder that you pick the benchmark that matches your actual work, not the one the vendor put in bold.

Simon Willison had early access to Sol and his take was the most honest one I read: “definitely very competent,” but not more impressive than Fable for complex coding. He also noticed Sol likes to over-investigate before it acts, which is a polite way of saying it burns tokens thinking in circles before it does the thing. More on that theme in a second, because it’s the theme of the entire week.

One genuinely cool bit: OpenAI is putting Sol on Cerebras hardware at up to 750 tokens per second. Fast is a real feature for agent loops. Just not fast enough to be the story.

Grok 4.5 and the Number Nobody’s Talking About

Here’s where I have to admit I underestimated xAI.

Grok 4.5 launched July 8th at $2 in / $6 out per million tokens. That’s over 60% cheaper than Opus 4.8 or GPT-5.5. It lands at #4 on the AA Intelligence Index, above every open-weight model and above every Gemini model on the board too. It was trained on real Cursor session data, which is the kind of thing that either makes a coding model great or gets you into a benchmark scandal, and this week it did both. We’ll get there.

But the number nobody’s putting in their headline is cost-per-task. Artificial Analysis measured GPT-5.6 Sol at $1.04 to run one Intelligence Index task. Grok 4.5? $0.31. Roughly a third of the cost for a model that’s four spots down and change on raw intelligence.

How? Token efficiency. Grok 4.5 uses about 15,954 output tokens on a SWE-Bench Pro task. Opus 4.8 uses 67,020 for the same work. That’s a 4.2x difference in how much the model talks to itself to arrive at an answer, and since you pay per token, that ratio lands directly on your invoice. On coding-agent tasks specifically, AA clocked Grok at $2.49 per task versus $5.07 for GPT-5.5 and $11.80 for Fable 5.

Read that last sentence again. Fable 5 costs almost 5x what Grok costs to finish the same coding task. Not because its per-token price is 5x higher (it’s not), but because it thinks longer and harder and you pay for every one of those tokens. This is the trap I keep watching people fall into: they compare the $/million numbers on the pricing page, pick the “cheaper” model, and then get a bigger bill because it’s chattier. The sticker price is not the price.

Now the asterisks, because there are real ones:

Grok 4.5’s launch scores were vendor-reported with no model card shipped. Cursor had to withdraw one internal benchmark after it came out that Grok had trained on their codebase — which, given it was literally trained on Cursor session data, is exactly the conflict you’d worry about. And the capability tradeoff is ugly: on the AA-Omniscience test, Grok’s accuracy climbed from 35% to 52%, which sounds great, except its hallucination rate also jumped from 25% to 54%. It knows more, and it’s more confident when it’s wrong. That’s arguably the worse failure mode. A model that admits it doesn’t know is annoying; a model that fabricates with conviction is the one that ships a fake function name into your codebase at 2 AM.

Oh, and it dropped from a 1M context window down to 500k, and it’s not available in the EU yet. But at $0.31 a task, a lot of people are going to forgive all of that.

Meta Closed the Door on the Way Out

Muse Spark 1.1 is the quiet winner of the week and also the most ironic.

Meta priced it at $1.25 in / $4.25 out , about a quarter of flagship rates, threw in $20 of free credits per account, and it immediately started landing inside the competitive band across the Arena leaderboard. Overall #6 at 1490. Coding #8. Instruction Following #8. Hard Prompts #7. It’s not topping anything, but it’s competitive everywhere at a price that undercuts almost everyone. That’s the definition of a value pick.

Here’s the irony. This is Meta, the company whose entire AI identity was giving models away. Llama got downloaded over a billion times because you could run it yourself, fine-tune it, own it. Muse Spark 1.1 ships closed-weight. No download, no local deploy, no fine-tuning. If your reason for loving Meta’s models was that you could actually possess them, that reason is gone. The cheapest brand-name model on the board this week is also the one that just walked away from open source. Make of that what you will. I have some feelings about it, and none of them are inspirational.

The Cheapskate Picks

Okay, the part you can actually use. Same method as always: for each Arena category, I take the leader’s rating and find the cheapest model within about 50 rating points of it. Because Arena’s top end is compressed (the whole competitive pack usually fits inside a 50-point window), “cheapest in the band” is a real choice between models that are genuinely close, not settling for garbage.

One caveat this week: Grok 4.5 and GPT-5.6’s Terra and Luna tiers are so new that Arena hasn’t accumulated enough votes to rank them in most categories yet. So they don’t show up in the band even though they’re obvious value plays. I’ve noted where that matters. Opus-tier leaders are priced around $25/million output; Fable 5 leaders at $50.

Category	Leader	$ out	Cheapskate pick	$ out	Δ rating	Cheaper by
Overall	Fable 5 (1505)	$50	Muse Spark 1.1 (1490)	$4.25	−15	~11.8x
Coding	Opus 4.7-thinking (1553)	~$25	Qwen3.7 Max (1526)	$3.75	−27	~6.7x
Creative	Fable 5 (1507)	$50	Gemini 3.5 Flash (1471)	$9	−36	~5.6x
Instruction Following	Opus 4.6-thinking (1513)	~$25	Muse Spark 1.1 (1487)	$4.25	−26	~5.9x
Hard Prompts	Opus 4.6-thinking (1532)	~$25	Muse Spark 1.1 (1513)	$4.25	−19	~5.9x
Math	Fable 5 (1548)	$50	Gemini 3.5 Flash (1517)	$9	−31	~5.6x

A few notes. Muse Spark 1.1 is the story here. It wins three categories outright as the cheapskate pick, mostly because it’s brand-name cheap and Arena caught up to it fast. For coding, Qwen3.7 Max is the by-the-numbers pick, but the real coding value if you don’t care about the Arena ranking is Grok 4.5 at $2.49 a task. It’s just not Arena-rated yet, so I can’t put it in the table honestly.

And Gemini 3.5 Flash keeps quietly winning Math and Creative for the third or fourth week running. At $9 output it beats every Claude Opus-thinking variant on Math except one. If you’re doing math-heavy or creative work and you’re paying Fable 5’s $50, you are lighting money on fire for a rating difference smaller than the noise in the measurement.

Also worth flagging: Fable 5’s Math #1 rating of 1548 is sitting on only 360 votes. That’s thin. Don’t over-trust a fresh #1 with that little data behind it.

Horror Stories From the Wild

Every roundup needs the part where I tell you what’s going to ruin your day. This week it comes courtesy of Cursor, and it’s a good one.

Multiple users on the Cursor forums reported that when they selected Grok 4.5 in the CLI, their usage logs showed they were actually being billed for GPT-5.6-sol-medium. Separately, Grok 4.5 was routing its subagent calls to GPT-5.6-terra-medium instead of the model people thought they’d picked. So you select the cheap, token-efficient model, and you get silently billed for a different, pricier one. This is the exact nightmare scenario for a week where the whole selling point is cost-per-task. The tooling can’t reliably tell you which model you’re even running, let alone what it costs. There were also plain “Grok 4.5 errors out and won’t come back” reports. New model, new plumbing, same old chaos.

The second horror story is the Grok hallucination number I already mentioned: a 54% hallucination rate on AA-Omniscience, up from 25%. I’m repeating it here because it deserves to live in the horror section too. A model that’s wrong more than half the time on knowledge questions and more confident about it is not a model you point at anything that touches production without a human reading every line.

What’s Coming: July 17 Is Going to Be a Bloodbath

Mark the 17th. Two big things land the same day.

Gemini 3.5 Pro is finally targeting July 17, after Google scrapped its base model and rebuilt the whole thing from the ground up. Reportedly engineers found structural failures in recursive tool-calling and SVG generation and decided a rebuild beat a patch. Context window, pricing, specs: still unconfirmed. Google has reportedly shed something like $225B in market cap over the delays and a DeepMind talent exodus, so there’s a lot riding on this one not being a dud.

DeepSeek V4 graduates from preview to official stable release the same day. V4-Pro at 1.6 trillion params, V4-Flash at 284 billion, both with 1M context. And if you’re already using DeepSeek, note the deadline: the API migration is mandatory by July 24th. After that, deepseek-chat and deepseek-reasoner start returning errors. Don’t get caught by that on a Friday.

Also on deck: Grok 4.5 EU availability is promised for later this month, and Anthropic extended Fable 5 access on all paid plans plus kept Claude Code’s weekly limits 50% higher through July 19th.

Background hum, unchanged: DeepSeek is still around 17.6% of all OpenRouter tokens, Chinese-origin labs are collectively pushing 46%, and US labs’ share has fallen from roughly 70% to 30% year over year. Three Western flagship launches in one week did not move that needle. They moved the price sheet.

The Takeaway

If there’s one thing to carry out of this week, it’s this: stop reading the pricing page and start reading your invoice.

The intelligence race is basically a tie at the top. Four models within six points. In a tie, the tiebreaker is cost, and cost is not the number on the API docs. It’s tokens-per-task times price-per-token, and the two frontier models with the flashiest benchmarks (Fable 5, GPT-5.6 Sol) are also the ones that think the longest and bill the most per finished job. Grok 4.5 winning on cost-per-task while sitting fourth on intelligence is the entire lesson in one data point.

So here’s what I’m actually doing. I’m running Grok 4.5 for coding tasks where I can eyeball the output, precisely because it’s cheap per task, and watching it like a hawk because of that hallucination number. I’m keeping Gemini 3.5 Flash on math and creative work because paying 5x more for a rating rounding error is stupid. I’m letting the GPT-5.6 hype cool for a couple weeks until there’s lived-experience data instead of launch-day benchmarks. And I’m double-checking which model my tools are actually calling, because apparently that’s not a settled question anymore.

Rent everything, own nothing, read your bills. That’s where the model world sits in July 2026. See you next week, when Gemini 3.5 Pro and DeepSeek V4 have presumably set something on fire.

I Got Tired of AI Memory Hype, So I Built a Context Lake

Stephan Miller — Wed, 08 Jul 2026 12:00:00 +0000

There are problems with creating a report that brings you all the AI news it can find every morning. The first time you hear about some new technique or technology, you’re on it. You’re testing it out. Two days later, you uninstall it to try the next one. Right about the 13th to 25th time you hear the same thing, you actually hear a carnival barker instead and move on.

Well, I got tired of hearing about AI memory. Every tool, every framework, every other thread has its own flavor of it: short-term, long-term, episodic, semantic, a memory MCP, some SDK that bolts a “memory layer” onto your agent. None of them agree with each other. I started skipping those articles.

Part of that is timing. I adopted AI coding early, back when the tools were genuinely crappy, and honestly a lot of them still are. So I’ve already been through a hype cycle or two. Install the getting-shit-done skill bundle, it’ll do miracles. Install the superpower skills, guess what, even better, shinier miracles. So I did. What I got was a bloated pile of skills scattered everywhere, half of them firing at random on the wrong things, most of them quietly depending on three other skills just to work. It burned me out. I’ve started to think early adoption is its own little curse: you go in idealistic and you come out the other side disillusioned. So by the time “memory” showed up as the next miracle, I was already numb to it.

Then, on a completely unrelated project, I accidentally built a piece of the answer without realizing that’s what I was doing. I’d wired up graphify (a tool that turns a codebase into a knowledge graph) and a vector database to index the research behind a project. Not the code. The notes, the plans, the stuff I’d been reading to figure out what to build get synced to a folder daily (I still read some of the news) and processed. I just wanted one place to plan from. It worked unreasonably well.

A while later I ran into a paper that put a name to the thing I’d stumbled into: a Context Lake. First idea in the entire memory conversation that made me go oh… yeah, that actually makes sense. It also didn’t hurt that I already built part of one.

One brain, not one per agent

The paper is a theory paper. It lays out what a Context Lake is and what it has to guarantee, then more or less leaves the actual building as an exercise for the reader. But the core idea fits in one breath:

Stop giving every agent its own memory. Give them all one brain, and let them read from it.

Yes, that’s the hype again, but by building it I knew how it worked. One place that quietly keeps track of everything you actually work on (your notes, your code, your past AI conversations) and stays current. Whatever tool you’re using just asks it for what it needs. I also knew I wouldn’t have to install it as a plugin in Claude. And I am going to say it. FUCK plugins. Let’s just call them “lockins.” We have portable standards, right? So why the fucking plugins, seriously. Yeah, it’s a touchy subject with me.

Now, if you’ve used any of these coding tools, you already have a version of this in your head. “A brain my agent reads from” probably sounds like: it remembers what we did last session, it knows the shape of the project, maybe someday it knows about my Jira tickets or my Confluence pages. That’s the version everyone’s racing to ship. And if that were all a Context Lake was, I’d have kept tuning it out.

It’s the stuff that only shows up once the brain is sitting outside the agents that got me to actually build one.

The part nobody pictures

Start with where the brain’s contents even come from. The tools I use all day, Claude Code and OpenCode, already write down what they did: every session is a record of what I asked, what the agent changed, and, crucially, which project I was in when it happened. That last part is the sneaky-powerful bit. If the lake reads those session logs, it doesn’t need me to tell it which repos matter or point it at my projects. The sessions already say. It back-traces from “here’s what you were working on” to “here’s the code and the context that go with it,” on its own.

Which means the core of the thing assembles itself. I don’t sit down and configure my whole life into it. I work the way I already work, and the record of that work is the setup. Everything else (pulling in an Obsidian vault, wiring up email or Jira down the line) is stuff I add on purpose, on top of a spine that populated itself for free.

And once the lake is quietly recording all of that, not just what’s in your files but how you and your agents actually work together, it stops being only a place to read from. It starts to notice things. Where you keep hand-fixing the same kind of output. Where you ask for the same thing over and over. Those are patterns, and patterns are something it can act on: “you keep correcting this, want me to fix the skill that keeps getting it wrong?” For a developer, that’s sharpening your own tools. For someone who isn’t a developer, it’s the same engine pointed a different direction: “you keep doing this by hand, want me to build you a app that just does it?”

That’s the part I keep coming back to. Every other memory tool stops at handing your agent better context. This one watches the friction pile up over time and offers to remove it, because it’s the only thing in the stack that can see the whole loop.

The sketchy part: it was going to need an MCP

I already ranted about plugins up there. Treat this as the sequel, because I’ve got one more name on the list: MCPs. I hate MCPs. Yeah, so fuck MCPs too, while your at it. Not the idea of them, the idea’s fine, a shared standard for handing an agent tools and data. The reality is that in my experience they randomly work when they’re supposed to and randomly don’t, and I’ve never found the pattern. So I’ve ended up at the same sad little ritual everyone ends up at: every single time I need the thing, I tell the agent to use it, by name, out loud, because it will not remember on its own. Ever. Or it might, sometimes, but that’s even worse actually.

Which is exactly where this project got sketchy. A Context Lake is a brain the agents read from. So how does an agent read from it? It calls out to it. And the standard, everybody-does-it-this-way plumbing for “agent calls out to an external service” is an MCP. I’d designed myself straight into depending on the one piece of the stack I trust the least: build the nice outside brain, then wire it to the agent with the flakiest connector I can find and pray the agent remembers to ask.

Then I found a post from Jason Zhou about a codebase-memory tool he’d been using, and it solved my problem from the side. His complaint was word-for-word mine: these “index your codebase” tools never stuck for him or his team, because either the index went stale or the agent forgot to call the special MCP tools. Same disease. His fix is the part that clicked, and the clever bit isn’t that he threw the MCP out. The tool is still an MCP. He just stopped relying on the agent to remember it. He hangs a pre-tool-use hook on grep, the one command the agent reaches for a hundred times a day anyway. The agent greps like it always does, and in the same step the hook quietly looks that query up in the graph and folds the structural answer into the result. The agent never had to remember a special tool. It greps, and the map rides along.

That was the missing piece, and it wasn’t about hating MCPs into submission. It was about not depending on the agent’s goldfish memory. Claude Code has hooks. So my lake doesn’t have to sit there as a tool the agent might call if it feels like it. It can ride along on something the agent already does and push what’s relevant in at the right moment, on its own. For my own thing I can lean on that even harder than he does: a hook can read the lake and inject context directly, no MCP in the middle at all, no plugin to install, no “please use the memory tool” chanted at the top of every session. It doesn’t ask the agent to be disciplined. It just works whether the agent cooperates or not. That post didn’t hand me the Context Lake. It handed me the thing that made me sure I could build one without it living or dying on whether the agent remembers to ask.

Why build my own instead of installing one of the five billion

Here’s the honest reason I’m building my own instead of just installing one of the memory tools that already exist: I want to know how it works. All of it. Every piece.

Because right now I can’t tell those tools apart. Mem0, Zep, Letta, Cognee, Graphiti, and a new one every week, each with a landing page swearing it’s the one, and from the outside they’re indistinguishable. The exact wall of “AI memory” noise that made me tune out in the first place. The only way I’ve ever cut through that kind of thing is to build it myself, badly if I have to, until I actually understand the moving parts. Once I’ve done that, I’ve got a ruler. Maybe I’ll find something in the wild that’s better than what I made. Great, I’ll happily throw mine out. But now I’ll be able to tell that it’s better, and why.

Where it actually is right now

So where is it actually? Honestly: part-built and mostly promise. The plumbing that reads my sessions and files into one place exists. A lot of the rest, the self-improving part especially, is still me sketching how the pieces fit and betting they will. I’m fairly sure they will; I’ve built enough to not see why they wouldn’t. But I want to be straight that a good chunk of what I’ve described here is potential.

I’m fine with that, because the thing I was chasing was never a product. It was a frame. A way of thinking about all this memory noise that finally sat still and made sense. Stop bolting a brain onto every agent. Build one, outside of them, that they all read from. Everything else is downstream. Whether my version survives contact with reality, the idea is the part I’d want you to walk away with. It’s the first one in this whole space that made me stop tuning out.

Claude Fable 5 Came Back, Sonnet 5 Shipped, and the Bill Went Up Anyway

Stephan Miller — Tue, 07 Jul 2026 13:00:00 +0000

Three weeks ago I watched the best AI model on the planet get switched off by the U.S. government. Not deprecated. Not price-hiked into irrelevance. Switched off. A Commerce Department letter landed at Anthropic on a Friday afternoon and Claude Fable 5 went dark worldwide, including for Anthropic’s own staff. I’d been using it, I got the “this model is unavailable” wall, and I spent the back half of June rerouting everything to Opus 4.8 like it was 2025.

On July 1 it came back. And in the same 48-hour window, Anthropic shipped a brand-new model, Claude Sonnet 5, that looks on the pricing page like the deal of the summer. Two bucks per million input tokens. I almost repointed my whole Claude Code setup at it before my coffee finished brewing.

Then I did the math. You know how that goes. The frontier is back online, folks, but this week it comes with a warning label: bring a calculator.

The Frontier Came Back Online
Sonnet 5: Cheaper Per Token, More Expensive Per Answer
Who’s Actually Shipping (And Who’s Stuck at the DMV)
The Cheapskate Table (The Part That Didn’t Flinch)
Horror Stories: The Meter Is Running
What’s Coming
The Takeaway

The Frontier Came Back Online

Let’s start with the good news, because there isn’t much of it in a month where the top model spent nearly three weeks as a paperweight.

Claude Fable 5, the one that’s been sitting at #1 on the LMArena text leaderboard all quarter, is available again as of July 1. The U.S. Commerce Department lifted the export controls it slapped on the model (and its unfiltered sibling Mythos 5) back on June 12. The whole mess started when Amazon researchers found a jailbreak: prompt Fable 5 the right way and it would happily identify a software vulnerability and, in at least one case, write the code to exploit it. That’s the kind of thing that gets you a government directive instead of a bug bounty.

The fix that ended the 19-day standoff is almost anticlimactic. Anthropic redeployed Fable 5 with a single new safety classifier trained to catch that one jailbreak technique. When a request trips it (reportedly 99%+ of the time), the request doesn’t just get refused. It gets quietly rerouted to Opus 4.8 for a second opinion. Commerce’s shiny new Center for AI Standards and Innovation reviewed the safeguard before pulling the controls.

And Fable 5 immediately went right back to running the table. It’s #1 on Arena Overall (1509), and #1 in Coding (1563), Creative Writing (1499), Instruction Following (1520), and Hard Prompts (1533). It’s #2 in Math by a single Elo point. Anthropic holds nine of the top twelve coding slots. Whatever you think about a model getting court-ordered off the internet, the thing is genuinely, stupidly good.

Here’s the catch nobody’s putting on the marketing slides: that reroute-to-Opus classifier is catching legitimate work. If you run security tooling, the honest kind, pentests you’re paid to run, vuln triage on your own codebase, your agent loop can hit that filter mid-run and get silently handed off to a different, weaker model with no clean signal that it happened. You asked Fable 5 to do a job and Opus 4.8 quietly answered. That’s a fun debugging session waiting to happen.

Sonnet 5: Cheaper Per Token, More Expensive Per Answer

Now the part where I almost got fooled.

Claude Sonnet 5 dropped June 30. Anthropic is calling it the most agentic Sonnet yet, and for once the marketing isn’t lying. It plans, it drives browsers and terminals, it runs autonomously at a level that a few months ago needed an Opus-sized model and an Opus-sized bill. It’s the default now for Free and Pro plans, it’s got a 1M-token context window, and on Artificial Analysis’s Intelligence Index it scores 53, good for #5 overall , sitting right on top of GPT-5.5 with high reasoning and just ahead of Opus 4.8 on agentic knowledge work.

The pricing looks like a gift: $2/$10 per million tokens as an intro rate through August 31, moving to $3/$15 after. Opus 4.8 is $5/$25. So Sonnet 5 is half the price of Opus, nearly as smart, and more agentic. Switch everything, right?

No. This is the whole point of the post. Look at cost per task instead of cost per token, and the deal evaporates.

Artificial Analysis actually ran the numbers, and an average task on their Intelligence Index costs:

~$1.20 on Sonnet 4.6 (the old one)
~$1.97 on Opus 4.8 (the “expensive” one)
~$2.29 on Sonnet 5 (the “cheap” one)

Read that again. The new Sonnet costs about 15% more per completed task than Opus 4.8 , and roughly double the old Sonnet. The per-token sticker went down and the actual bill went up.

How? Two things stack. First, a new tokenizer that’s less efficient on a lot of content, so the same input can map to 1.0 to 1.35x more tokens than it did under the old scheme, depending on what you feed it. Second, the more agentic behavior itself. With max effort it burned about 40% more output tokens per task than Sonnet 4.6 and took roughly 3x the agentic turns on knowledge-work evals. A more agentic model does more work per task by design: longer chains, more tool calls, more self-correction, more retries when a step fails. All of it billed.

This is Anthropic’s move now, and the-decoder called it out by name: raise the real cost while the per-token rate on the pricing page stays flat or drops. It’s not a scam. Sonnet 5 is a legitimately strong model and for a lot of agentic work it’s the right call. But if you switched based on the headline number without measuring your own workload, you’d be paying more and thinking you saved. The pricing page lies. Measure cost per finished task on your representative work, or don’t complain when the invoice shows up.

Who’s Actually Shipping (And Who’s Stuck at the DMV)

Step back and the shape of the week is Anthropic having an absurdly good run while everybody else’s flagship is vaporware.

OpenAI’s GPT-5.6 (the Sol/Terra/Luna trio) previewed June 26, and then went nowhere you can reach. At the U.S. government’s request, OpenAI shipped it to about 20 vetted partner organizations first, gated behind a safety review, with general availability “coming weeks” (analysts are betting July 10–17). OpenAI publicly grumbled that this kind of gating “shouldn’t become the norm.” It’s a launch you literally cannot use.

Google’s Gemini 3.5 Pro announced at I/O on May 19 with a June target, and has now slipped again to mid-July. Some reports say a full architecture rebuild after early testers flagged token-efficiency and coding problems. Still preview-only.

And while Google’s flagship stalls, its people are leaving. In one week Anthropic picked off four-plus senior Gemini researchers, including Nobel laureate John Jumper of AlphaFold fame, plus a couple more on pretraining and coding tools. Noam Shazeer, one of the “Attention Is All You Need” authors, went to OpenAI. Alphabet shed something like $270 billion in market cap over the stretch, and Anthropic is now reportedly the most valuable private AI company on earth. The people who built Gemini are literally going to go build the next Claude.

So the scoreboard for the week: one lab restored the world’s best model, shipped a new one, and hired the competition’s brain trust. The other two are showing you a locked demo and a “give us until next month.”

The Cheapskate Table (The Part That Didn’t Flinch)

Here’s the thing about all this frontier drama. If you’re actually shipping software, none of it changed what you should be running day to day. The value layer barely moved. The Cheapskate method is the same as it’s been: take the leader’s Arena rating in each category, look at everything within about 50 rating points of it, and pick the cheapest one, because the top of every Arena category is compressed into a tiny band. You are almost never paying for a meaningfully smarter model at the top. You’re paying for a rounding error.

Category	Leader	$/1M out	Cheapskate pick	$/1M out	Δ rating	You save	On AA value frontier?
Overall	Fable 5 (1509)	$50	Gemini 3.5 Flash (1479)	$9	−30	~5.6x	near it (speed leader)
Coding	Fable 5 (1563)	$50	GLM-5.1/5.2 (1524)	~$3	−39	~16x	yes
Creative	Fable 5 (1499)	$50	Gemini 3.5 Flash (1472)	$9	−27	~5.6x	near it
Math	Opus 4.6-thinking (1518)	$25	Qwen3.7 Max (1492)	$3.75	−26	~6.7x	no
Instruction Following	Fable 5 (1520)	$50	Gemini 3.1 Pro (1481)	~$12	−39	~4.2x	no
Hard Prompts	Fable 5 (1533)	$50	Gemini 3.1 Pro (1507)	~$12	−26	~4.2x	no

The headline of that table is GLM-5.2, Zhipu’s roughly 753B open-weight MoE, and it’s the model I’d actually point you at this week. It’s MIT-licensed, runs about $3 per million output tokens on open hosts, tops the open-weight SWE-bench Pro leaderboard at 62.1%, and it sits on Artificial Analysis’s Intelligence-vs-Cost Pareto frontier. Cheaper than Gemini 3.5 Flash while scoring higher on capability. When two totally different methods (my dumb “cheapest in the band” heuristic and AA’s Pareto math) point at the same model, that’s about as strong a signal as this game gives you.

One more nuance that rhymes with the Sonnet 5 lesson. Gemini 3.5 Flash wins Overall and Creative on per-token price, but per task it’s actually pricier than Gemini 3.1 Pro, because Flash burns a lot of reasoning tokens. AA has Flash costing about 75% more per task than 3.1 Pro despite the lower sticker. Same trap, different model. If your workloads are long and multi-step, price them on your own traffic before you trust the cheap-looking one.

And the throughline that’s held for a couple months now: US models have fallen from about 70% to about 30% of OpenRouter token volume in a year, with Chinese labs around 46% and six of the top ten by volume. When your #1 model can be switched off by a government letter, the open-weights model you can run yourself starts looking less like a budget compromise and more like insurance. Own your weights.

Horror Stories: The Meter Is Running

Two this week, and they’re the same story wearing different hats.

Agentic bills are blowing past budgets. TechTimes reported July 4 that Anthropic rushed enterprise spend controls out the door because customers’ agentic bills are overshooting what they planned. Seventy-eight percent of IT leaders reported unexpected charges from consumption-based AI pricing in 2026. Now drop a new, more-agentic default model into that fire. Sonnet 5 does more per task on purpose, and more-per-task means more-per-invoice. If you flip your team to it and don’t watch the meter, you find out at the end of the month.

Fable 5’s safety net is snagging real work. As covered up top, the reroute-to-Opus classifier is catching legitimate security workflows and silently swapping models on you mid-agent-loop. It’s a smaller-dollar horror than a runaway bill, but it’s the sneakier one, because nothing errors out. You just get a subtly worse answer from a model you didn’t ask for, and you’re left wondering why your pentest agent got dumber overnight.

Both are the same lesson the whole post keeps hammering. The number you look at is not the number you pay.

What’s Coming

GPT-5.6 Sol/Terra/Luna hits general availability “coming weeks,” with analysts guessing July 10–17. OpenAI is promising Cerebras hosting at up to 750 tokens/sec, which, if it’s real, is a genuinely different speed tier for agent loops.
Gemini 3.5 Pro slipped its GA to roughly July 17 after an apparent architecture rebuild. Believe it when you can actually call the API.
DeepSeek V4 is rumored for a full public launch mid-July (V4 Pro at 1.6T total / 49B active, V4 Flash at 284B / 13B, 1M context). DeepSeek is already the single largest token author on OpenRouter, so a real GA matters.
Portugal’s Amália shipped July 1, the first open LLM in European Portuguese, Apache 2.0 on Hugging Face, built for about €7 million in public money. The sovereign-model trend is quietly real, and “we built our own for the price of a mansion” is a hell of a flex.

The Takeaway

The frontier rebooted this week and it’s genuinely better than it was in June — Fable 5 is back, Sonnet 5 is a real step up in agentic muscle, and the lab that shipped both is running away with the talent war. If you only read headlines, this was a triumphant week for AI.

But the actual skill in 2026 isn’t picking the model at the top of the leaderboard. It’s reading the meter. Sonnet 5 taught it, Gemini 3.5 Flash taught it again, and the enterprise-spend-controls fire drill taught it to a lot of finance teams the hard way. Cost per token is marketing. Cost per finished task is reality. And they’re diverging on purpose.

So run GLM-5.2 for coding until something dislodges it. Price your cheap-looking models on your own traffic before you trust them. Keep an open-weights option in your back pocket for the week your favorite model gets a letter from Washington. And when a new model shows up half the price of the old one, smile, nod, and go check the invoice.

The leaderboard’s back. The meter never stopped.

The Living Plan Got Fat: Compacting a Doc That Won't Stop Growing

Stephan Miller — Wed, 01 Jul 2026 12:00:00 +0000

In a post a few weeks ago, I took a victory lap. I’d finally found a way to work with AI coding agents that didn’t collapse into chaos or drown me in specs. It was a single living PLAN.md that the agent re-reads every session, where every decision gets funneled in and logged. I ended that post on a line I was proud of: the doc is the deliverable, the code is the byproduct, and over 30 days my PLAN.md got touched 16 times, more than any actual code file in the repo.

That line was true. It was also the setup for the next problem, which I did see coming. I have just been only talking to Opus lately and having Sonnet minions do all the grunt work, which was really working out. I could work for a couple of hours or more and context barely got over 10% and I am only on the Pro plan. I just thought I had a little more runway.

The exact property that makes a living plan work is what eventually turns it into a chore. A doc you re-read every single session is great at 3,000 words. At 28,000 words it’s a lot to load before any thinking starts. This post is about the maintenance layer, and the skill I built so I’d never have to think about it manually again.

If you didn’t read the first post, the one-line version: instead of vibe coding or a pile of spec files, I keep one PLAN.md that records decisions, open questions, and a session log, and the agent treats it as the source of truth.

The Good Problem
Progressive Disclosure, Which I Was Already Doing Everywhere Else
What “Cooled” Actually Means
The Payoff: 28,357 Words Down to 8,332
It’s a Process
Why It Became a Skill: The Other Project Running This
The Skill Is a Router, Not a Script
The Honest Scope Note
What’s Next

The Good Problem

The living plan worked so well that I kept feeding it. Every architectural call went in as a numbered decision, sessions were appended a log entries, and half-formed “we should maybe…” landed in a parking lot instead of me forgetting it.

Then one morning I ran wc -w on the PLAN.md for content-tools-v2, my content pipeline project, and it told me 28,357 words.

Twenty-eight thousand words. That’s a novella. Which means every session I was spending context budget and my own attention re-skimming decisions D1 through D18, none of which had changed in over a month. D5 got decided in week two and never reopened. Why was I carrying its full body into every session four months later?

The decisions I’m actively wrestling with this week are maybe 20% of the document. The other 80% is settled history. Important history but it doesn’t need to be in my face every session. It needs to be findable, not present.

Progressive Disclosure, Which I Was Already Doing Everywhere Else

It’s how I work with CLAUDE.md in my projects. It doesn’t inline the architecture and the quickstart and the plan. It points at them: “see QUICKSTART.md, see PLAN.md.” The conductor file stays small; the heavy docs are one hop away.

I was using progressive disclosure everywhere except the one document that needed it most. Keep the hot layer (live decisions, open questions, recent sessions) right there in PLAN.md. Move the cold layer out to a docs/ tree, and leave a one-line pointer behind.

A collapsed decision still shows its heading. You still see that it exists and it links straight to the full body. Nothing is hidden.

Quick naming note, because I’m about to use one word a lot. I call this compacting the plan. When I first built the skill I named the operation “rebalancing”, and that name is now baked in. It’s the trigger word, it’s the name of the log file. So “rebalance” is going to keep showing up in this post whether I like it or not. But it’s the wrong word. I’m not balancing two things against each other toward some equilibrium. I’m compacting the hot doc and paging the cold half out to linked files on disk. So: compacting. (The skill keeps its dumb name until post 3, where it finally earns a better one.)

What “Cooled” Actually Means

This is the part that took real thought, because “just move the old stuff” is not a rule a tool can follow. Not everything cools the same way, and the heuristic has to be specific enough that I can hand it to an agent and trust the result. Here’s what I landed on:

Session logs cool by recency. Keep the last few inline (I keep three), archive everything older into docs/sessions/. This is almost always the heaviest cold mass in the whole document and it’s the safest thing to move, because a six-week-old session log is pure archive. Nobody’s making decisions off it.

Decisions stay whole while they’re hot, and collapse to a heading-plus-link when they cool. A decision is “hot” if it’s recent, still being referenced, or actively shaping current work. It cools when it’s settled, built, and nothing live points at it anymore. The exception: anything marked 🔒 foundational stays whole no matter how old it is, because the whole architecture leans on it. In content-tools that’s D23, the composable-pipeline decision the entire engine is built on. That one’s never getting collapsed.

Questions and parking-lot items are born as pointers. This was the cleanest insight. A parking-lot item doesn’t need to be classified later as hot or cold. The heading is the item. Only the question itself lives in PLAN.md. The discussion, if there is any, lives in a file in docs/. There’s no re-classification step because it started in the right shape.

The before-and-after looks like this. A hot decision sits in PLAN.md with its full body:

### D19 — Slot-3 stage reshape: deduplicator-as-gate, moved to slot 2,
contingent on empirical templating

[...a few hundred words of reasoning, tradeoffs, and what it depends on...]

A cooled one collapses to a single line that still tells you what it is and where to read it:

### D5 — Per-workspace knowledge base: curated wiki built from a raw dump → [full text](docs/decisions/D05.md)

You lose nothing. You can still see D5 exists and you’re one click from the full doc. You just stopped paying for it in every session.

The Payoff: 28,357 Words Down to 8,332

I ran the first real compaction on content-tools-v2 on June 19th. The PLAN.md went from 28,357 words to 8,332. Roughly a 70% cut, and not a single byte of history was deleted. It was relocated.

Here’s the docs/ tree it produced:

docs/
├── decisions/
│ ├── D01.md
│ ├── D02.md
│ ├── ...
│ └── D18.md
├── sessions/
│ └── sessions-01-18.md
├── questions/
├── parking-lot/
├── futures.md
└── reference-prior-artifacts.md

Eighteen settled decisions filed one-per-file. Sessions 1 through 18 collapsed into a single archive. Resolved questions, speculative futures, and the pile of “prior planning artifacts” reference material all moved out.

What’s left in PLAN.md is the hot layer only: the live decisions D19 through D24 with their full bodies, the open questions, and the active parking lot. Everything that’s settled is exactly one link away.

If the doc is the deliverable (which was the whole thesis of post 1), then this isn’t busywork. This is just refactoring the deliverable. You don’t delete the git history when you clean up a codebase. You file it.

It’s a Process

Now, I could have stopped there. One afternoon and done. But I didn’t want to redo by hand every month because the thing keeps growing. The plan is a living document. It got fat once; it’ll get fat again. A one-off fix for a recurring problem is just a chore you’ve scheduled for future-you.

So I built it as a repeatable, checked-off process with two triggers.

The first trigger is a phrase. I say “rebalance” (the skill’s word, not mine) and it runs. Simple.

The second is a size nudge. When the skill gets invoked, it checks the word count, and if PLAN.md is over a threshold (default 15,000 words ) it surfaces it: “PLAN.md is 27.6k words, ~12k over threshold, want to rebalance?” The key detail here, and the one I had to learn the hard way, is that the threshold is measured by wc -w PLAN.md, not by live context percentage. The agent cannot reliably read its own context usage.

And then there’s a ledger. Every run writes to docs/rebalance-log.md (the file’s named for the old word too), recording each hot/cold call and the reason behind it. Here’s the actual entry from that first run:

### 2026-06-19 — rebalance (PLAN.md 28357 → 8332 words)
First run; link graph not yet built, so all calls were manual read-through.
- sessions 1–18 | archived → docs/sessions/sessions-01-18.md | recency, kept last 3 (19–21)
- D1–D18 (bodies) | cooled → docs/decisions/D01–D18.md | settled/built; nothing active references them
- D19–D22 | kept | recent, conservative call (keep-recent over cooling all of D1–D22)
- D23 | kept | 🔒 foundational (novel pipeline / D23 step-3 depends on it)
- D24 | kept | active (linking work, sessions 18–21)
- Q6, Q7 | archived → docs/questions/ | resolved (Q7→D20, Q6 closed)
- Q8 | kept | open (D24 is its first capability)

Why bother logging the reasons? Because the plan is that once a reason recurs often enough, it gets promoted to an automatic rule. The first few runs are pure per-run judgment. But “sessions older than the last three always archive” is a pattern that shows up every single time, so eventually that stops being a judgment call and becomes a rule the skill just applies. It’s the skill-hardener pattern, except pointed at my own process: per-run judgment now, automation later, and the ledger is what bridges the two.

Why It Became a Skill: The Other Project Running This

The thing that pushed this from “a tidy script for one project” to “a reusable skill” was realizing I had the exact same disease on another repo. And that it was a slightly different flavor of it.

My other live project is a knowledge-graph site I mentioned in the update section of post 1. It had a living PLAN.md too, around 14,700 words, but it had drifted off the rails of the workflow itself: a plan, yes, but no implementer agent and no docs/ tree to cool anything into. content-tools just needed a diet. This project needed the diet and a couple of missing organs put back first.

So the deliverable couldn’t be a one-off manual reorg of one repo. It had to be a reusable convention I could point at any project, including one that wasn’t even fully set up yet. That’s the plan-rebalance skill. It lives in my skillshare directory and syncs out to all my tools, so it’s available wherever I’m working. I ran it across both projects the same day, June 19th. On content-tools it did a straight rebalance. On the other project it did an adopt-plus-rebalance in one pass: created the implementer agent, scaffolded the docs/ tree, reconciled the conductor file, then trimmed the plan from 14,700 down to about 11,000 words.

But here’s the catch that made portability non-optional: my two projects don’t even agree on what their own files are called.

	content-tools-v2	nsf-scifi-wiki
Task file	`TASK.md`	`TASKS.md` (plural)
Conductor file	`CLAUDE.md`	`AGENTS.md`
Wrinkle	none	`CLAUDE.md` is a symlink to `AGENTS.md`

If the skill had assumed TASK.md and CLAUDE.md, it would have written through the symlink instead of the real file and missed the task handoff entirely. So the skill discovers names, it never assumes them. It globs for the planning doc, tolerates singular-or-plural task files, and resolves the conductor symlink with readlink so it edits AGENTS.md directly instead of writing through the link. It even records what it found in that project’s own rebalance log, so the next run doesn’t have to re-derive any of it:

## Config
- Planning doc: PLAN.md
- Task handoff: TASKS.md (plural — project convention)
- Conductor: AGENTS.md (CLAUDE.md is a symlink → AGENTS.md; edit the real target)
- Implementer: implementer (.claude/agents/implementer.md, model: sonnet)
- Word threshold: 15000

The Skill Is a Router, Not a Script

The other design constraint came straight out of post 1’s philosophy: the planning agent has to stay light. Its job is to plan and orchestrate, nothing else. If I stuff a thousand words of compaction logic into PLAN.md or CLAUDE.md, I’ve just re-bloated the exact files I’m trying to keep lean. That’d be self-defeating.

So the skill is a router. The heavy process logic is lazy-loaded from the skill’s own workflows/ and references/ files. The project only ever gets a one-line pointer that says “invoke this skill,” never a copy of the process. The skill’s own description sums up its job: it “owns the planning-doc workflow.” The project doesn’t have to know how compaction works. It just has to know who to call.

When you invoke it, the first thing it does is detect what state the project is in and route accordingly:

State	What it means	Route
Greenfield	no planning doc at all	scaffold the whole workflow: PLAN/TASK/implementer agent/docs tree
Partial / adopt	a plan exists but pieces are missing	backfill only what’s missing, idempotently
Mature	full system, heavy doc	rebalance (the compaction pass)

content-tools was the Mature case. It had the whole post-1 system already and just needed the diet. The other project was the Partial case: a plan, but no implementer agent and no docs tree, so it needed a backfill and a rebalance, which is exactly what it got, in a single run. A project can need more than one of these, and the skill reports what it found and lets me pick the actions; it doesn’t silently chain them.

And every mutating action is propose-then-confirm. It shows me a manifest of what’s moving where before it touches anything. It never clobbers an existing file. I diffed the moved decision files against HEAD to confirm nothing got “helpfully” reworded on the way out. When a tool is rearranging the document that is my deliverable, I want a receipt.

The Honest Scope Note

Every post in this series gets one of these, so here’s this one’s: none of this matters until the living plan has already won.

This is a good-problem-to-have tax. You only hit the 28,000-word wall because the plan worked well enough that you kept feeding it for weeks. If you build the compactor before you have a plan worth compacting, congratulations, you’ve just reinvented spec-kit ceremony in a different hat, which is the exact thing the entire first post was an argument against. Don’t do that. Get the plan working first. Let it get fat. Then put it on a diet.

There’s no clever algorithm here. It’s “move the old stuff to a folder and leave a link.” But the alternative is the plan slowly turning into the document you dread opening, and the day you start avoiding your own source of truth is the day the whole method quietly dies. The boring maintenance layer is what keeps the interesting part alive.

What’s Next

So the plan stays lean now. The hot layer is hot, the cold layer is filed, and the compactor keeps it that way on a trigger instead of on my willpower.

Except (and this is where post 3 picks up) keeping the plan exposed a completely different bottleneck on the build side. My setup hands one task at a time to a background Sonnet agent and and then I try to plan in the gap. But the gap was not big enough. When your plan is finally clean enough to generate work faster than your builder consumes it, the new question becomes: how do you keep the builder always busy?

That’s the next experiment: the batch throughput problem, and this same skill growing to own that part of the workflow too. (And, if I’m lucky, finally getting a name I can actually remember and makes sense.)

Model Buzz Roundup — Week of June 24, 2026

Stephan Miller — Tue, 30 Jun 2026 13:00:00 +0000

Last week I called the West’s next two flagship models vaporware. This week one of them shipped, straight into government lockup with the others.

Last week the story was a single model getting unplugged: Claude Fable 5, the number one model on every leaderboard, switched off June 12 by a US export-control directive. I figured that was a one-off horror story, and that GPT-5.6 and Gemini 3.5 Pro, the two heirs everyone was waiting on, would show up and give us something we could actually use.

Reader, they did not. This week GPT-5.6 launched and it’s about as usable as Fable 5, for the exact same reason: Washington. Gemini 3.5 Pro slipped to July. And the one model that quietly went from “interesting” to “essential”? It’s the open-weights Chinese one the whole export-control apparatus is supposedly designed to stop. Except it can’t, because the weights are already a download and it just beat Claude on the cybersecurity benchmarks the bans were about. You know how that goes.

The Gate Spread to the Whole Frontier
Export Controls Failed Their First Real Test This Week
The Model Nobody Can Switch Off (Still GLM-5.2)
Cheapskate Picks: Best You Can Actually Run
Horror Stories from the Wild
Where This Leaves You

The Gate Spread to the Whole Frontier

Here’s the thing that turned this from “a weird week for Anthropic” into “a structural shift”: the export-control net is no longer catching one model. It’s catching every flagship a US lab can ship.

Count them. Start with Anthropic’s Fable 5 , still dark, going on three weeks now. On June 26, Commerce Secretary Howard Lutnick sent a follow-up letter that partially lifts the block on Mythos 5 (the heavier sibling), but only for a defined list of US entities, their foreign-national employees, Anthropic’s own foreign staff, and government partners. Fable 5, the model normal humans and API developers actually call, stays banned. The partial thaw is for the spy-cleared crowd, not for you.

Then there’s the new one, OpenAI’s GPT-5.6. It got previewed June 26 as a three-model lineup: Sol (the flagship), Terra (balanced), and Luna (fast and cheap). New “max” reasoning effort, a new “ultra” mode that spins up subagents, state-of-the-art on Terminal-Bench 2.1, big gains on biology evals. Sounds great. You can’t use it. OpenAI limited the launch to roughly 20 government-vetted partners at the request of the US government. This was the first public run of the AI-review process set up under the recent frontier-AI executive order, where a lab hands a “covered” model to the feds for up to 30 days before it can go to trusted partners. OpenAI itself warned that this kind of gating “should not become the long-term default” because it delays everyone downstream. General availability is “in the coming weeks.” Translation: maybe July.

And Google’s Gemini 3.5 Pro? Still not out. Announced at I/O on May 19 with a “give us until next month,” and next month is basically over. As of June 29 reporting it’s stuck in limited Vertex preview and the public launch officially slid to July. Two-million-token context, Deep Think reasoning, all very nice, all behind an enterprise gate.

So tally it up: of the three newest, best models from the three biggest US labs, one is suspended, one is government-rationed to 20 partners, and one is a preview that keeps sliding. Every leaderboard “winner” this week comes with the same asterisk it had last week, of the ones you can actually call, except now the asterisk applies to the challengers too.

Export Controls Failed Their First Real Test This Week

Now for the part that’s genuinely funny, in the bleak way.

The whole justification for switching off Fable and Mythos was cyber capability, the fear that a jailbreak could turn them into offensive cybersecurity tools. Fine. Defensible premise. Here’s the problem: the day after Anthropic pulled its models, Z.ai shipped GLM-5.2 with open MIT-licensed weights, and this week a security firm sat down and measured it.

Semgrep’s writeup is titled, and I am not making this up, “We have Mythos at Home: GLM 5.2 beats Claude in our Cyber Benchmarks.” TechTimes ran with “AI Export Controls Fail Their First Real Test.” The exact class of capability the directive was meant to contain is now sitting on Hugging Face under an MIT license, FP8 and GGUF quants included, free to download and self-host on hardware nobody can subpoena.

You cannot export-control a torrent. The directive successfully inconvenienced every paying, legitimate user of two American models, while the capability it was worried about walked out the front door in an open-weights release from a lab outside US jurisdiction. That’s not a security win. That’s security theater with a body count of exactly zero bad actors and a whole lot of annoyed developers.

I’m not saying the underlying worry is fake. Frontier cyber capability is a real thing to think hard about. I’m saying that “ban the American version” does precisely nothing when an equivalent open-weights model ships from Shenzhen a day later, and pretending otherwise is how you get policy that hurts the people following the rules and helps no one else.

The Model Nobody Can Switch Off (Still GLM-5.2)

Same hero as last week, and the case for it got stronger.

GLM-5.2 from Z.ai is the highest-ranked open-weights model on Artificial Analysis’s Intelligence Index. It sits at number six overall (score 51) and parks on the value frontier. VentureBeat clocked it beating GPT-5.5 on SWE-bench Pro (62.1% vs 58.6%) at roughly one-sixth the cost. MIT weights, a usable 1M-token context, and output pricing in the low single digits per million tokens depending on which provider you route through. The weights dropped for real the week of June 22, so the “trust but verify” caveat I put on it last week is now “verify it yourself, it’s right there.”

And it’s not a fluke, it’s the whole shape of the market. On OpenRouter, DeepSeek is the single largest model author by volume at around 17.6% of all platform tokens, and Chinese-origin models are somewhere in the 46%+ range of everything flowing through the platform. Tencent’s Hy3 is still the tool-call king. DeepSeek V4 Flash ($0.28 per million out) is the cheap daily driver an enormous chunk of production traffic quietly runs on. The usage has been voting open-and-cheap for months; this week the news finally made the argument out loud.

Connect last week to this week and the throughline isn’t price, it’s control. Hosted frontier models can be revoked by directive, rationed to 20 partners, or stuck in preview indefinitely. The model in your downloads folder can’t be any of those things. The cheapskate argument and the geopolitics argument keep landing on the same advice: own your weights.

Cheapskate Picks: Best You Can Actually Run

Same method as always. Take the Arena leader in each category, draw a 50-rating-point band below it, find the cheapest model in that band. Arena’s top is so compressed that paying 5–16x more usually buys you a sub-3% rating bump. The wrinkle, still: the leader in five of six categories is Fable 5, which is suspended, so each row also names the cheapest thing you can actually call, anchored to that unusable leader’s rating. Output dollars per million, because output dominates real workloads. Arena snapshot is June 25.

Category	Leader (status)	$ out	Cheapskate pick	$ out	Δ rating	Cheaper by	AA value frontier
Overall	Fable 5 (SUSPENDED)	$50	GLM-5.1	~$3	n/a	~16x	yes (GLM-5.2 #6)
Coding	Fable 5 (SUSPENDED)	$50	GLM-5.1 / GLM-5.2	~$3–4	−39	~13–16x	yes
Math	Opus 4.6-thinking (Fable tie SUSPENDED)	$25	Gemini 3.5 Flash	$9	−0 (tie)	~3x	yes
Creative Writing	Fable 5 (SUSPENDED)	$50	Gemini 3.5 Flash	$9	−34	~6x	nearby
Instruction Following	Fable 5 (SUSPENDED)	$50	Gemini 3.1 Pro	$12	−37	~4x	nearby
Hard Prompts	Fable 5 (SUSPENDED) / Opus 4.6-thinking	$25	Gemini 3.1 Pro	$12	−25	~2x	nearby

What the table is actually saying:

Coding is still the slam dunk. GLM-5.1 (Arena 1525) and GLM-5.2 both sit in the band at a few bucks output, both beat or match Claude Sonnet 4.6 (1527, $15) on price, and GLM-5.2 throws in the 1M context, the open weights, and that SWE-bench Pro number. Cheapskate methodology and AA’s value frontier agree. Highest-confidence pick of the week, again.

Math got better for the cheapskate. This is the fun one. With Fable 5 gone, Gemini 3.5 Flash now literally ties for number one on the Math board at 1517, dead level with Opus 4.6-thinking and the suspended Fable 5. So the cheap model isn’t “the best you can settle for” in math anymore, it’s co-champion, at $9 against Opus’s $25. Want the absolute floor? Qwen3.7 Max (1492, $3.75) is cheaper still and only 25 points back.

Creative writing stays a Gemini 3.5 Flash story at $9. In band, no regrets if words are the product. GLM is cheaper but stylistically thin for prose, so I’m not going to pretend it’s the move here.

Instruction Following has no genuine steal. Nothing under $10 lives in that band. Gemini 3.1 Pro at $12 is the honest value floor and I’m flagging it as “you’re paying for quality” rather than inventing a bargain that isn’t there.

Hard Prompts is the category where the usable leader is right there. Only Fable and Mythos got suspended, not the Opus line. Opus 4.6-thinking (1532, $25) leads among models you can actually call, and Gemini 3.1 Pro (1507, $12) gets you within range for half the money.

Boring-but-correct summary, unchanged from last week because the market didn’t move: if you’re not doing something that truly needs the frontier, GLM-5.1/5.2 and Gemini 3.5 Flash cover most of your week for single digits per million tokens, and at least one of them runs on your own iron.

Horror Stories from the Wild

First, the launch you’re not invited to. GPT-5.6 “shipped” June 26, and for ~99.99% of developers that meant reading a blog post about a model they can’t touch. No API, no app, no AI Studio. Twenty vetted partners and a “coming weeks” promise. OpenAI publicly admitted the gating delays “users, developers, enterprises, cyber defenders, and global partners.” A launch you can’t use isn’t a launch, it’s a press release with benchmarks attached, and you can’t verify the benchmarks either. (VentureBeat, The Hacker News)

Then there’s the flagship that’s still missing. Three weeks on, if you shipped anything on Fable 5 during its brief public window in early June, you’re still holding a dead dependency, and the June 26 partial reprieve doesn’t include you unless you’re an Annex A entity with a security clearance. The lesson from last week didn’t expire. It compounded. “Hosted by a responsible lab” is not “under my control,” and the failure mode is sometimes a federal agency that doesn’t care about your sprint. (Anthropic’s statement, Forbes)

Where This Leaves You

I came into June expecting to spend these posts arguing about benchmark deltas. Instead I’ve spent three of them watching the US government become the most important variable in which model you can run. That’s the genre now. The frontier is real and moving fast, and it is also increasingly a thing that can be switched off, rationed, or delayed by people who have never seen your codebase.

No inspiration porn, just the unglamorous read: if your work genuinely needs the absolute top of the stack, pay for it. But architect like it can vanish, because for three labs in a row this month it either did or never arrived. For everything else, which is most things, the open-weights stuff isn’t settling anymore. GLM-5.2 is the sixth-smartest model on Earth, it beat the banned American model on the cyber benchmarks that got it banned, and you can download it for free right now. Sit with that one.

The champ’s still in jail, his heirs are either in the same jail or running late, and the model in your downloads folder is doing your coding for a few dollars a million tokens and asking no one’s permission. Pick accordingly. And configure a fallback this time. I keep being the guy who learns that the hard way so you don’t have to.

The Obsidian Plugin Collection I Built One Free Kiro Credit at a Time

Stephan Miller — Wed, 24 Jun 2026 12:00:00 +0000

Here’s the problem with Claude Code on the Pro plan: it’s enough to get you started and never enough to get you finished. You sit down on a Saturday with a real idea, you get the agent into a groove, the code is actually taking shape, and then the session cap stops you.

So, once a month, I’d take one idea for an Obsidian and I’d buid it. Not on Claude. On Kiro, AWS’s agentic IDE, whose free tier resets on a monthly cycle. One idea, one credit, one plugin. Tweak the spec over a week or two of note-taking, then hand the whole thing to Kiro and let it grind through its task list.

I’ve written about Kiro before, back when it built me my first two plugins in a weekend. This is where the weekend turned into a habit that turned into a handful of plugins. Some of these are real and polished. Some are working but rough. And not all of them were even built completely with Kiro, but for the most part I have been turning a month of free Kiro credits into one Obsidian plugin.

The Free Tier Economy of AI Coding Tools
The Monthly Grind
The Plugin List
- Apple Books Annotation Import: the one that I started with
- Joplin Portal: the one Kiro broke, then fixed
- Obsidian Cleaner: the one that suffered scope creep
- Daily Prompts: the one that’s almost there
- Notebook OCR: the one that worked well and I stopped using
- YouTube Auto Video Summarizer: the one I forked
- Tag Explorer 3D: the one that doesn’t have a git repo yet
What the Process Actually Looks Like (a Kiro Horror Story)
The Real ROI

The Free Tier Economy of AI Coding Tools

I’m not paying $200 a month for a Max plan to ship a hobby plugin that twelve people will install. So I take advantage of free-tiers. Claude Code on Pro for the daytime stuff. Google’s AI Studio when you want a huge context window and want a quick opinion on an idea along with a rough plan before you start building something. Jules for fixing bugs in something that already exists. And Kiro for the building extensions, plugins, and the like.

The free tier is the hook: $0 a month, 50 credits, and, at the time I’m writing this, access to Claude Sonnet 4.5 inside it. The credits reset at the start of each billing month and you can use them up in one session.

Kiro’s whole pitch is spec-driven development. Instead of vibe-coding, it makes you write (or makes the agent write) a requirements doc, a design doc, and a tasks doc that breaks the build into a numbered checklist. Then it works the checklist. That structure is the entire reason I use it for Obsidian plugins specifically, and not for, say, a large web app.

Here’s why Obsidian plugins are the perfect shape for a free-tier:

Small surface area. It’s a TypeScript project with a manifest.json, a main.ts, and a documented API. There’s no backend, no auth, and Github Actions builds it for me.
Clear standards. Obsidian’s sample plugin repo and developer docs define exactly what “correct” looks like. An agent that follows documentation does well here.
You can ship before you’re done. BRAT lets anyone install a plugin straight from a GitHub repo, no community-store review required. So “done enough” is a real, useful state.

The Monthly Grind

I keep a running list of plugin ideas as plain notes. Over a week or two, the note stops being “wouldn’t it be cool if” and starts being an actual spec: what it does, what the settings are, where the edge cases live.

Then, when the note is ripe and the monthly credit is sitting there unspent, I open Kiro, point it at the notes, and tell it to build. Kiro turns that into its own internal task list. For Obsidian Cleaner, Kiro generated a tasks.md with 91 tasks. For the Notebook OCR plugin, it ended up spanning five separate specs with close to 280 tasks between them. The Daily Prompts build was 45. Even “small” Joplin Portal was 43 tasks in the main spec, before I made it add a 16-task spec later just to bring it up to Obsidian’s plugin guidelines.

I don’t read all 91 tasks. I read the design doc, I sanity-check the first few tasks, and then I let it run. When it finishes, I install the build into my test vault, poke at it, and sort it into one of three buckets: done messing with it, needs another pass, or back on the shelf. Most months land in the middle bucket. Some months produce a genuine mess I have to come back and fight with. It’s nice when the result works enough that I start using it all the time.

The Plugin List

This is everything that actually exists. If it’s installed in my test vault, I built it. Here’s the status of each one, including which ones Kiro built and which ones came from somewhere else.

Apple Books Annotation Import: the one that I started with

Repo: github.com/eristoddle/apple-books-annotation-import · Version: 1.0.22 · Status: working, most polished of the lot

Kiro had nothing to do with this one actually. It started life as a Python script that pulled annotations out of Apple Books’ SQLite databases, and I used Claude desktop to convert it into a plugin and Jules to fix the final bugs. It started the Obsidian plugin in an afternoon ritual.

It’s also the one that’s had the most love since. It pulls highlights and notes out of the macOS Books databases and turns them into formatted markdown: book metadata, ISBN, reading progress, highlight colors as emoji (🟡🟢🔵🟣🔴), chapter detection from EPUB CFI locations, the works. There’s an interactive picker so you choose exactly which books to import, with cover thumbnails and annotation counts. Turns out Apple’s annotation data is a labyrinth spread across separate SQLite files that aren’t meant to be touched. It’s macOS-only. I use it all the time.

Joplin Portal: the one Kiro broke, then fixed

Repo: github.com/eristoddle/joplin-portal · Version: 1.0.18 · Status: working, has a real test suite

Joplin Portal gives you a sidebar panel in Obsidian that searches, previews, and selectively imports notes from a running Joplin server through Joplin’s Data API. It’s not a hack or a file-format conversion. It talks to Joplin’s actual REST endpoint with a token, debounces the search, caches results, and lets you cherry-pick what comes across.

This is the plugin where I learned exactly where Kiro’s limits are, and it’s the best story in the bunch, so it gets its own section further down. Short version: Kiro built the working thing in 43 tasks, then I asked it to fix one cosmetic bug and it broke a lot of things in the process.

Obsidian Cleaner: the one that suffered scope creep

Repo: github.com/eristoddle/obsidian-cleaner · Version: 1.2.0 · Status: active, recently renamed

This one started as “Attachment Cleaner,” a single-purpose tool to find attachments nothing links to. Then I kept noticing other crap in my vault. Dropbox conflicted copies. Numbered duplicates from Web Clipper (Note 1.md, Note 2.md). Zero-byte markdown files. Empty folders. Tags that were one typo apart from each other. So I gave Kiro the bigger spec, watched it generate a 91-task checklist, and let it turn a one-trick tool into a seven-type vault-hygiene suite. Then I renamed the whole thing to Obsidian Cleaner because “Attachment Cleaner” no longer fit.

It walks you through a step-by-step modal: orphaned attachments, conflicted files, duplicates, empty markdown, empty folders, near-duplicate tags (edit distance ≤ 2), and a frontmatter-rule cleanup. Every single item gets its own accept/reject toggle before anything gets deleted. You pick the deletion mode too: system trash, Obsidian’s .trash, or permanent if you’re feeling brave. Started as a scalpel, ended as a Swiss Army knife. Scope creep, but the useful kind.

Daily Prompts: the one that’s almost there

Repo: github.com/eristoddle/obsidian-daily-note-prompts · Version: 1.0.1 · Status: mostly working, notifications still flaky

Daily writing prompts delivered into your daily note, three ways: sequential (for structured courses), random (no repeats until the pack’s exhausted), or date-based (for seasonal stuff). Prompts live in JSON packs you can import and export, so you can share a pack or back one up. It’ll create or open the daily note when a prompt fires, optionally drop you into a distraction-free mode, and ping you with either a system notification or an Obsidian notice.

That notification system is exactly where it’s still rough. Timezone-aware scheduling and “catch up on missed prompts” are great on paper, and the persistence is the part that needs another Kiro credit. It’s 45 tasks of mostly-done. One of these months it’ll get the pass that finishes it.

Notebook OCR: the one that worked well and I stopped using

Repo: github.com/eristoddle/obsidian-ocr-note-import · Version: 1.0.16 · Status: working

I carry a 3.5×5.5 field notebook everywhere, and for years the digital bridge was me typing my own handwriting back into Obsidian like an animal. This plugin kills that. You photograph the pages, it runs OCR (local Tesseract.js offline, or OpenAI Vision / Google Cloud Vision when you want it to actually read cursive), and then it routes the extracted text into your vault using regex pattern rules with capture groups. It even preprocesses multi-page notebook scans, splitting and rotating them before OCR, with presets for common pocket-notebook layouts.

This is the most over-engineered thing on the list (five Kiro specs, nearly 280 tasks total), and it already got its own full writeup.

YouTube Auto Video Summarizer: the one I forked

Repo: github.com/eristoddle/obsidian-auto-video-summarizer · Version: 1.2.3 · Status: forked and customized

Sometimes the best plugin is someone else’s that you make your own. This is a fork of mbramani’s video summarizer, which already pulls YouTube transcripts and summarizes them with an LLM: Gemini, OpenAI, or Anthropic, your key, your choice of model. What I added to my copy is the automatic part: it’ll summarize any YouTube URL you paste into the editor, or any new web clip whose source frontmatter is a YouTube link. Just a fork and a quick modification. Took about 15 minutes.

Tag Explorer 3D: the one that doesn’t have a git repo yet

Repo: none (never pushed) · Version: 1.0.0 · Status: built, never shipped

This lives in my test vault, rendering my hierarchical tags (#obsidian/plugin/idea) as an interactive 3D network graph with three.js and 3d-force-graph: orbit, zoom, hover-to-preview note contents, hierarchical and force-directed and radial layouts.

I could never decide whether a 3D tag graph is genuinely useful or just a very pretty answer to a question nobody asked. Sometimes you build things because they’re interesting, not because anyone needs them, and then you can’t quite bring yourself to delete them either.

What the Process Actually Looks Like (a Kiro Horror Story)

Let me show you a real month, with the mess included.

Joplin Portal worked. Kiro built the search, the preview, the import, all 43 tasks of it, and it was good. Then I noticed the panel’s icon wasn’t rendering right, which is a cosmetic nothing of a bug. So I asked Kiro to fix the icon.

This is where it went sideways. Instead of reading Obsidian’s icon documentation and using the one correct API call, Kiro started flailing. It wrote a registerJoplinIcon() function. The icon still didn’t render, so on the next pass it added a second function, registerJoplinIconEarly(), and called both. It started rendering image tags that looked like <img width="20" height="20" src="joplin-id:2f95b263..."/>, a made-up URL scheme that was never, ever going to resolve. It was guessing, and each guess piled another layer of garbage on top of the last one. The “fixing” produced a codebase that was worse than when it started.

So I did the thing you eventually learn to do with these tools: I stopped letting it improvise and put it on a leash. I went and did my own research, figured out the actual fix, and then wrote it a prompt that was less “please help” and more “here is your one job, do not deviate.”

This plugin needs to follow best practices. You have made it a mess trying to fix an issue with the icon rendering. See how many times you call this.registerJoplinIcon() and then the duplicate function this.registerJoplinIconEarly(). This is unnecessary, and whenever you catch yourself doing this, you should know you have taken a wrong turn. That was the only problem. Everything else worked and you have made a mess.

You MUST, MUST, MUST follow the documentation to do this right: https://docs.obsidian.md/Plugins/User+interface/Icons. Do not ever guess. Do not think you know unless you do. Do not make things up. You must also use this repo as reference for best practices: https://github.com/obsidianmd/obsidian-sample-plugin. And you must remember you are only fixing the mess with rendering the icon and bringing it back to standards. Nothing else.

Its confidence is uncorrelated with its correctness, and when it doesn’t know something it will invent something that looks plausible and ship it. The duplicate function with the Early suffix is the tell: when an agent starts bolting “early” and “v2” and “final” onto its own helpers, it’s not solving the problem, it’s papering over the fact that it doesn’t understand it. Your job isn’t to write the code. Your job is to notice the tell, hand it the authoritative documentation, and fence the task down to exactly one thing so it can’t wander.

After that prompt, it fixed the icon. Then I had it add a 16-task spec to bring the whole plugin in line with Obsidian’s official guidelines, and that’s why Joplin Portal is the one on this list with an actual Vitest test suite.

The Real ROI

So what does “one free Kiro credit a month” actually get you? Let’s add it all up.

It got me eight things that run: two genuinely polished, three that are working-but-rough, one fork, and one that’s never been pushed.

There’s friction too. You hit session caps. You switch tools and lose context between them. The agent sets your icon-rendering code on fire and you spend a Saturday afternoon being its very firm manager. Some months produce a finished tool and some months produce a mess.

The constraint makes you good at scoping. When your AI tool can only finish work that fits inside one month’s free allotment, you’re forced to break ideas down until they’re small enough to actually ship. And a plugin idea you’ve sharpened to that point is one you understand. The vault notes that become the Kiro specs are a documentation trail I’d never have written otherwise. The real product of this whole ritual is the discipline of cutting work down to a finishable size, which is the one skill that survives no matter which AI tool you’re using this month.