🎚️ Control the depth + set limits

The practical guide to using Fable 5 as a work agent sums this up in a four-step scale. Each step isn’t a technical setting — it’s an instruction you write in the prompt yourself, telling the agent how much it’s worth deliberating before giving you the answer.

The scale works best when you ask yourself before writing the prompt: "if this answer comes out wrong, what do I lose?" The more you stand to lose, the higher the level you should ask for.

Source: practical user guide to using Fable 5 as a work agent — prompt tested in practice, not an official Anthropic quote.

The 4-level ladder: each step increases reasoning time (dashed cyan line)— máxima stands out because it’s the level you should reserve for when a mistake really costs a lot.

Instead of trusting the agent to guess the right level on its own, you explicitly say where to focus the heavy reasoning — and where it isn’t worthwhile. This avoids the most common symptom of leaving everything at “high all the time”: solutions that are more complicated than the task calls for.

The prompt below does exactly that: it separates the part that deserves depth (the strategic decision) from the part that doesn’t (the implementation itself, which should stay simple).

Use análise profunda apenas na parte estratégica. Não complique a
solução. Não crie abstrações desnecessárias. Entregue a solução mais
simples que resolve bem o problema.

<isto você troca — cole junto o pedido real da tarefa>

A strong model isn't cautious by default — it is capable by default. This means that when a request is ambiguous, Fable 5 tends to fill in the gap on its own: if you asked it to “solve the problem,” it may decide for itself what counts as solving it, and take action.

This is great when you want it to continue until a clearly defined task is done. It's dangerous when the task is ambiguous about what it can touch — files, services, configuration, production data.

The most reliable way to enforce the boundary from the previous topic is to put the agent in a diagnostics-only mode explicit: it can inspect, measure, and draw conclusions — but it can't change anything until you approve.

Primeiro apenas avalie. Não altere arquivos, não reinicie serviços,
não crie branch, não edite configuração e não rode comandos
destrutivos.

Entregue um diagnóstico com evidências. Depois diga exatamente quais
mudanças recomenda e por quê.

<isto você troca — descreva o sistema ou problema a investigar>

The gate separates the two paths: diagnostics (cyan) are always allowed; actual execution (red) stays locked until you explicitly approve the recommended changes.

The two tips in this module don’t compete—they work together. The clearest example is a security audit: you want high depth (it's a decision that's costly if it goes wrong) e wants the agent locked in diagnostic-only mode (because now isn't the time to change anything yet).

In practice, this becomes a 5-step workflow you repeat for any sensitive task—not just security audits.

Perform a complete security audit of <replace this — the system/project>. Use deep analysis — getting this wrong would be costly.

But for this round, only assess: don’t change files, restart services, edit configuration, or run destructive commands.

Deliver a diagnosis with evidence, ranked by risk. Then say exactly what changes you recommend and why — I’ll approve each one before you act.

Before closing the module, here’s a quick checklist to review the prompts you just learned—calibrated depth (Tip 3) and explicit limits before acting (Tip 4).