Letting it run without you

Claude Fable 5.1's headline capability is long autonomous runs — hours of work through a coding agent while you do something else. That's genuinely available to you, and it's genuinely risky if the setup is wrong.

The non-negotiable

Version control, everything committed, before the run starts. An agent that edits forty files over two hours is fine when git diff shows exactly what changed and git restore . undoes it all. Without that, you're trusting a system you cannot inspect.

Commit between tasks, not between sessions. Ideally, run each big task on its own branch.

Give it a way to check itself

Unattended agents need a feedback loop, or a wrong assumption compounds for two hours. Tests, a type checker, a linter, a script that starts the app and hits an endpoint — anything. Tell it to run that after every change.

For long builds, go further and ask it to build its own harness:

Establish a method for checking your own work as you build — tests,
a script, whatever fits — and run it every time you complete a piece.
Verify against the specification, not against what you happened to
build.

Tell it you're not there

Deep into a long session, the model can occasionally end a turn by describing the next step instead of doing it, or asking permission for something the request already covered. Interactively you reply "continue". Unattended, it just stops. This system-prompt block prevents it:

You are operating autonomously. The user is not watching in real time
and cannot answer questions mid-task, so asking "Want me to...?" or
"Shall I...?" will block the work. For reversible actions that follow
from the original request, proceed without asking. Stop only for
destructive actions or genuine scope changes the user must decide.

Before ending your turn, check your last paragraph. If it is a plan, a
question, a list of next steps, or a promise about work you have not
done, do that work now. Do not stop because the session is long. End
your turn only when the task is complete or you are blocked on input
only the user can provide.

Before running a command that changes system state — restarts, deletes,
config edits — check that the evidence supports that specific action.

The first sentence is load-bearing. Keep it as written. If there are specific things you do want it to stop for, list them.

Hold the scope

Left alone, it may deliver what you asked and a bit more. Pair the autonomy prompt with a scope one:

My request sets the scope, and the scope is the deliverable — don't
narrow, widen, or swap it. Make routine judgement calls yourself; check
in only when different readings would lead to materially different
work. If you see a real problem with the task as specified, say so in a
sentence and keep building under stated assumptions.

If one part is blocked, complete every other part in full and say
exactly what you left out and why. Scaling the work down is my call.

Something else you notice worth doing is a suggestion for the end, not
a change to make.

Make it prove progress

Long runs used to produce fabricated status — "tests pass" when they didn't. This nearly eliminates it:

Before reporting progress, audit each claim against a tool result from
this session. Only report work you can point to evidence for. If tests
fail, say so with the output. If a step was skipped, say that. When
something is done and verified, state it plainly.

Then read everything

When you come back, read the whole diff. Not the feature — the whole diff. The problems from autonomous runs live in the files you didn't expect to change. If the diff is too big to read, that's information about the task size; revert, halve it, run again.

Autonomy is a multiplier. It multiplies a good setup into hours of saved work and a bad setup into hours of cleanup. The setup is the part you control.