Stephan Miller

The Expensive Model Only Plans Now: I Split My AI Coding Rig Across Two Tools

Wed, 05 Aug 2026 07:00:00 -0500

A couple of posts back I pulled a month of my own session logs to catch coding red-handed as the token hog, and the meter came back flat. Planning and building cost about the same to run. The expensive part is the thinking that has to happen before the typing, and that thinking is mine.

If the typing is the cheap, fast, mechanical part, why am I paying frontier-model prices for it? Why is Opus, the model I keep around because it can think, the one grinding out a config file from a spec I already wrote?

It shouldn’t be. I should keep the expensive model for the one thing it should, and hand all the work after that to the cheapest models that can write code. Which, it turns out, means splitting the work across two different tools. Claude Code plans, Opencode builds.

This is part four of a series about working with AI coding agents on an open-ended project through 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 few were about keeping that doc lean and figuring out where the real cost lives. This one is about what happens when you stop paying the planner to type.

The Setup: One Expensive Model Doing Two Jobs
Enter opencode (and a Roster of Cheap Models)
The Rule I’d Just Landed On, and Why I Inverted It
Reviewers That Don’t Share the Builder’s Blind Spots
The Tell: The Diagrams Came Before the Code
Three Docs, Three Sets of Write Permissions
The Whole Truth
What’s Next

The Setup: One Expensive Model Doing Two Jobs

For most of this series my setup has been one tool wearing two hats. I plan in Claude Code with Opus. Plain chat, back and forth, drilling down until the design is actually pinned. Then the same Claude Code hands the build work to Sonnet sub-agents. Opus knows, Sonnet does. On the Pro plan I could talk to Opus for a long planning session and barely dent my usage, because in build mode the token-heavy churn (the greps, the file reads, the edits) happens in a sub-agent’s own context and comes back as a short summary. The orchestrator stays lean.

That’s a fine setup. But it has Opus, or at least a Claude model, standing over every build task, and I’d just proven to myself that the build tasks are the mechanical part. I was using an expensive model to assemble flat-pack furniture. The instructions were already written. Any model that can read can do the work.

Here’s the framing that made me actually move, and it’s stolen from a thing I said to myself during a debugging session months ago: models are the Temu of things. They’ll have knowledge of many things, but the most generalized version of it. A one-line prompt gets you the average of everything ever written on the subject. And if the build task is fully specified, if I did the custom thinking already and wrote it down, then Temu is exactly what I want. Generalized competence at assembling a known thing is cheap and abundant. I just had to stop buying it at boutique prices.

Enter opencode (and a Roster of Cheap Models)

The tool that let me do this cleanly is Opencode, a terminal coding agent that, crucially, lets you assign a different model to every agent through a repo-local opencode.json, routed through OpenRouter. So the plan stays in Claude Code with Opus, and the entire build crew lives in opencode, each role on whatever model is cheapest for its job.

Here’s the roster, trimmed from the real config:

{
  "$schema": "https://opencode.ai/config.json",
  "small_model": "openrouter/z-ai/glm-4.7-flash",
  "default_agent": "orchestrate",
  "agent": {
    "orchestrate":        { "model": "openrouter/z-ai/glm-5.2" },
    "build":       { "mode": "subagent", "model": "openrouter/xiaomi/mimo-v2.5-pro" },
    "ai-pipeline": { "mode": "subagent", "model": "openrouter/deepseek/deepseek-v4-pro" },
    "qa-fast":     { "mode": "subagent", "model": "openrouter/deepseek/deepseek-v4-flash" },
    "qa-deep":     { "mode": "subagent", "model": "openrouter/google/gemini-3.1-pro-preview" },
    "debug":       { "mode": "subagent", "model": "openrouter/anthropic/claude-sonnet-5" },
    "docs":        { "mode": "subagent", "model": "openrouter/qwen/qwen3.7-plus" },
    "research":    { "mode": "subagent", "model": "openrouter/deepseek/deepseek-v4-flash" },
    "architect":   { "model": "openrouter/anthropic/claude-opus-5" }
  }
}

Not a Claude model in the build path. GLM-5.2 orchestrates. A Xiaomi MiMo model writes the Go daemon and the CLI. DeepSeek handles the ML and retrieval code. Qwen writes the docs. The only Anthropic models in the whole file are debug (Sonnet, for when something’s genuinely stuck) and architect. And to tell you the truth, most of the model choices are just a test of what will work in that slot or even if I need all these different agents.

I’ve been coy about what this crew is building, so: it’s the Context Lake, the one-brain-outside-the-agents thing I wrote about a month back. A Go daemon that watches my session logs and my vault, a Python ML layer that indexes and retrieves, a CLI and a dashboard sitting on top. That matters here for exactly one reason: it is not a toy. It’s a real multi-language system with a knowledge graph, a vector store, and a daemon.

MiMo wasn’t even my first pick for the build. I started with GLM-5.2 doing double duty, orchestrating and building, and swapped the builder over to MiMo on day three (the commit message, optimistically, reads “for improved performance”). It’s cheaper on the output tokens a builder spends most of, though I’ll warn you the exact gap is a moving target: model pricing on OpenRouter whiplashes week to week, and as I write this GLM’s page is showing 76% off. The reason I kept MiMo, though, wasn’t the couple of cents. It was that GLM tends to lose the thread across a long series of tasks, and MiMo just… doesn’t. Stack it deep and it grinds through the whole queue. For a builder whose entire job is to chew an unattended stack while I’m somewhere else, that turned out to matter more than the price.

The division of labor is the same knower/doer split I’ve run all along, just stretched across a tool boundary:

Claude Code + Opus is the planner. It’s where I think, discuss, and write the tasks. It never runs in opencode. The picks were made against live OpenRouter pricing using my weekly model-buzz research as the value spine, so this isn’t “cheap for the sake of cheap.” It’s cheap where cheap is fine, and one expensive model where thinking has to happen.
Opencode is the whole build crew. It reads the tasks I wrote, does the keystrokes, runs the checks, reports back.

And architect, the lone Opus-4.8 agent in opencode? It’s set to manual-only and never auto-invoked. It’s my break-glass “call in a senior for a from-orbit sanity check” button for when a Claude Code session isn’t handy. A zero-invocation count on it is expected. I wrote a note in the repo telling future-me not to delete it as dead config, because future-me absolutely would.

The Rule I’d Just Landed On, and Why I Inverted It

