The biggest structural change with Claude Fable 5.1 is that a single request can run for a long time. Reading your codebase, planning, building, running tests and fixing what broke — all in one turn — routinely takes many minutes at higher effort. This changes how you work more than any prompting technique.

Stop interrupting

If you're used to models that answer in seconds, silence feels like failure. With Fable 5.1, silence at minute six of a hard task is the model working. Interrupting throws away everything it has thought through and restarts from nothing.

Give a hard task, then do something else. Come back when it's done.

Give it the whole task up front

Longer turns reward complete specifications. The model can hold a large task in view and work through it without checking in, but only if it has the full picture at the start. Half a spec produces half a feature and a question.

full-task.txt
I'm working on <the larger goal> for <who it's for>. They need <what
the output enables>.

With that in mind, build: <the complete task>

Constraints: <stack, files that must not change, style rules>
Done means: <specific, checkable conditions>
Verify by: <the test command, or how to check it works>

Do the whole thing. Don't stop to ask about decisions I've covered here.

Including why — the larger goal and who it's for — measurably improves what comes back. The model connects the task to relevant context rather than guessing at intent.

Match effort to the turn you want

A long turn at high effort is right for "implement this feature". It's wrong for "rename this variable". Drop effort for small tasks and the turns shorten to match. If the wait feels disproportionate, effort is too high for the task.

Ask for progress you can see

Fable 5.1 narrates less between tool calls than earlier models. On a long turn you may see nothing for minutes, then a final summary describing only the last step. If your tool has a progress-update mode, turn it on. Otherwise ask directly:

progress-updates.txt
Before you start, say in a line what you're about to do. Brief updates
while you work help me follow along. Close with a short recap that
stands on its own — what you found, what you did, what's next — so I
have the full picture from the last message alone.

Handle the tool-level consequences

If you're building your own tools on the API: plan for long requests. Stream responses rather than waiting for the whole thing. Set generous timeouts. Design so that callers check on a run rather than blocking inside one request. A fifteen-minute HTTP request that times out at ten is a wasted fifteen minutes.

The payoff

The teams that got the most from early access gave it their hardest unsolved problems first — had it scope the problem, ask its questions, then execute. Long turns are what make that possible. Use them for the work that earns them.

If a task is small enough that a long turn feels wasteful, it's small enough for low effort. If it's big enough for high effort, give it the time.