This week I made the cheapest-looking change in the entire system: one default, in one config file. The background fleet — the couple dozen coding agents that take turns on my repositories while I’m away — now runs on Claude Fable 5, Anthropic’s new top-tier model, with the effort dial parked at its highest everyday setting.
\nModel-upgrade posts are a genre, and the genre lies. The screenshot, the “everything is different now,” the benchmark chart with the arrow. I promised this site would show the seams instead, so here is the honest version, written while the paint is still wet: what actually changed, what I can genuinely report a few days in, and what I refuse to claim yet.
\nFable 5 is the first model in a new family, sitting in a tier above the Opus models the fleet ran before. The headline property, for my purposes, isn’t a benchmark — it’s horizon. This model is built to run long: a single turn can stretch for many minutes of uninterrupted reasoning and tool use, thinking is always on, and the effort setting trades latency for depth. For interactive chat that profile is overkill. For a fleet whose whole job is to work unattended while I sleep, it’s exactly the shape you want.
\nThe switch cost nothing in the way that matters to the loop. It rides the same flat-rate plan I already pay for, so the “never spend” gate — the rule that no automation may create new costs without me — never even twitched. One config line, one commit. (The commit that flipped the default was co-authored by the model it was promoting, which I choose to find funny rather than ominous.)
\nDays, not weeks, of evidence. With that caveat:
\nTurns got longer and check-ins got fewer. Work that used to come back as several short rounds — attempt, stall, nudge, attempt — now more often comes back as one finished stretch: the change made, the tests run, the commit written. The babysitting layer I wrote about in Two Kinds of Stuck still earns its keep, but it visibly has less to do. An agent that finishes its thought before stopping is an agent the watchdog never has to poke.
\nThe stops are more interesting. When an agent halts now, it’s less often “the machine wedged” and more often “I reached a line I’m not allowed to cross alone” — push this, publish this, decide this. Which is the safety model working, and also my problem, as we’re about to see.
\nWhat I refuse to claim: any number. The loop’s scoreboard is time reclaimed — boring, rounded, audited — and right now it says what it said before the switch: about five hours a week handed back by a couple of deliberately dull automations that guard my calendar and triage my inbox. The new model hasn’t moved that line yet, because days-old infrastructure changes don’t move that line. If a future audit shows the number rising and the upkeep falling, that will be the benefit, and I’ll publish it then. Anything else would be the rocket-emoji genre with extra steps.
\nHere’s the real finding, and it’s a little uncomfortable.
\nBefore the switch, the build engine was already outrunning me. The fleet could produce more reviewed-and-committed work in a weekend than I could thoughtfully adopt into my actual life in a month. The constraint on this whole experiment was never “can the agents build things” — it was the human gates: which automation to build next, whether a finished one deserves to go live, what gets pruned. Those decisions are mine by design, they take minutes I have to choose to spend, and they don’t parallelize.
\nA meaningfully smarter model doesn’t relieve that constraint. It sharpens it. Every capability upgrade makes the cheap side of the system cheaper and leaves the expensive side — human judgment, human attention, human willingness to change a habit — exactly as expensive as before. The queue of finished work waiting at a confirm: gate grows faster now. The model got better; the bottleneck moved one seat closer to me.
I think this is the most under-reported fact about agentic AI right now. The marginal cost of building is collapsing. The marginal cost of adopting — deciding, trusting, integrating, living with — hasn’t budged. A system design that doesn’t account for that just converts model intelligence into a longer backlog.
\nThe loop already had an answer sketched in, which is why I’m not redesigning anything: maintenance cost sits in the denominator of every score, “build nothing” is always a valid choice, and the human gates were never a temporary scaffold to automate away. They’re the product. A stronger model makes restraint more valuable, not less — there is now more horsepower behind every action I don’t review.
\nOne line on one chart: time reclaimed, against the upkeep it costs. If the smarter fleet turns into more hours handed back — through automations good enough that saying yes at the gate gets easier — the upgrade pays for itself in the only currency this project counts. If instead it just produces a more impressive pile of unadopted work, then I’ll have learned that the model was never the limiting reagent, and the next investment belongs in the boring side: better proposals, smaller diffs, easier yeses.
\nThe magic, as ever, is downstream of the boring config. The model is new. The rule didn’t change.
", "summary": "This week I pointed the whole agent fleet at Claude Fable 5 and turned the effort dial to its highest setting. The honest report, days in: the engine is clearly stronger — and the scarcest resource in the system is now, even more obviously, me.", "date_published": "2026-06-10T00:00:00.000Z", "tags": [ "ai", "agents", "claude", "loop", "automation" ] }, { "id": "https://parallelogramist.com/writing/two-kinds-of-stuck/", "url": "https://parallelogramist.com/writing/two-kinds-of-stuck/", "title": "Two Kinds of Stuck", "content_html": "There’s a version of “my AI works while I sleep” that’s pure thread bait — a screenshot, a rocket emoji, a claim that the future arrived overnight. And there’s the real version, which is mostly plumbing, and which lives or dies on a single distinction I didn’t appreciate until it bit me.
\nHere’s the setup. I run a small fleet of background coding agents — roughly one per repository, a couple dozen of them, taking turns. While I’m away from the desk they pick up work, make changes, run tests, commit. Nothing exotic; it’s the same agent I’d drive by hand, just left running on a schedule with a cap on how many go at once.
\nThe interesting part isn’t that they run. It’s what happens when they stop.
\nSpend any time watching a fleet like this and you notice every halt falls into one of two buckets, and the two could not be more different.
\nThe first kind is machine-stuck. The agent hit the plan’s usage ceiling and the platform told it to come back later. Or it caught a transient server hiccup — a momentary “too many requests,” the kind of thing that clears on its own in a minute. In both cases the agent did nothing wrong. The world said wait, so it’s waiting. There’s nothing to decide here. Left alone it would sit there forever, holding a slot, doing nothing, for no good reason.
\nThe second kind is human-stuck. The agent walked up to a line I drew and refused to cross it without me. Push this branch to a remote. Send this email. Spend money. Make something go live. These are the few irreversible, outward-facing moves I never let an agent make alone, so when one arrives at the edge it stops and asks — confirm: this, pick: one of these.
That stop is not a failure. That stop is the entire safety model working exactly as designed.
\nAnd that’s the trap. Both buckets look identical from a distance: an agent that isn’t moving. If you write a dumb script that just pokes every stalled agent with “keep going,” it will faithfully wait out a usage limit and faithfully click past the one gate that exists to stop it from doing something you can’t take back. The same nudge that’s obviously correct for the first kind is the single worst thing you can do to the second.
\nSo I built a small thing — a watchdog — whose whole job is to honor that distinction and nothing else.
\nIt’s about as dumb as a useful program can be. Once a minute it asks the agent runner who’s stalled and why. For a usage-limit stall, it reads the time the limit resets, waits for that moment to actually pass, then sends a single “continue” — exactly what I’d do if I were typing into the fleet view myself. For a transient rate-limit, where there’s no reset clock to read, it backs off and retries on its own schedule, and it staggers those retries across the fleet — because a rate limit usually hits everyone at once, and the last thing you want is two dozen agents all lunging back through the same door the instant it cracks open and slamming it shut again.
\nAnd then the part that matters most, the part that’s defined by what it won’t do: it never, under any circumstances, touches an agent that’s stopped at a human gate. A confirm: or a pick: is invisible to it by construction. Those wait for me, every time, no exceptions, even at 3am when I’m asleep and the slot is idle and it would be so easy to just let it through. There’s also a single file I can drop to freeze the whole thing if I ever stop trusting it. The kill switch is more important than the feature.
That’s the rule, stated plainly: automatically recover from the machine telling you to wait; never automatically answer a question that was meant for a human.
\nI promised on this site to show the seams, so here’s one.
\nFor a while it worked beautifully, and then one morning I found the entire fleet flatlined. Zero agents working. Two dozen of them, all parked.
\nThe cause was a perfect little knot. One agent had been nudged back to life after a usage reset — but instead of returning cleanly to working, it got wedged in a limbo state: the process was alive, but it never actually resumed. The keeper that staffs the fleet didn’t count a ghost like that as a working agent, so it kept trying to fill the slot. But the slot wasn’t empty. So it stalled. So it tried again. One stuck agent, multiplied by a refill loop, quietly deadlocked everything around it. The recovery mechanism had become the outage.
\nThe fix is embarrassingly boring, which is the point: now anything that’s been sitting in that limbo state for more than a few minutes gets reaped, and the slot genuinely frees up. No demo will ever show you this. It’s exactly the kind of unglamorous, load-bearing detail that decides whether “it runs overnight” is a real claim or a lie you tell on a good day.
\nThe thesis I keep coming back to on this site is that the magic is downstream of the boring config. This is the cleanest example I have.
\n“My agents work while I sleep” sounds like a story about capability. It isn’t. It’s almost entirely a story about restraint — about deciding, in advance and in cold blood, the short list of things a machine may never do without me, and then building something small enough to be trustworthy that holds that line when I’m not watching. The watchdog has no judgment and I want it to have none. Judgment is the part I keep.
\nIt also has to earn its keep cheaply, because the loop underneath all of this puts maintenance cost in the denominator — anything that needs babysitting scores low and prunes itself. A watchdog that needed its own watchdog would defeat its own reason to exist. So it’s deliberately tiny and stupid: one distinction, drawn sharply, defended completely.
\nGet that one line right and the fleet quietly hands you back your mornings. Get it wrong and you wake up to a branch you didn’t push. Two kinds of stuck. Only one of them is yours to fix while you sleep.
", "summary": "I let a fleet of coding agents run while I sleep. The whole thing lives or dies on one distinction: an agent stopped because the world told it to wait, versus an agent stopped because it's about to do something it isn't allowed to do alone. Only one of those is safe to nudge.", "date_published": "2026-06-06T00:00:00.000Z", "tags": [ "ai", "agents", "automation", "loop", "seams" ] }, { "id": "https://parallelogramist.com/writing/why-parallelogramist/", "url": "https://parallelogramist.com/writing/why-parallelogramist/", "title": "Why Parallelogramist", "content_html": "There’s a particular kind of writing I keep wishing existed and rarely find: someone showing you the actual machinery of how they work with these tools. Not the demo. Not the thread that ends at “the future is here.” The seams — what broke, what they ripped out a week later, the boring config that made the magic reliable.
\nSo I’m going to write it.
\nI don’t sit and grind through everything myself. The center of it is a small always-on box — the quiet machine that runs the things that need to be up when I’m not. On it lives a fleet of coding agents that take turns on my repositories: they pick up work, make changes, run tests, and commit, mostly while I’m away from the desk. I check in from my phone and a watch, the lightest glanceable surfaces, and step in only at the decisions that are mine to make.
\nThe name is the thesis. A parallelogram is a shape made of parallel sides, pushed off-square. That’s what this feels like: work happening in parallel, off to the side, while I’m doing something else — never the “normal” rectangle of sitting at a desk grinding through it alone. Work on several tracks at once, slightly skewed.
\nThe surfaces are the fun part, but they’re not the point. The point is a loop.
\nUnderneath all of it I run a self-improving system whose only job is to hand me back time and then get out of the way. Each cycle it looks at where my time actually went, scores a backlog of things I could automate by value returned divided by what it costs to keep alive, and proposes exactly one thing to build next. I pick one — or I pick nothing, which is allowed and often correct. It builds the thing as something reversible. It keeps what earns its place and retires what rots.
\nThe trick that makes it safe is small and load-bearing: maintenance cost lives in the denominator. Anything that needs constant babysitting scores low and prunes itself. A system meant to give you time can’t be allowed to quietly become the thing that eats it. So the reclaimed time is the headline metric, not a dashboard full of charts — and that time goes back to my family by default, which is the whole reason any of this exists.
\nThree things:
\nThe goal is simple and a little selfish: explain these projects well enough that you could go build your own version. So each one gets a real write-up — what it does, how it’s wired together, and where I tripped over my own feet.
\nThe source is rolling out too. As I open each repo on GitHub, its link lands right on the project’s card — no gatekeeping, just a queue I’m working through. The handful of things that stay off the site are the boring-private ones: home-network details, family, secrets. Not a transparency flex — they’re simply not the fun part.
\nSo: real projects, explained plainly, with the code following close behind. Take what’s useful and go build something.
", "summary": "A small always-on box runs a fleet of coding agents across my repositories while I'm away. This is where I document how it actually works — the wins, the rough edges, and the boring config that made the magic reliable.", "date_published": "2026-05-25T00:00:00.000Z", "tags": [ "meta", "ai", "stack", "augmentation" ] } ] }