Here’s where it got uncomfortable, because I had to break something I’d just decided was right.

In my single-tool setup, the builder works a queue of numbered tasks, and the rule for a task it can’t finish was: skip it and keep going. If piece 3 of 8 turns out underspecified, some fork I didn’t see, don’t halt the whole queue. Mark it blocked, move to piece 4, do everything that doesn’t depend on the broken one. An hour away should come back with six of eight done, not two. I was proud of that rule. It’s the thing that makes walking away safe.

Then I moved the build to opencode and inverted it completely. The rule now: hit something underspecified, stop and report. Do not keep going. Do not invent the next task. Do not promote anything from the parking lot.

Same person, opposite rule, two weeks apart. What changed?

The tool boundary changed. In the single-tool world, the thing that skips a blocked task and continues is the same context that could re-plan it. It’s all one agent, warm on the whole conversation, and “keep going past the blocker” is safe because the planner is right there. In the cross-tool world, the planner is a different tool. Opencode is a cheap executor that knows nothing about my planning thread and has no business deciding what to build next. Discovering work and scheduling work are different authorities, and I’d just handed them to different tools. If I let the cheap builder skip-and-continue, I’m letting the model I specifically chose not to think make the scheduling calls.

So the executor’s rule became rigid on purpose. From the actual contract in the repo:

You may NOT execute items in § Next (underspecified by design — stop at the tier boundary and report), may NOT promote items out of § Parking lot, and may NOT invent new tasks. If § Now is drained, SAY SO AND STOP.

Take the planner out of the room and put it in another tool, and the safe move flips to “stop and wait.” A rule is only as good as the context it assumes, and the second you move the work across a boundary, re-check every assumption.

If cheap models are doing the building, the obvious worry is quality. My answer has two parts, and neither is “trust the cheap model.”

Part one: the reviewers run on a different bloodline than the builder. The build agent is MiMo; the deep reviewer, qa-deep, is Gemini; the debugger is Sonnet. A reviewer that shares the implementer’s model lineage shares its blind spots. It’ll wave through the same class of mistake the builder was prone to make, because it thinks the same way. Point review and implementation at the same model and review quietly stops catching anything. Different lineage, different blind spots.

Part two, and this is the one I got wrong first: the obligation to run the checks lives on the agent that can’t forget it. Originally I had the planner enforce QA: “call the reviewer after every step.” It decayed. And I have the receipts, because this is the kind of thing I’d rather catch myself than have a commenter catch. I audited 58 opencode sessions on this project and found QA delegation went from 5 calls in the first two weeks to 0 in the last two, while the builder kept right on running. The deep reviewer, whose trigger was the soft phrase “at milestones,” had fired exactly zero times. The invariants I care about were never actually being checked.

Why did it decay? Because a planner’s context fills up over a long orchestration and it drops the soft, optional steps, the same way you stop doing the stretches your physical therapist gave you. The fix wasn’t a sterner reminder. It was structural: move the obligation onto the sub-agents, which get fresh context on every spawn. The build and ai-pipeline agents are now not-done until they’ve run the checks and pasted the output into their report, and the planner rejects any completion report that lacks it. An obligation on a long-lived context erodes. An obligation on a fresh-every-spawn context can’t. Don’t ask a model to remember. Make it structural.

The deep reviewer got the same treatment. Instead of “at milestones,” it fires on a deterministic condition. When the current batch of work is drained, before the batch is reported done, it reviews the whole batch diff against a fixed list of the project’s load-bearing rules. A trigger you can’t measure is a trigger that never fires.

I did have to fix the ordering the hard way first, because my initial config looked right and wasn’t. Agents weren’t firing in sequence, QA was skippable, and a couple of agents never ran at all. So I rewrote it to force the line: build writes the code and runs its own tests, and only after the checks pass does the docs agent, which always reads the real code first, write anything. When I later asked Claude whether that fix actually held, the read was blunt: “Ordering is right. The QA-gate fix is genuinely first.”

And then, a couple of weeks later, the whole thing handed me a lesson I didn’t order. At the batch drain the gate was green across the board: 43 Python tests passed, ruff and mypy clean, go build and go test fine. Then I ran the thing against real data. The dashboard crashed on an actual projection file, and the project-identity code reported 6 projects where the vault holds 24, four of the six being phantoms. Its last-resort rule for naming a project was “first tag containing a hyphen,” so it had been happily minting a project per topic tag. Both bugs sailed straight through a green gate. Making the checks structural fixed whether they run. It did not turn them into a proxy for the software being correct, and I had started quietly treating it as one.

The Tell: The Diagrams Came Before the Code

Here’s the small, dumb detail that actually convinced me the split works.

Back at the start, on June 26th, before a line of the Go daemon or the Python ML code existed, I had Claude draw the architecture as a set of mermaid diagrams. Not because the code was complex; there wasn’t any. Because the plan was: “is there any way that we can create a rough mermaid diagram of what’s going on here? Cause it’s getting kind of complex now.” The diagrams were a picture of the intended system, committed a few hours before the first daemon/ and ml/ directories landed that same evening.

Then the roster of cheap models built the thing, over weeks, one specified task at a time.

At some point I had Claude audit the built system, half-expecting the usual rot, docs that lie because nobody updated them. Instead: “OpenCode has kept the architecture honest.” The diagrams hadn’t been quietly patched to match the code. The code had been built to match the diagrams. Weeks of cheap-model keystrokes, and the shape at the end was the shape I’d drawn on day one.

That’s the real proof, and it’s humbler than “the cheap models are geniuses.” They’re not. But a plan they can’t skip, run in an order they can’t reorder, gets followed faithfully enough that the map you sketched before any code existed still describes the territory a month later. That’s the whole bet: the intelligence goes into the plan, and the plan is cheap to enforce.

Three Docs, Three Sets of Write Permissions

The last piece is the guardrail that keeps a cheap, eager builder from wandering off. When two tools share one repo, “who’s allowed to write what” stops being a style preference and becomes the fence that keeps them from fighting. Three docs, three permissions:

| Doc              | What it is                          | Who writes            |
|------------------|-------------------------------------|-----------------------|
| docs/vision.md   | The vision, architecture, invariants| Planner only          |
| TASKS.md         | The current batch of committed work | Executor (checkboxes) |
| docs/archive/    | Completed batches, frozen           | Planner, at replan    |

