Where this came from: Modules 1.1 to 1.6 followed the video that inspired the course, with a backup in the official doc “Prompting Claude Fable 5.” This module is different: wasn't in the video. This is the result of combing through the documentation for one more question: "Fable 5 is designed for long, autonomous sessions—what else can you do with it beyond the 6 techniques you've already seen?" The answers became the 5 topics below, ending with a checklist that brings it all together.
Asynchronous delegation to subagents
Imagine it this way: you’re a project manager. Instead of doing every subtask yourself, you assign independent pieces to assistants— subagents — and keeps working while they handle their part, intervening only if one of them loses direction.
Fable 5 was trained to work over long, autonomous horizons—and that changes how it handles parallelism. It dispatches subagents more often than previous models, because you can trust them with larger subtasks without having to closely supervise every step.
The behavior change Anthropic recommends is subtle but important: prefer asynchronous communication between the orchestrator and subagents—dispatch and continue—instead of blocking while waiting for each one to return. And, when possible, use long-lived subagents that retain context between subtasks: this saves time and cost through caching.
The orchestrator dispatches and doesn’t get stuck: it continues while the subagents process in parallel and returns the result when they’re ready.
Dispatches
The orchestrator identifies independent subtasks and launches one subagent per subtask, passing along the necessary context.
Works in parallel
Each subagent handles its subtask without blocking the orchestrator—there’s no sequential wait, one at a time.
Orchestrator continues
While the subagents run, the orchestrator keeps monitoring or making progress on other parts of the task.
Intervenes if needed
If a subagent goes off track or lacks relevant context, the orchestrator corrects it or fills in the gaps before the error spreads.
Receives and incorporates
Each subagent’s result goes back to the orchestrator. Long-lived subagents retain context across subtasks, saving time and cost through caching.
Delegate independent subtasks to subagents and keep working while they run. Intervene if a subagent goes off track or is missing relevant context.
Delegue subtarefas independentes a subagents e continue trabalhando enquanto elas rodam. Intervenha se um subagent sair do rumo ou estiver sem o contexto necessário.
Goal: teach Fable 5 to truly parallelize—dispatch and move on—instead of treating subagents as blocking calls.
How to check: paste this into the CLAUDE.md or system prompt and request something with 3+ genuinely independent subtasks (e.g., “review modules 1.2, 1.3, and 1.4 for typos, in parallel”). In the transcript, check whether it starts multiple subagents and keeps monitoring while they work, instead of waiting for them one at a time.
📄 Official context
EN: "Claude Fable 5 dispatches parallel subagents more readily than prior models... prefer asynchronous communication between orchestrator and subagents over blocking until each subagent returns. Long-lived subagents that keep their context across subtasks save time and cost through cache reads."
PT-BR: "Claude Fable 5 dispatches parallel subagents more readily than prior models... prefer asynchronous communication between orchestrator and subagents over blocking until each subagent returns. Long-lived subagents that keep their context across subtasks save time and cost through cache reads."
In one sentence: dispatch independent subtasks to subagents and keep going — blocking while you wait for each response wastes exactly the advantage that parallelism gives you.
File-based memory system
Imagine it this way: you don’t recount everything you learned that day to the next person on shift. You write a note on the fridge. A file-based memory system is just that: one lesson, one note, one time—and the next shift reads it before repeating the mistake.
Long sessions and projects spanning several days run into an obvious limit: a session’s context doesn’t survive its end. The recommended solution is to externalize what was learned in memory files — short notes that future sessions can read before acting, instead of rediscovering the same lesson from scratch.
The golden rule is one file per lesson, with a one-line summary right at the top — designed to be scanned before being read in full. Corrections and confirmed approaches are added the same way, always with the "why" — without the reason, the note becomes an isolated fact that no one knows whether to rely on.
The note is the link between sessions: the person who writes it isn’t the one who reads it. A future session can avoid repeating the mistake only if the note exists, is specific, and remains accurate.
Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, including why they mattered. Don't save what the repo or chat history already records; update an existing note rather than creating a duplicate; delete notes that turn out to be wrong.
Guarde uma lição por arquivo, com um resumo de uma linha no topo. Registre tanto correções quanto abordagens confirmadas, incluindo por que elas importaram. Não salve o que o repositório ou o histórico de conversas já registra; atualize uma nota existente em vez de criar uma duplicata; apague notas que se mostrarem erradas.
Goal: turn lessons from one session into notes that future sessions can consult without rereading the entire history.
How to check: paste this into the CLAUDE.md or system prompt, work through a few real sessions, and check the memory folder: there should be one file per lesson, each with a one-line summary at the top, without duplicating what's already in the code or conversation history.
Bootstrap from existing history
If you already have old sessions but no organized memory, you don’t need to start from scratch by taking notes manually—ask Fable 5 itself to mine the history.
Reflect on the previous sessions we've had together. Use subagents to identify core themes and lessons, and store them in [X]. Make sure you know to reference [X] for future use.
[X] through your memory folderReflita sobre as sessões anteriores que tivemos juntos. Use subagents para identificar temas e lições centrais, e guarde-os em <X>. Garanta que você saiba referenciar <X> para uso futuro.
Goal: distill months of scattered sessions into a handful of reusable memory notes, all at once.
How to check: run this prompt once, pointing to [X] for your memory folder (e.g., .claude/memory/); check whether new files appear that summarize recurring themes from past sessions, and whether later sessions cite those files when relevant.
💡 Practical tip
Don’t duplicate what’s already in the repository or conversation history. If the code or chat already records it, extra memory only creates noise and becomes outdated—write down only what isn’t recorded anywhere else: the lesson, the reason, the fix.
In one sentence: one lesson per file, a one-line summary at the top, update instead of duplicating, delete what’s no longer correct.
The send_to_user tool
send_to_user is an client-side tool: when the model calls it, the interface displays the input text exactly as written — word for word, never summarized or rewritten over — and the turn doesn't finish. The model keeps working right after calling it.
This solves a common problem with long-running agents: the user only sees the compressed final summary after everything is done. With send_to_user, you can send specific information along the way without waiting for the turn to end.
✓ Use send_to_user when
- ✓There is a deliverable partial ready, but the work continues.
- ✓You want to give a progress update with specific numbers (e.g., "I processed 340 of 1,200 records").
- ✓The user asked a question in the middle of the loop and it deserves a direct answer now.
✗ Don’t count on it if
- ✗It’s just "thinking out loud"—that’s turn-by-turn reasoning, not a deliverable for the user.
- ✗The turn is already ending anyway—so the final summary is enough.
- ✗You only defined the tool in the API, without saying in the system prompt when to call it.
💡 Practical tip
Define the tool send_to_user in the API isn't enough. Without an explicit instruction in the system prompt saying WHEN to call it—partial deliverable, update with numbers, answer to a question in the middle of the loop—the model tends to save everything for the final summary, and the tool never fires on its own.
Call send_to_user whenever you have a partial deliverable, a concrete progress number, or a direct answer to a question asked during the task. Don’t wait for the final summary to report these things.
In one sentence: send_to_user sends what’s ready now, without waiting for the turn to end—but only if you explicitly say when to use it.
Rare early stopping in long sessions
In long, autonomous sessions, Fable 5 may — occasionally — end a turn with just an intent in writing ("I'll run the integration tests now") without actually calling the tool that would make it happen. It's rare, but in autonomous pipelines with no one watching, this stray turn can go unnoticed.
The good news is that the mitigation is simple: a "continue" fix the problem right away, interactively. In pipelines without a human in the loop, explicitly reinforce in the system prompt when it’s appropriate stop versus when appropriate act reduces the chance of this happening again.
✗ Weak signal (does not count as progress)
— turn ends here, no tool was called —
It looks like progress, but nothing verifiable has happened yet.
✓ Real action (counts as progress)
→ tool actually executed, result in the transcript —
Only this is evidence that can be audited later (see module 1.4).
⚠️ Attention
This is rare, not a behavioral pattern—but in automations without a human watching (overnight runs, CI pipelines, scheduled agents), a turn of "intent without action" can go uncorrected for hours. Reinforce the distinction between stopping and acting in the system prompt for any autonomous pipeline.
In one sentence: if the turn ended with only a written promise, “continue” fixes it right away; in automation without a human, explicitly reinforce when to stop vs. when to act.
Refactor old skills and prompts
If you migrated skills, CLAUDE.md, or system prompts tuned for earlier models, it’s worth reviewing them before assuming that “more instructions are always safer.” Fable 5’s default behavior is already strong enough that old instructions, designed to compensate for limitations it no longer has, may end up getting in the way instead of helping.
Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. Review and consider removing older instructions if default performance is better.
Skills desenvolvidas para modelos anteriores costumam ser prescritivas demais para o Claude Fable 5 e podem piorar a qualidade do resultado. Revise e considere remover instruções antigas se o comportamento padrão já for melhor.
✗ Opus-era skill
- - Detailed step-by-step instructions for everything, even the obvious
- - “Always explain your reasoning before acting”
- - Style/formatting micromanagement
- - Tasks calibrated "on the safe side" to avoid mistakes
✓ Adapted for Fable 5
- - Remove redundant instructions; trust the default
- - Request structured reasoning through adaptive thinking, not in text (see module 1.2)
- - Delegate style/formatting, focus on the goal
- - Test tasks at the top of the difficulty range
💡 Practical tip
"Start at the top of your difficulty range" (start at the top of your difficulty range) — give Fable 5 5 harder tasks than you would give a previous model before deciding that it "can’t do it." Calibrating too low is the most common mistake people make when migrating.
For long tasks, self-evaluation alone has an obvious blind spot: the same context that made the mistake is the one auditing it. That’s why it’s worth establish a check-in interval and, in the meantime, launch a subagent with fresh context to check the work against the specification—not just reread what’s already been done.
Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification.
[X] at your intervalEstabeleça um método para checar seu próprio trabalho a um intervalo de <X> conforme você constrói. Rode isso a cada <intervalo X>, verificando seu trabalho com subagents contra a especificação.
Goal: catching deviations early in long tasks with a verifier that doesn’t inherit the builder’s blind spot.
How to check: paste, replacing [X] at your interval (e.g., “every 3 edited files” or “every 30 minutes” on a long task); watch whether, when that interval is reached, it actually pauses and dispatches a fresh verification subagent against the spec instead of evaluating itself in the same context.
📄 Official context
EN: "Separate, fresh-context verifier subagents tend to outperform self-critique."
PT-BR: "Separate verifier subagents with fresh context tend to outperform self-evaluation."
In one sentence: review instructions that are too old, start at the top of the difficulty range, and check long tasks with a fresh subagent at fixed intervals.
Quick checklist
A dense cheat sheet to save: it brings together the 6 techniques from the video (modules 1.2 to 1.5), effort and safety (module 1.6), and the 5 from this bonus section (module 1.7). Add it to your CLAUDE.md if you want to bring this into your day-to-day work.
CHEAT SHEET — Prompting Claude Fable 5 (módulos 1.2–1.7) [1.2] Dê o porquê — contexto de intenção antes da tarefa [1.2] Não peça pra mostrar o raciocínio (evita a recusa reasoning_extraction) [1.3] Negative prompting — diga o que NÃO fazer, sem refactor/limpeza não pedidos [1.4] Deixe agir quando já tem informação suficiente; pause só pro que só o humano decide [1.4] Prove que terminou — audite cada alegação contra evidência de ferramenta [1.5] Diga menos, não mais — lidere com o resultado, corte o que não muda a próxima ação [1.6] Calibre o esforço (low/medium/high/xhigh/max) — baixo no Fable 5 ainda rende bem [1.6] Trate stop_reason:"refusal" como HTTP 200, não como erro; configure fallback pro Opus [1.7] Delegue subtarefas independentes a subagents; prefira comunicação assíncrona [1.7] Guarde memória em arquivo — uma lição por arquivo, resumo de 1 linha no topo [1.7] send_to_user pra deliverable parcial/update com números — só com instrução explícita [1.7] "Continue" resolve o early stopping raro; reforce quando parar vs. quando agir [1.7] Refatore skills antigas — comece no topo da dificuldade; verifique com subagent fresco
In one sentence: 11 techniques, 1 cheat sheet — paste into CLAUDE.md and review before starting a long session with Fable 5.
🎓 Module Summary
This concludes the course:
You went through the 7 parts of "Prompting Claude Fable 5"—from launch context to prompting techniques, effort, security, and now the extras for long sessions. Return to the topic 6 checklist whenever you start a long session with Fable 5.