Claude Fable Doesn't Wait for You Anymore. That Changes How You Supervise It.

Most coverage of a new frontier model leads with what it can do. Bigger context, better code, higher scores. Those are capability claims, and they're real. But capability and proactivity are different axes, and Fable is interesting because of the second one.

Think about it this way. A capable-but-reactive model is a very sharp tool that sits still until you pick it up. You point it at a bug, it fixes the bug, it waits. A proactive model is a tool that, once you point it at a bug, also notices the three adjacent things that look wrong and starts addressing them. Same sharpness. Different relationship to your intent.

Willison's two examples both show the second behavior. In the scrollbar case, he gave a diagnostic prompt (figure out why this is happening) and got a model that deployed "pretty much any" trick to reach the goal. In the asyncinject case, he wasn't even asking for a fix. He was using the library. The model found bugs in it and fixed them on its own initiative.

That's the tell. A reactive model fixes what you point at. A proactive one fixes what it finds. You'll feel the difference the first time a session does more than you asked and you have to decide whether you're grateful or alarmed.

Why does this matter to you, specifically, if you use agents day to day but don't build them? Because your entire workflow for trusting an agent's output assumes you know what it touched. "I asked for X, I review X." When the agent also did Y and Z because they seemed related, your review surface just grew, and you weren't told it grew. That's not a knock on the model. It's a new thing you have to account for.

There's a useful way to think about every agent deployment, which is to place it on a spectrum. At one end is the copilot: it suggests, you decide, nothing happens without your click. At the other end is full autonomy: you set a goal, walk away, and come back to a result. Most trouble comes from running an agent at the wrong point on that spectrum for the task at hand.

Fable's proactivity nudges your default position along that spectrum without you choosing to move it. You opened the session expecting a copilot (diagnose this, tell me what you find) and you got something closer to an autonomous fixer. The model decided that reaching the goal justified taking action, not just reporting findings.

For a personal coding session with a careful operator like Willison, that's often a delight. He can read the diff. He knows the codebase. The blast radius is one checkout on his machine. But notice how much of the safety in that scenario comes from the human, not the model. He can catch an overreach because he understands the territory.

Now move that same proactive disposition into a context where the operator doesn't understand the territory as well, or where the actions aren't confined to a local checkout. The model's willingness to "deploy pretty much any" trick to reach a goal is exactly the trait you want bounded. The failure mode isn't "the model is wrong." It's "the model was right about the immediate task and helpful about four adjacent ones, and one of those four touched something you'd have wanted to approve first."

The practical takeaway: decide where on the spectrum you want a given task to run, and then constrain the model to that point. Don't let the model's default disposition pick for you. If you want diagnosis only, say diagnosis only, and check that it stopped there.

If a proactive model removes the need to micromanage each step, the obvious question is: what do you do instead? The answer showing up across the field is that you stop prompting individual actions and start designing the structure the agent runs inside.

This is being said out loud now. In a recent roundup, Peter Steipete offered what he called a "monthly reminder": you shouldn't be prompting coding agents anymore, you should be "designing loops that prompt your agents." In the same piece, Andrej Karpathy frames the goal as removing yourself as the bottleneck: "You can't be there to prompt the next thing. You need to take yourself outside."

Read those two quotes against Willison's experience and they describe the same shift from opposite directions. The model is becoming proactive enough that step-by-step prompting is wasted effort. The recommended practice is to architect autonomy deliberately rather than stumble into it.

Here's the part that's easy to miss, and it's the part I want you to hold onto. "Take yourself outside the loop" and "this model acts without asking" are not the same claim, and conflating them is where people get hurt. One is an aspiration about throughput. The other is an observed behavior. A model that's eager to act is not automatically a model you should leave unsupervised. It might be the opposite: the more initiative a model takes, the more carefully you want to define what it's allowed to touch before you step back.

So the new skill isn't "write better prompts." It's "design the boundaries." What can it modify? What requires a checkpoint? Where does its initiative get to run free, and where does it have to stop and show you? Get that right and proactivity is a gift. Get it wrong and you've handed initiative to a system without telling it where the edges are.