The executor, opencode, can check off boxes in TASKS.md § Now as work lands, keep the status line current, and append discoveries to a parking lot. That’s it. It cannot edit the vision doc, cannot promote a parked item into the active work, cannot write the next batch. Those are planning authorities, and planning happens in the other tool, driven by me.

This sounds like bureaucracy until you’ve watched a helpful agent decide, unprompted, that it knows what you want to build next. The most load-bearing sentence in the whole config is the one that tells the opencode orchestrator, in so many words, to never tell the human to “exit plan mode” or hand the work back. Its job is to act by delegating to a sub-agent, not to bounce the plan back to me with a “ready when you are.” And the sibling rule, which longtime readers know I’ve promoted to a standing law: planning is a discussion, not a multiple-choice quiz. The moment a tool tries to compress the design conversation into three options, you lose the part that was doing the work.

The Whole Truth

What I’m solid on: the shape is right. Paying a thinker to type is a real waste, the cost data backs it up, and separating “who plans” from “who types” onto tools priced for each job is a clean way to stop doing it. The QA-decay finding is measured, not vibed: 58 sessions, 5 to 0, a reviewer that never fired. And putting the obligation on fresh context instead of a memory is a principle I’ll stand behind anywhere.

What surprised me is how smooth the unattended part has been. I can stack five tasks, walk away, and come back to a screen full of done. Actually unattended, actually finished, and I keep having Opus re-audit the whole thing because I half don’t believe it.

What I was wrong about is the finish line. I wrote most of this post feeling like the project was nearly done. It isn’t. The batch I cut on July 18th sits at 11 of 15 remaining, it got extended three days later after another dogfooding pass, and the scope has since grown a cross-repo orchestration layer and a skills catalog. The cheap crew is fast at the work I hand it. That was never the same thing as the work running out.

What I’m still not solid on: whether the cheap builders stay good enough, at scale, over time. The two bugs above are the first real data point, and they’re ambiguous on purpose. Neither is obviously a “a Claude builder would have caught this” failure, because both were spec gaps that a green test suite couldn’t see either. But they’re exactly the shape of thing I said I was watching for, they showed up inside a month, and one project going smoothly is still a sample size of one. The qa-deep reviewer is on a preview-tier model, which means it can get rate-limited, change behavior, or vanish out from under me on a random Tuesday; I keep a same-obligation, different-lineage fallback noted for exactly that. And the roster itself drifts. Model pricing moves, slugs get deprecated, and the config is the truth while any table I write about it is already going stale. The table in my own docs has lied to me before.

So: promising shape, real receipts on the why, genuinely unproven on the “are cheap models good enough” question that the whole thing rides on. Frontier of the method, not a settled result.

What’s Next

The plan lives in Claude Code with Opus, the build lives in Opencode with a crew of cheap models, the expensive model only thinks, and the whole thing is fenced by who’s allowed to write which file. It runs. Whether it holds is the thing I actually have to live with now instead of theorize about. Can Temu models carry a real build over months without quietly costing me more in bugs than they saved me in tokens?

There’s a bigger post hiding under this one, the thesis version: that planning is the only thing in the whole stack worth a boutique model, and everything downstream is keystrokes you can buy in bulk. I’ve now watched that hold across three projects, which is finally enough proof points to write it honestly instead of as a hot take. That’s the one I want to write eventually.

Qwen3.8-Max Dropped. I'm Still Running the $0.87 Model.

Tue, 04 Aug 2026 08:00:00 -0500

This week Alibaba dropped Qwen3.8-Max, a 2.4-trillion-parameter monster, and the stock jumped 7% in Hong Kong. Everybody lost their minds. And the smartest thing a cheapskate can do with that news is nod politely and keep running a Chinese model from April that costs 57 times less than the thing everyone’s actually cheering for.

Let me explain how I got there.

China Dropped a 2.4-Trillion-Parameter Flagship and I Mostly Yawned
The “Smartest Model in the World” Had an Awkward Debut
The Boring Answer That Keeps Winning
Cheapskate Picks: Where the Actual Money Is
Horror Stories From the Wild
Coming Soon (Or “Soon,” Anyway)
What I Actually Took Away This Week

China Dropped a 2.4-Trillion-Parameter Flagship and I Mostly Yawned

Here’s the thing about Qwen3.8-Max. It’s genuinely impressive on paper. 2.4 trillion total parameters, 95 billion active through a sparse mixture-of-experts setup, a 1-million-token context window, and API access that went worldwide on day one. It landed at #5 on the Arena text leaderboard and #2 on the vision board about a day after launch, which makes it the highest-ranked Chinese text model anyone’s ever put up. Alibaba priced it at roughly 24% to 40% of Claude Opus 5. Open weights are supposedly landing next week.

But look at the votes. It’s sitting at #5 on 3,327 Arena votes. Opus 4.6-thinking above it has 67,000. When a model debuts high on a thin vote count, that’s not a verdict, that’s a first impression with good lighting. Arena rewards new-and-polished before the crowd has actually lived with the thing.

And then there’s the benchmark table. Alibaba says Qwen3.8-Max scores 86.1 on OSWorld-Verified, ahead of GPT-5.6 Sol Max at 83.2 and Fable 5 at 85.0. It claims 86.6 on Terminal-Bench 2.1 and 93.0 on PaperBench. Great numbers. Here’s my problem: that table includes self-reported scores for the competitors too, and as of the day before I wrote this, no independent evaluation of the model existed at all. A vendor grading its own homework and its rivals’ homework in the same table isn’t a lie. It’s just not evidence yet. The correct posture is interested skepticism, and I’ll happily eat my words next week when somebody who doesn’t work at Alibaba runs the thing.

The “Smartest Model in the World” Had an Awkward Debut

Claude Opus 5 shipped July 24, and by this week it finally had enough Arena votes to show up properly. Anthropic and Artificial Analysis both told you it’s the most intelligent model on Earth right now. On AA’s Intelligence Index it scores 61, narrowly the top of the board, effectively tied with Fable 5 at 60 and ahead of GPT-5.6 Sol at 59 and Kimi K3 at 57.

So where does it land on Arena Overall, now that humans have actually voted on it blind?

Number 7. Behind Opus 4.6-thinking at #2 and Opus 4.7-thinking at #3. It got beaten by its own grandparents.

