▶ YouTube Summaries

← All summaries

Prompting Fable 5.1: wider prompts, clear end states, default settings

2026-09-22 Tue ⏱ 41 min t3dotgg

Theo walks through Anthropic's "Prompting Claude Fable 5.1" guide and pairs each section with a month of his own heavy usage. The practical thesis: stop micro-managing the model. Prompt wider, state clearly where the task ends, delete your accumulated workaround config, and let the agent verify its own work.

Effort levels

Subscription users get half their weekly limit reserved for Fable, the other half effectively reserved for Opus 5, which Theo rates poorly - so his Fable half runs dry while the rest sits unused. He considers Fable not worth paying full API prices for; Astra isn't better here because it loops and burns usage in dumb ways, while Fable is more willing to stop.

Anthropic suggests benchmarking effort levels against your own evals. Theo says nobody actually does that for Claude Code, so gut-feel it: default to high, bump to xhigh for deep work, almost never use max. Low and medium fail often enough that retrying costs more tokens than starting high. High on a trivial task stays cheap - the model doesn't pad reasoning it doesn't need, though Astra scales effort to task size better. Reserve low/medium for cases where you deliberately want the model to stop early or avoid a rabbit hole.

Behaviour you can just ask for

5.1 deliberately writes far fewer user-facing updates during long tool-call runs than 5 did. Theo doesn't want them - he fires a prompt and checks back later - but if you do, just ask, e.g. a system-prompt line asking for a one-line heads-up before each step and a self-contained recap at the end. He finds it remarkable that this depth of behavioural change is available through plain prose.

Two related notes: if your app hides tool outputs, tell the model, otherwise it stays quiet expecting the UI to show things. And editing earlier messages in a thread now drops access to reasoning traces - an anti-distillation measure.

Prose and formatting

5.1's prose is denser than 5's: longer sentences, fewer breaks. Anthropic's fix is to define "mannered prose" as an anti-pattern, preferably in a user message rather than the system prompt - writing that substitutes metaphor and flourish for direct statement, making the reader work harder so the writer can perform. Theo agrees with the diagnosis and notes you can skip the examples and just say "remove all mannered prose".

Older models overused bullets and bold, so people wrote anti-formatting rules. Those rules now overcorrect. His advice: delete the behavioural instructions in your CLAUDE.md entirely, see how it feels, and add back only what you miss. A wrinkle - recent Claude Code reads AGENTS.md when no CLAUDE.md exists, so stale formatting rules written for cheaper models can suddenly start applying. Use a local override if the team file can't be changed.

Finish the whole task

Fable 5.1 runs very long tasks with little methodology guidance when the goal is clear, but on complex async work it sometimes describes the next step instead of taking it. A nudge fixes it, and Theo finds this happens far less than with Astra.

He leans on skills for this. His babysit-PR skill keeps the model polling a pull request for bot comments and CI, verifying every bot finding against the source before acting, rebasing on main, and replying to feedback it disagrees with - plus two explicit "don't scope creep" and "don't post filler comments" rules added after watching models misbehave.

Two worked examples

The first: a bug in his own T3 Code client. He handed Fable a screenshot and a thread ID, described three symptoms, and asked it to root-cause everything and file one PR. When a contributor claimed their competing PR was better, he told the model to judge for itself - reopen theirs, cherry-pick commits, or finish its own - and to babysit whatever won. It compared both, took two fixes from the other PR, kept the branch modernized, and handled review comments until the PR was mergeable.

The second, explicitly labelled as not for important codebases: swapping his Lakebed cloud's runtime from Node isolates to a forked Rusty V8 engine Astra had written. Rather than merging blind, he asked Fable for an honest verdict. It said no, flagging the one-way-door migration, three features in one PR, and an unproven headline number. Asked how to de-risk, it said staging as configured couldn't catch the scary bug class - silently wrong query results - and listed what would fix that: shadow mode, structured refresh-failure reasons, synthetic traffic, runtime counters. He told it to build all of that on a branch; it worked 60 minutes, then another 94 minutes straight (on medium reasoning), pausing only when Theo asked it to stop hammering his home IP. Afterwards it reported that its own skepticism had been aimed at the wrong risk: differential testing forced 1,400 recomputes across 160 steps with no wrong answers, and the real risk was operational, not correctness.

End states are the key prompt ingredient

The lesson Theo most wants to land: every prompt should name where it stops. "File the PR and tell me when it's up." "Babysit until everything is green." "If you're happy, merge it in and test." He likes prompts that branch - if the model disagrees it comes back to talk; if it agrees it works for 90 minutes unattended - because either way the task leaves his head until it's done.

He also pushes for letting the model verify rather than verifying yourself. Claude is weaker at computer use than Codex, especially on macOS, so he has Fable call Codex to drive the screen or to review changes; he finds Astra the better reviewer and Fable the better writer, so "have Astra verify this" is a routine instruction. The analogy: writing runtime type checks inside a typed TypeScript function. The value of the type system isn't only safety, it's freeing the part of your brain that was watching for that bug class. If you're manually stepping through work the model can do and verify, you're spending brain the same wasteful way.

Smaller tips from the guide

  • You can tell the model what to preserve across compaction, in AGENTS.md or a system prompt, and it honours it.
  • If the model over-reaches into unrequested fixes, Anthropic's instruction to report pre-existing bugs as follow-ups instead of fixing them cuts that substantially with no loss in task success. Theo hasn't hit this much himself.
  • Low effort doesn't reliably trigger search; ask for it explicitly.
  • Safeguard false positives: ask "are there bugs in this program?" rather than "does this compile without errors", give context and docs for obscure languages so the model doesn't start poking at binaries, and keep base64 out of context. He's seen maybe five false positives in thousands of prompts.
  • The lead agent can now keep working while sub-agents run - delegating, messaging them, testing findings - rather than idling.

Reset your mental model, then reset your config

The closing argument, and the part Theo thinks most people miss. Long-time Claude Code users carry workarounds for problems that no longer exist. His example is the "dumb zone" - the fear of degraded output as context fills. Context limits are arbitrary numbers vendors choose; Anthropic picked one million because that's where they judge degradation starts. T3 Code ships no context meter at all, deliberately. With cache read costs cut 75%, compacting earlier mostly just costs you more, since compaction rewrites context.

Generalize it: when you catch yourself doing a step, clicking a button, or tuning a setting because of what you believe models can't do, test the belief. The only Claude Code settings he's changed are full-screen by default and routing through his proxy - plus turning memory off, which he concedes is a real preference. Accept-edits and supervised modes he calls artifacts of 2024: use auto if you're careful, full if you're not.

His recommendation is blunt: pretend you're on a new machine, delete your config, install Claude Code fresh with as little customization as possible, and add things back only as real problems appear. He's skeptical that a clever Twitter tip beats the defaults, and notes models themselves are unreliable narrators about how harnesses and compaction work, so asking Claude isn't a shortcut here.