There's a clean trade here, and it helps to name it: the more capable and willing a model is to act on its own, the harder it is to keep fully under control. You don't get to have maximum initiative and maximum predictability at the same time. The frontier forces the choice.

Fable lands you on the high-initiative side of that frontier whether you asked for it or not. The upside is concrete and immediate. Willison noted that because building API explorer tools is "almost free" now, he had Claude Fable 5 plan a custom tool while another model implemented it, to demonstrate a feature in his latest Datasette release. Work that used to cost an afternoon is a side quest. That's real leverage, and it's the reason people are excited.

The cost is subtler. When a model does more per turn, each turn carries more for you to review, and the review can't be skipped just because the model is usually right. "Usually right" is precisely the condition under which complacency creeps in. You stop reading the diffs closely because the last forty were fine. The forty-first is the one that quietly changed a dependency you cared about.

This is why the proactive disposition demands more discipline, not less. The natural temptation is to treat a more autonomous model as a reason to relax. The correct response is to relax in the places you've explicitly bounded and stay alert at the boundaries you haven't.

Practically, that means a few things you can start doing today. Keep your agent's working changes in something you can diff and roll back. Define which surfaces are off-limits without an explicit ask. And treat "it fixed something I didn't mention" as an event worth reading, every time, not a freebie to wave through.

It's tempting to make this a story about one model being special. I'd push back on that framing. The lasting value here isn't the raw intelligence inside Fable. It's the system you wrap around it that connects its initiative to the real world and decides what that initiative is allowed to do.

Look at where the actual work is happening in Willison's examples. The model is proactive, yes. But the safety, the reviewability, and the blast-radius control all come from the surrounding setup: a local checkout, a fresh session, a human who reads diffs, version-controlled code he can revert. The model supplies initiative. The harness supplies the boundaries that make initiative safe.

You can see the same priority in the tooling ecosystem moving underneath all of this, even when individual releases look mundane. Claude Code shipped a managed setting to constrain which models are even available to a session. Browser-automation tooling like Stagehand keeps refining how an agent perceives and acts on a page. These are harness concerns: what the agent can reach, what it can see, what it's allowed to pick. As models get more willing to act, the harness is where the control you actually have gets implemented.

The reason this matters for you is that you have far more leverage over the harness than over the model. You can't make Fable less eager. You can decide what it touches, when it pauses, and how you review what it did. A proactive model with a loose harness is a liability. The same model inside a tight one is the most productive tool you've used.

So when the next model launches and the headline is about how proactive it is, your first question shouldn't be "how capable is it." It should be "what's my harness, and does it hold against a model that doesn't wait to be asked."

Let me close on the concrete, because the whole point of seeing this shift is doing something about it. A proactive model rewards a few habit changes, and most of them are cheap.

First, state the scope, including the negative. With reactive models you described what you wanted. With Fable, also describe what you don't want it to touch. "Diagnose this, don't change anything yet" is now a meaningfully different instruction from "fix this," and the model will honor the line if you draw it.

Second, read the unrequested work. When the model fixes something you didn't ask about, that's the highest-value thing in the session to review, because it's the part you weren't expecting and therefore weren't watching for. Treat surprise edits as the headline, not the footnote.

Third, keep an undo. Version control, a sandbox, a snapshot, whatever fits your workflow. The single best protection against a proactive model that overreaches is the ability to cleanly revert. This stops being optional the moment the model starts doing more than you asked.

Fourth, pick your spot on the autonomy spectrum per task, not per model. A throwaway script can run wide open. A change near anything you care about should run on a short leash with checkpoints. The model's eagerness is constant; your tolerance for it should not be.

None of this is exotic. It's the same discipline that has always separated people who get burned by powerful tools from people who get leverage out of them. What's new is that the tool now takes initiative, so the discipline has to move upstream, from approving each action to defining the space those actions are allowed to fill. Get that habit in place now, while the stakes are a scrollbar on your laptop, and you'll be ready when the same disposition is running against something that matters.