I want to be fair here, because this is the interesting part, not a dunk. Opus 5 is #1 on the hard-benchmark axis and it takes the Arena Math crown outright (on thin preliminary votes, but still). The cost-per-task number is the real headline: $2.03 per Intelligence Index task versus Fable 5’s $2.75, about 26% cheaper, at the same $5/$25 sticker as Opus 4.8. That’s a real bargain if you’re doing hard agentic work.

But if you upgraded to Opus 5 on the strength of the word “smartest” alone, blind human raters are quietly telling you that you bought a lateral move on everyday chat. “Best on the benchmarks” and “the answer people prefer when they don’t know which model they’re looking at” are two different axes, and this week they pointed in two different directions at the same lab.

The Boring Answer That Keeps Winning

Now the part I actually care about. If I strip away the launch confetti, what’s the model that gives me the most quality per dollar right now?

Same answer as last cycle. MiMo v2.5 Pro. Xiaomi’s model from April, MIT-licensed, $0.43/$0.87 per million tokens on Arena’s list price and routing even cheaper on OpenRouter at roughly $0.35/$0.70. Listed, purchasable, no geo-lock, multiple providers. Boring. Available. Cheap as dirt.

What makes this week different is that two completely unrelated methodologies pointed at the same model. Arena’s price sort puts MiMo as the cheapest thing inside the competitive band of four separate categories. And Artificial Analysis, which measures hard-benchmark capability instead of crowd preference, puts MiMo on its Intelligence-vs-Cost Pareto frontier. Its “most attractive quadrant.” When the popularity metric and the capability metric independently name the same cheap model, that’s about as strong a buy signal as this newsletter ever gets.

The honest caveat: MiMo scores 42 on AA’s Intelligence Index while the frontier sits at 57 to 61, and it’s slow at around 47 tokens per second. So it’s the crowd favorite and cost-efficient for what it is. But it’s not frontier-grade on hard reasoning, and it won’t win a latency race. For everyday work and agentic loops where you care about the bill, that’s a trade I’ll take every time. For a gnarly proof or a nasty debugging session, spend the money.

That’s the whole hype-versus-value story this week in one line. Qwen3.8-Max is new, loud, and unproven. MiMo is old, quiet, and double-confirmed.

Cheapskate Picks: Where the Actual Money Is

This is the section I write the newsletter for. The method is simple and I’ll say it once so the table makes sense. For each Arena category, take the leader’s rating, draw a line 50 points below it, and that’s the competitive band. Everything inside that band is, statistically, a rounding error away from the “best” model. Then I sort the band by output price and pick the cheapest thing in it. The trick, and the thing I screwed up in a past issue, is that the band is defined by points, not by rank. It runs way deeper than the visible top 20. The Coding band this week is 53 models deep. The cheap open-weight models live down in the 20s, 30s, and 40s, sitting a couple of points below premium brands while costing an order of magnitude less. Truncate at rank 20 and you delete the entire reason this section exists.

So I pulled the full tables and computed the bands in code. Here’s where the money is:

