Theo spends forty minutes inside Anthropic's own Fable 5.1 prompting guide, rebuilding his habits around effort levels, finishing the whole task, and trusting the model's defaults instead of babysitting them.
Fable 5.1 rewards a small set of specific prompting habits, effort-level defaults, explicit end states, and a willingness to stop micromanaging, more than it rewards clever one-off prompts.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You use Claude Code, Claude Fable, or a wrapper built on it (like T3 Code) for daily software work and want to get more out of a subscription plan, not the API.
You've been burned by a model that stalls mid-task, over-formats its chat replies, or writes bloated, over-hedged prose, and want concrete prompt-level fixes.
You maintain a CLAUDE.md or AGENTS.md file full of formatting and behavior rules and haven't revisited it since an older, worse model needed them.
You're curious what it actually looks like to let an agent run for an hour-plus on a real, somewhat risky change instead of supervising every step.
SKIP IF…
You're paying API prices per token rather than using a subscription plan; several of the effort-level tradeoffs here are specific to a fixed weekly usage cap.
You want a benchmark-style head-to-head between models; this is one developer's lived-in workflow opinions, not a scored comparison.
TL;DR
The full version, fast.
Theo reads through Anthropic's own "Prompting Claude Fable 5.1" guide and compares it against a month of daily use, mostly inside his own tool, T3 Code. The core mechanism: on a subscription plan, effort level is the real cost lever, so he defaults to high and treats low/medium as a false economy once you count the redo. The other big shift is trusting the model's end state, telling it clearly where to stop (file a PR, wait for green then merge, ask first) and then not checking in until it gets there, illustrated with a routine PR fix and a risky hour-and-a-half V8 rewrite. His conclusion: most CLAUDE.md formatting rules and context-window anxiety are leftover habits from worse models and should be deleted, not defended.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Theo recaps the accusation that he's biased toward Anthropic, references his earlier Fable vs. Astra comparison video, and frames today's goal: distill a month of daily Fable use plus Anthropic's own prompting guide into practical habits.
02:20 – 03:49
02 · Sponsor: Sentry
Mid-roll read for Sentry, showing a T3 Code demo trace broken down by cost per request chunk and a chat-style transcript view for debugging agent and MCP requests.
03:49 – 05:58
03 · Effort levels and the 50% subscription limit
Theo explains that on a Fable subscription only half the weekly limit is reserved for Fable (the rest goes to Opus, which he calls weak right now), and argues paying full API price for these models doesn't make sense.
05:58 – 10:07
04 · Choosing an effort level
Walking through Anthropic's "consider all effort levels" section, Theo says he defaults to high, reserves x-high for deep work, almost never uses max, and explains why low/medium usually cost more overall once a failed attempt gets redone.
10:07 – 11:09
05 · Batching tool calls and API history edits
A quick note on batching independent tool calls in agent loops, then a callout that editing an earlier message in a thread strips reasoning traces from that point on, an intentional anti-distillation measure.
11:09 – 13:14
06 · Writing density: killing mannered prose
Theo reads Anthropic's definition of "mannered prose", agrees that it's slop even while admitting the guide's own examples are slop too, and gives the one-line fix: tell the model to remove all mannered prose.
13:14 – 14:16
07 · Formatting in chat and cleaning out CLAUDE.md
He covers the doc's advice on bullet/bold overuse, recommends deleting old anti-formatting rules outright rather than tuning them, and flags that Claude Code now reads AGENTS.md when no CLAUDE.md exists, which can surface stale rules written for weaker tools.
14:16 – 18:25
08 · Finish the whole task: the babysit-PR skill and a real bug
Theo shows his babysit-PR skill (only act on comments newer than the latest push, don't scope-creep, don't post filler comments) and a real example: a screenshot-rendering bug in T3 Code where he gave Fable a thread ID and let it investigate, open a PR, compare itself to a rival contributor's PR, and merge the best of both.
18:25 – 29:19
09 · The Lakebed YOLO rewrite
On his side project Lakebed, Theo asks Fable to honestly assess a risky, one-way-door V8-engine rewrite before merging; it refuses and names concrete concerns, so he asks it to build a staging-confidence plan instead. That plan runs unattended for an hour and thirty-four minutes, merges, and spins off three follow-up PRs on its own.
29:19 – 30:19
10 · Redundant checks and trusting the model
Theo compares over-defensive, doubly-checked code to over-supervising an agent that can already verify its own work, arguing both waste effort the tooling now handles.
30:19 – 31:55
11 · Sponsor: General Translation
Mid-roll read for General Translation, covering source-level localization tooling used by companies like Cursor, Ramp, and ClickHouse.
Three quick tips from the guide: tell the model what to preserve during compaction, add an explicit instruction against unrequested fixes and scope creep, and word requests carefully (avoid base64 in context, phrase things as "are there bugs" rather than "does this compile") to cut safety-classifier false positives.
34:31 – 35:02
13 · Sub-agents and vision tools
A short note that the lead agent can keep working while sub-agents run in parallel, and that vision tasks do better with crop-and-zoom tooling.
35:02 – 41:32
14 · The dumb zone myth and closing thoughts
Theo argues the feared "dumb zone" and context-window anxiety are outdated mental models: a 75% cut to cached-read pricing makes window size mostly a non-issue, Claude Code's defaults and permission modes are good enough to leave alone, and developers should reset their assumptions and delete their custom overrides before rebuilding them from scratch.
Atomic Insights
Lines worth screenshotting.
On a Claude subscription, only half your weekly limit is reserved for Fable; the other half covers Opus, which Theo calls not a good model right now.
Theo defaults every Fable task to high effort and rarely touches low or medium, because a failed low-effort attempt just gets redone on high anyway, costing more tokens overall.
Going from low to max effort on a simple prompt barely changes token spend; Fable scales its reasoning to the task size well enough that high is a safe default.
As of Fable 5.1, the model writes far fewer user-facing progress updates during long tool-call turns, so if you want a running commentary you have to explicitly ask for it in the system prompt.
Editing an earlier message in a Fable thread strips the reasoning trace from that point forward, a deliberate anti-distillation measure from Anthropic, not a bug.
Anthropic's own term for AI-flavored writing is "mannered prose": prose that substitutes metaphor for a direct statement so the writer can perform instead of communicate.
You can kill most of a model's mannered writing by adding one line to a system or user message: please remove all mannered prose.
Deleting behavioral formatting rules from an old CLAUDE.md or AGENTS.md and testing without them often works better than tuning the rule, because small nudges can overcorrect a model from doing something 50% of the time to essentially never.
A recent Claude Code update reads AGENTS.md when no CLAUDE.md exists, so old formatting rules written for weaker tools like OpenCode or Codex can suddenly start affecting Fable unless you add a CLAUDE.md that overrides them.
Without an explicit nudge to finish the whole task, Fable sometimes describes what it would do next instead of doing it; telling it to keep going fixes this more reliably with Fable than with Astra.
A babysit-PR skill that tells the model to only act on comments newer than the latest push, verify findings against source, and never scope-creep turned pull-request review into a fire-and-forget task.
On a real T3 Code bug, Theo gave Fable a thread ID and a repro, and it opened a PR, compared itself against a competing contributor's PR, and merged the better parts of both without further direction.
For a genuinely risky one-way-door change (rewriting a database engine's runtime), Theo asked Fable to review the plan before merging; it refused, named three concrete concerns, and proposed a staging-confidence plan instead.
That refused, then-de-risked change ran for an hour and thirty-four minutes unattended on medium reasoning, merged, then opened three follow-up PRs on its own.
The redundant defensive checks people still add after a typed function are the same instinct as babysitting an agent step it can already verify itself; both waste effort the tooling now handles.
The 1-million-token context window and the so-called "dumb zone" matter less than developers assume, because a 75% cut to cached-read pricing means the window size barely affects cost anymore.
Theo has changed almost nothing in his Claude Code config beyond full-screen mode and a proxy layer, arguing the current defaults are tuned well enough that most manual overrides are now out of date.
Base64-encoded content in a prompt tends to trigger Fable's safety classifiers because it reads as an obfuscation attempt, so avoiding it in context reduces false-positive refusals.
Takeaway
Six habits that make Fable 5.1 earn its keep.
PROMPTING HABITS
Fable 5.1 rewards a short list of specific habits, defaulting to high effort, naming an explicit end state, and deleting stale formatting rules, more than it rewards clever one-off prompts.
03Effort levels and the 50% subscription limit
On a subscription plan, only half your weekly limit covers Fable; treat low/medium effort as a false economy since a failed low-effort attempt usually gets redone on high anyway.
04Choosing an effort level
Default to high effort and reserve x-high for genuinely deep work; going from low to max on a simple task barely changes token spend, so high is a safe baseline.
05Batching tool calls and API history edits
If you want running commentary during long tool-call turns, ask for it explicitly; as of 5.1 the model writes far fewer unprompted progress updates than it used to.
Editing an earlier message in a thread strips the reasoning trace from that point forward on purpose, an anti-distillation measure, not a bug to work around.
06Writing density: killing mannered prose
Anthropic's own term for AI-flavored writing is mannered prose, writing that substitutes metaphor for a direct statement; one line, please remove all mannered prose, fixes most of it.
07Formatting in chat and cleaning out CLAUDE.md
Delete old anti-formatting rules from your CLAUDE.md instead of tuning them; a small nudge can overcorrect a model from doing something half the time to almost never.
Check whether your repo has an AGENTS.md with stale rules written for weaker tools; Claude Code now reads it when no CLAUDE.md exists, which can surface those rules unexpectedly.
08Finish the whole task: the babysit-PR skill and a real bug
Without a nudge to finish the whole task, the model can describe its next step instead of taking it; telling it to keep going fixes this more reliably with Fable than with rival models.
A babysit-PR skill that only acts on comments newer than the latest push, verifies findings against source, and bans scope creep turns pull-request review into fire-and-forget work.
Giving the model a thread ID and a repro for a real bug let it investigate, open a PR, compare itself to a competing contributor's PR, and merge the best of both unsupervised.
09The Lakebed YOLO rewrite
For a genuinely risky, one-way-door change, ask the model for an honest merge/no-merge verdict first; a good answer names concrete concerns instead of rubber-stamping the plan.
A refused, then de-risked change can run unattended for over an hour and still land cleanly, including follow-up PRs the model opens on its own once the main change is in.
10Redundant checks and trusting the model
Redundant defensive checks after a typed function are the same waste as over-supervising an agent step it can already verify; both spend effort the tooling now covers for you.
Tell the model explicitly what to preserve when it compacts a long thread; without that instruction it can drop details you actually needed kept.
Add one instruction against unrequested fixes and scope creep and unrequested additions drop substantially with no measurable hit to task success.
Avoid base64-encoded content in context and phrase requests neutrally (are there bugs in the program, not does this compile) to cut safety-classifier false positives.
13Sub-agents and vision tools
The lead agent can keep working while sub-agents run in parallel instead of sitting idle, and vision tasks do better with crop-and-zoom tooling than a raw full-frame screenshot.
14The dumb zone myth and closing thoughts
The context window and the feared dumb zone matter less than assumed; a 75% cut to cached-read pricing has mostly removed the cost penalty for a large window.
Most manual Claude Code config overrides are now out of date; reset your assumptions, start from defaults, and only add back the small things that solve a problem you actually have.
Glossary
Terms worth knowing.
Fable
The Claude model (Claude Fable 5.1 in this video) that Theo uses for daily coding work, referenced throughout via Anthropic's own prompting documentation.
Astra
The competing model Theo benchmarks Fable against throughout the video for reasoning-token efficiency, task persistence, and code review quality.
Effort level
A setting (low, medium, high, x-high, max) that controls how much a model reasons before answering, trading latency and token cost for output quality.
Mannered prose
Anthropic's own term for writing that substitutes metaphor and flourish for a direct statement, making the reader work harder so the writer can perform.
CLAUDE.md / AGENTS.md
Repo-level instruction files a coding agent reads before making changes; Claude Code prefers CLAUDE.md and only falls back to AGENTS.md when no CLAUDE.md exists.
Compaction
The process of summarizing an ongoing conversation so it fits back inside the model's context window once it starts running long.
The dumb zone
Developer slang for the point deep in a long context window where a model is believed to visibly degrade; Theo argues it matters far less than people assume.
Shadow mode
Running a new code path alongside the existing one in production without serving its results, used to compare behavior safely before a full cutover.
Babysit-PR skill
A saved instruction set that tells an agent to keep monitoring a pull request for new review comments and CI results and act only on what's newer than the latest push.
Distillation attack
Using a model's exposed reasoning traces to train a cheaper copycat model; it's why editing earlier messages in a thread strips the reasoning from that point forward.
Reserve funnel for compaction
Telling a model what specific facts or state to preserve when it summarizes a long thread, so nothing important gets dropped during compaction.
Resources
Things they pointed at.
00:15linkTheo's Fable vs. Astra comparison video
04:24linkPrompting Claude Fable 5.1 (Anthropic's official doc)
18:25productLakebed (Theo's self-hosted-cloud side project)
14:35toolbabysit-pr skill
15:00toolleaving-pr-comments skill
37:25toolCodex (used for computer-use verification)
Quotables
Lines you could clip.
00:10
“Sam Altman just called me an anthropic fanboy, specifically because of how much I prefer using Fable over Astra for my day-to-day work.”
cold-open hook, names the stakes immediately→ TikTok hook↗ Tweet quote
15:38
“please remove all mannered prose”
the exact one-line prompt fix, quotable and copy-pasteable→ newsletter pull-quote↗ Tweet quote
28:30
“My skepticism was in the right place, but aimed at the wrong thing.”
the model's own self-assessment after the Lakebed rewrite, a strong beat of the story→ IG reel cold open↗ Tweet quote
29:50
“You're wasting part of your brain if you're doing these steps with the model.”
the thesis of the redundant-checks bit, blunt and provocative→ TikTok hook↗ Tweet quote
35:18
“The dumb zone doesn't matter that much.”
contrarian one-liner against a widely-believed developer myth→ TikTok hook↗ Tweet quote
40:00
“Reset it. Pretend you're on a brand new machine.”
clean closing instruction, works as a standalone tip→ newsletter pull-quote↗ Tweet quote
41:29
“peace nerds”
sign-off, works as an outro tag→ IG reel cold open↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphorstory
Just a few months ago, people were accusing me of being paid by OpenAI because I liked the models they were shipping that much. I thought that was kind of insane. What's even more insane, though, is the fact that Sam Altman just called me an anthropic fanboy, specifically because of how much I prefer using Fable over Astra for my day -to -day work.
There are a lot of reasons for this, and I cover a bunch of them in my Fable vs. Astra video, but that's not what I want to rehash today. In that comparison video, I vibed out a graph showing how I feel the quality of the output I get from the models differs, where Astra can be way higher than Fable at points, but way, way worse at others.
Fable still makes its mistakes, but it was less noisy by far. That comes with benefits outside of trusting it more. It means the model can go longer and do more in a given pass.
It means you can tell it to come back with a video when it's done. actually can do that it also means that the little dips it does have hurt more and finding ways to reduce them is incredibly valuable i've spent a lot of time with this model it's probably the most i've ever used a model that i was paying for in such a short window i have shipped so much code with this model it's insane and i've been burning my five accounts to the ground using it i wish i hadn't burned as many of them as i did before reading this particular guide from anthropic because the prompting claude fable 5 .1 doc is actually really good and has a bunch of insights that are worth learning from.
The goal of this video is to try and take all of the things I figured out over the last month ish of using the model and distill it into the most useful pieces of info I can possibly give you everything from how to fix your agents MD to how to give the model the tools it needs to keep going and get better results to even using codecs to help make your cloud outputs better.
But as I mentioned before, I'm paying for these accounts myself. And if I'm going to need another I hope you can understand why we're doing a quick sponsor break.
There's a pretty good chance your company is shipping more code than it's ever shipped before. This also means you're probably shipping out more bugs than ever before. And those bugs are getting more insidious and harder to find, especially when you're building things with agents, not just using agents to build, but also serving agents to your users.
If you were around before agents, you've almost certainly heard about Sentry. And honestly, if you've been around since, you have too, because these guys are the go -to platform for identifying bugs in your real world applications. I've had Sentry set up on pretty much every code base I've worked in in the last, I don't even want to think.
about how many years God have been around for a while. Needless to say, these guys know how to find bugs in your apps, and the Sentry MCP makes it so your agents can use that same data as well. But I'm not just here to tell you that Sentry exists.
You probably already know that. I'm here to show you the really cool things they've set up for building with agents. I set up a demo in T3 code to get some traces, and goddamn, the info we get is so, so useful.
They break down the cost of the whole request, and even better, the cost of each chunk within the request. This timeline view is super helpful for figuring out what happened when and where the costs were so we could see that this top level request cost 40 cents or so but more importantly we could see where all that money went and if you're not that into timeline style views i understand it doesn't really map to my head very well especially when you're used to using a chat view for actually doing these things for those who weren't watching i just transitioned over to the chat view that they built into their agent platform yes you can actually see a transcript for the back and forth that your agents or your users or whoever else had that led to these issues And if I slide this over, you can see all the additional info from how many tokens were used, how many errors were hit, and how much the request actually cost to run.
And as you scroll, you can see how the user experienced this with the timestamp showing when different things happened, what worked, what didn't, and the actual cost of everything the user ends up seeing. This is particularly useful if you're building custom tools and interfaces like an MCP that your agents are working with, because you can debug not just what the model sent to the MCP, but the whole pipeline and all the code that actually serves that agent's request.
quest. Figure out what your agents and your code are actually doing at soydev .link slash sentry. I'm going to start with the official prompting guide because the amount that's changed with 5 .1 to 5 is meaningful, but it's almost all subtle things.
So it's worth going through. The first section they have is titled consider all effort levels. I find this one a little cringe because it forgets the fact that we only have 50 % of our limit as a subscriber.
And I'll be real up front with this. I don't think Fable is worth the money if you're not getting it subsidized through a subscription. Paying the full API price just kind of sounds insane to me.
I don't think Astra is much better here, sadly, because Astra can often get stuck in a loop and end up spending way more than it should. Fable is at least a bit more likely to stop when it should. So on a median task, Fable is definitely more expensive.
But on the extremes, I find that Astra can just burn usage in stupid ways. Now I've that out of the way, I want to make sure it's clear what I'm talking about is subscription usage, because I just I don't think it's worth using any of these over API prices. And that's also why a lot of companies probably aren't letting you use these models.
And for that, I am sorry, assuming you're on a subscription, you have half your limit reserved for fable and the other half of your weekly limit can be used for whatever else. That other half effectively is then reserved for Opus 5, which is not a good model. Thankfully, it does seem 5 .1 or 5 .2, whatever they call it, is coming soon for Opus, which should hopefully, fingers crossed, make it way less spiky.
But it's bad. I usually find myself at the end of a given week with most of that other 50 % left in my fable driven to zero. Now that we have that context, I want to talk about the consider all effort levels call out here.
They highly recommend that you try out other effort levels that you start at high, but then you test other ones against your own evals. No one's evaluating how this works in cloud code quite to that level. It is nice to get a gut feel to like take a task that you know how it should go and ask this model to answer it or solve it at different effort levels to see if it can figure it out.
But that ends up being a lot of effort and burning a lot of tokens. So I honestly recommend just kind of gut feeling it. That said.
I have not had as good of an experience with Fable on low and medium as I have with high. So I personally kind of just default to high. On really deep, thorough things, I'll bump to X high occasionally.
I almost never use max unless I'm just trying to burn a limit. But I found that high and X high are plenty for most things. With low and medium, I find that it's likely enough to fail on those reasoning levels that I...
Try to avoid them just because it ends up being more tokens if you have it do the task on low and it fails and then you redo it on medium or high. I'd rather just have it run the thing and come back with a result. It's also worth noting that if you use high on a simple task, it's not going to be that expensive because it is not going to just use and waste more reasoning if it doesn't need to.
Here, I'll even go crazy here. I'll use max reasoning for this. Hi, how are you doing today?
Really complex prompt. We're about to send it. Wow, it thought for so long there.
That was horrible. Yeah, you get the idea. Going from low to max, if it's a simple task, it's going to stay simple.
It's not going to waste a ton of tokens. It's not as good with the adjustment based on task size as Astra is, but it's good enough that I don't feel like I'm wasting too much when I use high when I shouldn't. I will say Astra is even better at this where I had a benchmark skate bench where I couldn't get the model to use meaningfully more tokens on max than it used on low.
It was like a 50 token gap. So like 130 to 180 or so at worst case, like it doesn't do a whole bunch. Meanwhile, Gemini 3 .1 Pro will do like a thousand plus reasoning tokens for that same task in the same bench.
So Astra adjusts its usage of the window it's given better based on the size of the task. Fable still does it well enough that I'm fine just leaving it on high. I'm going to switch it back from max to high before I forget to.
Generally speaking, only use low and medium if you specifically want the model to stop earlier or not go too deep. Or if you know the thing's a rabbit hole and you want to try and keep it from falling down the rabbit hole, lower reasoning levels can help a bit. I just leave it on high at this point.
The reason I brought up the limits thing is simply because if I had the whole 100%, low and medium would be more interesting. But the things I'd use low for... I'm just going to deal with Opus 4 from really trying to maximize my usage of the subs.
The next part is one of the ones that interested me the most, so much so that it kind of inspired me to make this video. Ask for user facing progress updates. Funny enough, just a couple of days ago, Julius asked me why Fable wasn't giving him traces on why it was doing things in my version of T3 code that he was trying.
And I said, oh, that's because it doesn't do that unless you ask it to. And then he asked it to and it did. Models like Opus and Fable 5 both love to give reasons and updates when they were doing things.
Every time it was going to do a tool call or a new batch of work, it would say, okay, I found this, so now I'm going to go do that. And the result was kind of noisy, to put it lightly, and they decided to make it stop doing that. As of 5 .1, the model is writing way fewer user -facing updates during long tool call turns that Fable 5 would have written updates for instead.
I've seen this too. I can't tell you how many times I had Fable just go off and do like 150 tool calls without giving me an update. And you know what?
I don't care. I don't want that info. I just want to see it when it's done.
That's how I operate now. I kick off a prompt using T3 code, command shift O, enter for the repo, tell it what I want, and then go check another thread after. That's just how I work.
So I don't care about this. But if you do, and you want to get these updates, there's a really simple solution. Ask for them.
I do legitimately think this is awesome. It's crazy the models are smart enough and trained well enough that you can get this type of deep behavioral change by just asking. You could add something in the system prompt like, before you start, say in a line what you're about to do.
Brief updates while you work help the user follow along. Close with a short recap that stands on its own. M -dash, what you found, what you did, and what's next, M -dash.
So a reader who only sees the last message has the full picture. The fact that you could steer your experience with cloud code these ways with prompts, I just think that's super cool. If you're building an app or product that closes tool outputs, you should tell the model because otherwise it won't show things because it expects the UI to show it.
We should actually probably put this in T3 code because we don't show tool call outputs because they're almost never useful. There's a call out in here about some API changes. In particular, if you edit your history, they're going to prevent you from having access to reasoning traces.
So if you have four messages in a thread and you edit something in the first or second message, it's no longer going to maintain the reasoning for that thread because it could be used for distillation attacks. On one hand, kind of silly. On the other hand, this is how they are.
They really want to prevent distillation. We're going to see more weird things like this going forward. You get the idea.
The next section is fun. writing density. This is another one of the ones where I think it's really cool that you can prompt for it.
They called out that Fable 5 had problems with its formatting of text. It's the classic clod slop that we all know and hate. Fable 5 .1 is meaningfully better.
They said that it's generally a step up from earlier clod models with fewer stock phrases and less unexplained jargon. In some cases, though, its prose is denser than Fable 5's. Its sentences run longer and there are fewer paragraph breaks.
You could add to your system prompt a definition of mannered prose as an anti -pattern in order to help the model be less likely to talk in the ways you don't like. They say that you could even add it as a user message or to the system prompt, but user message is the preferred way, which is interesting. Mannered prose substitutes metaphor and flourish for direct statements.
Instead of, quote, a parameter worth varying, the mannered writer would produce, quote, a dial worth turning. Instead of this point still matters. They write, this point earns its keep.
The phrase exists to display the writer, not to convey the idea and the reader can tell. This is why mannered prose irritates. It makes the reader work harder so the writer can perform.
Yep, yep, this is slop, but I very much agree here. It makes the reader work harder so the writer can perform. If you don't want to write all this in your system prompt or use the admittedly not good examples, just say, please remove all mannered prose.
The next section is fun. It's about formatting. They call it that earlier models would overuse bullets in bold in chat.
And many prompts had a bunch of anti -formatting rules written to hold that down. I've seen a lot of system prompts with things like don't use bullet points or bold or use them less. If the model used it half the time and you use that to tone it down, it might go from 50 % of the time to 10%.
But if the model does it 10 % of the time and you have that same thing in there, it might knock it down all the way to one, which you probably don't want. Generally speaking. any behavioral instructions that you have in your cloud md are worth deleting and reconsidering see how it feels to not have them at all and then adjust over time as you need so if you have a quad md or an agent md that is a bunch of these instructions around formatting delete them for now i have nothing like this in my agent md or quad md and it's been pretty nice to work with Also of note is that the latest update for Cloud Code will actually use your AgentMD file instead of only touching CloudMD.
It only does this if there isn't a CloudMD, but this means if you have an AgentMD in your repo that has a bunch of formatting suggestions, rules, and all these other things that isn't actually helpful for Cloud, but was helpful for maybe you're using some old, cheap, or dumb models and tools like OpenCode or Codex. That might not have been picked up if you were using Fable and Cloud Code before, and now suddenly it is.
Make sure your agent MD doesn't have those types of things in it if you don't have a Claude MD. And if you're in that case and the team won't let you make changes, do a Claude local MD or something to specify, ignore all that. This one is somewhat silly, but worth noting.
The model has a bad habit of quoting and reproducing passages from source text without marking it as quotations. If you do run into this and you want it to mark quotes better, you can absolutely do that by giving it an example of how to mark quotes better. Not a big thing unless you're building things around Fable, I would assume, but worth knowing.
Here's where we start getting into the meat and potatoes, the actual useful stuff. Finish the whole task. Fable 5 .1 can execute very long tasks without much guidance on methodology, especially when the goal is clear.
On complex asynchronous workloads, though, nudge it not to end its turn before the work is done. Without the nudge, the model sometimes describes what it would do next instead of doing it. like quote next i will do this thing and then you tell it okay go do it for what it's worth i have found that fable does this all significantly less than astra does where it doesn't just stop it usually will go where i want it to but it's relatively easy to get it to keep going with like basic changes to your prompting or maybe even a skill or two For example, here's my babysit PR skill.
This is a skill that gets invoked when I tell the model to watch or babysit a pull request. The point of this skill is to keep the model checking for updates for new comments and make sure by the time I go check the thread, it's good to go. The skill's contents are actually quite simple.
All the repos we work in have various AI review bots. They're helpful even if they're not always right. If your harness offers a tool to monitor the PR, use them so you can respond when comments arrive.
Otherwise, pull it for new comments and checks. Only act on checks and comments newer than the latest push. Verify every bot finding against the source before changing.
Fix real findings and CI failures, distinguish repository, yada, yada, yada. Keep an eye on changes to main and rebase when needed. If an overlapping PR makes this one obsolete, stop monitoring, report it to the user, and ask before closing the PR unless closure was explicitly authorized.
If a review bot leaves feedback you believe is not worth addressing, reply with a written response and resolve the comment. Use my leaving PR comments skill for every comment posted on Theo's behalf. This is just a skill that tells it how I like comments formatted and to like put a little disclaimer at the top that an AI agent wrote it.
I noticed a couple models, specifically Sol, had a habit of scope creeping when the babysitting happened. So I put a call out saying, please don't scope creep. Stop adding new things.
Only address real shortcomings. And also don't post filler comments, because I had a lot of agents that were just leaving comments when they didn't need to. These two callouts at the end were added to fix that, and this worked pretty well.
So now when I have a thing I want the model to fix, and I am relatively confident in its ability to fix it, I will specifically say that in the prompt. Here's a real world example of what I mean here. I noticed when I was using T3 code that I was having some issues with a model trying to take screenshots and render images.
I could have investigated more deeply, but it happened when I was using Fable on my computer with T3 code, so I figured I'd just ask Fable on my computer with T3 code. I gave it a screenshot in the thread ID, said, figure everything that went wrong in this particular thread in T3 code, and file a pull request to fix as much of it as we can on the T3 code side.
The image should have rendered and it failed to. The model should have been able to access the preview image through the preview environment and it couldn't. It seemed to have some issue with saving as well.
You should be able to see all the tool calls, what failed and everything else using the ID that I left above in the T3 code history on this machine. Figure out what the root causes are and fix as many of them as possible. File a single PR that clearly and simply addresses the issues.
It opened my PR and this is an interesting one because somebody started commenting on it immediately. Like, no, don't do that. Mine's better.
So I said, accordingly, someone is claiming their PR that we closed might be better than mine. You should take a look and see if that's the case. If so, reopen it and finish it, or just take the commits and start something new.
If ours is better, finish modernizing it and get ready to go. Babysit whatever ends up being put up as necessary. That's the key part at the end.
I gave it the freedom to do what it decided based on the data that it had and the PRs that existed to choose between these options. And this is another one of those things that has changed a lot for me. spending less time trying to choose from the options the model gave me, and more time trying to give the model everything it needs to make good choices.
It gave a summary with the verdict on the PR from this other contributor saying that this was a better base, but his PR has a different feature, save to disk. Its final design is the same as the save half of this one, but this one also has two failures that broke the thread that it found, and then it took two things from the other PR and fixed the bugs that it discovered.
It modernized, which is another skill that I have to keep the PR up to date on top of main. It kept dealing with review comments. Then I came over and I saw that there was no new findings.
Realized the PR is probably mergeable. I could have told it to merge when it was ready, but it was easier to just click the merge button, which I did and settled the thread. This next example is not meant to be a thing that you do in your day -to -day work on like a real big important code base because it's dangerous.
If you have really good systems for staging environments and QA and testing before things go out. maybe play around with these types of workflows because they are super super fun but know what you're getting into the models might not be quite where they need to be to do this type of thing yet but they're pretty damn good at it so it's worth trying i do see a future where everybody even people working on giant expensive important code bases with hundreds of co -workers and millions of users will start behaving similarly if the models get reliable enough we're like were surprisingly close.
This is one of the more fun YOLO tasks I did. I was working on Lakebed, which if you're not familiar with, is my attempt to make a better slop cloud for slop apps. And I built my own runtime again.
And when I say I built, I mean that I forked Rusty V8 with Astra and did some stupid things. It's only 26 ,000 lines of code, surprisingly. So not too, too bad, all things considered, but it is half the code for my cloud, roughly.
It is what it is. There's now a lot of rust in my JavaScript slot project. But this obviously is a scary change.
To make it so my user's code runs on my own engine instead of standard node isolates was terrifying. Instead of just blindly merging Astra's crazy work here, I asked Fable what its thoughts were. I took a screenshot of the claims Astra had alongside the PR and said, is this ready to merge?
Give me your honest thoughts. It's a big, risky, scary change, but it will help performance a lot. It said no, and it called out its concerns.
The one -way door nature, because the migration can't really be undone. Three features being introduced in the single PR. No human approval yet.
Yeah, I'm the only person in the code base. Default flipped to native. So now the source runtime being native is potentially a kill switch depending on how you're running things.
That assumption doesn't really matter here, but called it out. It said the headline number does not prove live queries. It's a huge part of how the app works.
And there were some unexplained failures. I asked directly, how can we de -risk this or test the changes to make sure it's relatively safe? I'm not too worried about existing deployments because we're not officially released yet.
Again, this is a strategy that works because it's not really an important service yet. I've been using Lakebed as my experimentation playground and sandbox to try these new flows and I've been blown away with how surprisingly good they are. It had a bunch of things it wanted to do for a proper soak testing.
I said, screw it. What if we just merge and deploy on staging? If I had two environments set up, one was staging and one was prod, would you confidently be able to debug behavioral changes in the staging environment?
Again, what I want is to have confidence in shipping this change. It said it could partly debug crashes, latency, and resource problems in staging, but it couldn't confidently debug wrong query results, and that's the scary class of bug. This is a really good call -up that I put in bold on the top.
I was actually really pumped that Fable made this so clear and easy to digest for me. It's so readable too, by the way. Like it's, this is super easy to digest what it is saying and what it's concerned about.
Here's why and what fixes it. Staging today gives it railway logs and metrics, engine crashes, the health ZN point and axiom events if we have them enabled. It doesn't have signals when maintained views are wrong, no reproduction paths and no traffic.
It was a pretty dead staging environment. So what would make staging enough? A shadow mode, a structured reason on refresh failures, synthetic traffic on staging, and runtime counters on health C.
So I said that it should make a new branch on top of the existing one that builds out all the changes and confidence boosts that it would like to introduce in order to get the info it's looking for. The reason I said that is both like, I'm okay with it shipping things I don't necessarily want. These PRs are going on to a long -lived branch that isn't super important if we decide not to merge it.
But also I gave it a brief read over here and all the things that suggested sounded reasonable. 16 minutes later, I had a new branch built and on top of my crazy overhaul rewrite, described all the things it added. I don't really care.
It did not open a PR because I didn't ask for one, which was a little annoying. I thought I had said that, but I hadn't. So I told it immediately.
Make a PR opened on top of it. And it did. I said, it looks good.
Do you think that that's all we need? And can we get started testing? If so, merge 280 to 200 and then merge it all the way in.
You could tell it worked because it then worked for an hour and 34 minutes. The only reason I came back is that I noticed that my network performance was starting to have problems and the box I was running this on was starting to have problems too. Also worth noting, I was on medium reasoning for this apparently, and it still was willing to work for an hour and a half straight.
I told it, hey, can you stop doing this the way you are? It's destroying my IP address and effectively DDoSing. Maybe you can just spin up another container and hit from there.
I don't know, but just stop abusing my IP address. Everything's merged, soaked, and restored. You're right about the laptop approach.
Here's the full picture. It merged these. It then made three additional PRs in order to fix different things that it needed.
It said that using my laptop was wrong and gave details as to why. Said the current state of things. Called it the shadow mode is not free, so we're slower because of all the shadowing we're doing.
I said, how do we turn off shadow mode the easiest possible way? Seems like this is working well so far. And I want to get real numbers for how much better the performance is here compared to current production builds.
Don't worry, that IP address got cycled forever ago. Shadow was already off, so nothing to change. Yada, yada, yada.
It worked for 42 minutes. Did a bunch of calls. Found the performance improvements.
And then we get more into prompt etiquette here. The way I'm prompting here is going to drive half of y 'all or more insane. It works.
I'm not saying I'm super smart for this. I'm saying I'm kind of dumb, but it's surprising that this is as useful as it is. How do you feel about these changes in the end?
You spent a lot of time with them, and I know you were skeptical initially. Was this a good thing to merge? My skepticism was in the right place, but aimed at the wrong thing.
I worried about wrong query results since that class of bug is silent. It turned out the incremental path is careful to the point of paranoia. It reseeds on any doubt.
A delete, a range change, a journal gap, a budget miss. The differential test forced 1 ,400 reseeds in 160 steps and never got a wrong answer. It treated the size of the diff as the risk, but the real risk was operational.
Yada, yada. It was actually good. useful data like this taught me a lot about what these changes were what the risks were and what we did to fix it i understood the code better than if i had wrote it myself at a point i did notice it call out other things here though so i said it sounds like you have other changes you want to make can you file a pr making those changes for me file 212 the engine pre -warm then i told it to babysit it's got comments coming in merge it once you've got everything green and you're happy with your changes and that was it i never saw the thread again this is different from how i know a lot of people prompt and i know lots of code bases doesn't work i'm trying to show what you can do if you have enough confidence in the model and its ability to verify its work you could do this in smaller and simpler cases for things like ui changes if you make a couple small adjustments to what the harness has access to I do still find that Claude isn't the best at computer use compared to Codex, especially on macOS.
So if you have a Codex sub, even like a cheaper one, set up and on your computer, you can have Fable call Codex to do the computer use stuff to verify results. You could also have it call Codex to confirm the work it did. I often find that while both Fable and Astra are incredibly thorough and thoughtful with what changes they recommend and how they review things, I found Astra to be a slightly better reviewer.
than Fable. But obviously, Fable is a much better writer of code than Astra. As such, I often will have Fable just go ask Astra to give it feedback on some changes or to go test the changes it made in order to verify the results.
I'll sometimes just say, hey, can you have Astra verify this? And it will. And if it fails to or it says something bad, it'll update the code accordingly, then test it again and not come back to me until it has results it's happy with.
if you built your mental model for what agents can do before we had models as good as fable 5 and as consistent and reliable as 5 .1 i would highly highly recommend resetting your brain a bit and trying again i have a feeling you'll be surprised at how well these models can stay on task one of the key things i want to make sure you guys take out of how i'm prompting is the end states i make it clear to the model where i want it to be done sometimes i'll say i want you to babysit it till everything is green sometimes i'll say i want you to wait till it's green then merge it sometimes i'll say file the pr and tell me when it's up depending on the task i want different things and i tell the model where i want it to be done that's an important thing to think about if you're finding that you're not getting as much out of the models and they're not doing what you want them to, really think about where you want the end state to be.
Every prompt should have a pretty clear place where it stops when it's done. This one, for example, I said clearly, merge it once you've got everything green and you're happy with your changes. This one I said, can you file up here making those changes for me?
This one I asked a question and I also said, if so, merge these things in and test it. This one I actually really like because I kind of created a... couple paths that we can take if it isn't happy that it can tell me that and we can talk about it if it is happy then it will start working i have to come back i'm trying to minimize the amount of times i go back to a thread until the work is done and here i gave it those two options option one is that it's not happy and it has more things we can talk about and work on option two is that it will keep going for an hour and a half straight without my intervention and once i've done that it's out of my head and it stays out of my head until i see the little marker in t3 code telling me to go back to it i really don't think you're seeing the benefits of fable if you're not prompting a bit wider these ways letting the model start a bit earlier and then go a bit longer giving it options for different paths it can take depending on what needs it decides on i feel like the way a lot of y 'all prompt kind of looks like this where you've defined a function that takes in a number and then you still check if it's a number or not
Like the model can do these checks itself. It knows how to do it. So it's a lot easier to let it just do the thing.
If the model knows what does or doesn't work, if it can check things for you, you should let it do that. Because if you're not doing that, you're not really taking advantage of the benefits these models give you. The value of TypeScript isn't just that TypeScript makes your code safer.
I would argue the bigger value is actually different. Once you remove this class of bugs, that part of your brain looking for them is freed up and it can be used for other more important things. If the computer can do the work of verifying the type safety across your app, then you are not using your brain well if you're letting your brain do that same work.
If the model can root cause a bug, fix it, verify that it's fixed, film a video showing the results, put up a pull request, monitor it to address all the review comments as they come in, and then tell you when it's done. If you're going through those steps with the model, you are the same person as the one who would write the type check after the type check in a TypeScript function.
And to be clear, I'm not saying the code is wrong. In fact, in certain cases, as great as TypeScript is, it is important to know if that thing is exposed externally, that it's being called the right way. There are times where it makes sense to write the same thing twice.
There are times where it makes sense to waste some of your brain to quadruple check that. I don't think it's as common as y 'all believe. It straight up just isn't.
And having lived through the era where TypeScript happened, there were a lot of people who wrote code like this when they absolutely didn't need to. You're wasting part of your brain if you're doing these steps with the model. We got a couple more small tips and one more real big one at the end.
So make sure you stay tuned for that. But real quick, we got to do a sponsor break. We're going to cut to the chase.
If your app isn't localized in various different languages, it's probably losing a bunch of potential users. It turns out that over 85 % of the world doesn't speak English. So if that's your only language, you're kind of screwed.
I've talked to a lot of people and I've noticed their apps tend to be in one of three different states. Either it's just one language, English, or they've built their own crazy translation stack to try and handle this all themselves. And they're constantly dealing with things like words being used one way in one place in a different way in another, inconsistency across their different apps and websites and platforms, stuff like that.
Or they're in group three. Group three is people who use today's sponsor, General Translation. That group includes companies like Cursor, Ramp, Partyful, ClickHouse, and more.
And there's a reason they're all using General Translation. They made it as easy as possible to manage your localization across all of the services that matter, whether it's your blog and your docs, or it's your mobile and web app and more. General Translation does this on a source code level, integrating directly with code your agents are already writing which makes it easy both to define the things that are needed and to export them before the localization.
The platform is where things really become magical though because you can define a glossary of terms that need to be consistently used the same way across different surfaces. Once you have this set up your agents will just write translatable code automatically and it is as simple as filing a PR and the CI will kick in and get things going.
Serve your app to the rest of the world at soydiv .link slash gt First one we have here is that you can tell the model what to preserve in compaction summaries. Generally speaking, I think people overthink compaction.
But if you've noticed the model isn't keeping certain things that you want it to or that it's losing track of stuff, you can add that to your agent MD or if you're building an application with Fable, you can add it to your system prompt. Since Fable is doing the compaction for your Fable threads, if you tell it what you want it to maintain in the compaction, it is actually capable of remembering that and doing it, which I think is really cool.
Anthropic calls out that the model can sometimes do things like change files it shouldn't, fixing nearby code, extending behavior the task didn't mention when given to open -ended a request. I haven't seen this that much. I don't know if there's something in my system prompt that's preventing that, but I haven't seen so much of this like model touching things it shouldn't type stuff.
Even when I ask it to, it's often a little more reserved than I would have expected. But if you are seeing that behavior, you can absolutely steer it through your prompts and your system prompts. They say that with the following instruction, unrequested additions and committed test code drop substantially with no measurable change in task success.
If while working or testing, you find pre -existing bugs, performance concerns, or behaviors the task doesn't mention, don't fix, optimize, or extend it in this change unless the requested behavior cannot work without it. Report it as a follow -up in your summary. This is great.
And if you do have this problem, there you go. There's a solution. You can copy paste it and you'll probably have a go away.
There's a small call out about low effort not triggering search. Again, I'm not recommending low effort a whole lot, but if you do have a problem with that, tell it to use search. This section is silly and either won't matter much for you or will matter a lot.
It's how you can reduce false positives with the safeguards. It's advice on wording so that the model doesn't think you're trying to hack and then lock you out. Instead of does this program compile without errors, ask are there bugs in the program?
apparently it's not great with lesser -known programming languages triggering safeguards so you should give it more context about the language and how it works like access to the documentation because once it's in the context it's less likely to explore places it might not need to because it will probably try and hack the binary to figure out what it's doing and then you'll hit a safeguard Another thing that's really bad about is base 64 and outputs that tends to trigger a lot because they probably think you're trying to obfuscate or hide something.
So if you can avoid base 64 ending up in the context, that can help a lot with false positives in your history with the model. I have had almost no false positives with Fable 5 .1, like maybe five total out of the thousands of prompts I've sent it. So not that big a deal, but worth noting these details if you do have problems with that.
the rest here is more for building apps with fable not like coding with fable but building something that uses fable in its core not as important for coding with it there are a couple of last pieces here that are worthwhile though like let the lead agent keep working while sub -agents run this has been really nice i find both astra and fable 5 -1 are really good at this they can delegate work to sub -agents but also do work in that top level agent at the same time instead of just sitting and waiting for the other things to come in it can go do something else it can send messages to the sub -agents it can test findings.
It can figure out what the next step should be. It can do a lot in that time. They also call out that vision work does much better with crop and zoom tools.
It can DIY that stuff using Python scripts locally. So it probably doesn't matter too much for quad code type usage, but worth noting if you're building around it. And now we need to talk about the last big piece.
The one I find the most people are missing that I also think is what set me up for so much success with this model. I think people who have been using a lot of quad code over the last year are missing out a lot. Hear me out.
Claude Code has a lot of Claude Code -isms. Things you have to learn, things you have to work around when you use it. For example, the dumb zone.
I know so many devs that are perpetually in fear that if they don't closely monitor how much context the thread is using, they might hit the dumb zone. And then all the work they did for the day is going to fall apart. They're going to get fired.
They're going to waste all their tokens. The model's not going to get results that work. I'm going to be so real with you guys.
Do you actually think Anthropic, at this point in time, with all of the capabilities, all of the tooling, all of the people they've hired, all of the work they've done to verify all this shit, is going to ship defaults for their flagship model that they want to have perform as well as possible for everything they can do?
That they're going to ship it with a bad window cutoff size? You know the context windows are arbitrarily defined anyways, right? Like if the API allowed, you could send 100 million tokens of context to Fable.
They pick a number based on the behaviors they see. And Anthropic picked 1 million tokens of context because that is the point at which they think you might start to see enough degradation that you shouldn't go further. The dumb zone doesn't matter that much.
The models have gotten pretty damn good at compaction and managing long runs. You might notice something in the T3 code UI. There's no context monitor.
There's nowhere here showing you how much context is being used because it doesn't matter. The models have gotten good at doing these things. They're training them in loops.
They're managing this with all of the context. It's going great. Shout out to Maria for having the balls to remove the context monitoring in T3 code.
She's calling, she's shouting herself out in chat. Figured it's worth shouting her out as well. This isn't the point of trying to make though.
This is just one example. Think through the reservations. When you find yourself doing extra work or taking a step that the model could have done or hitting a button that the model could have hit for you or doing anything that you're doing because you have this mental model of what the models can and can't do, challenge yourself on it a bit.
See what happens if you operate without that belief. I already see so much cope around the stupid window in context management and chat. Guys, Anthropic is good at this.
I don't like saying that. Anthropix engineering quality was shit, but their models are now smart enough that it's making their engineering better. The 1 million token context window is expensive when your costs for reads are expensive because you don't write the whole thing.
You append writes on top of it over time. And if you compact more, you're rewriting context more often. So if you lower the point where you start compacting, you're going to increase your cost.
The fact that they knocked the cache read cost by 75 % basically means the context window size doesn't matter. The one catch being if the cache has expired, which thankfully in tools like T3Chat, we now expose. They have this little resume with less context.
If the 527 ,000 tokens from earlier aren't cached yet, it might be worth compacting quick. That's fine. God, I just, there's so many dumb questions in chat.
I'm trying so hard to be as simple as possible here. Okay, I'm going to say the quiet part out loud. If the things I am saying don't make sense to you or are confusing or you have questions, there's a really simple solution.
Sadly, I can't give my usual solution of ask the model because I have found the models really, really struggle with understanding these things. If you ask Claude how compaction works in codecs, you're going to get a shit answer. I know because people who got that shit answer have been in my replies a lot recently.
The best thing you can do if these things are confusing or concerning to you is don't change the defaults. The only settings I have changed in my quad code config on my machine are I have it full screen by default and I have it route through my proxy layer. That is it.
The defaults in quad code are good enough now. And I promise you, some random shitpost you saw on Twitter isn't more clever than the hundreds of billions of dollars of incredible people and incredible effort going into stuff at Cloud Code and going into the work at Anthropic. Okay, memory is a fair point, actually.
I did turn off memory. I do not like the memory in Cloud Code. I'm sure it is useful in some places.
In some ways, it is not useful for me. There was actually just one really good question, though. This one cuts a little deep for me.
Why does T3 code let you adjust the compaction thresholds? I don't think we have compaction threshold adjustment in T3 code. If you change it in your config, it'll just work with T3 code because we are just using your quad code config from your machine.
We do offer the ability to change from the 200k context in the 1 mil context. The honest reason that we do this is because quad code does too. I'm just trying to expose the options that it exposes.
Generally speaking, I find a lot of people... massively over engineering around problems that haven't existed for at least a year the models are really good at managing their context you don't have to do it for them the harnesses are really good at using the different things on your machine you don't have to set that up yourself the permission systems and the auto approval modes are very good now and you definitely shouldn't use accept edits or supervised we recently added anti -gravity support to t3 code and after all the requests we got to add accept edits mode for anti -gravity Because they can't trust the Gemini models enough and they don't have an auto mode yet.
I was this close to just removing anti -gravity support. Like, supervise and auto accept edits are tools from the past. From like 2024 even, at like newest.
Use auto if you're careful and use full if you're not. Period. The points I'm trying to make here are simple.
The tools are good now. Any customization or careful configuration you've done to work around the flaws. are probably out of date.
And a lot of your own mental model around this stuff is also out of date. Reset it. Pretend you're on a brand new machine.
Delete everything. Install cloud code from scratch. Set it up with as little as possible.
I bet you'll be surprised how capable it is. And from there, slowly start adding small things that solve your small problems. I think I said all I have to on this point.
I hope this one was helpful. It's kind of different from how I normally do these types of videos, less about my specific day -to -day work and more about the philosophical way to take advantage of tools as powerful as these models. Fable 5 .1 was an incremental improvement in how the model works and behaves, but it has become much more than that for my day -to -day work.
I really, really like using this model and I bet you will too. And if you don't like using the model, I'm actually curious why. Let me know in the comments.
And until next time, peace nerds.
The Hook
The bait, then the rug-pull.
Theo opens with the accusation that got him here: first he was called an OpenAI shill, now Sam Altman is calling him an Anthropic fanboy for preferring Fable. Instead of relitigating that debate, he opens Anthropic's own prompting guide and checks it against a month of his own daily use.
Frameworks
Named ideas worth stealing.
05:58list
Effort levels
low
medium
high
x-high
max
Fable 5.1's reasoning-depth dial. Theo defaults to high, reserves x-high for genuinely deep work, and treats low/medium as a false economy on a subscription plan since a failed low-effort attempt usually gets redone on high anyway.
Steal forany Claude Code or Fable-backed CLI's default reasoning setting
37:40concept
End-state prompting
Every prompt should state exactly where the task stops: file the PR and tell me, wait for green then merge, or ask me first if you're unsure. Naming the end state is what lets you stop checking in until the model reaches it.
Steal forany long-running or multi-step agent task
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
A developer who shipped 89 merged PRs in 24 hours breaks down Claude Fable 5.1's pricing, benchmarks and real-world coding behavior against Fable 5 and GPT-5.6 Sol.
Boris Cherny said coding is solved. Matt Pocock called it VC-funded bullshit. Theo argues they're both right, because they're using the word coding to mean two different things.
Theo spends a week testing two rival "skills" repos for AI coding agents, Matt Pocock's 215,000-star collection and Cursor engineer Lauren's PStack, and finds the real value in a handful of specific files, not the whole install.
Theo runs OpenAI's GPT-5.6-Sol through Claude Code instead of Codex and gets visibly better designs and cheaper orchestration — then reads Codex's system prompt on camera to find out why.
Theo reacts line-by-line to Boris Cherny's post arguing that automation — CLAUDE.md rules, lint checks, CI — matters more than ever in the agent era, not less.
00:46
01:17
01:50
02:51
03:22
04:24
04:55
05:27
06:29
07:00
07:31
08:02
08:33
09:05
09:36
10:38
11:40
12:12
12:53
13:30
14:47
15:18
15:50
16:21
16:52
17:23
17:54
18:56
19:28
19:59
20:30
21:01
21:32
22:03
22:35
23:06
23:37
24:08
24:39
25:10
25:41
26:13
26:44
27:15
27:46
28:17
28:48
29:51
30:53
31:55
32:26
32:58
33:29
34:00
35:33
36:04
36:36
37:07
37:38
38:09
38:40
39:17
39:42
40:14
41:18
55:06
33:48
38:21
30:48
28:36
19:12