Category	Leader	$ leader	Cheapskate pick	$ pick	Δ rating	Price ratio	AA Pareto
Overall	claude-fable-5	$50	MiMo v2.5 Pro (#40)	$0.87	−43	~57×	✓
Coding	claude-fable-5	$50	MiMo v2.5 Pro (#29)	$0.87	−35	~57×	✓
Creative Writing	claude-fable-5	$50	Gemini 3 Flash (#23)	$3	−49	~16.7×	nearby
Instruction Following	claude-fable-5	$50	MiMo v2.5 Pro (#25)	$0.87	−46	~57×	✓
Hard Prompts	claude-fable-5	$50	MiMo v2.5 Pro (#27)	$0.87	−40	~57×	✓
Math	claude-opus-5-max*	$25	Gemini 3.6 Flash (#4)	$7.50	−32	~3.3×	nearby

* The Math leader is preliminary, sitting on only 231 votes. Treat that whole board as a rumor this week.

A few things worth saying out loud about that table.

MiMo sweeps four of six categories, all at $0.87 output, all roughly 57 times cheaper than the Fable 5 leader. Its ranks look scary (#40 in Overall) until you check the vote counts. That Overall rating is backed by 45,910 votes. It’s a far more settled number than most of the shiny preliminary top-10 entries with a few hundred votes each. Deep rank measures preference, not reliability. Don’t let it spook you.

Creative Writing is the one place MiMo can’t reach, because that category rewards polish and the cheap crowd falls just below the cutoff. The pick there is Gemini 3 Flash at $3 output, and it’s clinging to the very edge of the band at 49 points back. Still 16 times cheaper than the leader.

Math is a mess this week and I’m flagging it hard. The leader is Opus 5 on 231 votes, the band is only 8 models deep, and the cheapest thing in it is Gemini 3.6 Flash at $7.50. There’s no sub-$7 play here. Math is a “you’re paying for quality” category right now, so if you need it, budget for it and check back when the votes settle.

And the throughline underneath all of it: Fable 5 still sweeps 5 of 6 Arena categories as the outright leader. The ceiling hasn’t moved in weeks. What keeps changing is the floor, and the floor keeps getting cheaper.

Horror Stories From the Wild

Two this week. One is a real fire, the other is a smoke alarm.

The fire: the DeepSeek V4 API migration deadline hit on July 24 at 15:59 UTC, and it hit hard. DeepSeek retired the deepseek-chat and deepseek-reasoner model aliases with no grace period and no fallback. Call the old names now and you get an error, full stop. One developer went digging through production logs and found 14,000 calls still hitting deepseek-chat, every single one returning a 404. The fix is a one-line model-name swap, which sounds trivial until you hit the two gotchas: thinking mode moved from the model name into a request parameter, so a naive swap either silently drops your reasoning entirely or quietly turns the cheapest endpoint into a reasoning-token furnace that torches your bill. If you run anything scheduled or agentic against DeepSeek, go read your logs right now. I’ll wait.

The smoke alarm: I already said it above, but it belongs here too. Qwen3.8-Max launched with a benchmark table that scores its competitors for them and zero independent verification behind any of it. That’s not a crash. It’s a “don’t rewire your whole pipeline around a press release” warning. Wait for someone outside Alibaba to run it.

Coming Soon (Or “Soon,” Anyway)

Qwen3.8-Max open weights. Announced for roughly the week of August 10, right behind the API launch. If they’re real, the independent evals that follow will be the actual story, not the launch table.
Gemini 3.5 Pro. Still vapor. It missed its July 17 target, which is somewhere around the third or fourth slip now, and Google shipped three other Gemini models instead of it while reportedly scrapping and rebuilding the base model over hallucination and reliability problems. At this point I’ll believe it when I can call the API.
Kimi K3 community quants. The weights went public July 26 under a modified MIT license, so quantized community builds are showing up. Just remember the model is 2.8 trillion parameters and needs something like 1.4TB of fast memory even at four-bit. “Open weights” and “you can run it” aren’t the same sentence when you’d need 4 to 8 H100s to load the thing.

What I Actually Took Away This Week

The frontier is stuck and the bargain bin is on fire. That’s the real state of things.

Anthropic still owns the top of every leaderboard that matters, and it has for a month. Meanwhile Alibaba, Xiaomi, DeepSeek, and Moonshot are locked in a race to give away nearly-as-good models for pennies, and Chinese labs now make up something like 45% of all the tokens flowing through OpenRouter. The story isn’t “who’s the smartest.” It’s been settled for weeks. The story is that the price of “good enough for almost everything” fell off a cliff and keeps falling.

So here’s my honest advice, which is the same advice as last week and probably next week. Ignore the launch you read about in the news. Open the leaderboards, find the cheapest model inside the band, check that two different metrics agree it’s actually good, and run that. This week that’s MiMo v2.5 Pro at 57 times less than the model everyone’s cheering for.

And go read your DeepSeek logs. Seriously. Right now.

Next Tuesday I’ll be back with the coffee and the two tabs, and I fully expect a different Chinese lab to have dropped a trillion-parameter something-or-other by then. That’s the price you pay for paying attention.

Obsidian Git Sync in 2026: What Actually Works on Mobile

Mon, 03 Aug 2026 08:00:00 -0500

I use git every day. So when I started taking Obsidian seriously, the obvious move was to drop the vault into a repo and call it solved. Commit, push, pull, done.

That works perfectly. On laptops. The second you add a phone, git stops being the easy answer and starts being the thing you fight with, which is why it is the one method I do not use for mobile in my guide to syncing Obsidian for free on every device. I run the Git plugin on desktop for version history and sync my iPad with something else entirely.

Almost nobody searching for this is asking how to set up git. They already know git. They are asking one question: will this work on my phone? So let’s answer that directly.

Desktop Git Is Solved, So Let’s Not Waste Your Time
Why Mobile Is a Completely Different Animal
What Actually Breaks, and When
No, It Is Not Real-Time Sync
The Stable Path: Let a Real Git Client Do the Mobile Leg
Git vs Remotely Save vs LiveSync
Who Git Is Actually Right For
FAQ
The Short Version

Desktop Git Is Solved, So Let’s Not Waste Your Time

If you only use Obsidian on computers, there is no article here. Put the vault in a repo, add a .gitignore, commit, push. That is it. You do not need a plugin at all.

If you want the commits to happen without you thinking about it, install the Obsidian Git plugin from the community plugins tab like any other plugin, and it will do automatic commit-and-sync (commit, pull, and push) on a schedule, plus auto-pull when Obsidian starts. On desktop the plugin shells out to the actual git binary on your machine, so it behaves exactly the way git behaves. I walked through my own setup of this in the first post, including the part where it refused to give me any branch options and I had to go back to the command line like a caveman.

The mobile story is not the same.

Why Mobile Is a Completely Different Animal

Neither iOS nor Android will let an app run the real git binary. So the plugin does the only thing it can do: it swaps in isomorphic-git, a reimplementation of git written in JavaScript, and runs that inside Obsidian.

That is a different program wearing git’s clothes, and the gaps are specific:

No SSH authentication. isomorphic-git does not support it. Your SSH keys and git@github.com: remotes are useless here. You are on HTTPS with a personal access token, and you get to store that token on your phone.
No rebase merge strategy. If your workflow assumes rebase, mobile does not have it.
No submodules. Some people build vaults out of submodules. Not on a phone.
No git-lfs. If your repo uses Large File Storage, mobile is out.
Repo size is capped by memory. All of this happens inside the app’s RAM.

That last one is the one that actually kills people, and it deserves its own section.

What Actually Breaks, and When

The plugin’s documentation does not hedge. It says the git implementation on mobile is very unstable, that it would not recommend using this plugin on mobile, and that you should try other syncing services instead.

That is the developer of the plugin telling you not to use his plugin. I have never seen a clearer signal in an Obsidian community plugin.

The docs get specific about the failure mode too. Depending on your device and how much free RAM it has, Obsidian may crash on clone or pull, throw buffer overflow errors, or just run forever without finishing.

Notice what all three have in common. They are memory failures, not sync failures. So the variable that decides whether this works for you is not “is my vault big” in some absolute sense. It is your vault plus its entire history versus whatever RAM your phone has free right now. Which means it can work fine for weeks and then fail because you had a bunch of tabs open.

I am not going to give you a magic megabyte number, because there isn’t one. What I can tell you is the shape of it:

The initial clone is the worst moment, by a wide margin. Biggest memory spike you will ever ask it to perform, and where most people give up before they reach daily use.
Attachments are the accelerant. A pure-markdown vault is tiny. Start pasting screenshots and PDFs into it and the repo gets heavy fast, and unlike your notes, images do not compress or diff. Every version of that screenshot is in your history forever.
History accumulates even if the vault doesn’t. A three year old vault with automatic commits every ten minutes has a lot of objects in it, and the clone deals with all of them.

Also worth knowing: an older separate obsidian-git-mobile repo exists and shows up in search results. Do not install it. It was archived back in September 2022 and its functionality was folded into the main plugin.

No, It Is Not Real-Time Sync

“Obsidian git plugin real-time sync” is one of the most searched versions of this question, and I think people are hoping the answer has changed. It has not.

Git is not a sync engine. It is a version control system you are using as a sync engine, and the difference shows up exactly here. The plugin’s automatic commit-and-sync runs on a timer measured in minutes. There is no file watcher pushing your keystrokes to a server.

So the real behavior is: you type a note on your laptop, and some number of minutes later it gets committed and pushed. Then your phone pulls whenever it pulls. Best case, a gap of a few minutes. Worst case, you opened the app before it finished pulling and you are now editing a stale copy of a note, which is how you manufacture a merge conflict on a device with no good way to resolve one.

If you want changes to appear on the other device almost immediately, git is the wrong tool and Self-hosted LiveSync is the one built for that.

The Stable Path: Let a Real Git Client Do the Mobile Leg

Here is the setup that actually holds up, and it is the same principle for both platforms. Do not make Obsidian do the git. Install a dedicated git client on the phone, let it clone and push the repo into a real folder, and then point Obsidian at that folder as a vault. Obsidian just edits markdown files. The git app handles git. Neither one has to be clever.

GitSync, which is what I would use now

The plugin’s own docs point at GitSync as the alternative, and having looked at it, that recommendation is correct and it is the biggest thing that has changed in this space.

GitSync is a mobile git client built specifically for syncing a folder between a git remote and a local directory, which is precisely the job. It runs on Android 5+ and iOS 13+, it is open source under GPL-3.0, and it is on Google Play, the App Store, F-Droid, and IzzyOnDroid. It won a 2024 Gem of the Year award in the Obsidian tools category, so the vault use case is not an accident, it is the point.

The part that matters most: it does not use isomorphic-git. It uses a native Rust core built on git2-rs. So it supports SSH, along with HTTPS and OAuth (GitHub, GitLab, and Gitea), and it does not inherit the memory ceiling that makes the plugin fall over. It also does background sync, which the plugin cannot do because the plugin only runs while Obsidian is open.

It is free to download. Premium is a $24.99 one-time unlock that adds additional repositories, Git LFS, git-crypt, and priority issue tagging, and you can also get it by becoming a GitHub Sponsor. There is a separate GitSync AI subscription at $6.99, which has nothing to do with syncing and which you can ignore. Note that Git LFS thing: it is a capability the Obsidian plugin does not have on mobile at any price.

Working Copy on iOS

Working Copy is the old reliable iOS git client and it is genuinely excellent. The catch that nobody mentions in sync articles: the free version cannot push. The App Store description says it straight, that you need to unlock pro features “such as the ability to push commits and manage more than 5 repositories.” Pro Unlock is $35.99. There is a 10 day trial, and it is free for students through the GitHub Student Developer Pack.

One wrinkle on “one-time”: you get permanent access to every pro feature that exists at purchase plus anything added over the next year. Features added after that need a Pro Upgrade ($17.99 for the recent ones). You never lose what you bought, but “buy once, get everything forever” is not quite the deal.

For a sync workflow, “cannot push” means “cannot sync,” so budget for it. What you get is a mature app other iOS apps can read from, which is what makes the handoff to Obsidian clean.

About mgit on Android

I have recommended mgit before and I am walking that back. The advice used to be to skip the Google Play build (users report it broken) and grab it from F-Droid instead. That is still true, but the F-Droid listing’s latest release is version 1.7.0, from January 4, 2023. That is over three years of nothing. It may well still work for you, but I am not going to tell somebody to trust their notes to an abandoned app when GitSync exists, is maintained, and is better.

Git vs Remotely Save vs LiveSync

People search for this comparison literally, so here it is without hedging.

	Git	Remotely Save	Self-hosted LiveSync
What it really is	Version control used as sync	File sync to cloud storage	Live replication over CouchDB
Mobile story	Bad via plugin, fine via GitSync	Good, it is the whole point	Good, but you run a server
Speed	Minutes, on a timer	Minutes, on a timer	Near instant
Version history	Excellent, it is the entire feature	No	Yes
Setup burden	Low if you know git	Lowest	Highest by a mile
Conflict handling	Real merges, and real merge conflicts	Duplicate files	Handled at the database level

Pick Remotely Save if you want your notes on your phone with the least friction. This is what I actually run. Pick LiveSync if you want changes to land before you can switch apps, and you are the kind of person who is fine maintaining a CouchDB instance. Pick git if you want history.

Who Git Is Actually Right For

Git is right for you if you already live in git and what you want out of sync is a time machine, not a file transfer. Being able to see that you deleted three paragraphs on March 12th and get them back is a genuinely different capability from having your notes on two devices, and no cloud sync method matches it. Add the Version History Diff plugin and you can read those diffs inside Obsidian.

Git is wrong for you if what you want is your notes on your phone. That is a sync problem, and you should solve it with a sync tool.

Which leads to the setup I think most git people should actually run, and it is a hybrid: Git plugin on desktop only, for history and backup. Something else for the mobile leg. My iPad talks to Dropbox through Remotely Save, which is the route I walk through in the iPhone and iPad guide, my laptops keep a git history, and the two never touch each other.

That last part is a hard rule, and it is the same one that wrecks iCloud vaults on Windows: never point two sync systems at the same vault folder at once. Git and a cloud sync client fighting over the same .git directory is a genuinely creative way to destroy a repo.

FAQ

Does the Obsidian Git plugin work on mobile? Technically yes, on both iOS and Android, using isomorphic-git instead of real git. Practically, the plugin’s own documentation says the mobile implementation is very unstable and recommends using a different syncing service instead.

Is the Obsidian Git plugin stable on iOS and Android? No. The documented failure modes are Obsidian crashing during clone or pull, buffer overflow errors, or the operation running indefinitely, all depending on your device’s available RAM.

Does the Obsidian Git plugin do real-time sync? No. Automatic commit-and-sync runs on a schedule measured in minutes. If you need near instant propagation, Self-hosted LiveSync is the method built for it.

Can I use SSH with the Obsidian Git plugin on mobile? No. isomorphic-git does not support SSH authentication, so mobile requires HTTPS with a personal access token. GitSync does support SSH, because it uses a native git implementation.

What is the best Android support option for Obsidian and git? GitSync. It is maintained, it is on Play, F-Droid, and IzzyOnDroid, and it uses native git rather than a JavaScript reimplementation. mgit’s last F-Droid release was January 2023.

Can I use the Git plugin with Nextcloud for multi-user sync? You can host the remote anywhere, Nextcloud included. But git is not a live collaboration layer. Two people editing the same note between pushes produces a merge conflict, not a merged note. For shared vaults, look at LiveSync or Obsidian Sync’s shared vaults.

I uninstalled the Git plugin. Where did my vault go? Nowhere. The plugin does not own your vault, and removing it leaves your files and .git folder untouched. The confusion is almost always a mobile vault location problem: if you cloned through the plugin on iOS, the vault lives inside Obsidian’s own app storage, which is not somewhere you can casually browse to. Clone with a real git client into a folder you picked, and you always know where your notes are.

The Short Version

Git on Obsidian desktop is great and you should probably be doing it for the history alone. Git on Obsidian mobile through the plugin is a thing the plugin’s own author asked you not to do, and nobody seems to want to say that plainly.

If you want git on your phone anyway, and that is a reasonable thing to want, use GitSync and let a native git implementation do the work. If you just want your notes to show up on your phone, stop trying to make git do it and go use an actual sync method. I use git for the time machine and Dropbox for the phone, and I have not lost a note yet.

How to Sync Obsidian on iPhone and iPad for Free in 2026

Thu, 30 Jul 2026 08:00:00 -0500

My iPad is the device that made me actually think about Obsidian sync instead of just having opinions about it. Laptops are easy. Two MacBook Pros and a Windows desktop will happily share a folder in any cloud service you point them at. Then you add an iPad and the thing that worked everywhere else does not work at all, because iOS doesn’t let apps do the stuff sync tools need to do.

I run Dropbox with Remotely Save for my iPad, and I pay nothing for it, which is the whole point of my guide to syncing Obsidian for free on every device. This post is the iOS-only version of that. Four options that work, what each one costs, and why the answer depends on what your desktop computer is rather than anything about your phone.

Why iOS Is the Hard Case
The Four Routes That Actually Work
Route 1: iCloud, If Your Desktop Is a Mac
Route 2: Remotely Save, the One I Actually Run
Route 3: Syncthing on iOS, the Route Everyone Asks About
Route 4: Obsidian Sync, When You Are Done Fighting
OneDrive on iOS Is Its Own Problem
The Files App Trap
Frequently Asked Questions
The Verdict

Why iOS Is the Hard Case

Every other platform gives you a folder. iOS gives you a sandbox.

On a Mac or a Windows box, a sync tool runs as a background service, watches a directory, and pushes changes when they happen. None of that is available to an iOS app. There are no background daemons. An app that is not on screen is mostly not running, and iOS decides when to wake it, not you. Apps also cannot freely read each other’s files, so “just point Obsidian at the Dropbox folder” is not a thing that exists here the way it does on desktop.

That is also why there is no native Syncthing for iOS. Syncthing is a daemon. iOS does not do daemons. Everything you will find on the App Store is a third-party app that embeds the Syncthing engine and works within Apple’s rules, which is a different and more limited thing.

So the question is not “which sync tool is best.”, but “which compromise do I want.”

The Four Routes That Actually Work

Pick by what your desktop is.

Your desktop	Best free route	Why
Mac only	iCloud	Built into Obsidian’s iOS vault creation, near zero setup
Windows	Remotely Save with Dropbox or S3	Works identically on both ends, no Apple dependency
Linux	Remotely Save, or Syncthing via SyncTrain	Linux has no iCloud and no official OneDrive client
Mixed, or you want no cloud at all	Syncthing via SyncTrain or Möbius Sync	Peer to peer, nothing stored on anyone’s server
You want it to just work	Obsidian Sync, $4/mo annual	Not free, but it is the one that never needs troubleshooting

Now the details.

Route 1: iCloud, If Your Desktop Is a Mac

If you are all Apple, stop here. Create the vault on your iPhone or iPad, toggle on Store in iCloud during creation, and you are done. It is the only route with first-class support inside Obsidian’s own iOS app.

I am not going to repeat the setup steps, because I wrote the long version already. See the full iCloud walkthrough for creating versus migrating a vault, the “Optimize Mac Storage” setting that removes your notes, and the part where it falls apart if Windows is involved.

The short version: works perfectly on Apple hardware, unreliably the moment it is not.

Route 2: Remotely Save, the One I Actually Run

This is my setup. Remotely Save is a community plugin that syncs your vault to a storage backend you already have. The free tier covers S3 and anything S3-compatible like Cloudflare R2 or Backblaze B2, plus Dropbox, WebDAV including Nextcloud and Synology, and OneDrive personal with a caveat I get to below.

The reason it wins on iOS is that it sidesteps the sandbox problem. Remotely Save runs inside Obsidian. It does not need to watch a folder or run in the background, because it syncs when Obsidian is open and you tell it to, or on the schedule you set. iOS does not have to cooperate for it to work.

The setup is the same on every platform, which is the other reason I use it. Install the plugin from Community Plugins, pick your service, authenticate, set a sync interval, and run a manual sync once to seed the vault. Do the desktop side first and let it finish before you touch the iPad, same as any sync method.

The tradeoff is honest: sync happens when Obsidian is open. Open the app, wait a couple of seconds, then start typing. That is the deal, and after a couple of years of it I have stopped noticing.

Route 3: Syncthing on iOS, the Route Everyone Asks About

This is the biggest cluster of searches on this topic and the one the forum threads are full of, so here is the current state of it in 2026.

You cannot run Syncthing on iOS directly. You run one of two apps that wrap it.

Möbius Sync

Free to download. The catch is the one people keep asking about in forum threads: usage within the Möbius Sync sandbox is free up to 20MB. Past that you need the in-app purchase, Unlimited file sync, $4.99, which is a one-time purchase and not a subscription.

For an Obsidian vault, 20MB is the deciding number. A text-only vault of a few thousand notes fits under it well. A vault with images, PDFs, or scanned documents blows through it immediately. But five dollars once is a fair price for a sync solution.

SyncTrain

The other option, and worth knowing about because it is truly free. No in-app purchases, open source, iOS 17 or later, actively maintained. It has deeper Shortcuts integration, which is the closest thing iOS offers to background syncing, since you can trigger a sync from an automation rather than remembering to open the app.

I appreciate that its own App Store description tells you this: “Do not use Synctrain for back-up purposes, and always keep a back-up of your data.” An app that volunteers its own limitations is an app I trust more than one that does not.

The Reality of Both

Syncthing on iOS is peer to peer, which means your notes never sit on anyone else’s server. That is the real reason to pick it.

But it also means both devices have to be awake and reachable at the same time for anything to happen. Your Mac asleep in a bag syncs nothing. This is why people describe iOS Syncthing as flaky when it is actually working exactly as designed. There is no server holding your changes until the other device shows up. If you want that, you want one of the other three routes.

Route 4: Obsidian Sync, When You Are Done Fighting

Not free, so it does not really belong in a free guide, except that it belongs in every honest one. Sync Standard is $5 a month billed monthly or $4 billed annually, it is end-to-end encrypted by default, and it is the only option on this page where iOS is a first-class platform rather than a workaround.

If you have read this far and the phrase “sandbox limitations” has stopped being interesting, that is the answer. Four dollars a month is roughly one coffee.

OneDrive on iOS Is Its Own Problem

OneDrive keeps showing up in the search data for this topic, so it deserves a direct answer: it is the most awkward of the cloud options on iOS.

Remotely Save does support OneDrive on the free tier, but with a restriction worth understanding before you start. The free version can only connect to the App Folder, meaning /Apps/remotely-save inside your OneDrive. The PRO version is what connects to the root folder.

That means you can’t point free Remotely Save at a vault that already lives somewhere else in your OneDrive. The vault has to live in the app’s own folder. If you were planning to sync a vault that sits alongside your work documents, that is the plan that breaks, and it breaks after you have already set everything up.

If you are on OneDrive because your job is on Microsoft 365, this is workable as long as you keep the vault in the app folder. If you are on OneDrive out of habit, Dropbox or an S3 bucket will give you a smoother ride for free.

The Files App Trap

Here is the mistake that generates the most confused forum posts.

Your Obsidian vault on iOS is not just a folder in the Files app that you can put anywhere. Obsidian stores its iOS vaults in its own app container, which surfaces in Files as iCloud Drive > Obsidian. That location is not decoration. Obsidian’s docs are explicit that vaults should live inside the Obsidian folder in iCloud Drive.

Drop a vault in some other Files location and you get the confusing outcome: it looks fine in Files, it may even sync between your Macs, and the iOS app will not list it. People then conclude sync is broken when the vault was never somewhere Obsidian could see.

The other half of this trap is that “it’s in Files” does not mean “it’s on the device.” A file showing a cloud icon is a placeholder. Obsidian searching a vault full of placeholders returns incomplete results and nothing tells you why.

Frequently Asked Questions

Can I sync Obsidian on iPhone for free? Yes. iCloud if your desktop is a Mac, Remotely Save with Dropbox or S3 for everything else, or SyncTrain if you want peer to peer with no cloud involved.

Does Syncthing work on iOS? Not directly, because iOS does not allow background daemons. You use a wrapper app, either Möbius Sync or SyncTrain, and both devices must be awake at the same time to sync.

Is Möbius Sync free? Free to download and free within its sandbox up to 20MB. Beyond that the Unlimited file sync in-app purchase is $4.99, one time.

How do I sync Obsidian between my PC and iPhone? Remotely Save with Dropbox or an S3 bucket. iCloud is the wrong tool when a Windows machine is involved, for reasons covered in the iCloud walkthrough.

What about syncing with Git on iOS? It works, but not through the Obsidian Git plugin, whose own documentation recommends against mobile use. You need a real git client doing the mobile leg. I covered the whole situation in Obsidian git sync and what actually works on mobile.

Why are my notes out of date when I open Obsidian on my phone? Because no iOS sync method runs continuously in the background. Open the app and give it a few seconds before you start editing.

Where does Obsidian store vaults on iPhone and iPad? In its own container, visible in the Files app as iCloud Drive > Obsidian. Vaults kept elsewhere may not appear in the app’s vault list.

The Verdict

The iOS question answers itself once you stop asking it about iOS. Mac desktop, use iCloud. Windows or Linux desktop, use Remotely Save. Want nothing on anyone’s server, use SyncTrain and accept that both devices have to be on. Want to stop thinking about it, pay the four dollars.

What none of them do is sync silently in the background the way you are used to on a laptop, and no blog post is going to fix that, because it is Apple’s design and not a gap in the tooling. Once you build the two-second pause into opening the app, iOS sync stops being a problem and goes back to being a folder.

Mine has been a folder for four years now. I only think about it when I write about it.

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

Wed, 29 Jul 2026 07:00:00 -0500

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)

Tue, 28 Jul 2026 08:00:00 -0500

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

Mon, 27 Jul 2026 08:00:00 -0500

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. You tap a toggle. If your desktop is not a Mac, the other iOS options are worth comparing before you commit, and I ranked all four in the guide to syncing Obsidian on iPhone and iPad for free.

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

Wed, 22 Jul 2026 07:00:00 -0500

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

Tue, 21 Jul 2026 08:00:00 -0500

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

Wed, 15 Jul 2026 07:00:00 -0500

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.

Stephan Miller

The Expensive Model Only Plans Now: I Split My AI Coding Rig Across Two Tools

The Setup: One Expensive Model Doing Two Jobs

Enter opencode (and a Roster of Cheap Models)

The Rule I’d Just Landed On, and Why I Inverted It

Reviewers That Don’t Share the Builder’s Blind Spots

The Tell: The Diagrams Came Before the Code

Three Docs, Three Sets of Write Permissions

The Whole Truth

What’s Next

Qwen3.8-Max Dropped. I'm Still Running the $0.87 Model.

China Dropped a 2.4-Trillion-Parameter Flagship and I Mostly Yawned

The “Smartest Model in the World” Had an Awkward Debut

The Boring Answer That Keeps Winning

Cheapskate Picks: Where the Actual Money Is

Horror Stories From the Wild

Coming Soon (Or “Soon,” Anyway)

What I Actually Took Away This Week

Obsidian Git Sync in 2026: What Actually Works on Mobile

Desktop Git Is Solved, So Let’s Not Waste Your Time

Why Mobile Is a Completely Different Animal

What Actually Breaks, and When

No, It Is Not Real-Time Sync

The Stable Path: Let a Real Git Client Do the Mobile Leg

GitSync, which is what I would use now

Working Copy on iOS

About mgit on Android

Git vs Remotely Save vs LiveSync

Who Git Is Actually Right For

FAQ

The Short Version

How to Sync Obsidian on iPhone and iPad for Free in 2026

Why iOS Is the Hard Case

The Four Routes That Actually Work

Route 1: iCloud, If Your Desktop Is a Mac

Route 2: Remotely Save, the One I Actually Run

Route 3: Syncthing on iOS, the Route Everyone Asks About

Möbius Sync

SyncTrain

The Reality of Both

Route 4: Obsidian Sync, When You Are Done Fighting

OneDrive on iOS Is Its Own Problem

The Files App Trap

Frequently Asked Questions

The Verdict

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

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

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

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

Obsidian iCloud Sync in 2026, Including the Windows Problem

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

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

The Batch That Hooked Me

The Experiment: A Pre-Specified Queue

I Optimized the Wrong Thing

The Gap Was the Point